Translate this hex code

January 16, 2004 5:44 PM

Can someone translate this hex please? [more inside]

The hex is 12413AEB2ED4FA5E6F7D78E78BEDE820945092OF923A40EElOE5IOCC98D444AA08E324, from this oft-emailed tidbit. I'm not sure it means what it says it means.

posted by oissubke to computers & internet (18 comments total)

I'm no hex wizard, but it seems to me that "O" is not a valid hexadecimal character.

Looks like random crap to me.
posted by mr_crash_davis at 5:59 PM on January 16, 2004

Neither is "I".

I second the random crap theory.
posted by mathis23 at 6:05 PM on January 16, 2004

As noted, it's not good hex. But if you translated the remaining characters, you'd get something like:
?A:Ù.È·^o}xþïÝÞ öPÆ:@¯?Õ?¦ÿÈDÒ$
posted by waxpancake at 6:21 PM on January 16, 2004

Agreed, it pretty much looks like keyboard mashing with everything that didn't look like hex digits removed. Note the number of repetitions and near-repetitions.

Hex, for the curious is just hexadecimal, or "base 16". So even if it was a valid hexadecimal number, the result of translation would just be a (rather big) number. This kind of thing is often assumed to be ASCII (a mapping from 1-byte numbers to characters), but it doesn't look like sensible ASCII (taking I and l as 1, and O as 0) either, as the first character for instance is outside of the printable range, and many other characters are above 127 (ascii only defines characters for 7 bit numbers <pedant>(but is still a mapping from 8 bit numbers to characters, only the output is undefined for inputs > 127)</pedant>). It's not UTF8 either, and UTF16 looks unlikely too as it'd be all over the map, character-choice wise.
posted by fvw at 6:27 PM on January 16, 2004

If you take the i for 1 and O for 0, it still represents a number, right? Even if it's not ascii (or any other standard character mapping), there are any number replacement ciphers that substitute numbers for letters.

There don't look to be enough characters to spell out the "translation," but maybe some weird lempel ziv thing could be going on to compact the repeating parts. Not saying it's likely, just that it could be possible.
posted by juv3nal at 7:18 PM on January 16, 2004

To further pedant on fvw's pedantry, some character encodings do use the numbers >127 for special characters. Yes, I'm a geek, why do you ask? ;)

To be more on-topic, I agree with those who say it looks like garbage, plus the original email is just a silly little story/joke; I doubt the author of such a thing would necessarily even bother making the "hex" translate to anything for the sake of a joke. Especially such an obvious one.
posted by cyrusdogstar at 8:44 PM on January 16, 2004

Excellent, at least I wasn't imagining it. I think the correct hex would be something more like:

4f6e65204f5320746f2072756c
65207468656d20616c6c2cda4f
6e65204f5320746f2066696e64
207468656d2cda4f6e65204f53
20746f206272696e672074686
56d20616c6cda616e6420696e2
0746865206461726b6e6573732
062696e64207468656d2e
posted by oissubke at 10:14 PM on January 16, 2004

For the few individuals out there who haven't read the books or seen any of the movies: the e-mail is a spoof on the Lord of the Rings.

As for the hex code: since it's being referred to as 'of an ancient mode' I had a go at using EBCDIC in stead of ASCII for the translation, but again the resulting text seems to be gibberish.

My guess is that the 'hex code' is either a random string of characters, or a string of characters that actually appears somewhere in the Windows XP system information but doesn't mean what the e-mail claims.
posted by rjs at 4:45 AM on January 17, 2004

This goes back to 1996 at least:

http://www.netfunny.com/rhf/jokes/96q1/parody.html

The code seemed fine back then... no L,I, or O.

So let's see... there were all the uploading compression schemes: xmodem, ymodem, zmodem, kermit and one other I can't remember. And there were the binary encoding formats: base64, uuencode, mime, and binhex for the Macs. And there is of course the file compression schemes like arj, rar and zip. Could be any of 'em. Where any of those spondered by Microsoft?
posted by jwells at 7:26 AM on January 17, 2004

Oops. "sponsored"... gotta remember to spell check.
posted by jwells at 7:27 AM on January 17, 2004

Alright, let's waste some more time analysing what this can't be.

