IDA
Last updated
Last updated
The default view is the Graph View which we see above. If you press spacebar IDA switches between views
Each function is displayed as a node in the graph view. Below I've highlighted the functions starting the the "start (1)" function.
IDA's Text View employs arrows for different conditional jumps and control flow.
Solid Arrow (→): A solid arrow denotes a direct jump or branch instruction, indicating an unconditional shift in the program's flow where execution moves from one location to another. This occurs when a jump or branch instruction like jmp or call is encountered.
Dashed Arrow (---→): A dashed arrow represents a conditional jump or branch instruction, suggesting that the program's flow might change based on a specific condition. The destination of the jump depends on the condition's outcome. For instance, a jz (jump if zero) instruction will trigger a jump only if a previous comparison yielded a zero value.
IDA also offers a feature that visualizes the execution flow between functions in an executable via a call flow graph. This potent visual tool aids analysts in navigating and understanding the control flow and the interactions among functions.
To jump to a new function Right-Click and select "Jump to operand"
To backtrack to the previous function press the "esc" key or click "Jump Back"
The start function is the program's entry point and is generally responsible for setting up the runtime environment before invoking the actual main function. Below is the start function:
Once we found the start function our next step is to search for function calls or jumps that that lead to other functions, as one of them is likely to be main.
NOTE: sub_ and loc_ are autogenerated by IDA
sub_<virtual_address> : Subroutine function
loc_<virtual_address>: Location in program.
We need to keep scrolling through call functions until we find some juicy nodes. Here we found a RegOpenKeyEx that queries for Vmware. This is a common sandbox detection mechanism.
The function RegOpenKeyExA is a part of the Windows Registry API and is utilized to open a handle to a specified registry key
NOTE: In IDA, cs is a segment register that usually refers to the code segment. When we click on cs:RegOpenKeyExA and press Enter, this action takes us to the .idata section, which includes import-related data and the import address of the function RegOpenKeyExA.
In this scenario, the RegOpenKeyExA function is imported from an external library (advapi32.dll), with its address stored in the .idata section for future use.
The line extrn RegOpenKeyExA:qword indicates that RegOpenKeyExA is an external symbol to be resolved at runtime.
This alerts the assembler that the function is defined in another module or library, and the linker will handle the resolution of its address during the linking process.
To rename a function in IDA, we should proceed as follows:
Click the function then, press the N key on the keyboard, or right-click and select Rename from the context menu.
Input the new name for the function and press Enter.
Below is a function that implements a string stack in combination with presumably a scanf or printf concatenation scheme. It returns: SOFTWARE\Microsoft\Windows\Current\Version
The below snippet is a string comparison function calls lea "Load Effective Address" to get the address of the string C:\\Program Files\\Vmware\VMware Tools. If strcmp returns true the program stops execution with "Sandbox detected" if not it continues to sub_402EA0
If the sandbox is evaded the execution flows to sub_402EA0 which is what we describe above. Jumping to the function we discover a URL!
The below snippet is a classic process injection example. The malware opens a process handle, allocates virtual memory, copies shellcode buffer, and executes a remote thread.
Below is a snippet of a discovered random string.. We can search for it on google to see if it yields any valuable information.
Earlier we found the URL of the C2 server. Below is a snippet of the malware using to open a connection with the C2 to fetch a shellcode payload. .
