Part 6: Special Topics

Shellcode analyist
Group 7

Đặng Quang Huy 21520256

Cao Minh Đức 21520726
Phan Bá Cường 21521907
Bùi Hữu Khánh 18520897
1
 01 02 03
Position-Independent Identifying Execution Manual Symbol
Code Location Resolution

04 05 06
Shellcode Encodings NOP Sleds Finding Shellcode

2
 Shell code
• Payload of raw executable code that allows
adversary to obtain interactive shell access on
compromised system
• Often used alongside exploit to subvert running
program

3
 Issues to overcome
• Getting placed in preferred memory location
• Applying address locations if it cannot be placed properly
• Loading required libraries and resolving external dependencies

4
 1. Position-independent code
No hard-coded addresses
• All branches and jumps must be relative
• So that code can be placed anywhere in memory and still function as intended
• Essential in exploit code and shellcode being injected from a remote location since
addresses are not necessarily known

5
 2. Identifying Execution Location
Shellcode may need to find out its execution location32-bit
• x86 does not provide EIP-relative access to embedded data as it does for control-flow
instructions
• Must load EIP into general purpose register
• Problem: "mov %eip, %eax" not allowed

Two method
• call/pop
• fnstenv

6
 2. Identifying Execution Location
call/popcall
• pushes EIP of next instruction onto stack, pop retrieves it

7
 2. Identifying Execution Location
fnstenvstores
• 28-byte structure of FPU state to memory
• FPU runs parallel to CPU, so must be able to accurately identify faulting instruction
• fpu_instruction_pointer = EIP of last instruction that used FPU (Listing 19-2, 19-3,
p. 412)

8
 2. Identifying Execution Location
fnstenvstores example

9
 3. Manual Symbol Resolution
Shellcode exists as binary blobs executed by a system.
Upon execution, it needs to perform useful tasks, often involving interaction with the
system through APIs (Application Programming Interfaces).

Shellcode can not use Windows loader to find where libraries are in process memory
Must dynamically locate functions such as LoadLibraryA and GetProcAddress (both
located in kernel32.dll)

Therefore, shellcode must perform the following steps:

Find kernel32.dll in memory.
Parse kernel32.dll’s PE file and search the exported functions for LoadLibraryA and
GetProcAddress.

10
3. Manual Symbol Resolution

11
 3. Manual Symbol Resolution
1. Access TEB using FS register to get PEB
pointer.
2. Use js to check PEB pointer's sign bit,
distinguishing between Win9x and WinNT.
3. If Win9x detected, enter infinite loop.
4. Access PEB_LDR_DATA structure to get
information about loaded modules.
5. Return DllBase field of the second module in
the linked list InInitializationOrderLinks,
assuming Windows Vista or earlier.

12
3. Manual Symbol Resolution

13
3. Manual Symbol Resolution

14
 4. Shellcode Encodings
Shellcode needs to be present in the address space of the vulnerable program to execute.
It needs to bypass the program's filters to reach its target location.

Programs using strcpy or strcat are vulnerable to buffer overflows if they don't check
input. Attackers can inject malicious code (shellcode) but it can't contain NULL bytes (\
0) because they terminate string copying.

15
 5. NOP Sleds
Sequence of NOPs preceing shell code
• Address targeting inexact
• Allows exploit to increase likelihood of hits by giving a range of addresses that will
result in shellcode executing

16
 6. Finding Shellcode
This passage explains various ways malware analysts can find shellcode in different
scenarios.

Sources of Shellcode:
• Network traffic
• Web pages
• Media files
• Malware executables

Challenges:
• Not always possible to replicate the target vulnerable program environment for
testing.
• Malware analysts need to reverse-engineer shellcode through static analysis.

17
 6. Finding Shellcode
In Web Pages:
• Use JavaScript:
⚬ Profile Systems: Identify vulnerabilities like browser versions and plugins
⚬ Decode Shellcode: Often using unescape, treating %uXXYY as encoded
Unicode characters
⚬ Execution: Convert decoded text to binary for execution

