Reverse Engineering tip Variables

One of the main points about reverse engineering is that you won’t be able to really get back to source code 100 %. This is why when your analyzing malware it’s good to try multiple different methods. Stuff like dynamic analysis can help. Dynamic might help you get to an unpacked state of the malware. And then you can do static analysis in a reverse engineering tool. That has been the main point so far in reading Practical Malware Analysis book. You want to quickly get to the main picture, and not spend too much time chasing needle in the haystack.

Get Ruben’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

In this article I will focus on something I noticed about variables. I was following a c++ tutorial and in it we deal with pointers. Below is an example of code that creates a pointer holding an array.

#include<iostream>
using namespace std;

int main()
{
 //const int ARR_SIZE = 5;
 int ARR_SIZE;
 cout << "Specify Array Size" << endl;
 cin >> ARR_SIZE;
 int* myArray = new int[ARR_SIZE];
 for (int i = 0; i < ARR_SIZE; i++)
 {
  myArray[i] = i * 2;
 }

 for (int i = 0; i < ARR_SIZE; i++)
 {
  cout << myArray[i] << endl;
 }

 delete[] myArray;
 return 0;
}

Now one would think when you compile this you might see only one variable of the array. However this is not the case. I thought maybe it’s because the PDB file wasn’t being loaded to show debug information with my executable. But the PDB was being loaded by IDA and Binary Ninja. This shows that even with a PDB file don’t expect to see your variable names. This was very surprising to me because I thought that PDB files would contain all your custom variable names you would use in the source code. That is unfortunately not the case. In Binary ninja I saw the ARR_SIZE but not myArray. IDA was able to show us myArray on the stack. I didn’t even need to dynamically run it in IDA to see myArray.

In Binary Ninja I labeled the variables. We can see ARR_SIZE gets moved into var_30. In another area we see var_60 moved around, and eventually it gets put into a variable which i labeled as myArray. Unfortunately binary ninja even with PDB loaded had random names for both of them.

I was able to see this below in binary ninja showing us it recognized that there is a variable ARR_SIZE. but with the flow in main you still saw it showing as random variable names. I had to manually name it to ARR_SIZE as shown above.

My main point here was to show you how in our code we had two variables. But in the compiled binary you saw it living in different variables. Someone reverse engineering this might come to conclusion these are all seperate variables. When in fact they aren’t for example var_60 and myArray are the same thing. Keep in mind your coding in source code at abstract concepts. These concepts you have such as scope of your variable are abstract. The way the compiler compiles end product, and reverse engineer tool analyzes, will be very different. This is why when you try different view like rust or c in binary ninja it can look very different compared to what your source code was.

For example source code does a myArray[i] = i * 2 while in binary ninja Pseudo C view we see a shift happening by 2.