Using Radare to emulate BIOS

(There’s a Twitter URL for it, but I’ve lost it, sorry.)
Emulating a simple bootloader

Generally speaking, emulating a bootloader is simpler than it is for regular binaries, because they lack external libraries and usually have direct access to memory and hardware. In this case, the bootloader is a binary for x86 architecture which runs in 16-bits real mode using BIOS calls to perform its loading duties and textual input/output. The idea here is to emulate Cropta1 crackme using radare2 ESIL emulation, providing the needed BIOS via a trivial quick & dirty python implementation of just what it’s needed to run the crackme code. There are several ways to do it, I tried two of them and here is the story. […]




Praetorian on exploiting MIPS devices, part 1

The Praetorian security blog has a very detailed and well-written blog post of a MIPS-based system, showing/discussing multiple tools (BowCaster, QIRA, BinWalk, Radare, …). And there is a Part 2 in the works!

Reversing and Exploiting Embedded Devices: The Software Stack (Part 1)
Over the course of the past few months I’ve been traveling around educating people on exploiting embedded devices. My slides alone aren’t able to provide enough information, so I wanted to write everything out for people to digest online. The following blog post is “Part 1”, which will introduce the reader to the software side of embedded devices. I decided to cover software first since most flaws reside within the software stack, ranging from binary applications to drivers. Part 2 will cover the Hardware stack with a focus on educating the reader on how JTAG actually works and how to leverage Hardware modifications to either bypass password protections or to extract secrets that may be baked into the targeted device. […]



Derusbi codesigning bypass analysis

Windows driver signing bypass by Derusbi has a post on Sekoia.Fr analyzing the Derusbi malware and it’s code signing bypass. Detailed analysis.


(The above article is for Windows OS-level security. Note that UEFI also uses code signing very similar to Windows as it’s main form of security. Some of UEFI’s files are stored on a FAT-based file system, which — depending on your OS and how it is configured — lets anyone modify files on FAT volumes, no ACLs.)


Hack.lu 2015 Radare2 firmware hacking workshop materials

There was a Radare2 workshop at HACK.LU 2015, which included firmware targets. Check out the github’s top-level readme, Chapter 2 on Firmware.  There are some UEFI-based demos in the Github project, as well.




EBC, The EFI Byte Code, is a UEFI feature that supports Intel (Itanium, x86, and x64) instructions in a single bytecode. The Intel C Compiler can target EBC, and UEFI drivers can use EBC instead of native drivers, to save space (1 binary, instead of 3).

The other week I gave a firmware security tools talk at BlackLodgeResearch.org, and Vincent Zimmer of Intel showed up. I had a slide complaining that EBC is only supported by Intel C Compiler, a commercial-only product, and that the UEFI Forum should fund a ‘summer-of-code’-style effort to get EBC into GCC or LLVM CLang. After the talk, Vincent mentioned that ICC had to do a bit of unexpected work to generate EBC, and would blog about it. Well, he did blog about it, a few days ago, just catching up to it, and describe the problem.

If you know of someone on the LLVM CLang or GCC project, please try to add a request for EBC support.

Not only would it be nice to have LLVM CLang work with EBC to have an alternative to ICC, and for LLBVM’s Klee fuzzer (to fuzz UEFI via OVMF), but ALSO because the Capstone Framework RE tool uses LLVM’s intermediate form and would then get EBC support!!

Today, radare2, another RE tool, already has EBC support.

If technically possible, it might be nice if ARM added AArch32 and AArch64 support, and EBC support in their compiler, so that EBC could actually target all UEFI platforms with a single blob. ARM/Linaro already has something that appears to overlap in some ways:

Also, there’s a C#/IL to EBC translation project on Github. If you get it to work, let me know!


tool mini-review: radare2

[If you’re already familiar with radare2, and it’s firmware — and EBC — abilities, then skip this blog.]

In 2014, Anton Kochkov gave an interesting talk: “Reversing firmware using radare2”. The scope of ‘firmware’ used in the presentation includes a wide range, UEFI, BIOS, to peripherals. Actually, the talk isn’t that interesting for information on radare, since most of the fun stuff were in the demos, not shown in the slides. IMO, the most interesting parts are the first half of the slides, before radare is introduced, where the speaker gives an interesting overview of some known silicon and firmware attacks. The last few slides mention a few other firmware security tools besides radare: UEFI Tool, BIOS Extract, FlashROM, Bus Pirate, and a few QEMU-based emulators. The presentation has MANY pointers to more information, I’ve queued up about a dozen things to read as a result of reading this. 😦

Radare is an open source reverse engineering tool, it has GUI and command line interfaces. It is peer of IDA, disassembling code is the main focus.

It supports many architectures: 6502, 8051, CRIS, H8/300, LH5801, T8200, arc, arm, avr, bf, blackfin, csr, dalvik, dcpu16, gameboy, i386, i4004, i8080, m68k, malbolge, mips, mips, msil, nios II, powerpc, rar, sh, snes, sparc, tms320 (c54x c55x c55+), V810, x86-64, and zimg. It supports many file formats: bios, dex, elf, elf64, filesystem, java, fatmach0, mach0, mach0-64, MZ, PE, PE+, TE, COFF, plan9, bios, dyldcache, Gameboy and Nintendo DS ROMs. It supports many operating systems: Android, GNU/Linux, [Net|Free|Open]BSD, iOS, OSX, QNX, w32, w64, Solaris, Haiku, and FirefoxOS. It has multiple language bindings: Vala/Genie, Python (2, 3), NodeJS, LUA, Go, Perl, Guile, php5, newlisp, Ruby, Java, and OCAML.

Radare’s GUIs aside, the r2 command line UI offers nice use of colors and graphics to correlate assembly language features, somewhat like how Scapy does with network packets.

Radare definitely looks like a useful tool for firmware researchers. A Google Search for radare and firmware results in lots of existing research and tutorials. Apparently, I’m the last person to learn about radare. 😦

Best yet: radare supports EFI Bytecode (EBC)!! They added EBC support, started about 2 years ago. Search for TARGET_EBC in the code. They don’t list EBC in their architecture list (above), so I’ve yet to see how well it works.

Note also in above list, they support TE executable images, and some level of “BIOS” support (yet to determine what that means).

[I was about to write a paragarph about how UEFI Forum should sponsor EBC support in LLVM, so that radare can benefit from LLVM’s intermediate representation, as well as providing an alternative compiler to the single EBC-targetting compiler, the COMMERCIAL-ONLY Intel C Compiler. But since radare already manually added EBC support to their tool, the need for LLVM as a target is no longer as important, UEFI Forum could target either GCC or LLVM, since radare has dealt with EBC themselves. We still need an alternative, non-commercial, open source EBC-targetting C compiler, though!]

[[UPDATE: The above paragraph is wrong, w/r/t radare and LLVM: Capstone is the RE tool that uses LLVM intermediate language, not radare, sorry. http://www.capstone-engine.org/arch.html ]]

More Information: