Agent Systems/Investigation/3233 code

From otp22 db
Jump to: navigation, search
Investigation This is an investigation subpage.

The information found here includes bleeding-edge updates, information dumps, and speculation.
The factual/summarized article for this page is: Agent Systems/Investigation
Be sure to separate different subjects here using a new section and subtopics using ===Subsections===.


Sept. 25: autodialer finds NATO phonetic message at 99280.

Phonetic message

Original code: 3233 0A7F FECA 26B6 3ED8 D561 8E59 9569 6F8C C8E5 B5DF BDFA 849C

Mhtfa.jpg - 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).

simple ciphers

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.

Truecrypt password

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.

salt, hashes

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.

Chronomex solution

[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
[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 mirrored at Chronomex 3233 py code)


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/