18
6. Finding Shellcode

19
 6. Finding Shellcode
In Payload:
• Shellcode can be hidden within a program or stored as a separate payload for injection into another process.
Detection involves monitoring process injection API calls like VirtualAllocEx, WriteProcessMemory, and
CreateRemoteThread
• In media files: disassemblers such as IDA Pro can load suspicious media files, but they may not
automatically detect shellcode. Search for initial decoder opcode sequences listed in reference materials

20
C++ analyist

21
 01 02 03
Object-Oriented Virtual vs. Nonvirtual Creating and Destroying
Programming Functions Objects

22
 1. Object-Oriented Programming
Functions (i.e. methods) in C++ associated with particular classes of objects
• Classes used to define objects
• Similar to struct, but also include functions

23
 1. Object-Oriented Programming
“this” pointer
• Implicit pointer to object that holds the
variable being accessed
• Implied in every variable access within a
function that does not specify an object
• Passed as a compiler-generated parameter to a
function (typically the ECX register,
sometimes ESI)
• “thiscall” calling convention (compared to
stdcall, cdecl, and fastcall calling conventions)

24
 1. Object-Oriented Programming

1. allocates stack space and stores the object at var_10.

2. The variable x, which is the first data value in the object, is accessed at var_C.
3. The pointer to the object is placed in the ECX register to call the HelloWorld function.
4. In the HelloWorld function, the value of ECX is used as the this pointer.
5. At offset 4, the assembly code accesses and uses the value of variable x.
When main calls HelloWorld for the second time, a different pointer is loaded into ECX.
25
 1. Object-Oriented Programming

Overloading and Mangling

• Method overloading allows multiple functions to have same name, but accept different
parameters
• When function called, compiler determines which version to use

26
 1. Object-Oriented Programming
Overloading and Mangling
• C++ uses name mangling to support this construct in the PE file
• Algorithm for mangling is compiler-specific
• IDA Pro demangles based on what it knows about specific compilers

27
 2. Virtual vs. Nonvirtual Functions

Virtual functions Nonvirtual functions

• Can be overridden by a subclass • Execution is determined at compile time
(polymorphism) • If object is an instance of the parent, the
• Execution is determined at runtime with parent class's function will be called, even
the child subclass overriding the parent if the object at run-time belongs to the
• Can keep parent functionality by changing child class
the type of the object to be an instance of
the parent class

28
 2. Virtual vs. Nonvirtual Functions

On left g() compiled On right g()

to call A’s foo() compiled to
check at run-time
which foo() to
call

29
 2. Virtual vs. Nonvirtual Functions
Implementation
• Nonvirtual functions the same
• Polymorphism via virtual function tables (vtables), effectively an array of pointers to code
• On left, nonvirtual call as before
• On right, vtable traversed in 1) and 2), then function pointer loaded into eax and called

30
 2. Virtual vs. Nonvirtual Functions
