ReverseEngineering

Data Flow Analysis دنبال کردن مسیر واقعی داده تا اینجا بیشتر تمرکزمون روی این بود که برنامه چه دستور هایی اجرا میکنه ولی از اینجا به بعد یک سؤال مهمتر میپرسیم: داده از کجا میاد و آخرش کجا میره؟ این دقیقا همون چیزیه که بهش Data Flow Analysis میگیم فرض…

Data Flow Analysis Following the actual data path

So far, we have been mostly focused on what instructions the program executes

But from here on, we ask a more important question:

Where does the data come from and where does it end up?

This is exactly what we call Data Flow Analysis

Suppose we have this code:

C++

int calculate(int a, int b)
{
    int x = a + b;
    int y = x * 2;
    return y;
}

If we just look at the order of the instructions, we would say:

First the addition is done
Then the multiplication is done
Then the result is returned

But in Data Flow Analysis, we look at it like this:

a ─┐
├── ADD ──> x ──> MUL ──> y ──> Return
b ─┘

That is, we follow the path of the data itself
Now suppose there are these instructions in the middle of the program:

C++

int temp = 500;
temp ^= 123;
temp += 20;

If temp never affects y or the output of the function, it will not be in the main data path.
Here Data Flow Analysis helps a lot to separate Junk Code from the real logic.
When we see a complex function in IDA or Ghidra, we do not need to memorize everything from beginning to end.
Choose an important value and follow it.

For example, if the input of the function is entered into a register, see:

Where is it copied?

Where is it changed?

Is it stored in memory or not?

Is it passed to another function or not?

And what does it affect in the end?

For example, in assembly, you might see something like this:

Asm

mov eax, edi
add eax, esi
imul eax, 2

If we assume that EDI and ESI are inputs, the data path looks like this:

EDI ─┐
├──> EAX ──> ADD ──> IMUL
ESI ─┘

The important thing is that the name of the register does not mean the data path. A value from RAX may be entered into RBX, then stored in memory, and then again into RCX. Back
If you just look at the register names, you'll get lost very quickly😅

You have to follow the value itself
Sometimes we also call this Data Provenance

That is, find out where a value comes from

For example, a value might come from:

User Input
↓
Buffer
↓
Function A
↓
Function B
↓
Comparison

This approach is especially important when analyzing obfuscated programs
Because obfuscation may clutter the program's execution path, but the data still has to come from somewhere and go somewhere

Exercise:

Examine this function:

C

int process(int a)
{
int x = a;
x = x ^ 0x55;
x = x + 10;

int junk = 100;
junk *= 5;

return x;
}

Draw a path from a to the output on paper

Then determine whether junk enters the main data path

The goal of this exercise is to gradually see not just the instructions when you open a function

See the data moving between registers, memory, and functions

@reverseengine

❤1

44 views20:06