Research

here are the following issues currently in prod: canary exists for a binary, but initial crash analysis doesn’t pick it out. potential solution: doing a checksec at the beginning and including that in the final json (crash_data). this will also include important information such as PIE. feature requests: disassembly - pighidra source code integration - sending in the C code to the llm this would be useful for things like figuring out if alloca exists (contractor binary)

11.27.2025 Refactoring code hell. Patrick gave the idea of using exploit.py instead of static .poc file. Take-aways: The AI provides a high-level overview of ./contractor which is good. However, doesn’t get into the nitty-gritty of how exactly its solved. What I’m thinking to solve this: Summarize GDB outputs / summarize the last 5 iterations. Need to include pighidra to get C code in order to make RCA faster. 11.09.2025 Task 1: Create a persistent GDB Session. Should be pretty straight-forward to set up. Task 2: Refactor the code, such that you just use the master_llm to spit out plan + commands, then use a helper LLM to summarize said outputs of commands, so that the master_llm has a smaller context to worry about. Task 3: Integrate pighidra Task 4: Integrate checksec ...

It was early September, when I reached out to Professor Yener expressing my interest to be involved in security research. Now, a few months into this RCA research, I’m glad through happenstance I reached out. Background What is root-cause analysis, specifically of binaries? High-level overview Professor / Master Agent Student / Slave Agent(s)