I am exploiting weak PPPP encryption here to send all 157,092 possible ciphertexts of the LAN search packet. This allows discovering not only devices using plaintext communications but those using “encryption” as well. A detailed explainer for the key enumeration will be published under https://palant.info/2026/01/05/analysis-of-pppp-encryption/ on January 5th.

I’ve tested this with 40 fake devices: using unencrypted communication, all real-life keys I could quickly find and a number of randomly generated keys. The device IDs were randomly generated. The script consistently detected all 40 devices with between zero and two decryption ambiguities (same device listed with typically two or three possible IDs). This takes approximately 45 seconds for me.

Examples of decryption ambiguities: XBFMG-391344-JQSBU was also listed as XBFMG-391308-JCHBU; WCUHU-188234-BMVVM was also listed as WCUHUS-157514-BMVVM, WCUHUX-137290-BMVVM; XUAAP-705978-XJQMM was also listed as XUAXP-705978-XJTMM; KSCS-900857-TVSUR was also listed as KQCS-900857-TASUR, KDCS-900857-TLSUR.

I tried to see whether tracking which specific request (meaning which specific keys) triggered a response would resolve the ambiguities. As expected, this is not the case: the keys resulting in ambiguous decryptions of the punch packet also encrypt the LAN search packet in the same way.