Uncategorized

scan_thinkpwn: searches for ThinkPwn vulnerability

THINKPWN SCANNER: This program is used to scan UEFI drivers extracted from firmware image for ThinkPwn vulnerability in vendor/model agnostic way.
AUTHORS:
@d_olex (aka Cr4sh) — initial Vivisect based version of the program;

@trufae (aka pankake) — radare2 based version (this one);

Read the source code for more user docs, including a detailed source comment about how the code works.

https://github.com/Cr4sh/ThinkPwn/blob/master/scan_thinkpwn.py

More info:
https://github.com/Cr4sh/ThinkPwn
http://blog.cr4.sh/2016/06/exploring-and-exploiting-lenovo.html

Standard
Uncategorized

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. […]

http://radare.today/posts/emulating-simple-bootloader/

 

Standard
Uncategorized

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. […]

https://www.praetorian.com/blog/reversing-and-exploiting-embedded-devices-part-1-the-software-stack

Standard
Uncategorized

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.

http://www.sekoia.fr/blog/windows-driver-signing-bypass-by-derusbi/

(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.)

Standard
Uncategorized

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.

https://github.com/XVilka/hacklu
http://archive.hack.lu/2015/
http://archive.hack.lu/2015/radare2-workshop-slides.pdf
http://archive.hack.lu/2015/radare2-workshop/
http://2015.hack.lu/archive/2015/radare2-workshop/vm/

Standard
Uncategorized

EBC

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.
http://vzimmer.blogspot.com/2015/08/efi-byte-code.html

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!!
http://www.capstone-engine.org/

Today, radare2, another RE tool, already has EBC support.
https://firmwaresecurity.com/2015/07/26/tool-mini-review-radare2/

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:
http://people.linaro.org/~christoffer.dall/arm-vm-spec-v1.0.txt

Also, there’s a C#/IL to EBC translation project on Github. If you get it to work, let me know!
https://github.com/nnliaohua/CIL2EBC-ToolChain

Standard