Reconstructing Original Source Logic

When reverse engineering, especially optimized binaries, our goal is often to understand the original high-level code. This process is called source logic reconstruction.

Compilers transform human-readable code into machine instructions. Optimization makes this harder by rearranging, simplifying, or even removing parts of the original logic. Our task is to reverse this process.

Optimizations can drastically change how familiar programming constructs appear in assembly. For instance:

• Loop unrolling: A loop might become a sequence of repeated instructions.
• Function inlining: A function's code is inserted directly, removing the call.
• Dead code elimination: Unused variables or branches disappear entirely.

This makes direct mapping to source code difficult, requiring us to identify patterns instead.

Loops (for, while, do-while) in high-level languages translate to conditional jumps and backward branches in assembly.

When reconstructing, look for:

• A block of code that executes repeatedly.
• A comparison instruction checking a loop condition.
• A jump instruction that goes back to the start of the loop block.
• An update instruction (e.g., incrementing a counter).

Consider a simple for loop. An optimized compiler might unroll it or simplify its counter. The key is to find the repetitive block and the exit condition.

Try to infer the loop's purpose from the operations inside it:

if and else statements are fundamental for program flow. In assembly, they typically appear as a comparison followed by a conditional jump.

Optimizations might merge conditions or rearrange blocks. Look for:

• Comparison instructions (e.g., cmp, test).
• Conditional jump instructions (e.g., je, jne, jg, jl).
• Two distinct code paths originating from a single decision point.

Here's a basic if-else structure. In optimized assembly, the else branch might be directly after the if branch, with an unconditional jump skipping it if the if condition was true.

When a function is called, arguments are passed and a return value is expected. Compilers use calling conventions to manage this (e.g., registers, stack).

• Stack usage: Observe how much space is allocated on the stack before and after a call to guess argument count.
• Register usage: Certain registers (like RAX/EAX on x86/x64) often hold return values.
• Parameter types: The way an argument is used within the function can hint at its data type.

Identifying custom data structures (like structs or classes) from assembly is tricky, especially with optimizations that might flatten them.

Look for:

• Base pointer + offset: Accesses to memory locations at a fixed offset from a base register often indicate fields within a structure.
• Repeated access patterns: Similar sequences of instructions operating on adjacent memory locations can suggest an array or a series of structure members.
• Initialization patterns: How memory blocks are zeroed out or copied can hint at their size and usage.

Function inlining is an optimization where a function's body is inserted directly into the caller's code, removing the actual call instruction. This improves performance but makes reconstruction harder.

• You won't see a call instruction for inlined functions.
• The inlined code will appear as part of the calling function.
• Look for distinct blocks of code that perform a specific, reusable task to identify potential inlined functions.

Which assembly pattern is most indicative of a loop structure?

Reconstructing original source logic from optimized binaries is a detective's work. We look for patterns and infer intent.

• Identify repetitive code blocks and backward jumps for loops.
• Spot comparisons and conditional jumps for if/else logic.
• Analyze stack and register usage to infer function arguments.
• Look for base pointer + offset accesses to guess data structures.
• Be aware of inlining, which merges function bodies.

Practice and familiarity with compiler output are key to mastering this skill!