I don't actually thing any of xmodem, ymodem or zmodem did compression. xmodem just did CRCing, ymodem in addition did filename transfers (for batching) and zmodem did resuming and retransmitting. There'd still have to be valid encoded stuff after the headers, so those three are right out.

Next, Base64, uuencode and binhex all convert files to only printable (ascii) characters, so they're out too. Mime isn't an encoding, it's more of a wrapper thingy, so that's out too.

It could be arj, rar, zip (or gzip), but seeing as there aren't any proper headers, the data would at best be very incomplete.
posted by fvw at 9:05 AM on January 17, 2004

you could try running it through a x86 disassember and seeing if it looks sensible (not sure you could tell, since there's so little data, unless it happened to do something so obvious that you'd see ascii text in there anyway).
posted by andrew cooke at 10:21 AM on January 17, 2004

if this helps anyone get the data (from the 96 link) into a file (i've had to add a zero to get an even number of digits):

[andrew@ctioyn ~]$ cat tobin.py
import binascii
dta = binascii.a2b_hex("012413AEB2ED4FA5E6F7D78E78BEDE8209450920F923A40EE10E510CC98D444AA08E1324")
print dta
[andrew@ctioyn ~]$ python tobin.py > foo
[andrew@ctioyn ~]$ hexdump -C foo
00000000 01 24 13 ae b2 ed 4f a5 e6 f7 d7 8e 78 be de 82 |.$....O.....x...|
00000010 09 45 09 20 f9 23 a4 0e e1 0e 51 0c c9 8d 44 4a |.E. .#....Q...DJ|
00000020 a0 8e 13 24 0a |...$.|
00000025
posted by andrew cooke at 10:38 AM on January 17, 2004

Ooh, good idea on the assuming x86 machine code. Ok, let's try.
First, with the 0 prepended like andrew did: Total gibberish (doesn't initialise the registers it uses, access memory all over the map)

With 0 appended instead: Gibberish once again, second instruction does a short jump beyond the end of the snippet.


changing alignments (chopping off first byte or bytes) doesn't do much good either, though the version with the first 1 chopped off manages to be slightly obsessed with AL, ANDing it with 0x13, then comparing it to [ES:DI] (which are and is unitinalised). Then it copies the next (or previous, once again undefined) word to somewhere undefined, and then as a grand finale OUTs whatever was still in AL to port 0xF7. Then once again degeneration into (even worse) gibberish.

You know, I'm beginning to think the string might not mean anything at all. So, who's got another suggestion for ways to interpret it?
posted by fvw at 11:59 AM on January 17, 2004

from a strick cryptography point of view this would have to be more than a substitution cypher (a=01, b=02, etc..) because the lowest number is 18 and the highest is 250... far too many letters in that alphabet. There would also be 31 unique "letters" which is 5 too many. Add in punctuation and it's possible but unlikely for such a short "sample" to have that many letters.

Perhaps this?

http://www.xent.com/FoRK-archive/july98/0331.html
posted by jwells at 12:07 PM on January 17, 2004

Also note it's probably not encrypted, as, besides it not making sense in the context of the story, the snippet is pretty low entropy, while almost all modern symmetric ciphers have very high entropy ciphertexts (and the ones that don't and are still worth their salt balloon the ciphertext up to longer than the plain text, which would mean with a ciphertext this short there'd hardly be any plaintext at all).

(I'm really have way too much fun with this)
posted by fvw at 12:15 PM on January 17, 2004

jwells: I don't see any correlation between the COM CLSID listed there and the original snippet. Am I missing anything? (Also: COM CLSID's are just OSF DCE UUID's, which means they're supposed to be random. Any meaning would have to be attached after generation...)
posted by fvw at 12:20 PM on January 17, 2004

lol... I agree fvw. I'm betting each disc had a unique CLSID so in the post above that author was posting their own CLSID whereas the author of the LOTR posting may have used their own CLSIDs. Since their unique they won't match. It's just another idea. I did count the number of characters in the CLSID and it was 32, whereas the code is 71 characters long. So the CLSID idea doesn't really explain it away either unfortunately.

And if we are dealing with CLSIDs I don't think there would be any meaning to it. They person who wrote up the post just grabbed a disc and wrote it in calling it "Hex, of an ancient mode, but the language is that of Microsoft". We're probably chasing after nothing. Good practice though :-)
posted by jwells at 12:47 PM on January 17, 2004