Showing posts with label stack. Show all posts
Showing posts with label stack. Show all posts

Saturday, July 8, 2017

Writing and compiling a program in C

Hello there!

Today I want to bring a short post where I will show you how to write a program in C and compile it with GCC on Windows. This post will be useful, because we will need to compile the sources that I will bring on future technical posts. My goal is not to teach C programming, there is a lot of content about it on the web. Of course that I will help you along the posts with references about the code sources.

I recommend reading the previous topcis:



The GCC


Since I will not bring the executable here instead just the C code for you to compile on your own environment. In this way you can understand better how C code turns into Assembly code. Like a said in the previous topics, it's important to know programming in reverse engineering even if somebody tells you that isn't. There is no ultimate truth, so I'm open to any comment, tips or criticisms.

Well, let's do it! First we have to download the GCC, I'm using the MinGW to install it. There is a lot of C compilers out there, I pick the MinGW for convenience.




Download and install it at "C:\mingw" to be easy to access. Skip any checks to install components, just finish the installation. We will install the GCC via console on the next step. Once you have installed it, open the CMD or PowerShell goes to the mingw folder.


cd c:\mingw\bin
mingw-get.exe install mingw32-gcc-bin

We will only install the bin component, because we only want to compile our code. After the download process by the MinGW we are good to go, to write and compile our program.

To use the GCC directly, I mean through any folder in console you have to add the path of GCC to the Environment Path property.



GCC compiles our source with some initialization code that is default for every compilation, as I could see so far it starts to write the assembly from given address (0x401460), this is for the standard compilation setting. Let's see it in the next example. I wrote this simple code in C to test our GCC whether it's ok or not:


#include <stdio.h>

int main(){
   
    printf("Hello There. VerseInversing!\n");
   
    return 0;
}

Copy the code below on your favorite editor, save it like "sample.c" on C:/. Now open the console and run the command:


cd C:\
gcc sample.c -o sample

If everything it's ok you should see a sample.exe created on C:\. Just type it on console and execute it.


./sample.exe

Cool uh ? haha

Well, now we have to see how the assembly was generated. I was using the OllyDbg, but since the x64dbg has becoming very popular I'm giving it a try. It's a nice debug tool updated very often, have many features embed in it and many other good things. Download at:




Program loading (Very simple approach)


Before we get our hands dirty, let's see basically how the programming execution works. So first of all I assuming that you read the previous topics. So, to execute a program (binary file) the windows needs to load this file into memory so it takes the file and simply put it into the memory. Then each file type is interpreted in different ways when loaded into memory. The executable file have the header with key information that let the windows load it and execute it properly.

So the executable file always have the PE (Portable executable) header, without it the OS just can't load it. In the PE Header we have vital information that will help our analysis. Is this same information that let the debugger loads it and show us all the information that will help us on the debugging process.

In this PE Header we have many information, like the EntryPoint. EntryPoint like it's name, is the offset where the execution must to begin. This offset belong to the (code, text) section where all the code of our program is in. Again, everything on the file is hex data, but when you put this data on code or text section the OS reads it as instructions to CPU execute. All the rest is hex data too, but it is interpreted in a different way. As I said all depends on how you want to interpret information.

So as I said the executable mainly uses the OS to run, so it will need the libraries on the OS to run it's code. Unless the coder uses the ordinal number to call the API, it's easy to see which api the program uses by looking at the .idata section. IDATA stands for "Import Data" that is the imports the executable do to use on the execution.

On windows each DLL library has specific functionality so you can basically use some program like  CFF Explorer to look at the imports of the PE and google each DLL to see the specifics of each one. In our case it uses the KERNEL32.dll and msvcrt.dll. KERNEL32.dll it's pretty basic with core functions, it's very very common. msvcrt.dll it's the library of C on Windows, so as we are using C it make sense to importing it.

Anyway this is subject to another post, but I just doing a little intro on it. Let's continue our debugging.

Let's debug


After you have downloaded and installed it. Let's open our fresh compiled program. Well, it starts little different from others, not at all.. but a little.
It started at ntdll.dll module, but it's already set the breakpoint on the entry point of the executable (EntryPoint information is in the PE Header).

As I said before the program imports some DLLs to uses it's functionality. This DLLs run with our executable so each one of these DLLs and also our executable is a module running. In this case the ntdll.dll was imported by KERNEL32.dll because the the DLL itself uses the ntdll.dll that does some interface with the kernel.

Let's continue. In the x64dbg goes to the Breakpoints tab and look at the breakpoints:



Shortcuts used in this post:


  • F9: Run the program to the end if it doesn't find any breakpoint ahead.
  • F8: Step by step or Line by line.
  • F7: Step into. If there is any CALL instruction you are going inside the CALL. If you F8 then you jump to the next line and skip the CALL.


