hey two days ago i received the new
nintendo game and watch super mario
brothers handheld and it arrived one day
before the official release
awesome and being a hardware hacker i
immediately wanted to take it apart and
hack it
i published my progress on twitter and
after a couple of hours i got it
my own modified super mario brothers rom
on the nintendo game and watch
one day before the official release of
the device it was already hacked
in this video i want to walk you through
the process and show you exactly how it
works and how you can reproduce it at
home
let's start by looking at the actual
device it's pretty simple
it has a d-pad the usual b and a buttons
three additional buttons for switching
between game mode time mode and for
pausing the game
and setting the time it also has a power
button on the side and underneath it a
usbc port
this usb port is only for charging and
the data pins are unfortunately not
connected to the processor
this means that for modding it you will
have to open up the device and it
probably won't be possible to flash it
via the usb
port speaking about opening it up the
device uses nintendo's three wing screws
and so if you want to open one up you
need to make sure to have a fitting tree
ring
i'm using the 2.5 millimeter one and so
let's open it up
the first thing i recognized was the
battery it's the same as the one in the
nintendo switch joycons
but let's look at the rest of the
hardware the main processor is an
stm32h7b0
a microcontroller with slightly over 1
megabyte of
ram and 128 kilobytes of flash it's a
cortex m7 which is quite different from
the cortex a7 used in the nes and snes
classic
the cortex m7 can't run linux and so we
can expect the device to run a more or
less bare metal firmware the next chip
is a micronex 8 megabit or 1 megabyte
spi flash chip
it comes in an soic8 package making it
very easy to dump
the other chips are the charging circuit
speaker amplifier and so on
and not really interesting to us now
microcontrollers generally have a debug
port such as jtag
or in the case of cortex-m jtag and or
swd
serial wire debug via this port you can
flash the device
read firmware single step through the
program and so on
these parts are often exposed for the
engineers on some easy to access pins
and if we take a look at the pcb
there are some unpopulated pins pretty
close to the cpu
to verify whether this is actually the
debug port let's bring up the data sheet
and check on which pins it exposes the
debug port
on this package lqfp100 we can find the
first signal we need called
swdio on pin 72 and the second signal
swclk on pin 76
in the pin overview we can also see that
the reset signal
is brought out on pin 14. before we
measure this on the device
let's also quickly disconnect the
battery simply use a small flat head
screwdriver and lever it up now let's
take our multimeter set it to continuity
mode and see whether these pins on the
processor are connected to the contacts
of the unpopulated header
and indeed on the first pin we find
swclk
on the second we get the supply voltage
of the processor
the third one is ground fourth is swdio
and the last one is reset perfect now
chances are high that this debug port
was disabled in production
but it's always good to give it a try
and to do that i'm using an arm debug
pro
in my case i'm using a segar j link but
you can find a ton of different
compatible debug probes online
starting at roughly like three dollars
i've also connected a couple of test
clips to the debug probes so that i can
easily get a good connection to the
contacts without soldering
so let's hook them up finally i'll
connect the debug probe to usb
and also provide power to the game and
watch via usbc
note that i've got the battery
disconnected this will allow us to
easily power cycle the device
i booted up the device and started the
super mario brothers game
now let's jump over to the computer and
see whether our debug probe can connect
to the chip
start j-link select stm32h7b0 as the
target
swd as the protocol and i will leave the
debug speed at default
and success the debug probe can connect
to the chip perfect it wasn't disabled
in production
but unfortunately when we take a closer
look at the lock output
the chip is secured the stm32 has a
feature called read out protection which
can be set to one of three modes
rdp0 which allows full debug access rdp1
which leaves the debug port enabled but
prevents flash reads
though we can still access the ram and
so on and rdp2
which completely disables the port i
should also know that in rdp-1 we can
reprogram the chip
but doing that would erase the flash
contents and with that
brick the device so be careful when you
are playing along at home
i already got the first email from
someone who accidentally erased his
device
now in this case the device is set to
rdp one so we only have access to the
ram
which means we can't dump the firmware
however let's still go ahead and dump
the three ram areas and we will analyze
them later
next let's dump the flash chip to do
this i'm using a slightly modified
tl866cs
though any spy flash programmer with 1.8
volt support should work
i've connected an soic8 clip to the
programmer which allows me to simply
clip
onto the flash chip also note that the
programmer will power the flash chip
and so make sure to disconnect the
battery and to unplug usb if you try
this at home
with the clip attached to the flash chip
i can use mini pro to dump the contents
of the flash now we have two things a
full dump of the ram contents of the
device
and also a full dump of the external
flash memory now even though we couldn't
dump the firmware of the device
this gives us quite a lot to look at so
let's start with the flash contents
to check whether the flash is clear text
or encrypted i run an
entropy analysis on the flash dump using
bin walk a very high entropy such as
seen here
generally indicates that the contents
are encrypted or compressed
as i couldn't find any compression
header or so i was pretty confident that
it was encrypted
i also noticed that there were no
repeating patterns or so
making it less likely that this was a
very simple xor
soldering encryption or maybe aes in ecb
mode
too bad if the flash wasn't encrypted
this would be super easy
but also far too early to give up so
let's take a look at the remdum
next the first thing i was curious about
was whether the nes rom of the game was
loaded into memory
and so i opened the original super mario
bros rom
in the hex editor on the right and the
ram dump on the left
then i simply selected a part of the
original rom and searched for it in the
random
and yes the nes rom is loaded into ram
perfect
later on i also found that the second
rom super mario brothers 2
is also always in rum and that both roms
are always loaded at the same addresses
for example super mario bros 1 is always
loaded at the address hex 2400
zero zero zero i also noticed some
strange patterns in ram which looked a
lot like graphics to me
i wrote a small python script that
treats the bytes as rgba bitmap
and displays it and we can see the
screen contents
perfect we found the two roms and the
frame buffer but this doesn't really
bring us closer to running our own roms
on it
we need to figure out the flash
encryption now given that we had a nice
backup of the flash contents i felt
confident in trying to fiddle with it
i started by replacing a couple of bytes
in the flash image with zeros in a hex
editor
and use the flash programmer to write it
back to the device
after the flashing was complete i tried
to boot it up and after trying this a
couple of times with zeros in different
places in flush
i found that it still worked in most
cases this means that the device does
not really verify the contents of the
flash which is quite an important thing
to know when trying to understand the
security implementation of a device
my assumption was that the nes rom is
somehow loaded from the encrypted flash
and so i kept putting zeroes in random
places in the flash
programmed the device and then dumped
the ram to see whether eventually the
rom data
which normally is always static would
change and after
only a couple of tries i got lucky the
data of the nes rom in ram
changed i changed 4 bytes in the flash
to 0 and now suddenly 4 bytes in the rom
also changed
this is awesome and it tells us a lot it
means that the rom is loaded and
decrypted from flash
it's not validated and that it's a
bitewise encryption not for example a
block based encryption
we changed 4 bytes in the flash file and
4 bytes in the loaded rom changed
now it was time for some thinking and
some analysis and eventually i figured
out that if i xor the original 4 bytes
from ram
with the original 4 bytes from flash i
got exactly the same 4 bytes
that were loaded into memory when i
wrote zeros into flash
so we are looking at some xor based
encryption such as maybe
asctr now as we know the plain text
which is the nes rom
and the ciphertext which we got from the
flash dump we can
xor them to get the xor data stream that
was used for the encryption
which allows us in turn to encrypt our
own nes roms i wrote a couple of scripts
to try this and you can find them linked
in the description
the first script takes a flash number of
the device and ram image from the device
and generates the exostream required to
encrypt our own rom
the second script takes a flash dump the
xor stream and the modified rom and
creates a new encrypted flash image
i made some slight modifications to the
original nes rom
and flashed it onto the device so let's
turn on the device
hit the game button to choose the first
game
and yes we are playing hacked mario
brothers instead of super mario brothers
so we are able to upload our own roms to
the device
awesome now i also noticed that the
emulator does some hot patching of the
rom
for example to show the 1985 to 2020
copyright string
so there's still a lot of work to do
until we can freely put our own games
onto the device
but the first steps have been made and
we are able to execute our own nes code
on the device
my next goal is to find a way to dump
the firmware from the stm32 and if
you're interested in that kind of stuff
feel free to subscribe to this channel i
hope you enjoyed this video and to see
you on this channel again soon
thanks