As I explained in another blog post I started a side project to hack my Piano on my free time and oh boy do I have a lot of things to say on that…

Well let’s first begin with the obvious: I made a video about the whole project, using it as an example to try to explain Hardware Hacking!

Now that this has been taken care of let’s talk about it, shall we?

The Video

I originally didn’t planned a video simply because I thought(and still think) I am not a good enough speaker to have pleasing content for the ear. I originally planned to do a full talk more like the Tamagotchis one at 29c3 but in the end decided against it, and preferred a cross medium project, in that case a video, a lightning talk, and this post!

I began working on the video script right after I got replies from the CCC organizers, and finished the first draft one day after, I had some other changes but overall it took me one day to do it entirely. BUT(there’s always a but) couldn’t get the camera, microphone et cetera before the 20th. 6 days before the flight to the CCC. Challenge accepted.

It took me one day to do the audio recording, clear it up a bit, fix my script, and do post treatment on audio, another one for the video recording(I originally had much more shoots than what I’ve shown in the video!) and 2 days to edit the video(hence its look, never really done any video editing before).

The video goal was to give an overview, an introduction on what Hardware Hacking is, through something complex but simple to take over, and optionally something that you don’t see every day. It fall upon the Piano because of a silly joke I made on twitter: velocity curves that the piano were using seemed weird to my feel and I wanted to investigate why. Frankly they seem to have done the maths correctly so I’m still intrigued by this up to this day! This also begins a series of videos I’ll do, being “GovanifY’s Lab” which I really hope to improve. The goal is to introduce subjects in a way that makes it easy to understand and to go more in depth about, trying to show as much as possible about one subject in under 30 minutes. And be warned, the next episode won’t be on hacking but on a little project I’ve worked on.

If you want more informations about the Piano Hacking project on top of the video you should also check up the Appendix, in which I tried to give you some good resources for several hacking-related fields!

So I talked a lot about it until now but haven’t exactly described what it was, so let me introduce you to…

The CCC

Frankly, it’s pretty impressive: Between huge conference rooms in which people carelessly made a hoverboard-polonaise , acoustic levitators, a list of defaced Nazi domains and LEDs. EVERYWHERE. you didn’t knew where to look! It is all you’d expect from a hacker congress: it might seem childish but it’s a load of fun!

qwerty smoking weed and doing CTFs, fail0verflow failing, lockpicking groups and anarchists assemblies, several pro privacy groups, a lot, no really a lot, of beers, talks and nobody present at 8am, THIS is the CCC.

In spite of glaring issues with CCC organizers and organizations and the CCC being ruled by the laws of spectacle what the CCC is all about is the people there. What is shown of the CCC are the talks, because this is what businesses are interested in, but what you do when there includes visiting, talking to people, exploring new ideas, hacking stuff together, working on a CTF and so on.

The CCC is an amazing place to meet new people and to work together, which is much more important than the talks produced by the people in it, even then those are what makes the CCC alive in its mainstream idea.

At the end of the days it’s just like an university: it is what it is because of the people in it making it alive, not because of the people organizing it.

But let’s stop avoiding the subject and let’s talk about the one of the main reason I came to the CCC.

The talk

The demo in itself wasn’t really hard, I just tooked over the piano, using the USART2 port to create an USB HID keyboard, launching a MIDI server(Timidity) on my laptop, turning the piano into a MIDI device and connecting automatically the server to the device, playing a MIDI I hardcoded into the firmware(being the Flintstones).

This talk was just supposed to show what I couldn’t in video and pretty much the end goal of the project. I could also have created a fake instrument(VST) and use it to take over a computer or, even better, implement one Linux Kernel exploit I discussed in the talk, but I didn’t felt like it was worth my time frankly, not that it’s uninteresting, but that I was already working on another project by that point.

As a quick note aside I’ve actually recorded the demo a day before at my hotel in case anything would go wrong on stage but as the organization was already late I thought it would be better to just show it in this blog post for those interested:

