Mr. Crowbar – framework to reverse binary file formats

Kindof reminds me of Scapy for binary file formats!

Mr. Crowbar is a Django-esque model framework that makes it super easy to work with proprietary binary formats while reverse engineering. File formats are described with Python classes that allow ORM-like free modification of structures and properties, which in turn can be validated and converted back to the binary equivalent at any time. The eventual goal is to provide a library for storing file format information that retains the readability of a text file, while providing instant read/write support for almost no cost.[…]

 

doc/source/_static/mrcrowbar.png

arm_now: QEMU-based tool to setup VMs for security research

arm_now is a qemu powered tool that allows instant setup of virtual machines on arm cpu, mips, powerpc, nios2, x86 and more, for reverse, exploit, fuzzing and programming purpose.

https://github.com/nongiach/arm_now

Alt Text

 

RE-Canary: Detecting Reverse Engineering with Canary Tokens

https://twitter.com/qrs/status/1010259931373633538

https://twitter.com/qrs/status/1010541545638985729

Click to access Detecting_Reverse_Engineering_with_Canaries_CanSecWest2018.pdf

https://www.mulliner.org/blog/blosxom.cgi/security/re_canary.html

http://www.mulliner.org/collin/

hwloc – tool to discover hardware resources

The OpenMPI project has a tool called hwloc that helps identify hardware, useful beyond parallel/high-performance computing. It even generates ASCII artwork!

http://nitschinger.at/Discovering-Hardware-Topology-in-Rust/

The Hardware Locality (hwloc) software project aims at easing the process of discovering hardware resources in parallel architectures. It offers command-line tools and a C API for consulting these resources, their locality, attributes, and interconnection. hwloc primarily aims at helping high-performance computing (HPC) applications, but is also applicable to any project seeking to exploit code and/or data locality on modern computing platforms.

https://www.open-mpi.org/projects/hwloc/

https://github.com/open-mpi/hwloc

https://www.open-mpi.org/projects/hwloc/doc/v2.0.1/

Sample hwloc output

Quarks In The Shell – Episode IV

[…]One may need dedicated tools, like a debugger for a firmware or a baseband, or a disassembler to be able to read the instructions properly.[…]

https://blog.quarkslab.com/quarks-in-the-shell-episode-iv.html

 

ApfsSupportPkg – Open source apfs.efi loader based on reverse-engineered Apple’s ApsfJumpStart driver

Apple has a new file system, APFS. This causes Hackintosh people lots of grief. There are lots of Apple APFS binaries online, and now there’s this:

https://github.com/acidanthera/ApfsSupportPkg

Implementation of AppleLoadImage protocol discoverd in ApfsJumpStart Apple driver. This protocol installs in CoreDxe Apple’s firmware. Gives ability to use native ApfsJumpStart driver from Apple firmware

Credits:
cugu for awesome research according APFS structure
CupertinoNet and Download-Fritz for Apple EFI reverse-engineering
vit9696 for codereview and support in the development
savvas

Vincent to keynote Open Source Firmware Conference

Vincent has a new blog post out, with lots of photos of legacy (pre-UEFI) hardware, and various news items, such as:

[…]Following on the spirit of openness, I was honored to be invited to keynote the upcoming open source firmware summit https://osfc.io/. The landing page for my talk will be https://osfc.io/talks/keynote. This should follow the arc on reducing friction and providing transparency for host firmware development.[…]

http://vzimmer.blogspot.com/2018/06/system-firmware-past-present-future.html

bootloader_instrumentation_suite: [U-Boot] Bootloader research tools (very much a work in progress)

https://github.com/bx/bootloader_instrumentation_suite

This test suite helps you keep track of different versions of
u-boot/build tools, static analysis of that build’s binaries, and
runtime trace results of running that binary on a given hardware
configuration. For each u-boot/build configuration it keeps a database
of information it statically gathered for each boot stage, boot stage
images/ELF files, a prepared SD card image, and test results of
runtime trace analyses. If it detects changes in the u-boot source or
build tools it will create a new set of test result directories with a
new sdcard image and static analysis results.

mbed: Firmware updates for IoT and IETF SUIT Hackathon

See below blog for a few links to new projects.

https://twitter.com/ArmMbed/status/1009818609886089217

Improving firmware updates for Internet of Things devices – the IETF SUIT Hackathon in Berlin/Germany
Last updated about 13 hours ago, by Hannes Tschofenig. Arm Research, hackathon

