I'm looking at part of an exercise, which tells you that you have managed to 'sniff' an amount of code from an encrypted application.
It gives you this in the format
0000 0000 0000 0000
where each character is between 0-F. The last two of each four is always 00 or 80. There are also batches of the four that repeat themselves. It hands you a clue, which I suspect may be the unencrypted 'key', this is just a plaintext phrase. I think it is meant to be 128 bit AES but as I say I'm just new to this so am just thinking out loud really. From reading around, it appears the data won't naturally translate to characters because it is binary.
I've tried a few things like knocking off the 00 and 80 in case they were padding, and then using hex editors and ascii converters to get some sort of text but it all ends up in a dead end loop of alphanumeric characters.
I don't want the direct answer, but can anyone give me a little hint or anything I can read which will be helpful in uncovering what I need to do?
Thanks
differential cryptanalysis
Dont look into differential crypto. What a waste of time for a practical question.
You're on a 32 hex-character (or 128-bit) cryptography utility. Due to the fact that 4 characters act as a header and footer, that's 28 characters or 112 bits.
DES and Triple DES (DES3) are your only common 56-bit encryptors. And 56*2 = 112, so look into splitting the body of your sniffed data into 2 equally sized portions and go from there.
0000 0000 0000 0000 becomes…
HH AA AAAA BBBB BB FF
H = header
A = body, 1st half
B = body, 2nd half
F = footer
Good luck.
Dont look into differential crypto. What a waste of time for a practical question.
You're on a 32 hex-character (or 128-bit) cryptography utility. Due to the fact that 4 characters act as a header and footer, that's 28 characters or 112 bits.
DES and Triple DES (DES3) are your only common 56-bit encryptors. And 56*2 = 112, so look into splitting the body of your sniffed data into 2 equally sized portions and go from there.
0000 0000 0000 0000 becomes…
HH AA AAAA BBBB BB FFH = header
A = body, 1st half
B = body, 2nd half
F = footerGood luck.
Thanks for the advice ) I will give this a go as I think I've stumbled to another dead end. The actual block of data is
20 lines long of 0000 0000 0000 0000, so it's not just one line; e.g. an excerpt like this
3480 3280 3780 3700
1000 2200 3080 3d80
1000 2480 3780 3900
1080 680 500 3780
I now suspect it is an SMS message, and have been looking at GSM 7 encoded. One thing I can't figure out is why in the lines two blocks have one character less. I'm trying to wrap my head around working backwards through GSM 7 but am hitting brick walls.
Anything further to add I can check later while I explore your previous comments?
Thanks for the help, appreciate it.
You stated that the exercise says this is an encrypted application. Assuming it is a Windows based application the header would then be 4D 5A in plaintext.
You now have some known plaintext.
Not necessarily.
An executable can be loaded into memory and run in its encrypted or decrypted form with a bootstrap program.