Attributed metadata history

Analysis of PPPP “encryption”

My first article on the PPPP protocol already said everything there was to say about PPPP “encryption”: Keys are static and usually trivial to extract from the app. No matter how long the original key, it is mapped to an effective key that’s merely four bytes long. The “encryption” is extremely susceptible to known-plaintext attacks, usually allowing reconstruction of the effective key from a single encrypted packet. So this thing is completely broken, why look any further? There is at least one situation where you don’t know the app being used so you cannot extract the key and you don’t have any traffic to analyze either. It’s when you are trying to scan your local network for potential hidden cameras. This script will currently only work for cameras using plaintext communication. Other cameras expect a properly encrypted “LAN search” packet and will ignore everything else. How can this be solved without listing all possible keys in the script? By sending all possible ciphertexts of course! TL;DR: What would be completely ridiculous with any reasonable protocol turned out to be quite possible with PPPP. There are at most 157,092 ways in which a “LAN search” packet can be encrypted. I’ve opened a pull request to have the PPPP device detection script adjusted. Note: Cryptanalysis isn’t my topic, I am by no means an expert here. These issues are simply too obvious. Contents Mapping keys to effective keys Redundancies within the effective key ASCII to the rescue How large is n? How many ciphertexts is that? Understanding the response Mapping keys to effective keys The key which is specified as part of the app’s “init string” is not being used for encryption directly. Nor is it being fed into any of the established key stretching algorithms. Instead, a key represented by the byte sequence b1,b2,…,bnb_1, b_2, \ldots, b_n is mapped to four bytes k1,k2,k3,k4k_1, k_2, k_3, k_4 that become the effective key. These bytes are calculated as follows (⌊x⌋\lfloor x \rfloor means rounding down, ⊗\otimes stands for the bitwise XOR operation): k1=(b1+b2+…+bn)mod  256k2=(−b1+−b2+…+−bn)mod  256k3=(⌊b1÷3⌋+⌊b2÷3⌋+…+⌊bn÷3⌋)mod  256k4=b1⊗b2⊗…⊗bn \begin{aligned} k_1 &= (b_1 + b_2 + \ldots + b_n) \mod 256\\ k_2 &= (-b_1 + -b_2 + \ldots + -b_n) \mod 256\\ k_3 &= (\lfloor b_1 \div 3 \rfloor + \lfloor b_2 \div 3 \rfloor + \ldots + \lfloor b_n \div 3 \rfloor) \mod 256\\ k_4 &= b_1 \otimes b_2 \otimes \ldots \otimes b_n \end{aligned} In theory, a 4 byte long effective key means 2564=4,294,967,296256^4 = 4{,}294{,}967{,}296 possible values. But that would only be the case if these bytes were independent of each other. Redundancies within the effective key Of course the bytes of the effective key are not independent. This is most obvious with k2k_2 which is completely determined by k1k_1: k2=(−b1+−b2+…+−bn)mod  256=−(b1+b2+…+bn)mod  256=−k1mod  256 \begin{aligned} k_2 &= (-b_1 + -b_2 + \ldots + -b_n) \mod 256\\ &= -(b_1 + b_2 + \ldots + b_n) \mod 256\\ &= -k_1 \mod 256 \end{aligned} This means that we can ignore k2k_2, bringing the number of possible effective keys down to 2563=16,777,216256^3 = 16{,}777{,}216. Now let’s have a look at the relationship between k1k_1 and k4k_4. Addition and bitwise XOR operations are very similar, the latter merely ignores carry. This difference affects all the bits of the result but the lowest one, no carry to be considered here. This means that the lowest bits of k1k_1 and k4k_4 are always identical. So k4k_4 has only 128 possible values for any value of k1k_1, bringing the total number of effective keys down to 256⋅256⋅128=8,388,608256 \cdot 256 \cdot 128 = 8{,}388{,}608. And that’s how far we can get considering only redundancies. It can be shown that a key can be constructed resulting in any combination of k1k_1 a

This record contains metadata and attribution only. It does not host, download, unpack, render, or execute malware samples.