Hi, I have never really use a debugger /disassembler before (except online disassembler), so this is a new experience for me to try WinDbg!

Today I am going to disassemble my own program, called msgbox.exe, written also in fasm.


Example msgbox.exe to debug / disassemble

First, download the WinDbg and launch it:


Download debugging tools from Windows SDK


Start menu items of WinDbg after installation


Open WinDbg(x64)

Then, browse to msgbox.exe and open it.


Open executable (msgbox.exe)

But funny it didn't show a PE header analysis, I have to download a separate PEDump to find which memory to dump.


Run PEDump tool to find code section entry point

Finally, we got the address: 0x402000, so let's disassemble it.


View disassembly


Spot on!

It looks exactly like the source code!


I know quite a few sifu here, know better in anything disassembly, e.g. junyian, angch and cikelempadey.

I think I used the wrong tool to disassemble msgbox.exe, because it doesn't bring me directly to the code section of the executable.
Enlightenment please?


PEDump tool: forum.lazarus.freepascal.org/index.php?topic=46617.0

Windows SDK: developer.microsoft.com/en-us/windows/downloads/windows-sdk/

Whoops, the X64 disassembly is not correct, especially the first line (push 0x40), so I try WinDbg X86 and this time is correct:



Strange, I didn't know have to use 32-bit debugger to load 32-bit EXE.

Get with the times. We use Ghidra now.





This post has been edited by angch: Jan 17 2023, 09:57 AM

I see, thank you for including my cpuid.exe in your example screenshot!
I am thrilled.

Ghidra is open-source, part of NSA project. I have just tried it and it disassembles better than WinDbg.

At least it has PE header analysis, can click to go directly to different section of the executable, and it even try to create the source code in high level language.

But I don't like they use "dragon" as wait cursor though.

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

Thanks for chiming in. Silly me, now only I know the difference between debugger and disassembler.

I noted you use x64dbg for debugging, and IDA + Ghidra for dissasembling.

Someone revealed to me there is also cutter (github.com/rizinorg/cutter), a "Free and Open Source Reverse Engineering Platform powered by rizin", but I didn't try it, I thought I want to try the major tools first.

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

I am pening looking at the conditional jumps, its arrow and table. Better to look directly at code.

The CPUID has window message loop, which is standard either in C++ or Assembly, I just borrowed from one of the example source code, the only part I added myself is...



and the code to call "cpuid" thrice.

And a big thanks for downloading my cpuid.zip.

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.

Thanks for sharing some of the feature of IDA Free, it is amazing users are able to rename location labels.

Since I have started my initial attempt to use Windows Debugger and Ghidra, I might want to start trying FlareOn challenge, like last year #2 challenge, where I failed to capture the flag of corrupted PE file.

I will need your help once I started on it bit by bit, but I might revive the FlareOn challege 7 thread (by WestKid), or may ask question on this thread.

What tools do I need besides Ghidra to solve last year challenge #2? The EXE seems like a "packed executable"(I forgot the proper term to use here to describe the state of the EXE).

Sorry, it is already new year, then I mean year 2021 challenge.

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.

After I checked, the challenge file is garbage.exe, from FlareOn 7.
It is a good habit that you jot down notes while solving it, I think I must do the same also.
May I know do you normally disassemble them in virtual machine so that it won't cause harm to the host OS?
What tools are needed to solve challenge like garbage.exe? Thanks in advance.

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.

I open garbage.exe in CFF Explorer:



It shows the Import Directory RVA and Relocation Directory RVA are incorrect.
Do I just need to fix these two addresses?

Actually I read its solution before, but almost forgot everything.
If not mistaken, must also rebuild its resource section (since now it is blank).

Anyway, I will wait for your guidance after CNY, happy holiday!


For those who are interested:
CFF Explorer: ntcore.com/?page_id=388

I able to recover portion of the resource section, by editing the raw size value.


At least now Resource Editor shows some data instead of blank

But UPX Utility still not able to unpack:

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.

I think reverse-engineering involves a lot of guesswork, rebuilding import table, huh? I can only know the few basic ones, like kernel32.dll, user32.dll, vcruntime140.dll, I don't know others wor....

Reverse-engineering is a complete different game from normal programming, I know can learn, but I feel like giving up.

Thank you for explaining to me without revealing the details, at least I know reverse-engineering is a skill not commonly pursued, it is good that you and your friend know about malware analysis. Proud of you.

This post has been edited by FlierMate4: Feb 3 2023, 06:09 PM

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.