Author: hucktech

InternalBlue: Bluetooth experimentation framework based on Reverse Engineering of Broadcom Bluetooth Controllers.

~ hucktech ~ Leave a comment

https://github.com/seemoo-lab/internalblue

https://arxiv.org/abs/1905.00631

https://drive.google.com/file/d/1Ze3s7_1n0mIl5odiUvbkPk-vywVZMtKq/view

Several Broadcom/Cypress Bluetooth firmwares and their firmware update mechanism have been reverse engineered. Based on that we developed a Bluetooth experimentation framework which is able to patch the firmware and therefore implement monitoring and injection tools for the lower layers of the Bluetooth protocol stack.

Finite State’s Supply Chain Assessment on Huawei

~ hucktech ~ Leave a comment

Click to access Finite-State-SCA1-Final.pdf

Google: FUDGE: Fuzz Driver Generation at Scale

~ hucktech ~ Leave a comment

At Google we have found tens of thousands of security and robustness bugs by fuzzing C and C++ libraries. To fuzz a library, a fuzzer requires a fuzz driver—which exercises some library code—to which it can pass inputs. Unfortunately, writing fuzz drivers remains a primarily manual exercise, a major hindrance to the widespread adoption of fuzzing. In this paper, we address this major hindrance by introducing the Fudge system for automated fuzz driver generation. Fudge automatically generates fuzz driver candidates for libraries based on existing client code. We have used Fudge to generate thousands of new drivers for a wide variety of libraries. Each generated driver includes a synthesized C/C++ program and a corresponding build script, and is automatically analyzed for quality. Developers have integrated over 200 of these generated drivers into continuous fuzzing services and have committed to address reported security bugs. Further, several of these fuzz drivers have been upstreamed to open source projects and integrated into the OSS-Fuzz fuzzing infrastructure. Running these fuzz drivers has resulted in over 150 bug fixes, including the elimination of numerous exploitable security vulnerabilities.

Click to access pub48314.pdf

https://ai.google/research/pubs/pub48314

Brendan Gregg: BPF Performance Tools: Linux System and Application Observability

~ hucktech ~ Leave a comment

Brendan has maintained an EXCELLENT web site resource for Linux perf for years:

http://www.brendangregg.com/linuxperf.html

and now there is an upcoming 700-page book on the topic:

http://www.brendangregg.com/blog/2019-07-15/bpf-performance-tools-book.html

but it is not yet for sale:

http://www.informit.com/store/bpf-performance-tools-9780136554820

Python 3.8 gets more security

~ hucktech ~ Leave a comment

https://daddycocoaman.dev/posts/bypassing-python38-audit-hooks-part-1/

https://www.python.org/dev/peps/pep-0578/

PEP 578 — Python Runtime Audit Hooks

https://www.python.org/dev/peps/pep-0551/

PEP 551 — Security transparency in the Python runtime

EU Patent Office refuses secure booting patent

~ hucktech ~ Leave a comment

The European Patent Office refused to grant a software patent on a method of managing booting of secure devices with untrusted software. The decision was appealed successfully and the case was remitted to the Examining Division. Here are the practical takeaways of the decision T 1563/17 (Booting untrusted software) of 7.5.2019:[…]

Don’t read this if you’re an engineer at a company which has a policy that requires employees not read anything about other company’s patents:

https://www.lexology.com/library/detail.aspx?g=43d29e5b-fac4-4d12-9a3b-d360e730f3cf

https://www.epo.org/law-practice/case-law-appeals/recent/t171563eu1.html

P1 Security: QCSuper: a tool for capturing your 2G/3G/4G air traffic on Qualcomm-based phones

~ hucktech ~ Leave a comment
https://labs.p1sec.com/2019/07/09/presenting-qcsuper-a-tool-for-capturing-your-2g-3g-4g-air-traffic-on-qualcomm-based-phones/

https://github.com/P1sec/QCSuper