Appendix

Before anything I believe I should explain you what this appendix is here for:
In a nutshell I am trying to give good resources for things that I haven’t explained in depth in my video about Reverse Engineering and Hacking in general to try to clear out the misconceptions or simply lack of knowledge you might have had after my video.

To start off this appendix let me give you some resources for Reverse Engineering:
I’d usually recommend resources such as this website to learn about assembly in general, ARM being simple enough and the website being really well crafted, although usually you’d need a little bit more investment than just reading to get around assembly languages, for which I can recommend tools such as this allowing you to visualize the assembly you’re writing and ultimately understand it.

To go on with Hardware Hacking and IC reversing I would recommend you learning about Circuit Theory and then moving on with IC reversing, using IC pictures to train you or some blog posts about IC reversing (I have a preference for this one myself)

For more general hardware hacking I’d say my video does a fairly good job at explaining the basic principles with some peculiarities:

The first thing for this piano being: In most secure devices JTAG firmware read back would be LOCKED. You usually shouldn’t have access to the firmware directly, hence why I made such an emphasis on other hardware hacking tricks as those are the ones you usually employ. In that case if I couldn’t have used the JTAG I would have several options: reversing the update system, containing a raw binary of the firmware unencrypted, glitch attacks to try to make the firmware dump itself et cetera…

On to the update system itself: while it might seem impractical to ship a hacked piano and hope for the best it isn’t that much to ship a virused instrument: think of it. USB can be accessed from Userland so you could develop an instrument saying your piano is out of date, asking you to put it in update mode and have a hacked piano, all through userland without any warning!

On the software exploitation this project was really simple, usually with “secure” devices you usually have userland and kernel and you’ll try to get access to the kernel as this is what controls the device fully, in that case we just got code execution without any kind of protection and owned all the hardware. This is usually not how it works, as we would find a bug in a process in userland and go on by privilege escalation to our desired target, usually the kernel.

As for resources on how to interact and understand a device I/O I’d send you this video by LiveOverflow explaining how to find resources in a documentation and understand during reverse engineering what a piece of code does, while keeping in mind that libc implementations can also have the constants and examples you’re looking for.

In the end there is much, MUCH more to discuss about the subject but then again I just wanted to give an exhaustive overview of what hacking random devices feels like, and I feel like I accomplished this goal fairly well!

Video script

Here is the annotated script that was used to film the video. This isn’t exactly what I said, a lot of little things have been changed and all but this is the “original” script, hoping it’s not too bad for your liking!.

Script:
The Instrumentality of a Hacker - Introduction to Hardware Hacking


VIDEO:
    [
Yo, I'm GovanifY, and welcome to my lab!

[Intro]

So we're going to hack a piano but, since this is my first video, you'll
have bear with me to make a quick intro and try to explain WHY the hell I am doing that.

]

3
---
I've always been fascinated by the world since I was little. Through several prisms I
tried to understand the world around me, by, for example,  self-studying fields such as Physics, and trying to learn
from people that were obviously better than me when I was ten, such as Hubert Reeves. *nervous laugh*

4---
Although early on I realized that if I wanted to modify the world around me, and not just
understand it, I'd be faced with a lot of "We don't know if this is possible" or
"We don't quite understand this" and that's why I turned to hacking.

    Hacking allowed me to develop structuralist approach by understanding something that was 

already well documented piece  by piece, and modify it as I wished,
giving me a feel for later research projects.

5---
I'd like to share my way of trying to understand things and modify them throughout
this video by giving a broad overview of the subject, so that people can understand the whole
idea of what it is like to reverse engineer and modify a piece of electronics all
while giving enough general idea of the subject to allow everyone to documentate
itself if motivated enough.

[Preface]
6---
So why a piano? I've always been into music since I was little, convincing the
conservatory director to let me try violin at a very young age!
My interest in music never stopped and eventually I turned to the
composition world, which allowed me to learn how to play the piano!