Ignore the TLS Callback for now, we will not need it in this topic. To do this you go to Options=>Preferences=>[Tab]Events and uncheck the "TLS Callbacks*". I will bring this in the future posts. You can uncheck it or you can simply ignore it skipping with F9.

As you can see the address 0x4012E0 holds our entry point, so lets play until it stops on that address. Press F9 until you reach the address. This is the entry point on programs compiled with GCC, so our program starts after all the initialization code. My tip is to step through it to familiarize with the debugger.

But to make it shorter the call for our program block is on 0x401280 with a CALL instruction to the address 0x401460 (this is generally where the GCC starts to write our program assembly).



So let's do a little analysis. First it set the stack frame (see Assembly Basics) then it enlarges the stack frame by doing an AND followed by a SUB, then it calls a sample.sub_401970 at 0x401469 it's only check for some value at address 0x407028. If you go to the Memory tab you can see that (this information came from PE Header) the address 0x407000 is of the section .bss (uninitialized data), anyway doesn't do anything crucial and we know that, because we write it.

After this step, it move the address 0x405064 to the stack directly it doesn't uses any register to keep this value, it just MOV to the stack and call the PUTS API from the C library of the Windows. Now, why it uses puts if we write printf ? And why it calling from sample.puts ?

First question, if you see the difference from puts to printf you see why it uses the puts. Reference to the puts:




As you can see, the puts receives a pointer to a string then it put a newline character at the end of the string and that was exactly what we did in our code, but with printf. So the GCC just saw it and make it better.

Second question, if you press F7 you will step into the CALL and will see that inside the call it's just a Table JUMP to the original API. No secrets.

That's it. So we could see what the compiler can do with code, it work on it to make it simpler and "faster" in it's own way. So coding and see how compiler handles our code it's good to a better understating of assembly in practice.

I coded a simple program in C that have many ways to bypass, so the goal is to the reach the ultimate function which prints "You reach the secret stuff!!". I recommend that you do not see what it does and try to understand what it is doing and how to bypass it through x64dbg (or any other debugger). I will do a post explaining how to do it and how to patch it. Consider as an exercise. (The program is buggy, I will show why on the next post)




Any doubts, comments, tips, criticism just tell me. We are all here to learn with each other. Hope that's can be useful to anyone. I will bring some other analysis here very soon. Thanks! Bye!

Friday, June 23, 2017

Basics of Assembly

Introduction to Assembly

Hello everyone, it's me again bringing some basic stuff. Even being a basic stuff I hope that can help anyone. I am making this basic posts to my incoming ones, I will bring more technical analysis. Sorry for any mistakes that I maybe did on this post and if I did any, please send me a feedback.
Well, the assembly code it's the "only" way on reversing engineering. Or you interpret assembly mnemonics or you analyze opcodes (machine code). As said in the previous introductory topic (if you didn't read, I do recommend) the assembly code it's generated by the compiler for every code language that you use. So, understanding it is vital to RE. Assembly language doesn't is standart for all assemblers, the mnemonics(instructions) are different deppending of your processor architecture. Since the processor is made of several circuits and each processor has your own cricuits, the logic behind it's processing differs from each other. So the instructions that they "understand" is different from each processor architecture. In this blog I will give the approach of IA-32 architecture. I will not "teach", is more like an approach of what it is and how we work with. So knowing how the computer "works", as Memory-Data X Instruction-Operation. Logically the computer stocks all data on memory and all this data is interpreted and executed by the CPU.

 
Computer / Memory, CPU, IO Devices and BUS

The processor have some pointers to help the CPU keep track of what it need to do with what data. Then we have the instruction pointer and the data pointer. Through the posts we will see it in practice. So the instruction pointer points to the memory block that represents an instruction and the data pointer to a memory block that represents the data, then the CPU executes the instruction with the data that is pointed.

 
CPU Units X Memory

These pointers allocate the memory offsets in registers. As the processor executes these instructions the instruction pointer goes to the next instruction and the data pointer too. The instruction has between 1-3 bytes and is called opcode (operation code). So basically assembly has three "parts", opcode mnemonics, data sections and directives.

Opcode


Mnemonic code is the "english" representation of the instruction code, e. g. the '89' instruction is the 'mov' mnemonic. Different assembly types represent instructions differently.

 
OllyDbg / Right Assembly, Left OpCodes

Data


The data sections is the space used to store the data which the instrunction will use to execute, so this data can be in some memory section or it can use the stack (memory area, more later). All the data is stored in the hex representation and is referenced by it's memory address. So every data stored on the system has a memory address, it can be a immediate constant in the assembly code or it can be stored on the stack frame.

