Ever wonder what happens to those digital price tags you see in stores once they run out of juice? In what is a prime example of e-waste, many of those digital price tags are made with non-replaceable batteries, so once their life is over they are discarded. Seeing an opportunity to breathe new life into these displays, [Tylercrumpton] went about converting them to be the official badge of the Phreaknic 26 conference.

Looking for a solution for a cheap display for the upcoming conference badge, [Tylercrumpton] recalled seeing the work [Aaron Christophel] did with reusing electronic shelf labels. Looking on eBay, he picked up a lot of 100 ZBD 55c-RB labels for just $0.70 a piece. When they arrived, he got to work liberating the displays from their plastic cases. The long-dead batteries in the devices ended up being easily removed, leaving behind just the display and the PCB that drives it.

Another hacker assisting with the badge project, [Mog], noticed that the spacing of the programming pads on the PCB was very close to the spacing of a DB9/DE9 cable. This gave way to a very clever hack for programming the badges: putting pogo pins into a female connector. The other end of the cable was connected to a TI CC Debugger which was used to program the firmware on the displays. But along the way, even this part of the project got an upgrade with moving to an ESP32 for flashing firmware, allowing for firmware updates without a host computer.

The next challenge was how to handle customizing 200 unique badges for the conference. For this, each badge had a unique QR code embedded in the back of the 3D printed case that pointed to an online customization tool. The tool allowed the user to change which of the images was used for the background, as well as input the name they wanted to be displayed on the badge. Once finished, the server would provide a patched firmware image suitable for flashing the badge. The original intent was to have stations where attendees could plug in their badge and it would update itself; however, due to some 11th hour hiccups, that didn’t pan out for this conference. Instead, [Tylercrumpton] ran the update script on his machine, and it gave him a great opportunity to interact with conference attendees as they stopped by to update their badges.

For the Phreaknic 27 badge, the plan is to once again use electronic shelf labels, but this time to utilize some of the advanced features of the tags such as the EEPROM and wireless communications. We’re eager to see what the team comes up with.

Since modern household appliances now have an MCU inside, they often have a diagnostic interface and — sometimes — more. Case in point: Miele washing machines, like the one that [Severin] recently fixed, leading to the firmware becoming unhappy and refusing to work. This fortunately turned out to be recoverable by clearing the MCU’s fault memory, but if you’re unlucky, you will have to recalibrate the machine, which requires very special and proprietary software.

Naturally, this led [Severin] down the path of investigating how exactly the Miele Diagnostic Utility (MDU) and the Program Correction (PC) interface communicate. Interestingly, the PC interface uses an infrared LED/receiver combination that’s often combined with a status LED, as indicated by a ‘PC’ symbol. This interface uses the well-known IrDA standard, but [Severin] still had to track down the serial protocol.

Research started with digging into a spare 2010-era Miele EDPW 206 controller board with the 65C02-like Mitsubishi 740 series of 8-bit MCUs. These feature a mask ROM for the firmware, so no easy firmware dumping. Fortunately, the Miele@Home ‘smart appliance’ feature uses a module that communicates via UART with the MCU, using a very similar protocol, including switching from 2400 to 9600 baud after a handshake. An enterprising German user had a go at reverse-engineering this Miele@Home serial protocol, which proved to be incredibly useful here.

What is annoying is that the PC interface requires a special unlock sequence, which was a pain to figure out. Fortunately, the SYNC pin on the MCU’s pins for (here unused) external memory was active. It provided insight in which code path was being followed, making it much easier to determine the unlock sequence. As it turned out,  11 00 00 02 13 were the magic numbers to send as the first sequence.

After this, [Severin] was able to try out new commands, including 30 which, as it turns out, can be used to dump the mask ROM. This enabled the creation of a DIY transceiver you can tape to a fully assembled washing machine, for testing. As of now, the next target is a Miele G651 I Plus-3 dishwasher, which annoyingly seems to use a different unlock key.

