0. traffic dump
( stream5.pcap )
CHK <filename> <some binary garbage>
1. "HASH" is a some sort of hash.
I tried very hard to reverse that, but time was limited and I not wanted very much to learn some new artificial assembler nor understanding the VM code.
I took one sample file and generated a lot of it's clones, but they all had
ONE byte different from original file. And then launched a script with a lot
CHK commands with different binary garbage.
2. Guess what?!
"CHK" command returns hash of random 4 bytes of flag-file. The very first of "garbage" bytes is actually an index that determines which 4 bytes we want to get. 2nd and next "garbage" bytes only change the hash value, but not the index of bytes it is calculated from.
It is not necessary to reverse the hash calculation algorithm b/c every 4 bytes of flag-file actually contains one ASCII letter (something like UTF-32) and hash value is not depend on block index but only on block value.
So I enumerated all characters from range 0x20..0x7f and calculated hashes for them
using local server and modifying local flag-file. The only tricky part was 10-th
character which mapped to
0x0A AKA LINEFEED which was a line terminator
and caused the server to stop reading data. Solution was simple - as all client-server
communication in UTF-32, we just send a
0A 01 00 00 instead of
0A 00 00 00 - and it was a valid index, not causing linefeed.
- connect to target
- pass a challenge-response auth
- list files with "LST" command
for each file:
- issue 16 "CHK" commands (one per each letter of flag)
- restore each hash back to letter
all files for this task