7---
I was inspired to do this by the CCC talks about Tamagotchis.  
I believe it was one of the best intro to Hardware Hacking I've seen while
not making the mistake to go on either way too complex or simple machines, by
choosing a weird but simple one!

8---
The MIDI Keyboard I chose is an AKAI MPK 61 solely because of the fact that it's
what I own! It's a pretty high end MIDI keyboard which means that you have to
connect it to a computer to produce any sound at all, MIDI being a way to encode music notes,
not the music wave itself.

[
But enough talking now...

[1. Opening it up]
Let's open this piano up shall we?
]

When opening a device I usually take a picture of the back before
it is unscrewed, then several of each screw hole, with the screw next to them. 
I then put all of the screws in a safe place, to not lose them. This allows
me to remember which screws belong where, their size, and so on. Taking pictures
at each step also allows me to not forget to, say, reconnect a device if the build is a
bit more advanced.

After I am done breaking down the electronics, I usually like to create a mental map of the whole
device. You can see here that I'm writing it down in the form of schematics, but
most of the time it's just random notes I throw together in a text editor and
my brain does the rest of the job.
I try to identify the parts that I should target versus the "useless" ones from a hackers point of view, such as in that case: Inputs/Outputs, which are pretty much
the LEDs, Keyboard and the whole board with the LCD and the rest. From seeing this I can 
conclude that they're not too complicated, despite being useful. The LED board simply
connects everything to a single plug, and so does the LCD board, with a custom LCD
being used instead, of course.

Next on the list is to get a theoretical overview, more precisely of what could be
useful, in the case of the main board.
We can already see something below the CPU, which seems to be an Field-programmable gate array, FPGA but, despite first glance, is
actually a Complex programmable logic device, CPLD with a lot of  ports, both of which allow you to "program" electronic circuits.


We can also note that unplugged ports in our overview are above
the rest, as those can be used for in factory debug testing,  if not used in
production.

With everything noted we can finally unplug the board and take pictures of it, which can be useful later on for tracking down
connections.