Of course, you can just trash the electronics and roll your own. That happens more often than you might think.

Thanks to [Daniel] for the tip.

By Gary Miliefsky, Publisher of Cyber Defense Magazine Black Hat, the cybersecurity industry’s most established and in-depth security event series, has once again proven why it remains the go-to gathering...

The post Black Hat USA 2025 – AI, Innovation, and the Power of the Cybersecurity Community appeared first on Cyber Defense Magazine.

Black Hat USA 2025 was nothing short of groundbreaking. The show floor and conference tracks were buzzing with innovation, but one theme stood above all others – the rapid advancement...

The post AI Takes Center Stage at Black Hat USA 2025 – Booz Allen Leads the Conversation appeared first on Cyber Defense Magazine.

Framework for Automating Fuzzable Target Discovery with Static Analysis.

Introduction

Vulnerability researchers conducting security assessments on software will often harness the capabilities of coverage-guided fuzzing through powerful tools like AFL++ and libFuzzer. This is important as it automates the bughunting process and reveals exploitable conditions in targets quickly. However, when encountering large and complex codebases or closed-source binaries, researchers have to painstakingly dedicate time to manually audit and reverse engineer them to identify functions where fuzzing-based exploration can be useful.

Fuzzable is a framework that integrates both with C/C++ source code and binaries to assist vulnerability researchers in identifying function targets that are viable for fuzzing. This is done by applying several static analysis-based heuristics to pinpoint risky behaviors in the software and the functions that executes them. Researchers can then utilize the framework to generate basic harness templates, which can then be used to hunt for vulnerabilities, or to be integrated as part of a continuous fuzzing pipeline, such as Google's oss-fuzz project.

In addition to running as a standalone tool, Fuzzable is also integrated as a plugin for the Binary Ninja disassembler, with support for other disassembly backends being developed.

Check out the original blog post detailing the tool here, which highlights the technical specifications of the static analysis heuristics and how this tool came about. This tool is also featured at Black Hat Arsenal USA 2022.

Features

• Supports analyzing binaries (with Angr and Binary Ninja) and source code artifacts (with tree-sitter).
• Run static analysis both as a standalone CLI tool or a Binary Ninja plugin.
• Harness generation to ramp up on creating fuzzing campaigns quickly.

Installation

Some binary targets may require some sanitizing (ie. signature matching, or identifying functions from inlining), and therefore fuzzable primarily uses Binary Ninja as a disassembly backend because of it's ability to effectively solve these problems. Therefore, it can be utilized both as a standalone tool and plugin.

Since Binary Ninja isn't accessible to all and there may be a demand to utilize for security assessments and potentially scaling up in the cloud, an angr fallback backend is also supported. I anticipate to incorporate other disassemblers down the road as well (priority: Ghidra).

Command Line (Standalone)

If you have Binary Ninja Commercial, be sure to install the API for standalone headless usage:

$ python3 /Applications/Binary\ Ninja.app/Contents/Resources/scripts/install_api.py

Install with pip:

$ pip install fuzzable

Manual/Development Build

We use poetry for dependency management and building. To do a manual build, clone the repository with the third-party modules:

$ git clone --recursive https://github.com/ex0dus-0x/fuzzable

To install manually:

$ cd fuzzable/

# without poetry
$ pip install .

# with poetry
$ poetry install

# with poetry for a development virtualenv
$ poetry shell

You can now analyze binaries and/or source code with the tool!

# analyzing a single shared object library binary
$ fuzzable analyze examples/binaries/libbasic.so

# analyzing a single C source file
$ fuzzable analyze examples/source/libbasic.c

# analyzing a workspace with multiple C/C++ files and headers
$ fuzzable analyze examples/source/source_bundle/

Binary Ninja Plugin

fuzzable can be easily installed through the Binary Ninja plugin marketplace by going to Binary Ninja > Manage Plugins and searching for it. Here is an example of the fuzzable plugin running, accuracy identifying targets for fuzzing and further vulnerability assessment:

