ELVM/8cc: compile any C code into UEFI EBC binary




UefiDiskBenchmark.efi: Mass storage benchmark for UEFI (written in FASM)

UefiDiskBenchmark: Mass storage benchmark, based on EFI_BLOCK_IO_PROTOCOL EFI Byte Code (EBC) application.

Output parameters and flags:
“#” Device number in the list
“Revision” Revision of UEFI API EFI_BLOCK_IO_PROTOCOL.
“Media” Media ID
“RM” Removable Media flag, for example CD or USB flash
“MP” Media Present
“LP” Logical Partition
“RO” Read Only
“WC” Write Cache
“Block” Block size, bytes
“Align” Required alignment for memory buffer, bytes
“Size” Available size of mass storage device

Known bug: maximum 10 devices supported, include aliases.



EBC Debugger added to EDK2

Pete Batard has added EBC Debugger support to the EDK2 project! As I understand it, there was EBC Debugger support in the original EDK project, but it was not carried forward into the EDK2 project, so this is great news! It sounds like this initial patch will need to go through an iteration or two, so hold off until the dust settles…

“The EBC Debugger, which was present in Tianocore, is an invaluable tool for EBC development.  This patch adds it back into the EDK2, allowing, for instance, the compilation of an AARCH64 EBC debugger. […]”

EBC is a bytecode and VM that is widely used, yet barely understood by most, including security researchers.  While EBC was initially an Intel-centric technology, only supporting their Itaniaum, x86, and x64 processors, and only available from their commercial-only Intel C Compiler, these days ARM is also targetting EBC support.  I’m unclear about ARM’s EBC compiler options, perhaps only via their commecial-only compiler? I hope someone gets EBC support into an open source C compiler codebase, like clang or GCC.

More information:

EBC adds AArch64 support!

UEFI has a bytecode, the uEfi ByteCode (EBC). It has traditionally been a bytecode used to consolidate all 3 Intel platforms (x86, x64, Itanic), into a single bytecode, so there only needs to be a single driver on the flash, saving flash memory. Unfortunately, it only supported Intel platforms, not ARM, so it was not a universal bytecode for EFI, only a bytecode for Intel systems. Now, someone has ported AArch64 to ARM, so now EBC may now be more interesting!

Import the AArch64 EBC implementation from

Tested with MdeModulePkg/Application/HelloWorld built for EBC.
Would appreciate some reviewing and testing.

Jeff Brasen (1):
  MdeModulePkg/EbcDxe: Add AARCH64 EBC VM support

Leif Lindholm (1):
  ArmVirtPkg: enable EBC interpreter for AArch64 QEMU

More info:


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:

Click to access h2hc2014-reversing-firmware-radare-slides.pdf