[2. There's always a man in the middle]
Now that we feel like we have a confident enough understanding of the surface,
let's try to get to our potential first targets already! Testing the CPU
and CPLD is usually done through a non-standard connection called JTAG,
which is different for each component.
We will first try *scanning* those ports to see if we can already find any of
them operating under at least what is COMMON of the JTAG.

For this, I use a tool called the JTAGulator, because this is what I currently have on hand. 
However, if you don't have the money to spend on this piece of equipment, an Arduino can to do the work,
if wired and programmed correctly.

And...there we go! Results found for the first port! I'm also scanning the
second port too, but we can make an educated guess that one of them is for the
CPU and the other for the CPLD.

In addition, if you can't find any unused connectors on the board,you can 
look for test points, which most likely look like big (soldered or not)
conductive points on the board compared to the rest of the surface.
The pictures I took earlier could have been used to map out connections of
those points to see where they are connected and avoid connecting to unrelated
ports.
If the board had more than 2 layers of electronics though, you most likely
won't be able to trace back those points and would be left with
few other options: to test out all test points with a tool such as a JTAGulator,
to wire directly to the JTAG pins in the cpu, which could be tricky, but as those
pins are usually documented, you can do it if you have a good enough solder iron.
You can also just scrap out layer by layer your electronic board to map out all the
connections and act barbaric. That would work, but that would also be pretty overkill.

Now that we identified JTAG, let's see if we can make use of it!.

For this, I'm using OpenOCD connected to a Bus Pirate onto that because then
again this is what I had and that I tried another setup before that sort of
failed miserably.

~~might also want to use this too
For this, I'm using OpenOCD, a free and open source tool that can interface with JTAG,
connected to a Bus Pirate. This, again, is all that I had on hand that worked for me.
-Y2K~~


The first step with OpenOCD is to configure it for the current target, hoping it
is already implemented(crying in despair if your target is unimplemented and
digging your own grave if its JTAG interface is not documented).

In our case, as noted down earlier from what was written on the chip, it's an
ARM STM32F1 something, so let's go with that.

Few moments later and...booyah! We're in! 
But before yelling about your accomplishment yet try to see if you can read the
flash memory (what contains the code the CPU executes) because manufacturers
usually lock down reading after shipping to avoid any hackers to have an
easier job.

In this case we can easily read the flash, so it's a win!

In addition, if the JTAG didn't allow us to dump the flash memory,
unless you can make the code dump itself through some other tricks, you'd need
to go the barbaric way and dump the CPU in acid, scrape it to map out every
layer of electronics and to finally find the floating gate transistor of the
flash memory, analyzing them one by one to get the software code bit per bit.
Needless to say that due to the complexity and the costs required(an SEM
microscope. S E M MICROSCOPE FRICKING HELL)you usually really, REALLY don't want
to go that way.
This has although been done for proprietary chipsets with no documentationvolu
available to reverse engineer them at the electronics gate level or to dump, by
hand, the gameboy bootrom, no kidding.

[3. Reverse Engineering]

Now that we got our flash extracted it should be wise to at least try to read
it! Before looking at how to parse the file, when stumbling around fairly unknown
data, I tend to run it against tools such as Veles or binvis.io to quickly see
what the file is and what does it contain.

In a nutshell those kind of tools associate visual patterns to data patterns,
allowing you to see much better the discrepancies that you otherwise would by looking at hundreds
of lines in hexadecimal.
For example let us say I'm painting something with pretty dark colours, except
in the middle, you'll notice it right away. For a file it would be kind of
trickier if we couldn't quickly see it through visual feedback.

To come back to the main subject though to understand what this flash is and how
it works we should, before anything, try to look at the CPU documentation about
the flash format or try to find compilers online for the kind of CPU you're
working with, which could allow you to see how the binary files are formed.

[[To expand on this subject compilers use what we call "Linker files" which are
basically a fancy name for "we will put code at this place, data at this place,
pad this address with several bytes" etc... Basically it gives you the format
and where the raw code is, which will come in handy when trying to reverse
engineer a flash file]]

After reading a bit through some docs a couple of times, and understanding basically
the flash format of the ARM STM32 CPU, I understood that the first 4 bytes were
the beginning stack pointer, followed by the reset vector. What is this you may
ask? Well then it's simple: This is our Entrypoint!(If you still didn't got it
this is where code actually is). The format itself is a 4 bytes Little Endian value in 
which you subtract one, nothing too fancy there.

Now onto actual reverse engineering work: I myself use radare2, Some might like
it, some hate it, but it is my default choice unless something screws up, then
whatever works, being freeware version of Hopper, Binary Ninja, or a crackedvolu
version of IDA. Yeah I said cracked because a. I almost never use IDA and b.
dudes wtf have you smoked about the prices? Like even Adobe stepped down price 
wise to get more attractive, and don't go telling me you're having issues with money,
 you’ve been one of the biggest shareholders in the market for a good while now!

Anyways rant aside the most obvious thing to do after being able to load the
firmware is to understand what it does! For that I'm going to explain first the
layout and how everything works out and then try to explain how I figured those
things out.

The firmware is divided into 2 main parts. Or 3 depending of your way to see
things. The first part is the bootloader: it doesn't do much apart checking for
the main firmware to be present and booting it, although it contains an hidden
menu, but more onto that.
The second part starts at 0x4000 and is what I'm calling the "User code" even
though the user have no control over that: it is the thing that handles the key
pressed, the buttons, the pads, equalizer, the LCD, input feedback and all the
fancy stuff that makes this device a "Piano". 

