8.7. ENCRYPTED DATABASE CASE #1
It seems, first and fifth byte are changed each time. I finally concluded that the first 32-bit integer is just
OrderID from theXMLfile, and the second 32-bit integer is also OrderID, but negated. All other 8 bytes are
same for each operation. Now I have decrypted the whole database:https://raw.githubusercontent.
com/DennisYurichev/RE-for-beginners/master/examples/encrypted_DB1/decrypted.full.txt.
ThePythonscriptusedforthisis:https://github.com/DennisYurichev/RE-for-beginners/blob/master/
examples/encrypted_DB1/decrypt_blocks.py.
Perhaps, the author wanted each block encrypted differently, so he/she used OrderID as part of key. It
would be also possible to make different AES key instead ofIV.
So now we know thatIVonly affects first block during decryption inCFBmode, this is feature of it. All
other blocks can be decrypted without knowledgeIV, but using the key.
OK, so whyCFBmode? Apparently, because the very first AES example on CryptoPP wiki usesCFBmode:
http://www.cryptopp.com/wiki/Advanced_Encryption_Standard#Encrypting_and_DecryptingUsing
AES. Supposedly, developer choose it for simplicity: the example can encrypt/decrypt text strings with
arbitrary lengths, without padding.
It is very likely, program’s author(s) just copypasted the example from CryptoPP wiki page. Many pro-
grammers do so.
The only difference thatIVis chosen randomly in CryptoPP wiki example, while this indeterminism wasn’t
allowable to programmers of the software we are dissecting now, so they choose to initializeIVusing
Order ID.
Now we can proceed to analyzing matter of each byte in the decrypted block.
8.7.7 Structure of the buffer
Let’s take first four decrypted blocks:
00000000: 0D 00 FF FE 46 00 52 00 41 00 4E 00 4B 00 49 00 ....F.R.A.N.K.I.
00000010: 45 00 20 00 4A 00 4F 00 48 00 4E 00 53 00 66 66 E. .J.O.H.N.S.ff
00000020: 66 66 66 9E 61 40 D4 07 06 01 fff.a@....
00000000: 0B 00 FF FE 4C 00 4F 00 52 00 49 00 20 00 42 00 ....L.O.R.I. .B.
00000010: 41 00 52 00 52 00 4F 00 4E 00 CD CC CC CC CC CC A.R.R.O.N.......
00000020: 1B 40 D4 07 06 01 .@....
00000000: 0A 00 FF FE 47 00 41 00 52 00 59 00 20 00 42 00 ....G.A.R.Y. .B.
00000010: 49 00 47 00 47 00 53 00 00 00 00 00 00 C0 65 40 I.G.G.S.......e@
00000020: D4 07 06 01 ....
00000000: 0F 00 FF FE 4D 00 45 00 4C 00 49 00 4E 00 44 00 ....M.E.L.I.N.D.
00000010: 41 00 20 00 44 00 4F 00 48 00 45 00 52 00 54 00 A. .D.O.H.E.R.T.
00000020: 59 00 48 E1 7A 14 AE FF 68 40 D4 07 06 02 Y.H.z...h@....
UTF-16 encoded text strings are clearly visible, these are names and surnames. The first byte (or 16-bit
word) is seems string length, we can visually check it.FF FEis seems UnicodeBOM.
There are 12 more bytes after each string.
Using this script (https://github.com/DennisYurichev/RE-for-beginners/blob/master/examples/
encrypted_DB1/dump_buffer_rest.py) I’ve got random selection of thetails:
dennis@...:$ python decrypt.py encrypted.xml | shuf | head -20
00000000: 48 E1 7A 14 AE 5F 62 40 DD 07 05 08 H.z..b@....
00000000: 00 00 00 00 00 40 5A 40 DC 07 08 18 .....@Z@....
00000000: 00 00 00 00 00 80 56 40 D7 07 0B 04 ......V@....
00000000: 00 00 00 00 00 60 61 40 D7 07 0C 1C ......a@....
00000000: 00 00 00 00 00 20 63 40 D9 07 05 18 ..... c@....
00000000: 3D 0A D7 A3 70 FD 34 40 D7 07 07 11 =...p.4@....
00000000: 00 00 00 00 00 A0 63 40 D5 07 05 19 ......c@....
00000000: CD CC CC CC CC 3C 5C 40 D7 07 08 11 .......@....
00000000: 66 66 66 66 66 FE 62 40 D4 07 06 05 fffff.b@....
00000000: 1F 85 EB 51 B8 FE 40 40 D6 07 09 1E ...Q..@@....
00000000: 00 00 00 00 00 40 5F 40 DC 07 02 18 .....@@....
00000000: 48 E1 7A 14 AE 9F 67 40 D8 07 05 12 H.z...g@....
00000000: CD CC CC CC CC 3C 5E 40 DC 07 01 07 ......^@....