Sept. 25: autodialer finds NATO phonetic message at 99280.
- five clicks before code
32330A is 23\n
The first three bytes, 32 33 0A, are ASCII for the number 23 followed by a line break. There are 23 more bytes in the message, so this is just a length field, and the actual message is:
7F FE CA 26 B6 3E D8 D5 61 8E 59 95 69 6F 8C C8 E5 B5 DF BD FA 84 9C
This also implies that the four-character groups in the spoken version are not pertinent (because the length field cuts across them).
Various simple things have been tried:
- xoring 31, 0x1F, etc (the "salt")
- reversing the string, or bits of the string
- treating the hex as a simple substitution
- taking out the numbers from the hex, just looking at the letters
This probably isn't a simple cipher. The 23-byte payload is pretty close to random.
The popular theory for what this means is that it's a clue to the password for the truecrypt file retrieved from the Blue Hill dead drop.
People have tried using the message directly as a password, both as hex and raw bytes; also tried appending another byte to the end.
The message can be decoded as Unicode to get a bunch of Chinese characters. This is coincidence: most random strings do that. They don't mean anything in Chinese.
Several people who know about cryptography have got hung up on the "SALT 31" at the end of the message.
It's probably not relevant. Salts are a thing in cryptographic jargon (specifically hashes), but a "salt" appears in all messages from these guys, even the ones that are just plain ASCII, so they probably aren't using it in that sense of the word.
otp.txt / p1.txt etc
There's probably no link to the otp.txt/p1.txt etc files, since those are working with letters rather than binary.
People have tried interpreting the bytes as offsets within otp.txt. No joy.
23 bytes is 7 + 8 + 8 = 56 + 64 + 64 bits. Tried treating the first 7 bytes as a DES key with the parity bits removed, and the rest as two DES-encrypted blocks. It was a long shot. It didn't work.
The first two bytes, 7F FE, are 01111111 11111110 in binary.
[13:19] <chronomex> oh motherfucker [13:19] <kicktd> ? [13:19] <chronomex> I got 3233. [13:19] <wd-sa> !!! [13:19] <wd-sa> really? [13:20] <chronomex> yes [13:20] <chronomex> code here http://www.rafb.me/results/UzHhFY16.html [13:20] <chronomex> if you xor the 23 bytes after 32330a with the last 23 bytes of data.bin [13:20] <chronomex> you get /44.918216/-95.6284865/
- Also note that NEW drop location is located exactly in the middle of previous drops.
Drop 1 DROP/45.4240/-122.6675/0-8160-4195-4/PG272//
Drop 2 DROP/44.4124/-68.5897/PAYPHONE///
(45.4240 + 44.4124) /2 = 44.9182 (-122.6675 + -68.5897) /2 = -95.6286
Drop 3 /44.918216/-95.6284865/