The last part is at 0x20000 and finish at 0x40000, being coincidentally the end
of the 256kb of the flash memory. It is the "data" part, containing something
called "Presets". Basically when you want to compose music on your computer,
your hardware has to know how to talk to the software, what the sliders on the
equalizer are linked to in the software, and what the pads, potentiometers or even
recording buttons should be linked to. MIDI Keyboards have an automated way of
handling that called "presets" which basically tell the software "Hey this
button is connected to that" without having to do it yourself manually.

For the code itself bootloader, well, initialize itself: it begins by fancy low
level stuff and then goes to something that I call the "Bootloader Recovery
Menu". It checks if the strings at 0x08004100 and 0x0800050c are the same, both
of which are "MPK88Richard". 
As a funny note we can dedicate thanks to that the full name of the engineer that
designed and programmed the board was Richard Edmonds, as his family name was
printed in the silk of the PCB and his first name on the software.
Moving on, it verifies both strings to ensure the User code is actually present
before trying to boot and, failure to that, launch the bootloader recovery menu.
You can also force launch this menu by using the key combination <<, STOP and
REC.
This menu allows you to erase the User Code and update it.

For the User Code: you basically have a main loop rendering each "frame" of the
LCD and listening for user inputs, sending back MIDI packets. This contains the
settings, menus and various visual feedbacks of the data sent such as the
"scaling" tower when using pads or sliders.

Now here comes the fun part to explain: how did I understand how this piano
worked?
Well I can't do a full crash course on assembly in one video but when you
analyze binary code it is far from being even seemingly the same as the source
code you compiled to make the executable. You cannot "read back" the software as
if it was source code and just read it like a book.
Instead, this code is compiled into an assembly language, a low level code that
the CPU can understand.
Instead of having a huge set of functions you could use, define and such, an
assembly language have a set of defined instructions, which are just made to do
mathematical operations and deal with memory: move data X at place Y, add 2 to
variable XYZ, etc...
Even funnier is that this actually is sufficient to do pretty much everything!
You might wonder how the program can now do arithmetical tests with a subset of
function so little and well let's put it this way:
you subtract 16 to a variable. This operation returns an "Overflow" flag if the
variable is less than 16, since the value comes from 0 to MAX_VALUE when
decreasing in the electronics world. Then the program decides to change a
variable since your value is less than 16, which happens to be a value called
the "Process Counter", telling your program which data to execute, which
successfully allows you to redirect code execution!
This might seem crazy but I have even better: A compiler exists that compiles
your software using only one operation: mov, an operation to move value from one
place to another.
That's right, you can have a full computer by having only one arithmetical
operation!

Now that we view assembly as just a bunch of math operations how do we
distinguish one from another? How do we think that this function allows you to
print text on the LCD and this one to wait for one MIDI packet to be received?

There are two ways to approach this problem and I'll begin by the hardest as you
cannot always use the second method: Static analysis.
In static analysis, all is about patterns; You start from what you know, being
the entrypoint of the program, or strings the program use, and make your way
down the rabbit hole.
Let us look at the bootloader recovery menu for example: we see that it calls a
function with twice the same strings at 2 different addresses, and if you follow
the function that actually compares them, and pass the string "NO FIRMWARE"
to a function, this way you can understand that the last function called with
the string is a print in the LCD screen, that a "Firmware" exist inside of the
flash bootrom, which you now roughly know the address, that it is customizable,
as it can warn you about no firmware being found!
So much for just guessing what some function do!

For trickier instructions modifying value in memory, such as 0xE000E100, which
you don't fully understand you usually check the CPU documentation for them. In
that case the documentation tells us it is related to the NVIC IRQ, which, in a
nutshell, is used to change Interrupts. As we already know Interrupts are
addresses at which you can go if anything goes wrong or just to start the
program, but Interrupts can also be used to "listen" at inputs! For example,
each time you type with your keyboard, an interrupt is pressed which launch the
loop telling the software "hey this key has been pressed".

The same is true for Inputs/Outputs, usually just trying to see which address it
is poking and reading the documentation will help us tremendously!

