Tom SellersOh nice, 7 hours ago someone opened a PR to fix this:
I can't imagine there are many of you, but if you fuzz in Golang, use the fuzztime arg, and keep running into context deadline exceeded killing the fuzz run could you please go add a thumbs up to the following GH issue?
testing: Fuzz testing with `fuzztime` flag sometimes fails incorrectly with "context deadline exceeded" · Issue #75804 · golang/go
Go version go1.25.0 darwin/arm64 Output of go env in your module/workspace: AR='ar' CC='clang' CGO_CFLAGS='-O2 -g' CGO_CPPFLAGS='' CGO_CXXFLAGS='-O2 -g' CGO_ENABLED='1' CGO_FFLAGS='-O2 -g' CGO_LDFL...
In Golang you can fuzz your code in 32bit mode on amd64 machines. You do this by prepending GOARCH=386 to your go test call, just like you'd set GOARCH for any other task.
The reason might want to do this is that certain variable types, such as int are smaller on 32bit platforms. For example, on 32bit platforms int is generally int32 (-2147483648 to 2147483647) and on 64 bit platforms int is int64 (-9223372036854775808 to 9223372036854775807).
This matters because you are more likely to overflow an int32 value than an int64. For folks parsing untrusted data which specifies field length you could end up reading a large "field length" value that, when combined with some offset overflows the value of int. The resulting value would pass a check like if offset+fieldLen < len(data) due to being negative or just smaller than offset but still be invalid in the context of the data.
Fuzzing in 32bit mode makes it much easier to trigger these errors.
A caveat, fuzzing with GOARCH=386 will be slower because there is no coverage guidance for the fuzzer on this arch.
Note that you can't do 32 bit fuzzing on Apple Silicon machines since there is only one GOARCH for them which is arm64. I tend to do my fuzzing on Intel based machine running Linux.
Dr. Bruce Simpson@encthenet I'll try to give #afl ++ a go at #l2ping if I get around to rebooting it. #pcs never got as far as #fuzzing but #Scapy did. time is precious. I might have to drop the ball on committing to fully supporting pcs like I'd talked about with #gnn but I've put cycles in to #upskill my #Python to 2026 already. @lcamtuf
In Golang I love table driven tests for logic that slices and dices protocol bytes off the wire because it allows me to trivially feed those same test inputs to fuzzers. Anytime anyone adds a test entry to the table to exercise new code or check a failure mode it automatically gets added to the fuzzing corpus without additional work.
Annual Computer Security Applications ConferenceFourth in the session was Kim et al.'s "Fuzzing Acceleration for Memory Safety Bug Discovery with Slicer," which speeds bug finding by slicing away irrelevant code. (https://www.acsac.org/2025/program/final/s448.html) 5/6
#Fuzzing #VulnerabilityDiscovery #MemorySafety
#Fuzzing #VulnerabilityDiscovery #MemorySafety
The first paper in this session was Aoki & Shinagawa's "Sagitta: Facilitating Post-Fuzzing Root Cause Analysis via Data Flow Differencing" on easing post-fuzzing RCA by visualizing crash-causing data-flow differences. (https://www.acsac.org/2025/program/final/s228.html) 2/6
#Fuzzing #DataFlowAnalysis
#Fuzzing #DataFlowAnalysis
DoyensecIn our @Adenkiewicz 's latest post, see how combining AFL++ with GPT-5 Codex sped up triaging the results from fuzzing NASA’s CFITSIO library and uncovered numerous vulnerabilities.
SpaceLifeForm
hasamba----------------
🎯 AI
===================
Opening: An autonomous vulnerability-hunting workflow was built around Claude Code and the Model Context Protocol (MCP) to expose local research tooling as callable services. The deployment runs eight MCP Python processes across five VMs, aggregating over 300 tools used for reverse engineering, fuzzing, crash triage, exploit development and reporting.
Key Features:
• Tool orchestration: MCP endpoints wrap RE tools such as Ghidra, radare2 and Frida, allowing the model to invoke decompilation, dynamic instrumentation and static analysis as typed function calls.
• Fuzzing at scale: Multiple fuzzing domains are managed via dedicated MCPs and an Infra MCP that provisions and scales Proxmox VMs for campaigns.
• Persistent debugging: Debugger MCPs maintain long-lived WinDbg/GDB sessions across calls to preserve context between analyses.
• RAG integration: A RAG MCP provides semantic search across campaign artifacts, crash triage notes and past findings to inform ongoing campaigns.
• ROI telemetry: A complementary component, TokenBurn, tracks Claude Max usage and hardware cost against discovered findings.
Technical Implementation:
• Architecture: A central Claude Code instance interacts with separate Python MCP servers registered in a single .mcp.json manifest. Each MCP exposes typed function signatures so the model can request, for example, kernel driver listings or Ghidra decompilation via named tool calls.
• Data flow: Tool outputs are normalized into structured artifacts consumed by the RAG indexer and stored per-campaign for reuse. Crash triage results and diffs are fed back into campaigns to prioritize fuzz targets.
Use Cases:
• Automated attack-surface enumeration and patch diffing across binaries.
• Orchestrated fuzzing campaigns with automated triage and PoC scaffolding.
• Assisted exploit development using model-driven shellcode generation and emulation aids.
Limitations:
• Operational cost tied to Claude Max compute and persistent VM footprint.
• Reliance on historical campaign data for RAG effectiveness; novel code paths may require manual intervention.
• Security and trust considerations when exposing powerful tooling via model-accessible endpoints.
Conclusion: This workflow demonstrates how MCP-style function exposure and RAG indexing can reduce manual orchestration overhead in vulnerability research, while highlighting operational cost and data-dependence trade-offs.
🔹 MCP #ClaudeCode #RAG #fuzzing #tool
🔗 Source: https://blog.zsec.uk/bullyingllms/