Usage

fuzzable comes with various options to help better tune your analysis. More will be supported in future plans and any feature requests made.

Static Analysis Heuristics

To determine fuzzability, fuzzable utilize several heuristics to determine which targets are the most viable to target for dynamic analysis. These heuristics are all weighted differently using the scikit-criteria library, which utilizes multi-criteria decision analysis to determine the best candidates. These metrics and are there weights can be seen here:

As mentioned, check out the technical blog post for a more in-depth look into why and how these metrics are utilized.

Many metrics were largely inspired by Vincenzo Iozzo's original work in 0-knowledge fuzzing.

Every targets you want to analyze is diverse, and fuzzable will not be able to account for every edge case behavior in the program target. Thus, it may be important during analysis to tune these weights appropriately to see if different results make more sense for your use case. To tune these weights in the CLI, simply specify the --score-weights argument:

$ fuzzable analyze <TARGET> --score-weights=0.2,0.2,0.2,0.2,0.2

Analysis Filtering

By default, fuzzable will filter out function targets based on the following criteria:

• Top-level entry calls - functions that aren't called by any other calls in the target. These are ideal entry points that have potentially very high coverage.
• Static calls - (source only) functions that are static and aren't exposed through headers.
• Imports - (binary only) other library dependencies being used by the target's implementations.

To see calls that got filtered out by fuzzable, set the --list_ignored flag:

$ fuzzable analyze --list-ignored <TARGET>

In Binary Ninja, you can turn this setting in Settings > Fuzzable > List Ignored Calls.

In the case that fuzzable falsely filters out important calls that should be analyzed, it is recommended to use --include-* arguments to include them during the run:

# include ALL non top-level calls that were filtered out
$ fuzzable analyze --include-nontop <TARGET>

# include specific symbols that were filtered out
$ fuzzable analyze --include-sym <SYM> <TARGET>

In Binary Ninja, this is supported through Settings > Fuzzable > Include non-top level calls and Symbols to Exclude.

Harness Generation

Now that you have found your ideal candidates to fuzz, fuzzable will also help you generate fuzzing harnesses that are (almost) ready to instrument and compile for use with either a file-based fuzzer (ie. AFL++, Honggfuzz) or in-memory fuzzer (libFuzzer). To do so in the CLI:

$ fuzzable analyze --export=report.json <TARGET>

Framework for Automating Fuzzable Target Discovery with Static Analysis.

Introduction

Vulnerability researchers conducting security assessments on software will often harness the capabilities of coverage-guided fuzzing through powerful tools like AFL++ and libFuzzer. This is important as it automates the bughunting process and reveals exploitable conditions in targets quickly. However, when encountering large and complex codebases or closed-source binaries, researchers have to painstakingly dedicate time to manually audit and reverse engineer them to identify functions where fuzzing-based exploration can be useful.

Fuzzable is a framework that integrates both with C/C++ source code and binaries to assist vulnerability researchers in identifying function targets that are viable for fuzzing. This is done by applying several static analysis-based heuristics to pinpoint risky behaviors in the software and the functions that executes them. Researchers can then utilize the framework to generate basic harness templates, which can then be used to hunt for vulnerabilities, or to be integrated as part of a continuous fuzzing pipeline, such as Google's oss-fuzz project.

In addition to running as a standalone tool, Fuzzable is also integrated as a plugin for the Binary Ninja disassembler, with support for other disassembly backends being developed.

Check out the original blog post detailing the tool here, which highlights the technical specifications of the static analysis heuristics and how this tool came about. This tool is also featured at Black Hat Arsenal USA 2022.

Features

• Supports analyzing binaries (with Angr and Binary Ninja) and source code artifacts (with tree-sitter).
• Run static analysis both as a standalone CLI tool or a Binary Ninja plugin.
• Harness generation to ramp up on creating fuzzing campaigns quickly.

Installation

