Add a libopencm3 Cortex-M image with a string at the end of .text - #194
Open
zardus wants to merge 2 commits into
Open
Add a libopencm3 Cortex-M image with a string at the end of .text#194zardus wants to merge 2 commits into
zardus wants to merge 2 commits into
Conversation
Member
Author
|
THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS Validation record for head
|
Member
Author
|
THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS Exact fixture-shape and consumer-output record for #194.
Before — CFG memory-data record at Exact consumer baselineAfter — CFG memory-data record at Exact consumer head |
tests/armel/libopencm3_adc-dac-printf.elf is the DecBench O2-noinline build of the libopencm3 adc-dac-printf example, with DWARF removed (arm-none-eabi-strip --strip-debug, 516 KB -> 54 KB); the symbol table is kept so tests can name functions. Its newlib blanks[16]+zeroes[16] pair occupies the last 32 bytes of .text, which ends at 0x8007484 where .ARM.exidx begins. That layout is what CFGFast's printable-string scan needs in order to run off the end of a region, so angr uses it to pin the recovered string to the region rather than one byte past it. Upstream: https://huggingface.co/datasets/noelo-lab/decbench-dataset binaries/O2-noinline/libopencm3/adc-dac-printf.elf (BSD-2-Clause dataset, libopencm3 sources are LGPL-3.0-or-later). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
zardus
force-pushed
the
feature/cfgfast-string-boundary
branch
from
August 28, 2026 16:47
9651e43 to
139420a
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS
Problem
The linked angr change fixes
CFGFast._scan_for_printable_stringsclaiming a NUL terminator it never saw, when a printable run reaches the end of the region being scanned. Reproducing that needs a string that ends exactly at a region boundary with a different section immediately after, and nothing here has that shape — the census in the validation record is 881 string classifications across the armel, armhf, m68k and aarch64 fixtures, none of them changed by the fix, from a detector that fires four times elsewhere in the same run. So the consumer's reproducer is a path that does not exist:Root cause
Most builds pad, so the layout is rare.
tests/armel/libopencm3_adc-dac-printf.elfhas it. Read back throughcle.Loader:newlib's
blanks[16]andzeroes[16]are the last 32 bytes of.text, and.ARM.exidxstarts at the next byte with no gap.Fix
Commit that image. It is the DecBench O2-noinline build of the libopencm3
adc-dac-printfexample with DWARF removed byarm-none-eabi-strip --strip-debug, which takes it from 516 KB to 54 KB; the symbol table is kept so tests can name functions. Upstream is the BSD-2-Clause DecBench dataset atbinaries/O2-noinline/libopencm3/adc-dac-printf.elf, built from LGPL-3.0-or-later libopencm3 sources, and the file was scanned for build paths and usernames before committing.With the fixture present,
p.analyses.CFGFast(data_references=True, normalize=True)on unfixed angr shows the defect the consumer repairs:The 33-byte string has swallowed the first byte of
.ARM.exidx, and.ARM.exidxcomes back as a 1-byte object plus a 7-byte object instead of one 8-byte object.Testing
No test suite in this repository covers fixtures, so nothing is executed here. What was checked instead: the committed file loads through
cle.Loaderwith the section and symbol addresses above, and the string measurement is identical before and after the strip — the same 471 scan calls, 23 of them non-zero, and the same single affected address with the same content — so stripping did not move the boundary the fixture exists to exercise.Validation: #194 (comment)
sync: angr/angr#6943
session: sharpen