IoT devices commonly require security patches and updates to protect against known vulnerabilities. In this blog post Hannes Tschofenig highlights a recently-launched standardization effort in the Internet Engineering Task Force (IETF): the “Software Updates group for Internet of Things (SUIT)” working group. The report shares experiences from a Hackathon in Berlin, where several working group members met to work on code for firmware updates.

Working Group Formation and IETF London Hackathon

The Internet Engineering Task Force (IETF) met in London from March 17th – 23rd for the first face-to-face meeting of the IETF Software Updates group for Internet of Things (SUIT). The SUIT working group is chartered to develop firmware update solutions that can be implemented into Internet of Things (IoT) devices, especially microcontrollers with limited RAM and flash memory, such as 10 KiB RAM and 100 KiB flash. The focus of the group is simple: since many IoT devices require software updates to fix security vulnerabilities, the group will develop and standardize a secure approach to these updates. For IoT devices, this software update often comes in the form of a monolithic block, where the entire codebase running on the device, i.e. the firmware, is replaced in one shot.[…]

https://os.mbed.com/blog/entry/Firmware-updates-for-IoT-devices/

https://tools.ietf.org/html/draft-ietf-suit-architecture-00

/media/uploads/dirons/hackathon1.jpg

 

James Bottomley: Containers and Cloud Security

The idea behind this blog post is to take a new look at how cloud security is measured and what its impact is on the various actors in the cloud ecosystem. From the measurement point of view, we look at the vertical stack: all code that is traversed to provide a service all the way from input web request to database update to output response potentially contains bugs; the bug density is variable for the different components but the more code you traverse the higher your chance of exposure to exploitable vulnerabilities.[…]

Containers and Cloud Security

 

AMI on their MegaRAC SP-X Service Processor BMC product

In a new blog post, AMI gives an introduction to their MegaRAC SPX-Service Processor, useful background if you’ve no idea about what it is.

[…]In our next post on MegaRAC SP-X, we will look more closely at some of the other specific features and benefits of MegaRAC SP-X mentioned earlier, including hardware and software inventory, power, BIOS and user management, along with more of the different interface protocols that SP-X supports.

https://ami.com/en/tech-blog/megarac-spx-the-foundation-for-powerful-server-management–part-i/

https://ami.com/en/products/remote-management/service-processor/

MegaRAC SPX Logo

 

Automated Detection, Exploitation, and Elimination of Double-Fetch Bugs using Modern CPU Features

Double-fetch bugs are a special type of race condition, where an unprivileged execution thread is able to change a memory location between the time-of-check and time-of-use of a privileged execution thread. If an unprivileged attacker changes the value at the right time, the privileged operation becomes inconsistent, leading to a change in control flow, and thus an escalation of privileges for the attacker. More severely, such double-fetch bugs can be introduced by the compiler, entirely invisible on the source-code level. We propose novel techniques to efficiently detect, exploit, and eliminate double-fetch bugs. We demonstrate the first combination of state-of-the-art cache attacks with kernel-fuzzing techniques to allow fully automated identification of double fetches. We demonstrate the first fully automated reliable detection and exploitation of double-fetch bugs, making manual analysis as in previous work superfluous. We show that cache-based triggers outperform state-of-the-art exploitation techniques significantly, leading to an exploitation success rate of up to 97%. Our modified fuzzer automatically detects double fetches and automatically narrows down this candidate set for double-fetch bugs to the exploitable ones. We present the first generic technique based on hardware transactional memory, to eliminate double-fetch bugs in a fully automated and transparent manner. We extend defensive programming techniques by retrofitting arbitrary code with automated double-fetch prevention, both in trusted execution environments as well as in syscalls, with a performance overhead below 1%.

 

https://arxiv.org/abs/1711.01254

Click to access double_fetch_slides.pdf

IEEE: 6 Reasons Why IoT Security Is Terrible

The Internet of Things bears little resemblance to traditional IT systems—and that makes it harder to protect
By Stacey Higginbotham

Connecting physical infrastructure to the Internet makes systems vulnerable to new security threats. What keeps executives awake at night varies by industry, but cybersecurity problems are worsening everywhere. Security officers in manufacturing worry about employees inserting infected USB drives into machines, while hospital administrators fear that malware will wipe out an unpatched MRI machine, or that a hacker will direct an infusion pump to administer a lethal dose of medicine. Josh Corman, chief security officer at PTC, a computer software firm based in Massachusetts, has codified six reasons why security for the Internet of Things (IoT) is different from—and more difficult to tackle than—traditional IT security.[…]

https://spectrum.ieee.org/telecom/security/6-reasons-why-iot-security-is-terrible