Lately, I have been playing with a 3G dongle – a small USB device enabling to connect to the mobile Internet. I have discovered that most USB dongles with a Qualcomm processor exposed a special diagnostic protocol, called Diag (or DM, or QCDM – for Qualcomm Diagnostic monitor).But I have also discovered that this proprietary protocol was also present inside Android phones (through a device called /dev/diag) and it allowed a couple good things, such as obtaining raw captures of network air traffic or, in older models, reading/writing at arbitrary offsets of the radio chip’s memory (!). Today, we are proud to present QCSuper, an open-source tool that will enable you to passively capture raw 2G/3G/4G frames produced by your rooted Qualcomm-based Android phone or dongle, and produce a PCAP analyzable using Wireshark (in addition to a couple other input/output formats).[…]

Rompar: Semi-automatic extraction of data from microscopic images of Masked ROM

~ hucktech ~ Leave a comment
Rompar is an interactive tool for extracting bianry data out of mask ROM images. The computer vision method implemented is rather simple, but has proven useful in several projects. There is still a lot that can be added to rompar, and pull requests are welcome.

https://github.com/AdamLaurie/rompar

pyba2: Python tools for Beyond Architecture 2 firmware analysis

~ hucktech ~ Leave a comment

Aleph Research has another blog post on ZigBee, and they’ve created a Radare2 plugin to help!

https://alephsecurity.com/2019/07/09/xiaomi-zigbee-2/

https://github.com/alephsecurity/pyba2

https://alephsecurity.com/2019/07/09/xiaomi-zigbee-2/

MoonShine: Optimizing OS Fuzzer Seed Selection with Trace Distillation

~ hucktech ~ Leave a comment

OS fuzzers primarily test the system call interface between the OS kernel and user-level applications for security vulnerabilities. The effectiveness of evolutionary OS fuzzers depends heavily on the quality and diversity of their seed system call sequences. However, generating good seeds for OS fuzzing is a hard problem as the behavior of each system call depends heavily on the OS kernel state created by the previously executed system calls. Therefore, popular evolutionary OS fuzzers often rely on hand-coded rules for generating valid seed sequences of system calls that can bootstrap the fuzzing process. Unfortunately, this approach severely restricts the diversity of the seed system call sequences and therefore limits the effectiveness of the fuzzers. In this paper, we develop MoonShine, a novel strategy for distilling seeds for OS fuzzers from system call traces of real-world programs while still maintaining the dependencies across the system calls. MoonShine leverages light-weight static analysis for efficiently detecting dependencies across different system calls. We designed and implemented MoonShine as an extension to Syzkaller, a state-of-the-art evolutionary fuzzer for the Linux kernel. Starting from traces containing 2.8 million system calls gathered from 3,220 real-world programs, MoonShine distilled down to just over 14,000 calls while preserving 86% of the original code coverage. Using these distilled seed system call sequences, MoonShine was able to improve Syzkaller’s achieved code coverage for the Linux kernel by 13% on average. MoonShine also found 14 new vulnerabilities in the Linux kernel that were not found by Syzkaller.

https://github.com/shankarapailoor/moonshine

https://www.usenix.org/conference/usenixsecurity18/presentation/pailoor

Click to access sec18-pailoor.pdf

Click to access security18_slides_pailoor.pdf

nanoprintf: a tiny embeddable printf replacement written in C89/C99

~ hucktech ~ Leave a comment
nanoprintf is an implementation of snprintf and vsnprintf for embedded systems that aims for C11 standard compliance. nanoprintf makes no memory allocations, uses less than 100 bytes of stack, and is smaller than 5KB of ARM Cortex-M object code when optimized with all the bells and whistles turned on (slightly larger on x64, where you don’t want to use it anyway). nanoprintf is a single header file in the style of the stb libraries. The rest of the repository is tests and scaffolding and not required for use. nanoprintf is written in C89 for maximal compiler compatibility. C99 or C++11 compilers are required (for uint64_t and other types) if floating point conversion or large modifiers are enabled. nanoprintf does include standard headers but only uses them for types and argument lists; no calls are made into stdlib / libc, with the exception of any internal double-to-float conversion ABI calls your compiler might emit. nanoprintf is statically configurable so users can find a balance between size, compiler requirements, and feature set. […]

https://github.com/charlesnicholson/nanoprintf