Directives


Directives are the elements used in assembly to tell the assembler (which compiles the assembly) how to interpret this type of data, data includes everything, like code and values. For example if you want to store a float value the assembler needs to know, then it can reserve memory properly. One of the important directives of assembly is the ".section" directive. This directive creates sections on memory for each type of data.

Sections


We can have any kind of section we want, but all programs have this by default:

  • .text:
    • All the code instructions are alocated in this section. No data is allowed here, except some fixed data of variables like a = 5, but that depends of the programmer on low-level programming and depends of the compiler on high-level programming.
  • .data:
    • This section is responsible for stores all data that the .text request. It will be referenced as an address in the .text section, like program.ADDRESS.
  • .bss:
    • This section generally used to unitialized data. I think the name might change from language to language, don't sure.


The IA-32 Architecture


The IA-32 architecture was designed for pentium processors by Intel. I don't know for sure if it is the most used nowdays, but it's a very known one and have a lot of documentation about it. When you learn assembly basis in one architecture, makes easy to learn in another one, because the base still the same. Some assembly let you do more others let do less, I think it's the basic difference. In my last topic I tried to wrote about computer in general form and I think that you already know how it is. I don't want to make this part too much extensive. So basically IA-32 is divided in 4 parts:

  • Control unit:
    • Control is responsible for bring all the information from memory, data and instructions. Then it decodes this instructions into micro-operations and pass to execution unit. The result of the operation is passed back for control unit that stores the result.
  • Execution unit:
    • Responsible for execute all the micro-operations.
  • Registers:
    • Registers are responsible to keep track of data that are been used. This registers are internal memory of the processor. Having this little memory inside the processor make it much more faster than going outside (from processor itself) searching data in RAM memory and retrieve it.
    • I want to keep it objective so I will not write about all of them. You can read in the book listed on the reference, I do recommend. So there are basically four types of registers (there are more like I said):
      • General Purposes: 8 32-bits registers. They are used to work with data.
      • Segment: 6 16-bit registers. Used to memory access.
      • Intruction Pointer: 1 32-bit register. Points to the next instruction to be executed.
      • Floating-point: 8 80-bit register. It used to work with floating-point numbers.
  • Flags:
    • Flags are used to keep control of the operations executed by processor. It's a way to know if some operation worked or not. There are specific type of flags to specific operations. We will see it.


Registers


General Purposes


These registers are mainly used to work with data as the code is been executed. All data used in the instructions are stored in these registers. They are 32-bits longer at the "top" level (32-bits), but it can be sliced in minor parts (16-bits, 8-bits) that stores minor data.

  • EAX (32-bits):
    • AH (16-bits):
      • AL (8-bits)
  • EBX (32-bits):
    • BH (16-bits):
      • BL (8-bits)
  • ECX (32-bits):
    • CH (16-bits):
      • CL (8-bits)
  • EDX (32-bits):
    • DH (16-bits):
      • DL (8-bits)
  • EDI (32-bits):
    • DI (16-bits)
  • ESI (32-bits):
    • SI (16-bits)
  • EBP (32-bits):
    • BP (16-bits)
  • ESP (32-bits):
    • SP (16-bits)

OllyDbg / Registers and Flags

These are the 8 32-bits registers that we will work with a lot. So it's important to say that modifing a top level register you will modify the low level register. For example if you put any value at AL and then put a new value on EAX the AL value will be overrided. Some of these registers are used in the default way. EBP and ESP for example are used to control the stack frame. Stack frame is a block of memory used to control some local variables of function/method. But you can use the stack when you need to call a method/function you push the parameter onto the stack so the call instructions can grab these parameters to call the method/function. As we analyze artifacts we will see the pattern of it's usage. Because of this it's important to know programming. The good way to learn it's to code and analyze it. On the later topics I will bring much more pratical examples with C language. It's amazing what we can do (I mean, you are managing energy, bro!! lol).


Segment


The segment registers are used to identify where data is located. Each segment register has a pointer to the section where it suposed to grab the data. The segment registers are:
  • CS: Code Segment.
  • DS: Data Segment
  • SS: Stack Segment
  • ES: Extra Segment
  • FS: Extra Segment
  • GS: Extra Segment
So each one is used in specific cases. For example, if you have a address memory on EAX (of data section) register and you have some data on EBX and want to save it on the .data section you maybe see that:

mov ds:[EAX], EBX

So you are moving the data on the EBX to where [EAX] pointing in the DS section. The [] brackets indicating that is a pointer to some memory address.

 
OllyDbg / Code acessing SS segment


We will see much more in pratical examples. The best way to learn.


Flags


