Infecting The Embedded Supply Chain
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 322 | |
| Autor | ||
| Lizenz | CC-Namensnennung 3.0 Unported: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/39760 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
DEF CON 26219 / 322
18
27
28
40
130
134
164
173
177
178
184
190
192
202
203
218
219
224
231
233
234
235
237
249
252
255
268
274
287
289
290
295
297
298
299
302
306
309
312
315
316
00:00
Kette <Mathematik>SoftwaretestComputersicherheitReverse EngineeringAnalysisDatenverarbeitungssystemSchaltnetzForcingComputersicherheitExploitHackerBitPersönliche IdentifikationsnummerCodeProtokoll <Datenverarbeitungssystem>SoftwaretestKette <Mathematik>SoftwareschwachstelleApp <Programm>Reverse EngineeringEDV-BeratungBenutzerbeteiligungSoftwareentwicklerMultiplikationsoperatorProdukt <Mathematik>Twitter <Softwareplattform>Web-ApplikationHardwareBeweistheoriePhysikalischer EffektProjektive EbeneHilfesystemVideokonferenzTelekommunikationWeb SiteAggregatzustandXML
02:49
AnalysisComputersicherheitMobiles InternetProdukt <Mathematik>SoftwareschwachstelleUmsetzung <Informatik>Web ServicesApp <Programm>Computeranimation
03:23
DebuggingKette <Mathematik>RISCSoftwareDigitaltechnikEmulatorPhysikalisches SystemProgrammiergerätSystemplattformVisualisierungDatenanalyseSoftware Development KitServerSichtenkonzeptAnalysisROM <Informatik>ViewerFlash-SpeicherProjektive EbeneSoftwareentwicklungSega Enterprises Ltd.ARM <Computerarchitektur>Mobiles InternetElement <Gruppentheorie>HalbleiterspeicherPlug inHardwareViewerDigitaltechnikOpen SourceSystemprogrammierungKette <Mathematik>ServerSoftwareProgrammpaketModulare ProgrammierungVisualisierungClientDebuggingLokales NetzEmulatorInstantiierungEchtzeitsystemAnalysisPortabilitätSoftware Development KitTelekommunikationGeradeNeuroinformatikComputeranimationXML
05:19
Kette <Mathematik>SoftwareSuite <Programmpaket>FlächentheorieHardwareTreiber <Programm>FirmwareATMTermProgrammpaketTreiber <Programm>DifferenteKartesische KoordinatenHardwareFirmwareAdditionFlächentheorieProdukt <Mathematik>EindringerkennungSoftwareKette <Mathematik>ATMFlussdiagrammComputeranimation
06:16
ComputersicherheitKette <Mathematik>HardwareDifferenz <Mathematik>Offene MengeTypentheoriePunktComputersicherheitHardwareFirmwareDifferenteMechanismus-Design-TheorieVersionsverwaltungSchlüsselverwaltungOpen SourceKette <Mathematik>XMLComputeranimation
06:57
Kette <Mathematik>HardwareARM <Computerarchitektur>E-MailPersönliche Identifikationsnummer
07:32
InformationKette <Mathematik>RechenwerkKrümmungsmaßBitComputersicherheitKette <Mathematik>Flash-SpeicherComputeranimation
07:58
Kette <Mathematik>Hintertür <Informatik>Flash-SpeicherDatenfeldGanze FunktionProgrammverifikationInhalt <Mathematik>PaarvergleichHill-DifferentialgleichungKette <Mathematik>SchlüsselverwaltungARM <Computerarchitektur>ComputersicherheitBitComputeranimation
08:24
Kette <Mathematik>SoftwareSoftwareschwachstelleReverse EngineeringEin-AusgabeMathematikElektronische PublikationRechnernetzInterface <Schaltung>SoftwareSoftwareschwachstelleKette <Mathematik>VektorraumInterface <Schaltung>VersionsverwaltungPhysikalisches SystemCodeDickeElektronische PublikationBildschirmfensterPunktDifferenteComputerunterstützte ÜbersetzungEin-AusgabeKartesische KoordinatenGenerator <Informatik>Keller <Informatik>ZeichenkettePuffer <Netzplantechnik>BinärcodeReverse EngineeringBitZahlenbereichBetriebssystemFunktionalanalysisOrdnung <Mathematik>SoftwaretestMAPPi <Zahl>HyperbelverfahrenComputeranimation
10:03
Elektronische PublikationKette <Mathematik>SoftwareschwachstelleTablet PCExploitFunktion <Mathematik>Format-String-SchwachstelleTeilmengeDateiformatROM <Informatik>SystemzusammenbruchExploitZeichenketteBitDateiformatSoftwareschwachstelleFunktionalanalysisSchreiben <Datenverarbeitung>Computeranimation
11:00
Kette <Mathematik>ProgrammfehlerWurm <Informatik>Syntaktische AnalyseCodeSoftwareschwachstelleProgrammierumgebungFlächeninhaltPufferüberlaufElektronische PublikationSkriptspracheBildgebendes VerfahrenComputeranimation
11:31
AdressraumSystemaufrufKontrollstrukturFolge <Mathematik>Physikalisches SystemAdressraumSystemaufrufZeiger <Informatik>MultiplikationsoperatorCodeParametersystemBinärcodePhysikalischer EffektBitXMLComputeranimation
11:59
Elektronische PublikationKette <Mathematik>SystemprogrammierungRekursiver AbstiegCodeStellenringBinärdatenProxy ServerNabel <Mathematik>Reverse EngineeringCodeNabel <Mathematik>ProgrammbibliothekPhysikalisches SystemZweiunddreißig BitProxy ServerBinärcodeComputeranimation
12:18
ProgrammfehlerCASE <Informatik>SoftwareentwicklerElektronische PublikationBinärcodeMultiplikationsoperatorE-MailFirmwareSyntaktische AnalyseFlussdiagramm
12:40
PufferüberlaufZeiger <Informatik>Funktion <Mathematik>PASS <Programm>SoftwareschwachstelleKette <Mathematik>FlächeninhaltSchnittmengeFunktionalanalysisARM <Computerarchitektur>Funktion <Mathematik>ProgrammpaketDifferenteElektronische PublikationZeiger <Informatik>CodeFahne <Mathematik>ProgrammbibliothekUmwandlungsenthalpieSyntaktische AnalysePufferüberlaufComputeranimation
13:11
ExploitStatistikTelnetÄhnlichkeitsgeometrieBitTelnetServerReverse EngineeringGewicht <Ausgleichsrechnung>ZahlenbereichSoftwareRPCFunktionalanalysisSystemzusammenbruchXMLComputeranimation
13:58
SoftwareschwachstelleProgrammfehlerSystemzusammenbruchKonditionszahlWiderspruchsfreiheitROM <Informatik>PufferspeicherKette <Mathematik>Minkowski-MetrikLokales MinimumPi <Zahl>ParametersystemZeichenkettePhysikalisches SystemFunktion <Mathematik>AdressraumZeichenketteKeller <Informatik>URLZeiger <Informatik>Wurm <Informatik>ProgrammfehlerSystemzusammenbruchInverser LimesPhysikalisches SystemPufferüberlaufKonditionszahlKette <Mathematik>Reverse EngineeringMinkowski-MetrikProgrammbibliothekOrdnung <Mathematik>BitExploitAdressraumPi <Zahl>Computeranimation
15:28
Minkowski-MetrikBenutzerfreundlichkeitZeichenketteParametersystemAdressraumExploitSystemaufrufMinkowski-MetrikInverter <Schaltung>MultiplikationsoperatorWiderspruchsfreiheitParametersystemPhysikalisches SystemWurm <Informatik>URLZeichenketteSharewareKnoten <Statik>ExploitServerComputeranimation
16:10
Case-ModdingServerHintertür <Informatik>StellenringKette <Mathematik>CodeKanal <Bildverarbeitung>Exogene VariableSerielle SchnittstelleProxy ServerClientZahlenbereichDezimalzahlZahlzeichenBitAuthentifikationSpannweite <Stochastik>TypentheorieEinfach zusammenhängender RaumZahlenbereichMinkowski-MetrikServerKette <Mathematik>Serielle SchnittstelleSoftwareschwachstelleFunktionalanalysisKartesische KoordinatenDebuggingATMSoftwareDateiformatClientNeuroinformatikPunktRPCFeasibility-StudieLokales NetzComputeranimation
17:55
Serielle SchnittstelleZahlenbereichAnalysisGoogolSpezialrechnerKette <Mathematik>Bildgebendes VerfahrenSerielle SchnittstelleZahlenbereichMusterspracheDickeComputeranimation
18:18
Serielle SchnittstelleAnalysisZahlenbereichZahlenbereichEndliche ModelltheorieVersionsverwaltungDigitalisierungKette <Mathematik>BitAnalysisEindeutigkeit
18:43
Serielle SchnittstelleZahlenbereichAnalysisE-MailKette <Mathematik>Kartesische KoordinatenSerielle SchnittstelleMinkowski-MetrikZahlenbereichEinfach zusammenhängender RaumMultiplikationsoperatorDickeForcingComputeranimation
19:09
Kette <Mathematik>Patch <Software>Exogene VariableServerPi <Zahl>ROM <Informatik>SoftwareentwicklerFahne <Mathematik>ComputersicherheitDebuggingSoftwareQuick-SortEinfach zusammenhängender RaumPersonal Area NetworkFirmwareServerExploitKette <Mathematik>Pi <Zahl>ComputersicherheitAuthentifikationExogene VariableFahne <Mathematik>MultiplikationsoperatorComputeranimation
20:10
Kette <Mathematik>Prozess <Informatik>Große VereinheitlichungMalwareMultiplikationsoperatorHardwareSoftwareKette <Mathematik>Protokoll <Datenverarbeitungssystem>VideokonferenzBildschirmfensterProzess <Informatik>SchnittmengeProgrammpaketFirmwarePerspektiveMalwareVersionsverwaltungComputeranimation
Transkript: Englisch(automatisch erzeugt)
00:00
have two more first time speakers coming up here. We're gonna give them the only piece of DefCon merch that each and every one of you out here could earn but you have to earn it. Not only do we give them shots, they get the shot the noob shot glass that's our
00:23
present to them for coming and giving a talk at DefCon. So, help me welcome Zach and Alex to their first talk. Infecting the embedded supply chain. I was telling them on the walk
00:45
over here I haven't read your abstract but just from the title I saw that and I'm like yeah we need to do better at that cause I work on an embedded device and eh they're poking holes where we've got holes. Alright, help me welcome Zach and Alex. Hello? Can
01:10
this is uh infecting the embedded supply chain. So, disclaimer um we thought we had a 45 minute slot but we actually have 20 minutes so we're gonna try our best to condense everything within that 20 minutes. So, we have a couple of videos um which we'll try to
01:24
do. We'll try to get to everything um but if we don't make it to everything we'll post everything to our website summersetrecon.com and we'll have proof of concept code on GitHub as well. So, you guys can check that out. Um I'm Zach um like I said I work at Somerset Recon. I do a combination of web application pen testing and reverse
01:45
engineering. I specialize in vulnerability research and exploit development. I'm Alex uh I'm a barista that occasionally does security things at Somerset Recon. Uh I enjoy making cappuccinos, hardware hacking and reverse engineering. Um just a little bit
02:01
about Somerset Recon. We are a security consultancy based out of San Diego. We specialize in web applications, mobile applications and embedded device security. Um and you can find out more about us at summersetrecon.com. And our Twitter. Cool. So, aside from our day to day work we also like to do uh some cool side projects. Uh one
02:23
of which was an electronic safe lock that we looked at um that allowed you to uh either enter in a pin manually to unlock a safe or you know over bluetooth on uh your uh favorite mobile device. Um we found some vulnerabilities there including being able to dig deep code pins wirelessly over the air and replay them. And also um we reversed
02:45
the uh wire protocol and created a brute force um device for that. Um we also did work on the hello Barbie which is an IOT doll that um kids can talk to and have a full conversation with. Um we looked at all the uh web services and reversed the mobile
03:01
application and pretty much just figured out how that all worked and found some vulnerabilities and made a white paper which is online as well. So um these are all embedded devices and that's primarily what we focus on uh on our side research. And so when we decided to do this research we wanted to do something slightly different but touched on it still. Um so we tried to look at what all these products had in in
03:30
the tools used to program and debug them. Um so this is our target. Uh we've focused on the Seger Jlink which is a pretty popular device um on both the hardware and the
03:45
software used to control it. Uh the Seger Jlink debug probe uh communicates with a embedded device that you're targeting and trying to program like a mobile device for instance uh over a Jtag, SWD, etc. Um it's an in circuit emulator and an in circuit system
04:04
programmer so it can program chips. It primarily supports uh ARM and ARM Cortex chips but also supports uh some others like Renaissance. Um it communicates with a host uh computer over USB and Ethernet which is kinda interesting. Has a cross platform toolchain and some other cool features. Um and the Seger Jlinks are the most
04:25
widely used line of debug probes available today. Which is a quote from them. That's kinda cool. Um other than hardware they create a ton of software um including like the software package that's used to control the Jlinks themselves. They also have a
04:41
GDB server um RTOS plug in source development kit. Um a couple of real time analysis visualization tools and a graphical debugger. Um we primarily focused on the software suite used to control these Jlink devices. And this package just includes a ton of tools including uh Jlink commander which is like your typical command line tool that you
05:03
would use with most debuggers. Um a GDB server, a remote server which allows a client to connect to a Jlink commander session um within the local network. Uh a memory viewer and
05:21
the typical setup looks like this. You have a host PC that has a software suite installed and you're communicating to this Jlink device over USB and Ethernet. And then you connect it to your embedded target over Jtag or SWD. So in terms of attack surface, I mean there's a lot. I mean this company makes a lot of different products. Um the hardware debug probes themselves were interested in firmware and you
05:43
know uh how that works. And also can you infect the debug probe itself or can the debug probe infect um the end device that you're trying to uh target? Uh and then in addition to that there's a lot of software attack surface as well. Uh there's a USB driver that's included with this device as well as a host of different user mode
06:05
applications that are run. And in addition to that which is also a pretty interesting thing, they have a custom IDE that's also used to develop applications for the Jlink. So hardware. Yeah so we're interested in how the hardware works um extracting firmware. How easy is it to do that? How does the firmware work? Um the feature differences
06:24
between each of the devices cause Segr makes a ton of different types of Jlinks um at different price points of course. And we're wondering like are there hardware differences or is it just firmware? And um with these devices what are the security mechanisms that are on it? Is the device open? Can I flash an open source version of
06:44
firmware or can I modify firmware and flash the debug probe? So this is a typical Jlink EDU. It's kind of like the cheapest consumer end uh Jlink you can get. Um if we focus here and open GIMP. You can see that it is also an ARM device. So the in the
07:04
tool that's used to debug and program ARM embedded devices is also an ARM embedded device which is yeah that's that's pretty nice. Um then we started looking for you know debug ports and found a tag connect which is uh kind of like it it's kind of like a Jtag
07:21
header but um a proprietary connector that has pogo pins. So we had one of those lying around and we were asking well can we do we do we have anything that can program or debug this device? And we're like why not try debugging a Jlink with a Jlink? So it turns out that the security and flash bits are set so that's good. Um the flash bit
07:42
basically means that you can't reprogram the device unless you erase uh flash. Um what you can't do because a security bit is set which basically says uh you can't debug this chip. So it refuses to connect and erase. We were looking for other ways around this so we needed to go deeper. So we took a look at some of the other Jlink debug
08:02
probes and the Jlink mini EDU has an interesting feature in um its ARM chip which is called the backdoor key access. Which is an opt in um feature that basically if you provide the chip with the proper key it will like willingly disable the security bit and
08:21
then you can kind of do whatever you want with the device which is pretty cool. So then we began really looking at some of the uh desktop software that was distributed with the Seger Jlink for security vulnerabilities. We started out just doing some high level reverse engineering. We uh noticed that they distributed their
08:40
software to both Linux and Windows systems. In reverse engineering this we determined that they were using cross compiled code so that eliminated some redundant work uh where the only one of the operating systems versions really needed to be reverse engineered to determine the functionality and vulnerable por- portions of the code. We also noticed that they were using some custom string manipulation code which was
09:03
somewhat interesting and we'll talk a little bit about that more later. Um we also noticed that they used a lot of dangerous functions. They used string copy, string cat and a lot of other things that don't check the length of the destination buffer. From the point of binary protections Seger opted into most binary protections however they did
09:24
uh leave out both PIE and stack canaries in their Linux executables. So once we had that we began setting up some fuzzers in order to uh test the different input vectors, see if we could find any uh vulnerabilities that we could begin to exploit. So we tested
09:42
all input vectors that these applications seemed to accept. We tested files, both network interfaces and command line arguments that they accepted. Since um our reversing revealed that there were some really interesting uh code paths that were somewhat deep and required magic numbers and different things to reach we decided to use a generational fuzzing approach so we used peach for that. Um we fuzzed and got tons of
10:05
crashes and uh began looking into actually exploiting them. So the first thing is the custom string formatting. We noticed in uh looking into this some interesting usages such as shown here where if it were a standard string formatting function it would be a
10:23
format string vulnerability. So we began looking into that a little bit more. So the custom string formatting that they implemented used most of the basic format specifiers such as percent s, percent n, percent d, etc. Um but it did not accept the percent n that's typically used in format string vulnerabilities. Um so with that we
10:45
were able to uh do some of the format string uh exploits. We were able to do arbitrary reads as shown here. However due to the fact that it lacked the percent n specifier that's used to write bits we were not able to turn this into an arbitrary write. Also found in the uh jlink commander tool which we talked about earlier it's a
11:05
command line tool um there's a feature called command file which basically you can feed jlink commander a uh script to kind of set up your environment before you start uh debugging your device and this uh the um file parsing code had a
11:20
vulnerability which was a traditional stack buffer overflow. And so in the image you can see that we kind of just feed a bunch of a's into a payload and then we pass it into jlink exe and it just segfaults. So if you triage that in gdb you can see that it um it tries to return to address 4141 4141. So we went a little bit further with it and we
11:41
were able to create a POC um with like 5 basic steps which is take over the return address, get the address libc, use that pointer to get the address of system and call arguments and you got code execution. Uh we won't be able to go over the POC cause of time but ultimately uh we got code execution. It works on the 32 bit jlink exe binary on
12:07
I386 and AMD64 Linux systems and it's a ROP with ASLR bypass return to libc and reverse shell is very doable but requires ROPing in libc a lot but the general idea is with this attack that an attacker can create a malicious uh command file and dummy
12:26
firmware and send an urgent email um with this as an attachment to a developer at a targeted company. So developer developers are typically pressed for time so they'll probably run this with jlink commander and it would pop a shell and return back to the attacker. Uh we also found uh in the same binary we found a another file parsing
12:47
vulnerability in the settings file flag which is very similar to command file um but it's in a completely different area. Uh it's in a library called uh jlink arm.so and that's where a lot of like the arm specific code is in for like uh uh the jlink software
13:02
suite. Um and this is in particular is a buffer overrun in the BSS segment so you can use this to kind of overwrite function pointers in the BSS segment. We also got this RCE which is cool. So after that we started looking at uh an in really interestingly named executable called jlink remote server. So once we saw this we kind
13:23
of perked up a little bit and began trying to look at the functionality of this executable. So running a basic net set we noticed that it was listening on a number of ports and particularly of interest to us was it looked like it was listening as a telnet server. So we wanted to figure out if this was actually having a telnet server embedded in
13:41
the executable or what was going on there. So a little bit of reverse engineering revealed that they actually had embedded a telnet server within their executable. So it allows users within the network to uh connect to this jlink server and uh do remote debugging. So we began fuzzing this and uh noticed a really interesting crash where we
14:03
had overwritten the uh instruction pointer with AAAA which is always good. Uh we did a reverse engineering and triage on this and picked up a couple things. It was a stack buffer overflow that we were able to trigger remotely. We were not able to get the crashes to be consistent due to race conditions within the executable. We had a fairly
14:25
limited amount of stack space to work with if we were going to build a ROP chain. We were limited to 48 bytes and again we had ASLR and NX enabled on this executable but PIE was not enabled. So we used typical exploitation techniques. We
14:41
used ROP to bypass the NX and then with a ROP chain we did a dereference of the got in order to leak the address of libc. From there we could calculate the offset of system and then do a return to libc. Um the main issue that we ran into here was we wanted to send arbitrary attacker controlled payloads to system and we had trouble kind of
15:04
getting the user controlled strings to consistently be passed in the system. So we realized that user controlled data was being stored in one of two locations in the executable. And due to a race condition we couldn't determine if it was going to be in
15:21
one location or the other. So we tried to figure out if there was some way we could make it more consistent and we came up with the following. So we sort of called this space sleds where we were inspired by the not sled techniques in which nots are prepended to a shellcode payload and it improves exploit consistency. So here we prepend
15:42
spaces to the user controlled command string and we hoped that that would improve the consistency of our exploit. So what we did here is since the two locations where we were seeing the attacker controlled payload string were 72 bytes apart, we prepended 72 spaces to our string and that created an overlap where we could point our argument to
16:05
the system. So we have a demo where if we have enough time at the end of this we'll be able to show. And then additionally in looking into the Jlink remote server we found some other really interesting functionality. So we termed this the tunnel server back
16:21
door and Seger has this as a documented feature within their application. And they said it just provides a tunneling mode from a remote computer into your network and allows remote debugging. Even when they're not within the local network. Correct. So our first thought at that point was I wonder what type of authentication they're using, if
16:44
there's any weaknesses there or anything that we could exploit. So as you can kind of see here, they use magic numbers in your device serial number to authenticate your device. So that was a pretty scary thing. So when you run Jlink remote server,
17:04
with your Jlink device attached, it sends a magic number and registers your Jlink debugger with the server and then it allows client connections to specify the serial number of the device that they hope to connect to. So we looked at the serial
17:22
numbers and realized that there were 10 billion possibilities, which would make brute forcing all of the connected serial numbers a bit infeasible. So we wondered is this actually something that would be a potential attack? Is there some way that an attacker could shrink the space of serial numbers that they would attempt to
17:41
brute force? So we began looking into is there some format that Seger uses for their serial numbers? Is there like some smaller range or number that they start at that we could use to shrink the space? So we Googled Seger Jlink and found tons of images that people had posted online that included their device serial number. We
18:04
called some people that we know that also had Seger Jlinks and asked their device serial number. And in the end, we got about 30 Jlink serial numbers that we were able to analyze and started to notice a few patterns that emerged. So the first two digits of the serial numbers were correlated with the model of device, whether you had
18:25
a Jlink Pro or a Jlink Mini. After that, two digits for the version where if Seger would release a slightly updated version, that would increment. And then finally, the last five digits are a device unique number that's incremented. So doing a little bit
18:42
of analysis on the numbers that we had, we were able to shrink the serial number space and still achieve what we think would be very good coverage with only 100,000 device serial numbers. And assuming about ten serial numbers per second could be brute force, which is about the length that we saw the connections taking with the when it was done properly via the Jlink application. It would take the time from
19:04
31 years to brute force the space to about three hours. The impact here really is once you make a connection via this server, you can do all sorts of things. You can flash new firmware. You could read existing or read the existing firmware or make any sort of malicious modifications to the connected devices. So we disclosed
19:25
Seger and were really pleased with the response. They responded right away and within a week. And it was very ‑‑ we even received a thank you from the founder and CTO of the company. So in conclusion, we just really realized that these devices
19:45
are oftentimes lacking in a lot of the protections and security that we would hope from a device piece of the supply chain. It was lacking the PIE flag, which would have made our exploitation much more difficult, as well as having lacking the security features that are just architectural and no authentication in the remote server or
20:07
anything like that. But wait, there's more. Okay. Before we run out of time, we revisited the Jlink hardware, but instead of ‑‑ from the perspective of trying to manipulate the firmware with a hardware debugging device from the OTA process, we
20:26
realized that if you download a newer version of the Jlink software suite, Jlink commander will ask you if you want to update your Jlink debug probe. So we started from the network perspective and found that there was no firmware blobs being transferred over the network and we thought that was kind of interesting. So we
20:45
eventually figured out where firmware was being stored and how the update process worked. And we reversed the USB protocol to be able to flash the Jlink devices. And it turns out that the Jlink device, when it's being flashed over USB, it does do a
21:04
firmware check, but it's not very good. Hint, it uses dates to check whether our firmware is valid or not. So this could be a bad thing. Also, firmware is not signed and can be modified. So in the end ‑‑ we don't have time for the video, but
21:21
we ‑‑ to illustrate it, we created a piece of malware that runs on Windows. It runs silently in the background and just any Jlink device that is connected via USB, it immediately flashes and completely bricks. By flashing firmware that's set like way far in the future and you can't fix your device unless you have like hardware debugging
21:41
privileges. And that's ‑‑ cool.