Research
Analyzing and protecting systems across the stack
My research spans compiled software, embedded firmware, and hardware, with a common thread: developing practical ways to find weaknesses and add protections to systems as they are actually built and deployed — and evaluating where AI can responsibly help.
01
Compiled Software Security and Binary Rewriting
- binary analysis
- binary rewriting
- software hardening
- post-compilation
Problem
A large share of deployed software — legacy applications, third-party libraries, vendor firmware — is available only as compiled binaries. Its source code cannot be recompiled with modern hardening options, which leaves known classes of memory-safety and control-flow attacks unaddressed.
Motivation
Post-compilation binary rewriting offers a route to strengthen such software without access to source code or the original toolchain, provided the transformation preserves program behaviour and keeps overhead acceptable.
Approach
- 01Analyze compiled binaries to recover the structure needed for safe transformation, such as functions, control flow, and code pointers.
- 02Insert security instrumentation directly at the binary level and reassemble a functioning, hardened executable.
- 03Evaluate correctness and performance impact of the rewritten software.
02
ARM Architecture and Control-Flow Protection
- AArch64
- pointer authentication
- control-flow integrity
- ARM
Problem
Control-flow hijacking attacks redirect a program's execution by corrupting return addresses and function pointers. Software-only defenses can be costly, while hardware support for pointer integrity is not used by binaries that were compiled without it.
Motivation
AArch64 processors increasingly provide Pointer Authentication (PAC), which cryptographically signs and verifies pointers in hardware. Bringing these protections to existing compiled software could raise the bar against control-flow attacks on ARM-based systems.
Approach
- 01Study how pointer authentication instructions can be applied to return addresses and indirect control-flow targets in compiled AArch64 code.
- 02Combine binary rewriting with control-flow integrity (CFI) policies to retrofit protection without recompilation.
- 03Assess compatibility, security coverage, and overhead on AArch64 platforms.
03
Hardware Security and Vulnerability Analysis
- hardware weaknesses
- side channels
- hardware Trojans
- vulnerability knowledge
Problem
Hardware vulnerabilities are difficult to patch after fabrication, and knowledge about hardware weaknesses and their mitigations is spread across records, reports, and specifications that are hard for designers to navigate.
Motivation
Helping engineers find relevant weaknesses and mitigations early in the design process — and understanding emerging threats such as side channels and hardware Trojans in AI hardware — supports more trustworthy systems.
Approach
- 01Build frameworks that let designers query hardware weakness and vulnerability information in natural language and retrieve related records by semantic similarity.
- 02Use language models to assist with extracting, organizing, and explaining vulnerability knowledge and mitigation suggestions.
- 03Collaborate on assessments of side-channel leakage and hardware Trojan threats in AI and FPGA-based hardware.
04
LLMs and Agentic AI for Security
- large language models
- agentic AI
- security automation
- evaluation
Problem
Security analysis and hardening tasks require scarce expert effort. Large language models and agentic workflows can automate parts of this work, but their reliability and security implications must be measured rather than assumed.
Motivation
Careful evaluation of AI-assisted security automation clarifies which tasks benefit from LLM assistance, where humans must remain in the loop, and how such tools might themselves be attacked.
Approach
- 01Design LLM-assisted pipelines for hardware vulnerability exploration, knowledge extraction, and documentation analysis.
- 02Evaluate agentic LLM workflows for hardware design protection tasks such as logic obfuscation.
- 03Study the security properties of transformer-based models themselves.
05
Embedded Systems and Firmware Security
- bare-metal firmware
- fuzzing
- emulation
- rehosting
- microcontrollers
Problem
Bare-metal firmware runs directly on microcontrollers without an operating system, tightly coupled to peripherals. This makes it hard to test at scale and leaves many embedded devices with limited security evaluation.
Motivation
Emulation and rehosting allow firmware to execute outside its original hardware, enabling dynamic analysis techniques such as fuzzing that can uncover vulnerabilities before deployment.
Approach
- 01Survey and compare techniques for bare-metal firmware fuzzing, emulation, and rehosting.
- 02Explore automated extraction of hardware knowledge from microcontroller documentation to support firmware analysis.
- 03Apply vulnerability analysis to evaluate firmware security.
06
Hardware IP Protection and Logic Obfuscation
- logic obfuscation
- hardware IP
- supply-chain security
- RTL
Problem
Integrated circuit design relies on a globalized supply chain, exposing hardware intellectual property to piracy, overproduction, and reverse engineering by untrusted parties.
Motivation
Logic obfuscation locks a design's functionality behind a secret key, but applying it well requires expertise. Automation through LLMs and agents could make obfuscation more accessible, if its security can be validated.
Approach
- 01Explore LLM-driven frameworks that apply logic obfuscation to hardware designs.
- 02Evaluate agentic LLM workflows for IP protection, examining both functional correctness and security of the resulting designs.
See the full list of papers, with DOIs and BibTeX.
Publications