It's assembler, Jim, but not as we know it!
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 |
| |
| Alternativer 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/39716 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
00:00
AssemblerPhysikalisches SystemARM <Computerarchitektur>BitQuick-Sortt-TestSystemtechnik
00:33
ARM <Computerarchitektur>ARM <Computerarchitektur>MultiplikationReverse EngineeringVirtuelle MaschineRISCDatenfeldt-TestPunktSchätzfunktionMereologieDienst <Informatik>BitPhysikalisches SystemVersionsverwaltungWhiteboardQuick-SortFigurierte ZahlGrundraumKomplex <Algebra>SystemplattformMultiplikationsoperatorPhysikalische TheorieDezimalzahl
02:28
ARM <Computerarchitektur>VersionsverwaltungPhysikalisches SystemFirmwareNotebook-ComputerZellularer AutomatGamecontrollerMini-DiscFlächentheorieSystem-on-ChipRouterFreewareStochastische AbhängigkeitBildschirmfenster
03:34
Theoretische PhysikSpeicher <Informatik>Protokoll <Datenverarbeitungssystem>BefehlsprozessorPeripheres GerätBus <Informatik>Quick-SortStandardabweichungSystem-on-ChipSpeicher <Informatik>MAPGamecontrollerBlockdiagrammDatensichtgerätBootenMehrkernprozessorInhalt <Mathematik>ARM <Computerarchitektur>GeradeBefehlsprozessorPlastikkarteEinhüllendePi <Zahl>Leistung <Physik>WasserdampftafelMereologie
04:54
DiagrammVerschlingungSystem-on-ChipWeg <Topologie>EinsEinfacher RingBus <Informatik>BootenSystem-on-ChipNotebook-ComputerARM <Computerarchitektur>Rechter WinkelFlussdiagramm
05:23
Speicher <Informatik>PartitionsfunktionHalbleiterspeicherMultimediaPlastikkarteLineare AbbildungDatenmodellBandmatrixSCSISpeicher <Informatik>PlastikkarteMultimediaDifferenteFlash-SpeicherDichte <Physik>Zellularer AutomatXML
05:52
TVD-VerfahrenFlash-SpeicherATMBootenHumanoider RoboterGraphische BenutzeroberflächeSpeicher <Informatik>BootenTVD-VerfahrenBitDifferenteFlash-SpeicherVersionsverwaltungProgrammierumgebungWort <Informatik>ComputeranimationXML
06:41
Drahtloses lokales NetzPlastikkarteDatenverwaltungPeripheres GerätPlastikkarteDrahtloses lokales NetzSoundkarteDatenverwaltungHardwareQuick-SortLeistung <Physik>DifferenteTVD-VerfahrenGamecontrollerPersönliche IdentifikationsnummerModemPCI-ExpressKette <Mathematik>MereologieCase-ModdingEin-AusgabeCoxeter-GruppeEntscheidungsmodellEinfach zusammenhängender RaumPeripheres GerätXML
07:54
Leistung <Physik>BootenSchlussregelKonfiguration <Informatik>Formale SpracheSerielle SchnittstelleTelnetMinimumBitZustandsmaschineVollständigkeitGamecontrollerBootenFlash-SpeicherKernel <Informatik>Serielle SchnittstelleTablet PCHalbleiterspeicherModemMAPQuick-SortSpieltheorieFormale SpracheJSONXMLFlussdiagramm
08:53
SpezialrechnerBootenKernel <Informatik>ComputerspielCodeBootstrap-AggregationSurjektivitätWiederherstellung <Informatik>BootenKernel <Informatik>FlächentheorieComputerspielOrdnung <Mathematik>Elektronische UnterschriftGamecontrollerCodeSoftwareBildgebendes VerfahrenLastSchießverfahrenFaktor <Algebra>ProgrammierungXML
09:52
DateiverwaltungWurzel <Mathematik>VererbungshierarchiePhysikalisches SystemDisk-ArrayObjekt <Kategorie>DateiverwaltungWurzel <Mathematik>Ordnung <Mathematik>SchnittmengeMultiplikationHumanoider RoboterSchreib-Lese-KopfLokales MinimumVersionsverwaltungARM <Computerarchitektur>Basis <Mathematik>RouterBootenWiderspruchsfreiheitInhalt <Mathematik>System-on-ChipPhysikalisches SystemMultiplikationsoperatorBinärcodeSystemplattformProgrammbibliothekFluidXML
10:51
Nabel <Mathematik>GenerizitätVersionsverwaltungKeller <Informatik>BenutzeroberflächePeripheres GerätBootenARM <Computerarchitektur>BinärcodeKeller <Informatik>Elektronischer FingerabdruckSicherungskopieDämpfungQuick-SortTermHardwareSoftwareRechter Winkel
11:51
SoftwareTaskComputersicherheitSinusfunktionWeb logFirmwareInternetworkingKonfiguration <Informatik>Physikalisches SystemNabel <Mathematik>BlackboxFirmwareWeb logComputersicherheitBinärcodeKonfiguration <Informatik>DifferenteSchwebungInternetworkingPhysikalisches SystemLaufzeitfehlerMomentenproblemDienst <Informatik>Internet der DingeKernel <Informatik>Nabel <Mathematik>Mailing-ListeLikelihood-FunktionSchreib-Lese-KopfTaskSchnittmengeEndliche ModelltheorieMengensystemMultiplikationsoperatorBitÄhnlichkeitsgeometrieCompilerWiderspruchsfreiheitDebuggingXML
13:46
Konfiguration <Informatik>Reverse EngineeringKonfiguration <Informatik>Internet der DingeSpeicherabzugBinärcodeJSONXMLTechnische Zeichnung
14:13
Fuzzy-LogikEmulatorATMSkriptspracheSystemprogrammierungElektronische PublikationGruppenoperationSpywareInterface <Schaltung>ImplementierungFuzzy-LogikEmulatorBinärcodeDateiverwaltungWurzel <Mathematik>DebuggingMini-DiscLokales NetzElektronische PublikationSpywareATMVerschlingungImplementierungVersionsverwaltungSimulationBroadcastingverfahrenChiffrierungAdressraumRouterPunktNabel <Mathematik>InternetworkingComputerunterstützte ÜbersetzungARM <Computerarchitektur>RechenwerkInjektivitätMultiplikationsoperatorInterface <Schaltung>XMLComputeranimation
16:08
BetriebsmittelverwaltungInterface <Schaltung>SystemverwaltungWurzel <Mathematik>MultiplikationsoperatorRouterDirekte numerische SimulationInformationHalbleiterspeicherPunktNabel <Mathematik>Automatische HandlungsplanungSystemzusammenbruchProgramm/Quellcode
16:48
KonfigurationsraumComputersicherheitFormation <Mathematik>ServerProgramm/Quellcode
17:17
DateiverwaltungKugelkappeFlash-SpeicherMultiplikationsoperatorSurjektivitätp-BlockReelle ZahlGemeinsamer SpeicherMessage-PassingEchtzeitsystemProgramm/QuellcodeXMLJSONComputeranimationFlussdiagramm
17:45
Lesen <Datenverarbeitung>DämpfungGanze FunktionDateiverwaltungGraphiktablettHalbleiterspeicherWurzel <Mathematik>POKESchreiben <Datenverarbeitung>InformationFormation <Mathematik>RoutingProgramm/Quellcode
18:19
Gerichtete MengeATMBildgebendes VerfahrenDateiverwaltungMaschinenschreibenFormation <Mathematik>Direkte numerische SimulationPlastikkarteWurzel <Mathematik>InformationHalbleiterspeicherInterface <Schaltung>Flash-SpeicherElektronische PublikationXML
18:54
SpezialrechnerPlastikkarteElektronische PublikationGenerator <Informatik>MinimumExpandierender GraphBildgebendes VerfahrenQuaderStandardabweichungDateiverwaltungComputersicherheitMinkowski-MetrikComputeranimation
19:35
Gerichtete MengeATMInformationPartitionsfunktionTabelleZustandsdichteSpezialrechnerGeradePlastikkartePlastikkarteInformationMultimediaRandomisierungVirtuelle MaschineTVD-VerfahrenMini-DiscHackerSchaltnetzBitXMLUMLFlussdiagramm
20:10
Gerichtete MengeATMDongleWeb logPlastikkarteAnpassung <Mathematik>BitRotationsflächePhysikalisches SystemCase-ModdingXMLUML
20:44
SpezialrechnerMini-DiscKrümmungsmaßGerichtete MengeATMInformationHardwarePartitionsfunktionZustandsdichteTabelleStandardabweichungSpeicher <Informatik>Fermatsche VermutungMathematische LogikAblaufverfolgungSpeicher <Informatik>PunktHardwareLogikanalysatorMathematische LogikXML
21:12
PartitionsfunktionInformationDateiverwaltungVorzeichen <Mathematik>BitrateReverse EngineeringPlastikkarteTabelleBinärcodeOpen SourceHardwareRechter WinkelProtokoll <Datenverarbeitungssystem>Interface <Schaltung>SoftwarepiraterieDatensatzDateiverwaltungTreiber <Programm>Bus <Informatik>BitPartitionsfunktionAuswahlaxiomBinärdatenStatisches RAM
22:30
Quick-SortMultiplikationsoperatorEmulatorCoprozessorInternetworkingJensen-MaßBootenHalbleiterspeicherLineare OptimierungOffene MengeGroßrechner
23:23
HardwareBildschirmfensterBootenProgrammierumgebungMAPParallele SchnittstelleKernel <Informatik>CoprozessorDigitaltechnikGamecontrollerEmulatorProzess <Informatik>
24:23
MagnetbandlaufwerkHardwareGroßrechnerLeistung <Physik>SpeicherabzugInstallation <Informatik>Parallele SchnittstelleZustandsdichteVirtuelle MaschinePhysikalisches SystemNotebook-ComputerProgramm/QuellcodeComputeranimation
25:07
ZustandsdichteDatenbankInklusion <Mathematik>ProgrammierumgebungBinärdatenHydrostatikBootenVirtuelle MaschineZustandsdichteBinärdatenDateiverwaltungTypentheorieVersionsverwaltungWurzel <Mathematik>DateiformatSynchronisierungProgrammbibliothekNummernsystemBinärcodeStellenringHydrostatikPhysikalisches SystemMinkowski-MetrikEmulatorPersönliche IdentifikationsnummerComputeranimationXML
26:28
Demo <Programm>MenütechnikUniformer RaumSolitärspielPhysikalisches SystemSoftwareDemo <Programm>StandardabweichungXMLUMLProgramm/QuellcodeJSON
27:01
StatistikHauptidealringBefehlsprozessorBenutzeroberflächeDemo <Programm>BitStandardabweichungPhysikalisches SystemVirtuelle MaschineARM <Computerarchitektur>QuaderMereologieProgramm/QuellcodeJSONComputeranimationXMLUML
27:28
MereologieBitFormation <Mathematik>JSONXML
27:55
Demo <Programm>Inklusion <Mathematik>Virtuelle MaschineHardwareBinärcodeSchnelltasteProgrammierumgebungSoftwaretestMessage-PassingNotebook-ComputerProgramm/QuellcodeXMLJSON
28:43
GroßrechnerHardwareHardwareARM <Computerarchitektur>Prozess <Informatik>Physikalisches SystemMultiplikationsoperatorRouterSoftwareBinärcodeSchlussregelXML
30:07
BootenEmulationGroße VereinheitlichungDateiverwaltungVorzeichen <Mathematik>BitrateEntropie <Informationstheorie>ATMGerichtete MengeWeb logSpezialrechnerNabel <Mathematik>VersionsverwaltungKeller <Informatik>BenutzeroberflächeMereologieSchlussregelBitVersionsverwaltungPhysikalisches SystemPufferüberlaufRahmenproblemPCI-ExpressGamecontrollerCodeGanze FunktionAutomatische HandlungsplanungBildschirmmaskeTelekommunikationXML
31:26
ComputerspielCodeBootstrap-AggregationSurjektivitätWiederherstellung <Informatik>BootenFormale SpracheSerielle SchnittstelleTelnetKonfiguration <Informatik>Dichte <Stochastik>MultiplikationsoperatorFormation <Mathematik>Computeranimation
32:07
DatenverwaltungPlastikkartePeripheres GerätTechnische InformatikSchlüsselverwaltungBootenRouterHardwareMechanismus-Design-TheorieQuick-SortARM <Computerarchitektur>NormalvektorPasswortHackerTablet PCBus <Informatik>ChiffrierungPCI-ExpressDateiverwaltungGraphiktablettKonfigurationsraumFormation <Mathematik>Abstimmung <Frequenz>
33:26
Konfiguration <Informatik>Wurzel <Mathematik>TelnetATMGerichtete MengeInformationBootenPartitionsfunktionElektronische PublikationVorzeichen <Mathematik>Formation <Mathematik>Peripheres GerätProgrammierumgebungSystem-on-ChipSpeicheradresseFramework <Informatik>HalbleiterspeicherComputeranimation
34:00
EmulatorHardwareReverse EngineeringEmulatorPeripheres GerätTreiber <Programm>Bridge <Kommunikationstechnik>SoftwarepiraterieBus <Informatik>Formation <Mathematik>HardwarePhysikalisches SystemInternetworkingReverse EngineeringRechter WinkelARM <Computerarchitektur>HackerComputeranimation
Transkript: Englisch(automatisch erzeugt)
00:00
Hi, my name is Morgan Gengmer. I'm a student, but first you've made it to talk about ARM and all sorts of fun stuff. So first a little bit of a dedication to my father. My father is an embedded systems engineer. What you're seeing right here is he has one arm. He taught me to build my own tools. Keep building your own tools. You will learn so much just by exploring your world, and he taught me that.
00:26
And I want you to come out of this, at least with explore your world, know how it works. Thanks, dad.
00:40
I'm the hoopiest food that ever did cross the universe. I know exactly where my towel is. It's a little puck. I bought it from REI. I've been fiddling with Linux stuff for a good 10 years now. I got an old embedded ARM board from my father at one point. I've done ARM services for the last little while. I've even built my own version of cyanogen just to try and get it to build on a machine.
01:00
I'm actually a student by day. I try to not talk about it as much because it's in a completely unrelated field. I'm here because it's fun. So this talk is a fair amount of kind of theory. There's a whole lot of complex and like, ooh, look at this sweet trick that you can pull. This is because this sort of work, reverse engineering, is one part science, one part estimation,
01:24
a dash of bitter feelings about everything in the world, and a little bit of hint of, what the fuck was that EE thinking when they built this? A lot of things come from experience. I can point the way, but I cannot see the future. You will have to learn many little tools and techniques on your own. There are a lot of seemingly random parts in this talk. They'll all come together.
01:43
So first, let's talk about ARM. The BBC to your face. ARM originally stood for Arachronal Risk Machine. If you think you are away from an ARM machine, you are sorely wrong. ARM originally built the ARM1 chip for the BBC Micro for a lightweight risk system.
02:04
Acorn changed hands a couple of times. They've never cut silicon, but, fun fact, Intel has cut silicon for a non-Intel platform multiple times, especially after they have bought DEC. The ISA actually hasn't changed about 20, 30 years. You can still read ARM1 assembly from the 80s, kind of figure it out, and then run it on a brand new ARM chip today.
02:29
There are ARM devices all around you, including in routers, cell phones, NAS devices. QNAP actually has a version of their NAS that runs on a Cortex ARM system.
02:40
Synology is another company that produces hundreds of devices that run on ARM chips, and even new laptops with Qualcomm Snapdragon chips are coming out today that are running Windows, Linux, everything. In the non-SOC world, ARM takes up everything, from smart watches to home lighting to even in your laptop today.
03:07
In the surface alone, there are four or five ARM chips, just for things like firmware control, disk access. Even the touchpad has two independent ARM chips. The Steam controller is built around a Cortex M0, and IKEA's trot-free
03:21
lighting system is built around an embedded Zigbee and Cortex ARM0 base station. Sony has been building ARM into their cameras for a long while, and your camera today probably runs ARM. So let's talk about embedded Linux at a kind of high level. An embedded Linux device looks like three parts, storage, an SoC, and RAM.
03:45
Everything else is a bonus. You're going to see physical devices on I2C or USB or SDIO. There's standards for how cameras and displays work. A lot of this has been hashed out pretty straightforward. It looks a lot like a standard PC today, and the lines are getting really blurry.
04:04
So let's ask the question of what is a system on chip. It's a just-to-add-water sort of easy design peripheral. What you're seeing here is an orange Pi with an all-winter chip. That is a quad-core ARM device that you can get for $10.
04:22
This is really amazing, actually, because now we have stuff in today's world where you can put this onto a breakout board, add power, boot Linux from an SD card, and actually build a device. This has meant that there's a lot of devices that are using really cheap SoCs, including our phones.
04:43
Everything looks about the same, especially when you look at the block diagram. Everything sits on an internal bus. There's a peripheral controller for external content. There's a storage controller for boot content, a GPU, a CPU, some external peripherals. Once you've seen one, you've seen them all, including ones from Intel. You don't actually always see ARM stuff on an SoC.
05:03
This is from Bay Trail SoC that goes into a laptop. As you can see down there, there's even an old SM bus and what looks to be boot ROM and legacy stuff to hold all of the old x86 stuff that has been sitting there, withering away in a corner, because nobody runs 32-bit x86 anymore, right?
05:24
Storage comes in a couple of different flavors. MTD, which is basically a cheap way to say, ooh, this is Flash. EMMC, which are called Embedded Multimedia Cards, SD cards. And if you've ever seen an SD card in a device, you have just won the jackpot. Then there's UFS.
05:41
UFS is a new standard that's come along in recent years for the purposes of cell phones for higher speed, higher density stuff. If you have a newer cell phone, you are probably using this. There's a lot of different variations for this. Some devices have a little bit of onboard Flash on the chip so that they can load the first stage bootloader.
06:01
This is common on phones, stuff like fast boot boots from this. Every vendor has their own way of shoving bits onto a device. They all suck. RAM, you're going to see a whole lot of different variations of this. Vendors are notoriously tight-assed, especially after the terrific price fixing that SK Hynix was found of doing.
06:21
But consider that there's a lot of devices that have 8 megabytes of RAM, including the word 54G. And later, they did another revision that had 4 megs of RAM. But modern phones are hitting the realm of a gig to 4 to 6 gigs. In a pure Flash environment, you might actually be losing RAM because Flash can sometimes be slow, and it's faster to shove things into RAM.
06:42
When it comes to peripherals, you've got SPI, I2C, I2 sound. These are common stuff. But then you're going to see really crazy shit in there. SDIO wireless cards are not uncommon. Turns out SD cards were also built for general purpose I0 devices, and so they actually talk a slightly different variation of SPI.
07:02
You're going to see sound cards over I2 sound. GSM modems, most of them are just pretending to be Haze AT modems. Power management is all the rage. You'll see LEDs on your GPIO pins. Go look around in CyanogenMod and you'll see all sorts of different examples of this.
07:20
Linux doesn't care if they're on die. This is an example from a Snapdragon 820. A PCIe, a UART, and a PCM chain are all used just for the wireless LAN and Bluetooth. This is so that they can turn Bluetooth audio into just another channel on the audio stack and completely abstract away the actual hardware. The PCIe is typically for wireless LAN connectivity,
07:41
and the UART is actually going to be probably for part of a baseband controller for the Bluetooth. Again, Linux doesn't care if these are on die. You could have these emulated somewhere. You could have them completely non-present. Another good example of this is the NexBit Robin. The flash on the camera is done through GPIO.
08:01
It's a bicolor LED. But all of the LEDs in the back, including the bottom notification LED, are actually run off of a small TI light LED controller that has its own ISA and is actually its own complete state machine. When it comes to bootloaders, there's one predominant game in the market, DOS U-Boot. It has a very simple scripting language, talks over a serial port.
08:22
It can pull over TFTP, HTTP, all sorts of stuff. You can shove X modem kernels at this thing. It doesn't care. All you have to tell it is I want to put this thing in memory at this place and then jump to this place and execute. Some devices don't use U-Boot, though. Fast boot is a very common thing to see on phones.
08:41
Some Linux tablets are also built around U-Boot, but more often commercial devices you might be seeing. Samsung has their own stage 2 bootloader and such. It's all something interesting. So let's talk about the life and death of an SoC-based device. First off, it does a DFU check to see if there's anything to load fresh code onto it.
09:02
Then it loads its initial program loader. This is from the vendor, typically. It does any signature checking from the initial image. This is typically burned straight onto die at factory. Then it pulls in the bootloader for early UART network wakeup, especially if it's a network boot device. Then you get U-Boot loading kernel into RAM for some other fun stuff.
09:24
It kicks the kernel, and then you're in user space. The fun shit is in the DFU, because that's the first chance you have to actually attack the device. If you can get life at DFU, then you can run whatever you want on it. You have full control over everything that's happening. If you can interrupt U-Boot or any other bootloader,
09:41
then you can run your own kernel. Now you can start attacking other pieces. If you're going to get an attack in user land, that's still fun. You can go and attack the actual surface that most people would be hitting. In order to start a Linux system, you need a root file system. It contains the bare minimum of boot Linux, any shared object libraries, binaries, other content.
10:02
Autofluid content actually gets tarballed up in a lot of routers. You'll see this on a consistent basis. This means that TempFS is going to look really huge, and if you try to extract content from it, it's going to look weird. Sometimes there's actually multiple root file systems. Newer Android phones are running off of a more consistent AB platform,
10:22
which means that you have one version of Android that is known good to boot, and you have an unknown version that has just been applied. You might find yourself scratching your head at times, especially if you've gotten a dump off of a live system as to why you're not booting that. That might be why. Some devices might actually try NFS.
10:41
There's a whole set of devices that internally they have a bunch of ARM SOCs running DSPs, and they're going to boot off of NFS because that's the easiest thing to do. Attacking these devices comes down to scoping out your device. Get to know what makes your device actually run. Get to know what it's running in terms of Linux,
11:00
what its software stack is, et cetera. If you're going to start attacking Cortex ARM 0 devices in Friends, then what you're going to start doing is looking at what SOC it has, what sort of JTAG ports it has, what kind of backup stuff does it have. Is there a known way to dump the code off of your chip? ARM executables are really generic. ARM really doesn't care as long as you can wake up the peripherals in the right way.
11:23
Under Linux, this means that you don't have to compile for a particular chip. Debian has an ARM HF, and that's for any ARM that has hard float. If you have ARM Arch 64 binaries, they'll run on any ARM Arch 64 device as long as they can load up their loader and their necessary shared binaries.
11:44
Hardware vendors are also dumb and lazy. You will see a lot of devices that are just variations on current existing devices. Don't reinvent the wheel as well. Embedded devices like this are going to be really common, really popular, and they're going to be consistent.
12:01
CenturyLink, for example, sends out really consistently similar devices. Kobo puts out devices that the only difference is what kernel they're running internally. Everything else gets loaded at runtime. OWASP has a whole set of tasks devoted to looking at embedded IoT devices. Their little toolset can actually become really helpful for devices which talk over the Internet
12:24
or which are trying to figure out what's going on. Tools like FirmWalker and such, they are built for turnkey, push this at your device and see what happens. They are intended to start looking and interrogating devices and services
12:41
and especially running binaries to see what's going on. If you are curious about this, there's a fantastic blog called the Firmware Security Blog. They have a whole list of tools. So one option, especially if it's a Linux system, is say it's a Unix system. You know, I know this. If you're going to shell, beat against the shell.
13:01
You have only what's on the target, only what's available at that moment. This is a bit like going into the wild with a Bowie knife and a jar of piss. I mean, it's going to work. You're going to beat your head against a brick wall for a while, but you'll eventually find something. But you have no debugger, you have no compiler, you have no fuzzer. You have none of the tools that most people like to play with.
13:21
The second option is to black box it entirely. Don't even try and pull apart the system. Just attack what externally visible things are. I'm not a lawyer. If you think you might be touching something that's going to violate some NDAs, get a lawyer, but you have a less likelihood of running into some secret. You are only out externally attacking this as though it were just a black box.
13:44
But unfortunately, you've lost the jar of piss and all you have is the Bowie knife. Both of these options suck. So you go, okay, let's reverse it. Pull out Iodide or Redara, any of your standard reversing tools. Grab a beer, learn you an ISA, and off you go. This is a great way to start with stuff like embedded IoT devices,
14:04
like those light bulbs from Philips, Ikea, et cetera. Your smart watch, et cetera. The core problem is how the fuck do you get the binaries? Forget that. You know, but I'm a lazy asshole. I want to fuzz this thing. I don't want to learn IDA. Well, then you emulate it.
14:20
You have every tool at your disposal if you're emulating. Debugger, fuzzer, cool. But you still have that problem of how the hell do you get your actual binary of interest? You get the root file system, especially if it is a Linux device. If it's a standard embedded device, a lot of these tools are going to apply as well.
14:41
Easy mode is update packages. These are probably the fastest way to get a root file system if you have a complete OTA or a lot of routers to ship an entire complete version of the file system. They open up the disk. They say, cool, here's my update, and they just plow right over whatever is there already.
15:01
Sometimes they are actual executables. The downside is sometimes they're encrypted. Sometimes they're really obfuscated. Sometimes they're actually intended to keep you from doing this. The second trick is in-view execution. You're going to need a shell, hijack some administrative interfaces, go back to step zero and start looking at what can you do?
15:22
Is there a known attack against command injection? Can you start netcat? Can you explore what's on the file system through some blind command injection? You might need some kind of packer. There's a lot of stuff built into most BusyBox implementations. You're going to have to find a way to get it somewhere. Netcat is a good example.
15:41
Curl can do some amount of push. You might actually have an HDPD to follow on on the device if you can set up a sim link into whatever it's using. You might need some creativity. I've actually done this at one point. I just simply had the device send its entire disk straight over the local network to a broadcast address and used Wireshark to capture all the traffic and then pieced it back together.
16:06
So let's take a look at what that looks like. So this is me the first time I looked at the Technicolor C100T. This is a DSL router sent by CenturyLink.
16:21
I've turned on the admin interface here, and I'm just poking around what the admin interface gives me. It gives you some information about the memory of allocation. There's some DNS redirecting that you can do. This is really cool. It's been running for a couple minutes. I can actually muck with the WAN interface here. Let's see if we have a shell. Oh, look, we have a root shell.
16:42
The world is our oyster at this point, so let's go peek around. They put fucking plain text credentials all over PS, but what I'm starting to see is like GDB server. I'm starting to see config stuff, TF TPD. I'm starting to actually find some really cool stuff,
17:01
especially if you look very carefully there. You can actually flash from wget straight to the device. Yeah, this is definitely the security. This is available to CenturyLink over their back door. So I start figuring out can I net cap this thing off,
17:22
and then I go and I plug a flash drive into the back because this is meant for shoving printers onto for printer sharing. So I'm going to copy over the MTD flash blocks just directly, and there's a handful of them. I don't care how many it thinks it has. I'm going to copy them all over just because I think I can.
17:41
Some time passes. This takes about 10 minutes in real time, and let's go poke around some more. Turns out we have like scratch pad stuff. There's actually some arbitrary memory read and write that I end up finding here. This is some interesting useful information about how MTD is laid out.
18:03
It looks like there's a root FS and root FS update, which do not appear to be intentionally overlapping, but they are overlapping entirely. I know what kind of file systems it has access to, and just kind of playing around.
18:21
So what did we get out of that? We got a whole bunch of information. We know that this thing has read and write commands that can touch arbitrary chunks of memory, and that it can do things like DNS redirection, and that this is available to CenturyLink through their administrative interface. But more importantly, we got the full root file system. These are ext2 file system blobs just hanging out on a flash drive now.
18:45
Other methods. Surprise is direct extraction. A lot of these devices have an SD card, so pull it out and image it. And you're telling me, okay, asshole, tell me something I can't already figure out my own damn self. SD cards were hiding in fucking plain sight.
19:01
These are like kickstarters for devices that are literally just a Raspberry Pi. There's an anti-villain box, which is intended for Tor security. Over on the bottom left there is the first generation Amazon Kindle device. It just had a standard off-the-shelf 2 gig SD card that you could just pull.
19:22
Oh, you need more space. Well, put a fucking 16 gig card in there. It doesn't care. Kobo is the same way. That's an SD card, just a SanDisk SD card, which you can pull out, you can image it, expand the file systems, off you go. EMMC is just a variation on SD. They're actually both simply multimedia cards.
19:43
It can be done. You're going to have to pull some stuff. You're going to need to understand how the disk is laid out in the end. Having some in vivo information is really helpful, doing some reconnaissance, shelling into your device, playing around like a traditional Unix hacker would, given a random machine.
20:01
Some things are made a little bit harder by the fact that EMMC is also now bound into EMCP, which is LPDDR and EMMC combined. However, all of this is made simple by China, because they need to work on iPhones, and iPhones use EMMC devices. So these are SD card adapters that you slot your EMMC device into,
20:23
and they turn it into a USB or SD card. Or you can make your own. It's just an SD card. It talks for a bit. It's a little bit slow, but it works. And these things are everywhere. These are Raspberry Pi-based devices. The Modberry and Revolution Pi are both DIN-mountable.
20:41
These are going in industrial control systems. All else fails. Solder the rescue. You might need to desolder some storage, especially if you're on EMMC. You might need to drag out some traces. You're going to look for JTAG. If you're interested this weekend, go check out the Hardware Hacking Village and start looking at what you can do.
21:04
At this point, you might be looking for a logic analyzer. Selle makes a really good one. It's cheap, runs over USB, does a lot of the decoding for you. There's also hardware interfaces to talk to a lot of this stuff. On the left is the Bus Pirate. It is an open source SRAM-backed protocol analyzer.
21:22
It has a lot of stuff baked in. On the right is the SPI driver. It is a little USB device that lets you make up an SPI interface. But you can run it at any speed. You can see and visualize what's going on in the wire. So now that we have that, what the hell do we do? You try extracting it.
21:41
You mount it. You take a look at what you've just pulled. EMMCs regularly and sometimes do have partition tables. SD cards more than likely because somebody's actually on a PC had to touch this thing. Go back to the reconnaissance. Go back to step zero and see what you found. Then let automation do your work. Look at Binwalk.
22:01
Binwalk is a fantastic tool for anybody who is getting into reverse engineering especially. Tools like Photorec might actually be useful. You might have to get a little bit more creative. Ello Setup and Friends can do a lot of stuff like finding partition tables. They can find certain records that mark that this is a file system.
22:20
If you're only looking for stuff for like IDA and Redari, once you have your binary of choice, automation might be the easy way to get it. This is kind of where you're going to stop. However, if you're looking to actually attack this thing live, you want something like QEMU. Because the problem is these devices are slow. The device that sits and does my internet at home
22:43
is an 18 megahertz device. It has shit all for RAM. I don't want to sit and try and figure out how to cross-compile my fuzzer and something and run it on there and try to beat it against it. It takes five minutes to boot. Every time I touch a bad chunk of memory, it reboots.
23:00
Then I'm down for another five minutes. Now I'm back to where I started. QEMU allowed to do some stuff. It's a simple, fast processor emulator for all sorts of stuff like mainframes, ARM, MIPS, OpenRISC. You can pretend you're an STM32F4 or you can pretend that you are a DEC alpha.
23:21
You can run OS X on Amiga. You can even run Haiku on BOS. There's two ways to run QEMU. As a full FAT VM or as a translating loader. With the full FAT VM, you have full control over everything. You are the hardware. This is an in-circuit emulator for everything.
23:40
You've got GDB at kernel level because you can step through the entire processor. It requires zero trust in whatever binary you're working with, especially if you've got something that you might think is malicious. You probably want a special kernel if you're working with this. However, there's a lot of ways to make QEMU do what you need to do. Any tools that you need, you're going to have to push it into the target environment.
24:01
And I hate cross-compile. So that's why I typically use a translating loader. You have access to whatever you're doing. The downside to translating loaders is that it's kind of like Wine, except that it can't run Windows executables. It's intended to run Linux executables directly. You can run it in a container, so now you can completely automate a process.
24:20
You can run this in parallel. You don't need a container. So this is actually a full FAT VM. I have a friend that needed some work done. This is a nine-track tape drive from Overland Data with a laptop running MS-DOS 6 as a full FAT VM over the parallel port interfacing with real hardware.
24:43
Here I'm actually reading blocks out of an AOS install tape from a data general mainframe that we had picked up. This is just to the system. It's running on an old DOS machine. It's old. It's slow. I'm running on a Core 2 Duo.
25:00
This doesn't require a whole lot of power, all things considered. But what it does mean is that you don't have to worry about is the hardware actually there? Do I have to drag out a DOS machine? No, you just boot DOS out of a QEMU. As a loader, you're relying on bin format. Long ago, Linux had the ability to just say,
25:21
hey, I need to say that this is my executable for this type of executable. It was originally for running JARs so that you could run JARs from the command line. Turns out it's a great place to put emulators. QEMU has a static version, which runs entirely in user space, and it uses the magic number system that's baked into bin format.
25:43
Debian puts it in their bin format package and a couple others. Without a container, it's dumb simple to set up. You just call bin QEMU whatever static. You call your binary. It all goes. You have to trust that your executable isn't malicious. You also have to have all of your local libraries sync up to whatever libraries it had.
26:03
This works best for big static monolithic executables like BusyBox. However, for a container, you can bring that whole root file system along. You can bring those weird versions of glibc. You have effectively a little jail. You can run it in Docker. You can run it in systemd's machine containers. It's great for when your binary is linked against some weird,
26:22
like, oh, we had this idea, and let's go mangle glibc. For this next demo, we're going to look at a piece of software that's running on what is more normally known as IBM Z14. If anybody is familiar with S390X, it's actually compatible with the system 360.
26:45
So this is a quick user demo. So here we are. We're starting an S390X container from systemd.
27:00
We have, you know, standard thing here. You can see that it's changed a little bit in Htop, but to everything. It's a standard S390X system. But for fun, we can also do this for ARM. Again, my machine just says, yeah, you're an ARM system. Never mind that this is actually internally just an x86 box.
27:21
It's actually a VM running inside a VM. QEMU in this way is really astonishingly powerful. The big part is you can run AFL internally. AFL is a fantastic fuzzer, and AFL has support for QEMU. There's a little bit of setup. You have to bring a copy of QEMU built for AFL
27:44
for your target alongside. I've done this in a VM. It's really slow, and it works. So here we are.
28:03
We're going to run our S390X, and we're going to bind a couple of things over from the Debian machine that I'm running this on. I've compiled AFL for x86 already. Here's our target executable. It's a 64-bit IBM S390 executable.
28:22
We're going to tell AFL, hey, here's your AFL pass, and AFL starts up. It's got a couple of small, simple test environments, and this is actually really slow. Here we can see AFL is attacking an S390X binary. I don't have S390X hardware. I have a cheap laptop with a VM.
28:46
So what we learned is that hardware vendors are lazy. As we saw, a lot of these devices are going to be very similar to each other. There is a lot of duplication in so many things. Attacking hardware means getting really creative.
29:01
You're going to see a lot of stuff. That whole process of pulling off a CenturyLink router's firmware, that was the first time I had seen it, and that took me just over an hour so you can peek around. You spend a lot of time doing reconnaissance. You start looking at what is my device doing.
29:21
QEMU is pretty new. It is fundamentally a way to make a piece of software pretend that it is on the actual piece of hardware that it believes it is. QEMU can actually be used for way more. There is, again, an STM32 port. You can run it on embedded ARM. You can run QEMU on ARM to pretend that it's ARM
29:42
if you have the wrong kind of ARM. For a little while, I was doing this so that I could use ARM64 binaries on ARM32 systems. It works. It's slow, but it works. AFL also runs really slow when you're emulating x86 stuff on the other way around.
30:03
And remember rule zero. This is the big part here. That little rule zero, a lot of reconnaissance, a little bit of planning, can save you hours and hours of a headache.
30:23
Sometimes just simply noticing that there's an EMMC device means, oh, I'll desolder it, pop it into a reader, I'm done, I don't have to worry about how am I going to extract this. Then you find out that it's encrypted. Well, all right, then you go back, you start looking. You start sniffing the wires.
30:43
A lot of creativity comes with things like when fail overflow, did there attack on the PlayStation 4? They found out it was just an x86 system. So what they did is they intercepted a lot of the communications between two sides by running PCIe over a UART at 9600 baud
31:02
so they could watch each frame visually as it went through their entire system. And people are lazy. Remember that the Xbox One, PS4, and probably upcoming versions are just x86 systems. They're just putting newer and more creative forms of control
31:22
on how code gets loaded. Attack early and find interesting ways. You will pore over documents in broken Chinese. You will pore over documents in broken English. I have spent many hours sitting in front of data sheets that were I copied and pasted this out of a PDF into Google Translate
31:44
and then had to re-translate it because the company that makes it only makes it in Chinese because all the engineers are Chinese. You'll see stuff, you know, don't be afraid to look for TFTP.
32:00
Your device actually might pop open in TFTP early. Meraki devices for a long time did this, and it was really interesting. Yes. The comment was that a lot of consumer routers will boot from TFTP
32:23
if they can't boot from their normal file system. And yeah, that happens. If you can induce that failure, it might be as simple as a paperclip. This is, you know, a paperclip is how you defeat on a lot of older Thinkpads the lockout mechanism. So you cause the thing to boot, misread the boot configuration,
32:42
and then out comes an empty slate. You go back into the boot configuration, the BIOS, and it goes, I don't have a password. All the encryption keys have been wiped. So now you just have to reboot and you have no encryption keys. This sort of stuff is pretty common. Again, if you're interested, go look at Hardware Hacking Village. Explore what hardware engineers have to build
33:04
because you will wonder, what the hell was that EE drinking on that day? Because people put PCIe devices on ARM. There's even, there's a GPS receiver there as well. And that's going over its own custom proprietary bus.
33:25
There are many different ways to attack these. AFL is an amazing tool, if you can get it working, great. So, any questions? Yes.
33:45
So for SOC, the question was how do I emulate peripherals in QEMU? I've worked predominantly in environments where I don't have to worry about peripherals. I know that there is a framework for saying when you write to this memory address, really write to this device.
34:02
Check the QEMU documentation. They have a lot of how to emulate external peripherals. Something like the SPI driver or bus pirate can be used as a bridge to the real hardware as well. You would have to check the documentation.
34:23
Remember, I can't see all the way back. Fantastic. Thank you so much. There's more resources available on the internet. Definitely check out if you are more interested in this. Recon 2010, there was a fantastic talk by Igor Skocinski
34:42
on reverse engineering for PC reversers, as well as the fantastic JTAG explain article. Go look at eLinux and Linux MIPS. There are many targets that you can attack. There are ARM devices and embedded Linux devices all around you, like right here. This is a 100 MHz ARM chip.
35:00
There are ARM devices on your body. There are possibly ARM devices in your body. There are embedded systems everywhere. Keep on hacking.