The flags are maintained in a single 32-bits register called EFLAGS and each flag is represented by each bit. So as I said the flags are used to control if the operations that the processor executed worked or not. For example for conditional jumps through the code execution it checks if the Zero Flag (depends on the jump, others can be used) was set so it can know whether it will jump or not. There is an image as you already saw in registers topic. The flags is divided in three groups:

  • Status Flags
  • Control Flags
  • System Flags

I will only discuss about status. If you want to know more, there are books listed in the reference, I do recommend to read. The status flags are used to sign the result of mathematical operations executed by the processor. The flags are:
  • CF: Carry Flag.
    • Carry flag is used to manage the carry or borrow out in mathematical operations. It means that occured an overflow, i. e. there is some remaining data. Used in unsigned arithmetic.
  • PF: Parity Flag.
    • Is set when the result of the operation have sum of the 1's bit even number.
  • AF: Adjust Flag.
    • Used in Binary Coded Decimal (BCD), is set when the result of an operation is a borrow or carry. BCD it's a nice feature to work with decimals, if you want to know more at reference has what you need.
  • ZF: Zero Flag.
    • Is set when the result of an operation is 0.
  • SF: Sign Flag.
    • Is set in the most significant bit, when the operation results in a negative number.
  • OF: Overflow Flag.
    • Is used in signed integer operations and is set when the operation result is too large for positive numbers representation or too small in the negative numbers representation.

Stack


So now we are going to talk about the stack. Stack is very important in the reversing due it's common usage in the assembly world. The stack is a memory area where the program in execution uses to store short-term data. So the stack is generally used to:
  • Save register values
    • You can save the register in the stack to use it for another operation and then retrieve the old value to it.
  • Store local variables
    • Store the local variables at function scope. Like I said before, when doing it the variable is accessed directly using SS segment to access the offset in the stack.
  • Passing function parameters
    • To call a function generally you push all parameters on the stack from the right to left and call the function. For example, f(p1,p2,p3), you will pass p3,p2,p1.
  • Store the return address of the function call
    • The address of the next instruction after the call instruction, doing that the program will know where to back when it executes the retn instruction inside the function called.
Storing locally means that when you enter in a function scope all the local variables generally uses the stack to keep your data. In general everything is on memory, on the address space that the operating system gave us. The stack is just an area on that address space where the program uses to store data. So to put values on the stack you uses push instruction and to retrieve it you uses pop instruction. Everytime you enter a function a stack frame is set. Stack frame is set of addresses reserved to the function in execution, that set is limited by EBP(Base pointer) and ESP ('Top' Stack pointer). Generally this is how you see the stack frame been set:

PUSH EBP
MOV EBP,ESP
SUB ESP, SIZE

 First you save the old EBP, for when you back to the previous function will be able to reset the old stack frame, then you set the new base pointer and add the size (how many addresses) you need to that function. Stack are managed as LIFO type, last in first out. So the last element that you pushed onto the stack is the first element that will be poped out. But you can access this data directly if you need it, remember the SS segement ? So you can access using it together with the ESP (points to the top of the stack) register, like:

mov EAX, PTR SS:[ESP+4]

In the last instruction you moved the value of "ESP (plus) 4" pointing at to the general register EAX.

 Some important things about stack is that it grows up to lower addresses on IA-32 architecture. So bigger the stack is, lower addresses it access as we can see:

 
How stack works basically

In the image we can see the heap too and it's our next topic. This post I am bringing a theorical approach but in the next we will discuss it all in a pratical way. For now lets just abstract.


Heap


Heap is a memory area where the program uses for dynamic allocation. The heap is managed generally by the OS. So when the programmer need some space to store data that is bigger than the stack could manage, then the program store it in the heap memory. So the memory heap is passed to the program when the OS is loading it on memory. When you have a literal expression on your code like:

char newText[] = "Testing how code storing data.";

Regardless the data was inside some function the compiler generally uses the .data section and give to the instruction that will use this data the constant immediate address of the data, something like program.ADDRESS. But when you are loading something external for example, you don't know the size you going to need so the size is dynamic, then the program will have a routine that allocate the size you need in the heap.

 Heap it's important in RE because many program uses it to allocate data and sometimes identify which routine allocates the memory can be useful.

Now I think you are able to understand the incoming new posts that I will bring here. As I post new topics I will try to discuss a little more on technical topics. On the pratical part we will have a better view.

References


  • Google
  • Eldad Eilam - Reversing: Secrets of Reverse Engineering
  • Reverse Engineering Code With IDA Pro
  • Professional Assembly Language - Richard Blum

Windows Objects

Objects in windows are referred as kernel objects . They provide a link or an way to use any objects functionality according with the object...