Don't let a filename Ghidra dislikes kill the server - #229
Open
subwire wants to merge 1 commit into
Open
Conversation
Ghidra validates project and program names and rejects a set of
characters outright. Both names are derived from the binary's file name,
so a crackme called `timo#3` throws
java.lang.IllegalArgumentException: name contains invalid character: '#'
from inside the import. That reaches the caller only as "server exited
with status 1 before registering", with the real reason buried in the
server log -- and the sole workaround available to an analyst is to
rename the file.
Caught on a benchmark run, where an agent did exactly that: it hit the
error, then copied `timo#3` to `timo3_working_copy` and loaded that
instead. It recovered, but spent several minutes and a backend
switch to do it.
Filenames are not ours to choose -- CTF and crackme corpora are full of
them -- so sanitize the derived names and leave the path on disk alone.
The binary is still opened by its real path; only the names handed to
Ghidra change.
Verified against the binary that failed: it now loads and its functions
list normally.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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
1 participant
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.
Problem
Ghidra validates project and program names and rejects certain characters. Both names are derived from the binary's file name, so a crackme called
timo#3throws from inside the import:The caller sees only:
The real reason is buried in the server log, and the only workaround available to an analyst is to rename the file.
Seen in the wild
Caught on a 40-binary benchmark run. An agent hit this, diagnosed it, and worked around it by copying
timo#3totimo3_working_copyand loading that instead. It recovered — after several minutes and a backend switch.Worth noting how it got there: it had preferred IDA (as SKILL.md says to), IDA crashed on this binary, it fell back to Ghidra, and then hit this. Two failures compounding.
Change
Sanitize the derived project/program names; leave the path on disk alone. The binary is still opened by its real path — only the names handed to Ghidra change. An explicitly-passed
project_name/program_nameis sanitized too, since it lands in the same validator.Verified against the binary that failed — it now loads and lists functions normally:
Tests
Three: rejected characters are replaced; ordinary names (including spaces, dots, dashes) are untouched; degenerate input never yields an empty name, which Ghidra also rejects.
🤖 Generated with Claude Code