But that isn't always the best approach to Reverse Engineer a software, so here
comes Dynamic Analysis! This method is the computer representation of poking
fire with a wood stick and see if it burns; no really.
We start up something we call a debugger which can allow us to trace back every
instruction executed, stop at a point of the software, skip a bunch of
instructions and jump at another place of the software et cetera.

For this, using my current setup with the debug JTAG access, we will use Gdb
connected to OpenOCD.
As you can see connecting isn't hard, and the work is less;
You usually put down a breakpoint, which is something which allows you to pause the program, step
through some instructions and try to see what they do by comparing registers(our variables),
 the stack(a bigger list of data) or memory. or even the Inputs/Outputs!(such as the LCD/packets sent
through the USB cable)

(What is Gdb?)

On top of all of that, software such as radare2 shows you a visual
representation of the program, not unlike the mental map we made at the
beginning, allowing us to see what would happen in case this or that failed or
not.

In the end, it's all about recognizing patterns, reading documentation and 
hoping that the fire we are poking won't burn us too harshly!

[4. Engineering]

Now that we have a global understanding of how this piano works the most obvious
thing to do would be to take it over, ie run your own code on it! For that
usually you try to seek up compilers on the net that would suit your particular
type of CPU or, failure to find something good enough, just make up linker
scripts on top of a compiler for the given architecture and build your own
libraries.
In that case I used OpenSTM32. While I greatly despised the GUI interface I've
just used it to create Makefiles to automatically build the firmware, linking the libraries I needed together so
that I wouldn't have to do it myself.
At first I just tried to get an Hardware Abstraction Layer(HAL) working, so that I
could use easily most I/Os of the board and change their configuration if
needed, for example if one I/O was linked to a non standard pin of the CPU.


Getting the HAL working was actually rather easy as soon as I got a somewhat
stable JTAG setup, I then through some Reverse Engineering got the USART ports
used, standard USART2, and began working my way towards what I wanted to do.
But first let's talk about how the whole board was programmed and designed:


I wanted to say that since quite a while now but preferred to wait up until now
to not break the rhythm of the video:
WHAT THE FUCK IS THIS BULLSHIT???!

Like okay this board was made in 2009, 9 years ago currently so I can understand
about the fact that they left the flash in read/write mode and not write only,
that's just one stupid mistake but after all security of a piano wasn't exactly
one of the main goal and the engineer could just have been nice and let users
hack their devices if they wished, who knows?

But now: WTF IS WRONG WITH YOUR UPDATE SYSTEM??
I mean you just write back into the firmware section what is sent over USB and
as sole check before executing it you verify that the string "MPK88Richard" is
there at the beginning. Not only does this allow rogue updates but those rogue
updates have full control over your piano, including the power to modify the
bootloader, or to remove it, bricking the piano altogether!

