WinDbg is a debugger. It's not a disassembler, even though it has some level of capability of doing that. Personally I find WinDbg quite hard to use, but I do know it's very powerful, and can do windows kernel debugging. For user level app debugging I normally use x64dbg.

Ghidra and IDA are proper disassemblers. I personally use IDA Free and Ghidra as a mix since there are some complementary features between both. There's also Radare and Binary Ninja, but I never really tried to use these before.

Your CPUID loaded in IDA Freeware with default settings.


And the 2nd half of the disassembly where you had the conditional jumps.


This post has been edited by junyian: Jan 17 2023, 10:50 PM

Cutter is actually the GUI version of Rizin, which is a fork from Radare (forked due to some disagreements between the developers, apparently).

Disassemblers normally come with built-in debuggers. IDA and Ghidra have it. If I'm lazy I'll resort to using IDA's debugger. But if I need some more advanced features then x64dbg is my preferred one. For linux, I tried GDB, but failed miserably... haha. If needed, I will use edb-debugger.

This post has been edited by junyian: Jan 17 2023, 11:00 PM

IDA have the text mode disassembly also. Modern disassemblers will have the graph mode these days. It makes it easier to look at thousands of assembly lines with loops/conditional jumps/nested loops/nested jumps, etc.

This is now showing the capabilities of a proper disassembler. Where you can rename locations to something more readable (I used the same names as your ASM source). And just like Ghidra, there's also a decompiler to try translate this back to C-like code.

Year 2021 Challenge 2? I checked my previous notes and I'm sure that file's PE header is not corrupted. Is this with the title "Known" and executable file "UnlockYourFiles.exe"?
Year 2021 Challenge 7 (spel.exe) is definitely challenging, though not as hard as Challenge 9. This one is not really a packed executable. There is an encrypted/embedded binary file which gets unloaded/decrypted at run-time... and that's just part of the challenge. There's still more to it after getting the embedded binary dumped.

I don't remember trying garbage.exe yet. Haha. But if it's really a corrupted exe, just a disassembler is not enough. I'd use a PE editor like CFF Explorer Suite too. Dealing with corrupted PE seems a bit hard for a 2nd challenge. I'll take a look after CNY.

And yes, I do use a dedicated VM for this.

Here's what I did, roughly. So I don't spoil your fun
I used CFF Explorer and PE-Bear:-
- CFF Explorer is old and was not updated for many years. But there are some features that I like which I couldn't find in other newer PE editors
- PE-Bear is much newer, and still regularly updated.

The resource section you found is the first step. But you should know that this incomplete XML is useless, and is not critical for an exe to be recognized as a valid PE file by Windows. So you can safely delete this resource ID. The more important thing is the import directory. As long as this is corrupted or not formed properly, Windows cannot load the exe. When recreating unpacked/decrypted exes/dlls, rebuilding the import table is a common step. You can see that after fixing the .rsrc section, the import table is empty. So you can use CFF Explorer to add your own import table into this.

After that, the exe should be recognized by UPX and you can unpack it nicely. But the exe still can't execute properly again. There's still something wrong with import table, which can be fixed easily by renaming the dll that it's supposed to load. After that we can run the exe and get this.

Rebuilding the import table is not as difficult as you might imagine. No matter how the binary is changed, it need to preserve the final import table somehow. For this one, I'm doing just enough for the OS to successfully load the PE and pass the execution back to it. And continue debugging from there to get the original import table. In this case, all I did was to add ExitProcess from kernel32.dll (the 32 bit version, since this is a 32 bit executable). We can still discuss the details on discord if needed.

Guesswork is always part of the game. But this is educated guess. The way I solved this challenge is probably not the only way. There might be easier methods used by others. All in all, it still did take me about 5 hours to solve this. So I think I'm considered quite slow.