File : https://drive.google.com/open?id=0B_TlESfLlYGQY05TWmlNSHhXS1k
Unfortunately, we didn't manage to solve this question while at the competition. So to redeem the 'sin' here is the write-up.
We had been given a somewhat raw file (encrypt.bin), which it size around 1GB++ size.
file' command doesn't give us something good.
So back to the basic! View it using any hex editor.
There is a lot of As characters there. If you scroll much further, you will see that there is a lot of chunk of bytes with As characters.
Maybe this file had been xored with an A characters before? This makes sense because if the original file has a lot of zero bytes, and if all of that zero bytes is xor with an 'A' character, the result will always going to be an 'A' character also. This assumption works on a lot of files, but not all (it will not work to the file containing randomly generated bytes).
However, we also have another problem. On the internet, a lot of xor-decoding tools can't handle such a big file in order to xor it back to original file. Most of the tools that I tried will throw a "Memory exhausted"-something like that error before the operation finished. My early assumption is that most of the tool stored the resultant xored bytes into the memory before it writes to the disk.
So, how can we deal with that problem? We write our own decoding program. It shouldn't be that hard.
Let's look again,
We have the code, compile & then run it,
Take a look again at the 'out.bin' file using Hex editor.
You must be kididng me!!! (pun intended) The header now shows 'KDMV' and it contains some junk data below it!!!
So run the `file` command again,
It is then obvious now.
With no further ado, load it up using Virtualbox.
While the Virtualbox load it up, this loading wallpaper appears,
What a memory!!
After the desktop appears, there are flag.txt inside it. Could it contain the flag? (tradam-dam-dam)
So finally! We have the final flag `do_you_like_ransomware?`.
Till we meet again. :)