├── .gitattributes ├── 2010-07 [Recon] Intro to Embedded Reverse Engineering for PC reversers (draft).rtf ├── 2010-07 [Recon] Intro to Embedded Reverse Engineering for PC reversers (tools).zip ├── 2010-07 [Recon] Intro to Embedded Reverse Engineering for PC reversers.pdf ├── 2012-10 [Breakpoint] Rootkit in your laptop.pdf ├── 2014-01 [CODE BLUE] Intel ME Secrets.pdf ├── 2014-06 [Recon] Intel ME Secrets.pdf ├── 2014-10 [Breakpoint] Intel ME - Two Years Later.pdf └── 2017-12 [34C3] Intel ME Myths and Reality.pdf /.gitattributes: -------------------------------------------------------------------------------- 1 | # Auto detect text files and perform LF normalization 2 | * text=auto 3 | 4 | # Custom for Visual Studio 5 | *.cs diff=csharp 6 | *.sln merge=union 7 | *.csproj merge=union 8 | *.vbproj merge=union 9 | *.fsproj merge=union 10 | *.dbproj merge=union 11 | 12 | # Standard to msysgit 13 | *.doc diff=astextplain 14 | *.DOC diff=astextplain 15 | *.docx diff=astextplain 16 | *.DOCX diff=astextplain 17 | *.dot diff=astextplain 18 | *.DOT diff=astextplain 19 | *.pdf diff=astextplain 20 | *.PDF diff=astextplain 21 | *.rtf diff=astextplain 22 | *.RTF diff=astextplain 23 | -------------------------------------------------------------------------------- /2010-07 [Recon] Intro to Embedded Reverse Engineering for PC reversers (draft).rtf: -------------------------------------------------------------------------------- 1 | {\rtf1\ansi\ansicpg1251\deff0\deflang1049{\fonttbl{\f0\fnil\fcharset0 Calibri;}{\f1\fnil\fcharset204 Calibri;}} 2 | {\colortbl ;\red0\green0\blue255;} 3 | {\*\generator Msftedit 5.41.21.2509;}\viewkind4\uc1\pard\sa200\sl276\slmult1\lang9\b\f0\fs36 Introduction\b0\fs22\par 4 | Currently there is a lot of interest into reverse engineering consumer electronics and other embedded devices. There were some talks and presentations at security conferences, but most of them are about just a single aspect and aimed at people already familiar with the subject. Not many resources are available for those who are just starting out and know only PC software reverse engineering.\par 5 | I have tried to fill this gap and make a basic intro based on my own experience.\b\fs40\par 6 | \fs36 Getting inside\b0\par 7 | \fs22 One of the first steps necessary in embedded reverse engineering is getting the actual code that runs on the device. There are several ways to do it, some easier and some harder.\par 8 | \b\fs28 1. Firmware updates\par 9 | \b0\fs22 Many embedded devices get firmware updates from the manufactures in their life cycle. If those updates are not encrypted or slightly obfuscated, they are the easiest way to get the code. If you're lucky, this is the simplest way, and sometimes does not even require physical access to the device.\par 10 | Usually an update consists of an updater program (mostly for Windows) and the firmware image or images, either as separate files or embedded into the executable. The updater program, when executed, switches the device into the update mode and then sends the images. Sometimes the update is just the image, which should be copied to the device and will be recognized by it by the filename or file contents.\par 11 | Some real examples of firmware updates:\par 12 | a) Sony Librie.\line The update consists of the updater program (UPLIBRIE.exe and EBRCTR.dll) and the firmware file (data.bin). The firmware file is obfuscated with a XOR key, which, luckuly, can be easily found in the executable. Inside there are images of the Linux kernel and the CRAMFS filesystem.\line b) Sony Reader PRS-500.\line The update includes the updater program ("PRS-500 Updater.exe" with a bunch of supporting files) and plain-text CRAMFS images of the filesystems.\line c) Intel SSD drive\line The firmware update is a CD ISO, which contains a FreeDOS system with a DOS-based firmware updater. The plain-text firmware images are embedded inside the exe as byte arrays and need to be identified by following the updater logic.\line d) Amazon Kindle\line The firmware update is a .bin file. The file needs to be copied to the device and, after it's recognized by the unit, the update procedure has to be triggered by the user. The file has an idenitifying header and is followed by an obfuscated .tgz image which is extracted and executed on the device. It is not easy to uncover the obfuscation as the de-obfuscation is done completely on the device. (In fact, the code was recovered another way, see below.)\line e) Sony Walkman NWZ-X1000\line The firmware update is an updater program (FWUpdater.exe plus some DLLs) and the firmware image NW_WM_FW.UPG. The updater copies file to the device and sends a special USB command to begin the update. The update is encrypted with an unknown cypher, and so far I did not find a way to decrypt it.\par 13 | \b\fs28 2. Serial port.\b0\par 14 | \fs22 The serial port (UART) is used in most cases to help debugging the device during development. Since it's useful for diagnostics, it remains available even on production devices, though not often obvious. Once identified, it usually allows access to the bootloader and/or the main OS, which can then be used to get the actual code fron the device.\line\line 2.1. Finding out UART parameters\par 15 | Since UART is a asynchronous protocol, it's sensitive to timing and bit patters, and thus you need to know the correct baud rate, stop bits and parity configuration, or you'll get garbage output. For this, the best source is the Linux and/or bootloader sources which most manufacturers have to provide because of GPL. Search the sources for "uart", "serial" and "console". Another way is to download the official sources of the same or similar version and do a file compare with the manufacturer's. This way you'll find what they have changed or added, and often this will include the initialization of the UART. Sometimes it can be mentioned in plain text (e.g. "115200 8n1"), and sometimes you'll need to figure it out from the values loaded into the registers and the processor datasheet. However, even if you don't succeed in that or there are no sources, here are most common configurations:\line 1) For Linux and U-Boot the most common setting is 115200 baud, 8 data bits, no parity, 1 stop bit\line 2) For Windows CE, the usual config is 38400 baud, 8n1.\par 16 | 2.2. The cable\par 17 | To actually communicate with the device from PC, you'll need a serial cable. However, even if your PC still has a real COM port, you can't use it as-is. The PC's port operates with so-called "RS-232" voltage levels, which use up to +/-15V for logical one an zero. The embedded devices use "TTL" or "CMOS" levels (most common 0 and +3.3V), and so the direct connection in the best case just won't work and in worst case will burn the device. There are several ways you can overcome that.\par 18 | 1) RS232 converter.\par 19 | There are chips available (most common is Maxim MAX232/3232), which convert RS232 levels to TTL and vice versa. You can either get the chip and solder one yourself, or get a ready-made level converter (plenty are available on eBay). Note that you will need to choose a correct chip or converter depending on the operating voltage of your device (3.3V or 5V).\par 20 | 2) USB-TTL converter\par 21 | If your computer does not have a COM port, you can use a USB-TTL converter. Such converter plugs into the USB port on PC and is appears as a virtual COM port. Again, many such converters are available on eBay and electronic shops.\par 22 | 3) Phone cable\par 23 | This is getting less viable as everyone is switching to USB, but a few years ago most mobile phones used serial connection to the PC. Thus most phone cables were not much more than level converters such as we need. If you have such a cable (you can also buy them in many places for a couple of bucks), you can usually use it as well. To identify the cable's pinout, either find the pinout for your phone's connector and match it, or use the following algorithm:\line a) connect the cable to PC so that it has power\line b) run a terminal program, connect to the COM port corresponding to the cable, and put something heavy on a key so that it keeps sending.\line c) briefly connect pairs of the cable's output wires until you see the pressed key echo on the screen. This way you will find the RX (receive) and TX (transmit) wires.\line d) with a multimemeter, measure voltages between one of the two pins and the rest. The voltage between GND and TX should be around 3.3V and sag slightly if you press and hold a key to send data, and voltage between GND and RX should be around 2.5V.\par 24 | For more explanations and examples see here: {\field{\*\fldinst{HYPERLINK "http://www.nslu2-linux.org/wiki/HowTo/AddASerialPort"}}{\fldrslt{\ul\cf1 http://www.nslu2-linux.org/wiki/HowTo/AddASerialPort}}}\f0\fs22\par 25 | 2.3. Identification on board\par 26 | The most common UART encountered in current devices needs only three wires: GND (ground), RX (receive) and TX (transmit). It is often accompanied by a Vcc (supply) pin, so a good rule of thumb is to check any groups of four pads or pins on the board. However, it's not always the case, so sometimes you'll just have to do trial and error. If the pins are not obvious, try the following approach.\line 1) for ground, you can usually use any of the metallic shields commonly found on boards, including outer cover of USB or other connectors.\line 2) with the serial cable's GND connected to the ground, put the cable's RX pin to a potential TX pad on the board, and reset the device. If you got it right, you should see some output on the terminal program's screen. You can usually try several pads while device is booting to try and capture the boot log. Once TX is identified, fix the cable (e.g. with a bit of solder).\line 3) if you get to a login prompt (usually the case when the device is running Linux), attach cable's TX to a potential RX pad and try pressing some keys in the terminal. Once you see them echoed on the screen, you've got it.\line 4) if you don't get a login prompt, you can try to stop in the bootloader. For that, attach cable's TX to a potential RX pad, reset the device, and immediately start pressing keys in the terminal. Many bootloaders check for a key press on boot and drop into interactive mode.\par 27 | 2.4. Getting the code\par 28 | Once you identified the serial port, you can usually use the connection to get the actual code to the PC.\par 29 | 1) Linux\par 30 | If you get to the login prompt, try the following logins/passwords: root/(no password), root/root, root/admin, root/(name of the device). Quite often this is enough to get inside. Once logged in, there are several ways to copy the code to PC\line a) if there is a parition on the device which is accessible from the PC (e.g. when USB is connected, or an SD card), you can just copy the files there, or even tar/gz the whole filesystem (if there is enough space). If nothing is mounted by default, try connecting USB to see if extra mounts appear. Also check /etc/fstab and/or init scripts for mentions of external filesystems.\line b) instead of copying separate files, often you can dump the complete flash image. Many Linux devices use MTD (memory technology devices) driver to abstract the flash chip from the system. If it is used, /proc/mtd contains the current flash map. It will be something like this (example from Sony Reader PRS-500):\par 31 | dev: size erasesize name\line mtd0: 00200000 00010000 "sdm device NOR 0"\line <...>\line mtd11: 00160000 00020000 "Linux0"\line mtd12: 007e0000 00020000 "Rootfs2"\line <...>\line\par 32 | From the sizes and names you can usually find out which partition you need. To get a specific partition, dd a file named /dev/mtdN. You can also download the complete image with all partitions (mdt0, and sometimes mtd1, check the size column).\par 33 | 2) U-Boot.\par 34 | If you managed to drop into the bootloader by pressing a key shortly after reset, it's more likely than not is U-Boot. U-Boot is de facto standard bootloader on many ARM devices (and sometimes other architectures) and it offers a wide range of built-in commands. The first command you should try is 'help', it will list all available commands with short description. Often there are commands to work with flash partitions, sometimes even to copy things to/from an SD card. The actual commands depend on the device, but here's what I used to get the Amazon Kindle firmware:\line a) used "bbm show partition" to list the available partitions\line b) used "bbm load image 3" to load the partition 3 into RAM\line c) used "base NNNNN" and "md.b N MMM" commands to hex dump the RAM in smal chunks. I wrote a small script to automate this and gather the hex dumps into a final image.\par 35 | \b\fs28 3. Misusing the PC communication\par 36 | \b0\fs22 Sometimes the device uses a specialized program on the PC to communicate with it. It's worth reversing that program to discover the communication protocol and see if there are any backdoors or unforeseen ways it can be used to access the device. There usually no standard in such protocols so it has to be handled on case-by-case basis. I will list two real-life examples I encountered.\par 37 | 1. Sony Reader PRS-500.\par 38 | The PRS-500 was bundles with the "Sony CONNECT Library" program that was necessary to copy ebooks to the device. I reversed it and discovered that ebooks were copied to the device into the directory "/Data/". In addition to the "write" command used for that, the protocol also included "read" and "delete" commands. I wrote a small Python script which used the program's DLLs to duplicate the communication. However, with my script I could specify any path, not just /Data, and I quicky found out that /proc/mtd and /dev/mtdNN were accessible and dumped them, thus getting the firmware image.\par 39 | 2. Casio EX-word electronic dictionary.\par 40 | For those who purchased the dictionary, Casio offered free downloads of simple games that could be installed on it. I reversed the program that was used to upload them and discovered that the files were decrypted right before uploading. I duplicated the decryption and so got the plain-text executables of the games. Reversing them was not trivial because Casio did not use any known interface for system calls. However, by following references to the savefile name and the program logic, I eventually identified calls for "open file", and "write buffer to file". By patching the executable to use the RAM address of the main OS image instead of savefile buffer, encrypting the file back and uploading it, I was able to dump parts of the main OS to the savefile and copy them to PC.\par 41 | \b\fs28 4. JTAG\par 42 | \b0\fs22 JTAG stands for "Joint Test Action Group", but nowadays is almost always used to refer to the standard developed by the said group, known as IEEE 1149.1 "Standard Test Access Port and Boundary-Scan Architecture".\par 43 | Initially the standard was used only for testing PCB connectivity after they've been populated with the chips. The standard offered a way to set or test values on all the I/O pins of the device equipped with a JTAG connector. This allowed, for example, to set the pin values of one chip to a known pattern and check that the values of pins on another chip connected to it match what's expected by the connection schematics. This way wrong connection could be easily discovered without physical testing of each pair of connected pins.\par 44 | Since the protocol was quite flexible and allowed addition of extra commands, many processor manufacturers started to add commands for debugging. Almost any modern processor includes a JTAG module which allows almost complete control over what's happening inside it. You can halt the processor core, inspect and change its registers/cache/RAM, set breakpoints, inject instructions in the code stream and so on.\par 45 | 4.1 JTAG adapter\par 46 | Simplest one can be made out of 5 resistors; uses LPT port\par 47 | Cheap adapters available using FT2232 chips\par 48 | Expensive adapters use a dedicated microcontroller, offer high speed\par 49 | 4.2 Identification\par 50 | Look for groups of 2x10 pins\par 51 | Might be possible to trace from the main processor\par 52 | There are programs available that can brute-force the pinout. \par 53 | 4.3 using boundary scan\par 54 | Boundary scan allows to set or read values on all the processor's pins, bypassing the core.\par 55 | Pins connected to flash are used to read the flash contents\par 56 | This technique requires knowlegde of the layout of the chip's boundary scan register\par 57 | See UrJTAG\par 58 | 4.4 using debugging functionality\par 59 | Most ARM chips allow debugging using the JTAG.\par 60 | Allows inspection and changing of registers and processor state\par 61 | Instructions can be uploaded and executed\par 62 | A small snippet can be uploaded to read data from flash and send over JTAG\par 63 | See OpenOCD\par 64 | \b\fs28 5.Filesystems\par 65 | \b0\fs22 Embedded devices often use special filesystems not found on desktop PCs\par 66 | Most common: cramfs squashfs yaffs jffs2 minix ext2fs\par 67 | \b cramfs\par 68 | \b0 Compressed ROM file-system\par 69 | Files are compressed with zlib.\par 70 | #define CRAMFS_MAGIC 0x28cd3d45 /* some random number */\par 71 | #define CRAMFS_SIGNATURE "Compressed ROMFS"\par 72 | 45 3D CD 28 00 00 01 00 \u9474? 00 00 00 00 00 00 00 00 E=\lang1049\f1\'cd( \u9786?\par 73 | 43 6F 6D 70 72 65 73 73 \u9474? 65 64 20 52 4F 4D 46 53 Compressed ROMFS\par 74 | \lang1033\f0 cramfsck to unpack\lang9\par 75 | \b SquashFS\par 76 | \b0 Another read-only filesystem\par 77 | Uses zlib or LZMA\par 78 | 0x73717368 (sqsh), in little endian systems 68 73 71 73\par 79 | unsquashfs to unpack\par 80 | \b JFFS2\par 81 | \b0 Journalling Flash File System version 2\par 82 | Used for read/write filesystems\par 83 | Designed to reduce flash wear\par 84 | Offers several compression algorithms\par 85 | Magic: blocks begin with 0x1985 (85 19 in little-endian)\par 86 | Unpacking: official way involves mtd device on Linux\par 87 | Wrote a Python script to unpack images\par 88 | \b YAFFS\b0\par 89 | Yet Another Flash Filesystem\par 90 | Popularized by Google's Android\par 91 | Also designed for flash chips\par 92 | No dedicated magic value, tends to begin with 03 00 00 00 01 00 00 00 FF FF\par 93 | unyaffs to unpack\par 94 | \b Others\b0\par 95 | Ext2fs, minix, UBIFS\par 96 | \b Embedded Operating Systems\b0\par 97 | Embedded systems are often constrained by processing power and memory size\line\par 98 | On smaller devices some RTOS (Real-time OS) is usually used.\line RTOS provides basic functionality for running tasks (or threads), synchronization primitives, memory allocation, message passing and other useful APIs.\line Can be very small - from few KB\line Tasks are usually defined at compile time and get compiled into the image\line From the "big" OSes usually only Linux\par 99 | \b Linux\par 100 | \b0 Gets used more often lately\par 101 | Generaly needs an MMU (Memory Mapping Unit)\par 102 | MMU-less variant exists (uCLinux)\par 103 | Due to GPL, manufacturer has to provide sources; thus often easiest to reverse\par 104 | Bootloader: U-Boot is used\par 105 | Some new variations are actually Linux: Android, WebOS\par 106 | String "Linux" is usually present somewhere in the image\par 107 | \b Nucleus\par 108 | \b0 A small RTOS made by Mentor Graphics\line Distributed in source form; mostly written in C with few processor-specific parts\line Used in many mobile phones, especially Infineon chips (Siemens phones, iPhone baseband)\par 109 | Example ID string: "Copyright (c) 1993-2002 ATI - Nucleus PLUS - Integrator ADS v. 1.13.4"\par 110 | \b VxWorks\par 111 | \b0 RTOS, made by Wind River Systems (bought by Intel in 2009)\par 112 | Used in some network appliances, set-top boxes, and even spacecraft (e.g. Mars rovers)\par 113 | "Copyright 1999-2001 Wind River Systems, Inc."\par 114 | \b Windows CE\par 115 | \b0 Written from scratch, RTOS with Win32 APIs.\par 116 | First versions were ported to ARM, MIPS, PowerPC, StrongARM, SuperH and x86.\par 117 | Current versions support only ARM and x86.\par 118 | Runs on Pocket PCs and Windows Mobile phones.\par 119 | Also on some other devices (GPS devices, Panasonic Words Gear)\par 120 | ID string: "ECEC" at offset 0x40 (for ARM)\par 121 | \b Other OSes\b0\par 122 | QNX\par 123 | ThreadX\par 124 | Symbian\par 125 | \b Embedded processors\par 126 | \b0 Distinguishing features:\par 127 | Microcontroller vs. microprocessor\par 128 | Peripherals, RAM, ROM on-chip\par 129 | RISC\par 130 | 32-bit ARM MIPS PowerPC SuperH 68K\line 8-bit 8051, PIC, H8, AVR\par 131 | embedded processors: differences with x86, ARM MIPS PowerPC SuperH DSPs?\par 132 | Recognizing code: Typical opcodes\par 133 | Memory layout\par 134 | datasheets: memory map, reset config, ABI\par 135 | ARM: \par 136 | disassembling images: linux kernel, wince kernel, elf files, modified files (PSP X360 PS3), Mach-O/iPhone, raw binary, zlib scan\par 137 | determining load base: relocation code offset tables string tables\par 138 | \par 139 | } 140 | -------------------------------------------------------------------------------- /2010-07 [Recon] Intro to Embedded Reverse Engineering for PC reversers (tools).zip: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/skochinsky/papers/5d0f71f109e4602cd1e137ed78647c8f166eb1e2/2010-07 [Recon] Intro to Embedded Reverse Engineering for PC reversers (tools).zip -------------------------------------------------------------------------------- /2010-07 [Recon] Intro to Embedded Reverse Engineering for PC reversers.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/skochinsky/papers/5d0f71f109e4602cd1e137ed78647c8f166eb1e2/2010-07 [Recon] Intro to Embedded Reverse Engineering for PC reversers.pdf -------------------------------------------------------------------------------- /2012-10 [Breakpoint] Rootkit in your laptop.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/skochinsky/papers/5d0f71f109e4602cd1e137ed78647c8f166eb1e2/2012-10 [Breakpoint] Rootkit in your laptop.pdf -------------------------------------------------------------------------------- /2014-01 [CODE BLUE] Intel ME Secrets.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/skochinsky/papers/5d0f71f109e4602cd1e137ed78647c8f166eb1e2/2014-01 [CODE BLUE] Intel ME Secrets.pdf -------------------------------------------------------------------------------- /2014-06 [Recon] Intel ME Secrets.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/skochinsky/papers/5d0f71f109e4602cd1e137ed78647c8f166eb1e2/2014-06 [Recon] Intel ME Secrets.pdf -------------------------------------------------------------------------------- /2014-10 [Breakpoint] Intel ME - Two Years Later.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/skochinsky/papers/5d0f71f109e4602cd1e137ed78647c8f166eb1e2/2014-10 [Breakpoint] Intel ME - Two Years Later.pdf -------------------------------------------------------------------------------- /2017-12 [34C3] Intel ME Myths and Reality.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/skochinsky/papers/5d0f71f109e4602cd1e137ed78647c8f166eb1e2/2017-12 [34C3] Intel ME Myths and Reality.pdf --------------------------------------------------------------------------------