Hashing and Hidden Characters

The dangers of command line hashing and helpful tools

I was sitting in a training class the other day, learning about hashing. The instructor ran a demo on the screen of the below command.

1
2
C:\Users\student\Desktop\md5deep-4.4>echo koala | md5deep64
340fa0664ec760eadddf2216bb8bc1d5

One eagle-eyed student asked an inisghtful question, absolutely showing off his critical thinking skills (ok, ok, it was me, and I only asked it in my brain).

“In windows, does the space between koala and | matter?”.

Being a naturally lazy lad, I can’t be bothered downloading and installing md5deep64, so I crack open the amazing CyberChef. I type koala into the input box, and add the MD5 recipe, as shown below.

The hash of koala in CyberChef

Success! Those hashes don’t match, so the space between koala and pipe must have been included in the hash input. Heck, we’ve already got cyberchef open, let’s do a sanity check while we’re here (the pipe looking character after koala is actually a flashing cursor, showing there’s a space there)

The hash of koala with a space in CyberChef

Hoo- wait, what? That’s a different hash again. Fine, damn our laziness, let’s go find md5deep and do our own testing. First, we replicate the condition we’re testing for:

1
2
C:\Users\student\Desktop\md5deep-4.4>echo koala | md5deep64
340fa0664ec760eadddf2216bb8bc1d5

Hooray! It matches. Aight, let’s get rid of the space, see if our hash changes

1
2
C:\Users\student\Desktop\md5deep-4.4>echo koala|md5deep64
fa453c56d2590383aac34119a707ad35

Starting to feel like a pokemon master collecting all these hashes. Fine, let’s see what’s actually getting passed to md5deep64 when we pipe it through. I know in the below command I’m also replacing pipe (|) with a redirect to disk (>), but we’ll test out to make sure that doesn’t break it later.

1
2
3
4
C:\Users\student\Desktop\md5deep-4.4>echo koala > myfile.txt

C:\Users\student\Desktop\md5deep-4.4>type myfile.txt
koala

So far so good. Let’s crack open myfile.txt in a hex editor (HxD for me) and see exactly what made it to disk:

HxD view of myfile.txt

Referencing an ASCII table, we can see the characters 6B 6F 61 6C 61 map to k o a l a, so we’re on the right track. 20 maps to space, so boom! we’ve answered our initial question (is the space included to be hashed). But what are these other crazy characters - 0D 0A. Looking at the ASCII table, they map to carriage return and line feed respectively. This is basically what computers record when you hit enter in a document.

History time! Think of an old school typewriter, first the “carriage” has to return to it’s starting position (when you type, it moves right along the page, so it’s returns to it’s leftmost position). Then we feed in a new line of paper (because otherwise we’d type over what we just typed). So, 0D, carriage return, 0A, line feed, new line.

We solved it! … or did we? We’ve still made some changes, and need to prove they didn’t introduce these changes separate from the hashing issue. Validation time!

Converting the hex to ASCII, then hashing it

This recipe is effectively taking the hex values we enter, converting them back into ASCII, then hashing the output. And we can see our original hash! Looks like echo in Windows adds a new line (a 0D 0A) after it’s finished printing to make it look prettier on the command line. Thanks Windows!

Licensed under CC BY-NC-SA 4.0
Built with Hugo
Theme Stack designed by Jimmy