#decompiling

[44dagainagain]

MSVC Boolean Branches (Adventures in Reverse Engineering)

There are many ways of writing the same boolean expression, but some are not the same! Particularly, pay attention to explicit comparisons to TRUE! Anyway, i use this graphic when I get confused about how to decompile something

[44dagainagain]

x87 FPU and SSE (Adventures in Reverse Engineering)

Game: Diablo Pre-Release Demo (1996) Language: C++ Toolchain: Visual C++ 4.0 (suspected)

Take a look at this:

These are x87 FPU instructions (described in Intel® 64 and IA-32 Architectures Software Developer’s Manual, Chapter 8). This roughly corresponds to:

if (gamma_correction >= min_gamma) gamma_correction -= gamma_delta;

However, if you put any floating point math into Compiler Explorer, you won't get the same output! That's because the default mode now is to use the SSE instructions.

Fortunately, you can disable SSE on MSVC using /arch:IA32.

[44dagainagain]

__fastcall (Adventures in Reverse Engineering)

Game: Diablo Pre-Release Demo (1996) Language: C++ Toolchain: Visual C++ 4.0 (suspected)

Calling conventions are something that a programmer rarely thinks about but is very important to code interoperability. It covers things like: do I push all my arguments on the stack? Can I use registers to pass arguments? Who cleans up the stack, you or me? What matters most about calling convention is that both caller and callee agree.

The default calling convention for the Visual C++ 4.0 toolchain seems to be __fastcall. Here's the Microsoft documentation: https://learn.microsoft.com/en-us/cpp/cpp/fastcall?view=msvc-170 In essence: the first two arguments (if they fit in 4 bytes) can use ecx and edx; other arguments go on the stack in reverse order (e.g. the third argument is at the top, followed by the fourth, etc).

But let's look at an example:

The prologue allocates 8 bytes on the stack, then saves ecx (4 bytes) and edx (4 bytes) in that space. It does this so it can reuse ecx and edx later (for indexing monster[])

Calling code looks like this:

What happens if I treat this like a __stdcall? I push my arguments on the stack but ignore ecx/edx so they contain garbage. The function though doesn't look at the stack, it looks at ecx and edx! So undefined behavior. Worst case, the i variable accesses monster beyond its bounds, corrupts memory, and eventually the game crashes.

[44dagainagain]

Was this a macro? (Adventures in Reverse Engineering)

Game: Diablo Pre-Release Demo Langauge: C++ Toolchain: Visual C++ 4.0 (suspected)

One of the tricky things about decompiling is that a lot is lost when the source goes through a compiler:

comments are thrown away

human-readable names are discarded

the preprocessor kicks in and copy-pastes code

variables can be optimized away

In this case, let's look at the preprocessor. The preprocessor runs pretty early on and expands macros into new code. This is indistinguishable from the developer copy-pasting a block of code. Compiler Explorer backs us up here if you look at this sample, both functions produce the same assembly despite seemingly being implemented differently.

So when I see things like this:

or this

or this

Did the developers copy-paste these function calls or did they make a macro?

To some extent, the answer is "who cares". Although it largely depends on what your goals are. If you want source that produces the same binary (which is what I'm doing) then both copy-paste and macros are viable options. If you're aiming to be source exact then... good luck.

For me, compiling to the same binary gives me confidence that I have a working version that I can build on. I don't the same exact source.

[44dagainagain]

How I (want to) make Pre-ablo

Total reverse engineering including decompilation is the holy grail of any mod project where an SDK is not provided.

I'm currently embarking on a journey of totally decompiling the Diablo Pre-Release Demo using Devilution as a reference. After I have the source code, I can make any change I want anywhere I want. I'll be free from the whims of the original DIABLO.EXE that I'm patching. I won't need binary patching, and I won't need DLL hijacking. I won't need to worry about new code throwing off relative offsets, nor will I need to worry about how to jump in and out of patch code; the patch will be seamlessly integrated.

This is a long way off and I make slow progress. I'm currently investigating what my options are for speeding up this process.

[44dagainagain]

How I (used to) make Pre-ablo

Pre-ablo is my mod of the Diablo Pre-Release Demo that aims to be as faithful to the source while allowing it to be played from start to finish. I started it because the only existing mod of the Pre-Release Demo was Alpha4 and, while I enjoyed it, I wanted something with fewer creative liberties. Alpha4 is a new game entirely, I just wanted to play the Pre-Release Demo as it was without crashing!

However, I'm relatively new to the world of decompiling and x86 assembly. I figured the best place to start was the most obvious and I could bootstrap my way from there.

I started with binary patching. It was painful. The workflow looked like this:

Load DIABLO.EXE into IDA. I have a running IDA file where I annotate functions and variables based on Devilution

Identify the broken code. This often requires understanding the x86 assembly, mentally decompiling it to C++, and saving those annotations into the IDA file. Very rarely do I already know exactly what the code is doing, so understanding the code is a large part of this time.

Identify a fix. The best fix is one that doesn't add net new instructions so I tried to favor those. I'd also take some shortcuts which I regret doing later...

Identify where the fix would go. In step 3 I said that I didn't want to add net new instructions. This is largely thanks to the .EXE format. If I add new bytes to the file then all the offsets are now wrong and the game won't work. In these cases I had to repurpose dead code, and figure out how to jump in and out. Every jump is more work down the line...

Turn the fix into asm. My mind works in C++ so I need to mentally translate that into X86 assembly. This is tricky since I'm largely unfamiliar with x86 assembly (though I get better every day)

Turn the asm into machine code. Oh boy this sucked. This sucked so hard. Machine code is meant to be read by the processor, not humans! It ends up being incredibly terse! In addition, x86 has some peculiarities: it uses a multibyte encoding and has a lot of weird edge cases. At one point I switched to using Ghidra to do this for me (but this created its own headaches since I can't use my IDA annotations in Ghidra...). Also I needed to calculate relative offsets to the current instruction pointer...

Insert the machine code into DIABLO.EXE. I did this with a hex editor. By hand. If I made a mistake I'd have to start over.

I made this reproducible by encoding the binary differences using vcdiff. That way, I could take a fresh DIABLO.EXE and reconstruct Pre-ablo by applying the vcdiff patches in order. It also separated the logical changes into a list of discrete patches; changing one patch (usually) had no impact on the other.

This sucked but it worked. I used this approach until v0.4 when I replaced it with something better...

(The "easy way out" was to pay for IDA Pro. Which is several hundred US $. No thanks.)

[goodanswerbiz]

Fix: How do I decompile a .NET EXE into readable C# source code? #solution #computers #dev

Fix: How do I decompile a .NET EXE into readable C# source code? #solution #computers #dev

How do I decompile a .NET EXE into readable C# source code?

I wrote a C# application for a client a couple of years ago, but I no longer have the source code. All I have is the EXE that I deployed on the client’s PC. Is there a way I can generate C# source code from the EXE?

Answer [by GEOCHET]: How do I decompile a .NET EXE into readable C# source code?

Reflector and its add-in FileDisassembler

View On WordPress

[sevennet-blog]

How to: How do I decompile a .NET EXE into readable C# source code?

How to: How do I decompile a .NET EXE into readable C# source code?

How do I decompile a .NET EXE into readable C# source code?

I wrote a C# application for a client a couple of years ago, but I no longer have the source code. All I have is the EXE that I deployed on the client’s PC. Is there a way I can generate C# source code from the EXE?

Answer: How do I decompile a .NET EXE into readable C# source code?

Reflector and its add-in FileDisassembler.

Reflector…

View On WordPress