Some binary targets may require some sanitizing (ie. signature matching, or identifying functions from inlining), and therefore fuzzable primarily uses Binary Ninja as a disassembly backend because of it's ability to effectively solve these problems. Therefore, it can be utilized both as a standalone tool and plugin.

Since Binary Ninja isn't accessible to all and there may be a demand to utilize for security assessments and potentially scaling up in the cloud, an angr fallback backend is also supported. I anticipate to incorporate other disassemblers down the road as well (priority: Ghidra).

Command Line (Standalone)

If you have Binary Ninja Commercial, be sure to install the API for standalone headless usage:

$ python3 /Applications/Binary\ Ninja.app/Contents/Resources/scripts/install_api.py

Install with pip:

$ pip install fuzzable

Manual/Development Build

We use poetry for dependency management and building. To do a manual build, clone the repository with the third-party modules:

$ git clone --recursive https://github.com/ex0dus-0x/fuzzable

To install manually:

$ cd fuzzable/

# without poetry
$ pip install .

# with poetry
$ poetry install

# with poetry for a development virtualenv
$ poetry shell

You can now analyze binaries and/or source code with the tool!

# analyzing a single shared object library binary
$ fuzzable analyze examples/binaries/libbasic.so

# analyzing a single C source file
$ fuzzable analyze examples/source/libbasic.c

# analyzing a workspace with multiple C/C++ files and headers
$ fuzzable analyze examples/source/source_bundle/

Binary Ninja Plugin

fuzzable can be easily installed through the Binary Ninja plugin marketplace by going to Binary Ninja > Manage Plugins and searching for it. Here is an example of the fuzzable plugin running, accuracy identifying targets for fuzzing and further vulnerability assessment:

Usage

fuzzable comes with various options to help better tune your analysis. More will be supported in future plans and any feature requests made.

Static Analysis Heuristics

To determine fuzzability, fuzzable utilize several heuristics to determine which targets are the most viable to target for dynamic analysis. These heuristics are all weighted differently using the scikit-criteria library, which utilizes multi-criteria decision analysis to determine the best candidates. These metrics and are there weights can be seen here:

As mentioned, check out the technical blog post for a more in-depth look into why and how these metrics are utilized.

Many metrics were largely inspired by Vincenzo Iozzo's original work in 0-knowledge fuzzing.

Every targets you want to analyze is diverse, and fuzzable will not be able to account for every edge case behavior in the program target. Thus, it may be important during analysis to tune these weights appropriately to see if different results make more sense for your use case. To tune these weights in the CLI, simply specify the --score-weights argument:

$ fuzzable analyze <TARGET> --score-weights=0.2,0.2,0.2,0.2,0.2

Analysis Filtering

By default, fuzzable will filter out function targets based on the following criteria:

• Top-level entry calls - functions that aren't called by any other calls in the target. These are ideal entry points that have potentially very high coverage.
• Static calls - (source only) functions that are static and aren't exposed through headers.
• Imports - (binary only) other library dependencies being used by the target's implementations.

To see calls that got filtered out by fuzzable, set the --list_ignored flag:

$ fuzzable analyze --list-ignored <TARGET>

In Binary Ninja, you can turn this setting in Settings > Fuzzable > List Ignored Calls.

In the case that fuzzable falsely filters out important calls that should be analyzed, it is recommended to use --include-* arguments to include them during the run:

# include ALL non top-level calls that were filtered out
$ fuzzable analyze --include-nontop <TARGET>

# include specific symbols that were filtered out
$ fuzzable analyze --include-sym <SYM> <TARGET>

In Binary Ninja, this is supported through Settings > Fuzzable > Include non-top level calls and Symbols to Exclude.

Harness Generation

Now that you have found your ideal candidates to fuzz, fuzzable will also help you generate fuzzing harnesses that are (almost) ready to instrument and compile for use with either a file-based fuzzer (ie. AFL++, Honggfuzz) or in-memory fuzzer (libFuzzer). To do so in the CLI:

$ fuzzable analyze --export=report.json <TARGET>