And that's just the tip of the iceberg, because they are storing settings of the
piano in the CPU FLASH. IN THE CPU FLASH. NOT LIKE EVERY OTHER ELECTRONIC BOARD
EVER USED A SEPARATE FLASH DEVICE OR EEPROM TO DO THAT, AFTER ALL WHAT COULD GO
WRONG BY WRITING TO CRITICAL STORAGE SPACE WHILE THE PIANO IS RUNNING, SECTION
WHICH CANNOT BE MODIFIED BY THE USER??
ALSO OF FUCKING COURSE STORING THOSE SETTINGS THIS WAY F O R C E THE MEMORY
LOCKBITS TO BE DISABLED, THEREBY MAKING FIRMWARE READ BACK POSSIBLE(unless you
forcefully succeed into disabling JTAG and making sure you need to erase the
firmware to re-enable it but that would really be over engineering at this
point, plus I'm not even sure if this is doable).

Also this could have been a factor of attack as the CPU is reading from its
flash, using a glitch attack you could have tricked the CPU into reading its own
code!

Anyways the whole chain of trust is entirely broken, not like there was even one
to begin with, and users are allowed to brick their pianos with rogue updates. I
personally am all for letting users do what they wish with their material but
knowing hardware vendors I do not think this was their primary idea in mind,
unfortunately.

Now that we own the device, what could we do?
Well let's think like a hacker now shall we? What COULD BE COOL?

My first idea was to target computers from this piano. Indeed, the piano having
an USB port and us having complete control of what is running we could
theoretically transform our Piano into an USB Keyboard, thereby allowing us to
send as quickly as possible key presses that would open a terminal and launch an
executable, which could link back to us, allowing us therefore to control the
computer without the person knowing!
But recently some exploits have been published for the Linux Kernel.
Specifically 14 USB KERNEL EXPLOITS http://www.openwall.com/lists/oss-security/2017/11/06/8
So piano to kernel exploit? Seems like a deal to me!

Another thing that could have been cool would have been to simply wait for a G
to play and then to play back the Flintstones theme, disregarding any input from
the user.

I unfortunately don't have enough time to really explain either nor is it
really the subject of the video, focused on hardware hacking, not software
hacking, but I'll get back to software hacking a bit at the end. 

Either way, we own the device and the project is successful, reliable code execution on a Piano, rogue updates and 
linux kernel exploit!

[5. Appendix]

Now that we more or less finished the project for the piano, except for the exploitation 
part which I do not have the time to explain in that video, let us review a bit of hardware exploitation as a whole.

While I actually have shown a fairly straightforward approach on how to get the firmware, hardware
exploits can also be used to make the hardware reveal important data; Such an attack can be
a Correlation Power Analysis which, in a nutshell, analyze the voltage that the CPU takes(the CPU needs
to take more or less voltage to modify the state of logic gates simply put) and correlates it to known cryptographic
algorithms, allowing you to retrieve one cryptographic key only from knowing the voltage the CPU used during the operation!
In the same kind of attacks you also have glitch attacks, which tries to change the behaviour of a program through changing 
the voltage of the supposed stable voltage line. This can lead to a bad execution being parsed and the CPU jumping to an error
vector, to a variable being corrupted and nice things like this. You can also do this through glitching the clock, supposed to,
well, be a clock, and so have a stable frequency or through other means, the sky is the limit!

For entirely unknown chips, before jumping to your fancy 100k€ SEM microscopes and burning you alive with acid,
you can always try a logic analyzer to see the data being sent and received from this chip, which would let you visualize
data in the form of HIGH and LOW, being 1 and 0 in binary. A more advanced voltage checker would be an oscilloscope 
which would be a bit less used as its use is usually to just check differences between voltage, and chips usually interact 
between each other in binary, which introduce always similar voltage changes.

You also have other attacks, such as tweezer attacks, which was forcing hardware to write protected data at an unprotected memory region
by simply linking those two memory regions together, might still be possible depending of the hardware but are pretty much relying on what
you have, so I cannot really be general about it. The best way to think about it is to have a mental map and analyze all the possible factor of attacks,
sort them by difficulty and research about them!

For complex devices, such as those with linux embedded, you also usually have an UART port somewhere on the board, which
you should be able to find thanks to the JTAGulator, allowing you to interact with the board. Coupled with a JTAG access you can skip the linux login screen
and have a shell!




And I'm done! I tried to keep the video understandable and explain as much as I could
about the subject so if you have any criticisms about the format, tell me that you liked this 
or want me to burn alive you can contact me on twitter, @GovanifY, mail, gauvain@govanify.com or read up 
my blog, govanify.com, which is going to have an article as a follow up to this video, going a bit more in depth
over some concepts I tried to introduce in this video or explain more stuff!

I'll also be present at the 34c3, being an annual Hacker congress whose name is the Chaos Communication Congress to 
demonstrate the attack! I'll be there the 28th, 12:25am Leipzig time and I hope to see some of you there!

On those words,
GovanifY...out!