Recognizing vtables
• Should point to legitimate subroutines in IDA Pro (sub_####)
• Switch tables similar but point to legitimate code locations within code in IDA Pro without function
prologue (loc_#####)

31
 2. Virtual vs. Nonvirtual Functions
Recognizing vtables
• Virtual functions never directly called
• Code xrefs to functions within IDA Pro yield nothing due to use of registers in call
• Vtable similarity can be used to associate objects

32
 3. Creating and Destroying Objects

Constructor and Destructor functions

• Object either stored on stack for local variables
• Object stored in heap if “new” is used

Note: Implicit “deletes” for objects that go out of scope may be handled as exceptions

33
 3. Creating and Destroying Objects
• Initializes vtable for object stored on stack
• Does multiple loads of vtable (parent, then child)
• Creates another object via “new” call (note the name mangling)
??2@YAPAXI@Z
void * __cdecl operator new(unsigned int)

34
64-bit Malware
Group ..

35
 01 02
Why 64-bit Malware? Differences in x64
architectures

03 04
64-Bit Hints at Malware
Windows 32-Bit on
Functionality
Windows 64-Bit

36
 1. Why 64-bit Malware?

AMD64 now known as x64 or x86-64

• Similar to 32-bit x86 with quad extensions
• Not all tools support it
• Backwards compatibility support for 32-bit ensures that 32-bit malware can run on both 32-bit and
64-bit machines
Reasons for 64-bit malware
• Kernel rootkits must be 64-bit for machines to run on a 64-bit OS
• Malware and shellcode being injected into a 64-bit process must be 64-bit

37
 2. Differences in x64 Architecture

64-bit vs. 32-bit x86

• All addresses and pointers 64-bit
• All general purpose registers 64-bit (%rax vs. %eax)
• Special purpose registers also 64-bit (%rip vs. %eip)
• Double the general purpose registers (%r8-%r15)
⚬ %r8 = 64-bits
⚬ %r8d = 32-bit DWORD
⚬ %r8w = 16-bit WORD
⚬ %r8l = 8-bit LOW byte

38
 1. Differences in x64 Architecture
64-bit vs. 32-bit x86
• RIP-relative data addressing
• Recall “call/pop” needed previously to get location of data attached to exploit code
• Allows compiler to easily generate position-independent code
• Decreases the amount of relocation needed when code/DLLs are loaded
• Without call/pop, it is much harder to identify exploit code

39
 2. Differences in x64 Architecture
64-bit vs. 32-bit x86
• RIP-relative data addressing
• Recall “call/pop” needed previously to get location of data attached to exploit code
• Allows compiler to easily generate position-independent code
• Decreases the amount of relocation needed when code/DLLs are loaded
• Without call/pop, it is much harder to identify exploit code

40
 2. Differences in x64 Architecture
64-bit vs. 32-bit x86 calling convention and stack usage
• Similar to “fastcall”
• First six parameters passed in %rdi,%rsi,%rdx,%rcx,%r8,%r9
• Additional parameters passed on stack
• Hand-coded malware may completely deviate from this convention to confuse analysis
• Stack space is allocated at beginning of function call for the duration of the call
• Microsoft's 64-bit exception handling model assumes a static stack

41
 2. Differences in x64 Architecture
64-bit vs. 32-bit x86 calling convention and stack usage
• Reverse engineering complicated since local variables and function parameters co-mingled

42
 2. Differences in x64 Architecture

64-bit vs. 32-bit x86

• Leaf and Nonleaf Functions
⚬ Functions that call other functions are non-leaf or frame functions as they require a frame to be
allocated
⚬ Nonleaf functions required to allocate at least 0x20 bytes of stack space when calling another
function to save register parameters (local variables bump allocation beyond 0x20)
• 64-Bit Exception Handling
⚬ For 32-bit, SEH handling uses stack
⚬ For 64-bit, static exception information table stored in PE file and stored in .pdata section per
function. (Does not use stack)

43
 3. Windows 32-Bit on Windows 64-Bit

WOW64 subsystem allows 32-bit Windows to run on 64-bit Windows

• Redirects accesses to C:\Windows\System32 to C:\Windows\WOW64
• So if 32-bit malware running on 64-bit Windows writes a file to C:\Windows\System32, it shows
up in C:\WINDOWS\WOW64
• Similar redirection for registry keys
• 32-bit malware wishing to “break-out” of WOW64 to infect 64-bit system can disable redirection
(IsWow64Process, C:\Windows\Sysnative, Wow64DisableWow64FsRedirection to disable for a
thread)

44
 4. 64-Bit Hints at Malware Functionality

64-bit shortcuts
• Integers often stored in 32-bit values
• Pointers are always 64-bit
• Can differentiate non-pointers from pointers via size of register used

45