This weekend's project was to refresh on assembly language and more specifically disassemblers and decompilers for reverse engineering. It's been a while (early in my career) since I've worked with tools like windbg and ollyDbg, but more recently ildasm, and dotnetPeek. We collect dumps of crashed programs to see what went wrong, especially when it's unmanged code. In the .NET space, we've had to use decompilers to determine the source code since the original some internal team wrote couldn't be found...
It is also useful for reverse engineering any software and malware in particular.
It's great that we have tools like Hack The Box. Crackme.one is one such site specific to cracking.
Windows Sandbox
Because I can't completely trust anything I download from the internet and especially in this context of cracks, I wanted to create a VM to run/debug the downloaded executables. Looks like Windows has a quick and dirty way sandbox feature called Windows Sandbox. I typically use Sandboxie for anything I want to run in isolation that isn't short-lived without the need for virtual machine software. I had initial issues with it starting up due to some port being used, but I worked around it by disabling the network of the sandbox with the following configuration file:
<Configuration>
<Networking>Disable</Networking>
</Configuration>
After creating this you can just double-click on it to start the Sandbox with configuration.
Ever wonder why cracked software may be flagged as a Trojan by anti-virus or anti-malware software? Yes, it could be that there is an actual virus or malware embedded in that cracked software or executable. Even if there wasn't, it would still be flagged since modifying a library (.dll) or executable (.exe) alters the signature of the file and which is probably one of the heuristic checks used.
Better safe than sorry.
2ourc3's 2 - Baby Crackme
Searching crackme.one for an easy one. Note, that all downloads are password-protected zip archives. You could try your hand at cracking them with John the Ripper/Hashcat, but that's not part of the challenge. The password is crackmes.one or crackmes.de as stated on the FAQ page.
Copy and paste the zipped archive to the sandbox window and extract the executable (caesar.exe). This is our first clue as it hints at the possible use of a caesar cipher.
Once the executable is run, it prompts for Enter the key:. You can type whatever in there and the application will close.
x64dbg
Here is a good breakdown of the panes and features of x64dbg. When you drag or open the executable in x64dbg, you have the option to debug through the disassembly. When the debugger starts the address 0007FFED25E951 is where it first pauses.
Each line is an assembly statement:
[label] mnemonic [operands] [;comment]
Clicking run three more times will pause at the actual entry point. This is because I have additional Events selected to break on under Options -> Preferences -> Events . You want to ignore any of the framework libraries' disassembled code such as ntdll and mscvrt.
Taking a look around this can be helpful, especially seeing the call to the caeser function at address 00000000004014F1 to address 0000000000401740 as well as the following line. We can take a look at what those functions do by mousing over those lines or right-clicking ->Follow in Disassembler -> the line in question which will navigate to the address in the CPU pane. You can also highlight the line and press g for graph view.
Notice the <JMP.&exit> call. It is the exit point of the program. I discovered this by stepping through the program as done previously with the initial pauses. I put a breakpoint here. Looking around this area can yield some clues, but if this were a large program, it would be difficult to know where to start looking even at the main entry point. You can search for a specific string by right-clicking on the CPU panel and navigating to Search for -> All user modules -> String references.
Here we see Enter the key:. We can navigate to the address where this is executed by double-clicking on it or right-clicking and selecting Follow in Disassembler. Here we click on the navigated line and enable the graph view to focus on the logic.
Looks exactly what we would expect with a printf followed by the expected string and after the <JMP.&scanf> (read line) we see a call to <caeser.sub_401150>. Double-clicking on this line while in graph-view yields the logic at the address 0000000000401550:
Interesting, the mov operations on bytes might be the key or input we're looking for. Using the dcode online tool for caesar cipher, we can see what Nkrru&Ngiqkxy translates to:
It doesn't take long since the search space is 25 letters (1 taken by the current string). With O(n) being 25 * length_of_input. Ok, so the message is Hello&Hackers.
At this point, I try typing in Hello&Hackers into the prompt:
Well, the program stays open and I see Nkrru&Ngiqkxy printed back out. Looks like the same string array that was noted in the dissassembly. No matter what string I type, the output is the same encoded text. If I try a digit like one of the most common ssh passwords 123456. We see something else:
The non-ASCII symbols (♬ and µ) lead me to believe that the shift in the letters is due to an add operation to the current byte value. Then I try just 1 for the key.
Ok, so the key is just how many letters you want to shift left from A (0). So let's try 6 since we're looking for H in Hello Hackers since & (38) decremented by 6 is (space - 32)
Nice.
Ghidra
Another tool we can use to examine the .exe is using Ghidra and open-source reverse engineering tool created by the National Security Agency (NSA). Another good reason to use a sandbox/VM :).
TODO
Summary
x64dbg is pretty cool.
Don't use caesar cipher as encryption.