- This week as my first week in this VIP, and I hadn't done any VIP's before this so I'm still getting use to how VIP's are organized and how I should have my work documented.
- I also went over the recommended Linux tutorial that was recommended in the announcement, which is This Tutorial
- One of the things that I didn't know was to use grep with regular and extended regular expressions, which in the following case it gives any line with 3 vowels or more in the file.
grep -E '[aeiou]{3,}' file.txt
- I also knew about
> and >> but I didn't know that I could also pass in the output of a file into the standard input of the command, and I've been using it for my InfoSec Projects all this time!
(gdb) run <(python3 sol0.py)
- I also learned how to use neovim and installed and am learning how to use lazyvim from this tutorial
- I finished setting up and went through the tutorial for file navigation, editing, and a lot more that I can do with lazyvim to make development more agile without an actual IDE.
* I'm still getting used to it but I'm excited to keep using it more during future developments.
- My goal for this entry was to understand agentic reverse engineering and how it could help analyze the firmware and security routines used in this project.
- I learned that an agentic approach gives an AI model access to reverse-engineering tools so it can inspect a binary, form a hypothesis, collect more evidence, and revise its explanation.
- I looked at GhidraMCP (https://github.com/LaurieWired/GhidraMCP), which exposes Ghidra functionality to an agent. It seems like a useful starting point for experimenting with this workflow without having to build the entire tool connection myself.
- I also researched CREBench (https://jams-zhou-james.github.io/CREBench/), a 2026 benchmark for cryptographic reverse engineering. It separates recognizing an algorithm, extracting key material, reconstructing program logic, and recovering the final plaintext. I found that distinction useful because recognizing encryption code does not necessarily mean the agent understands how the whole program uses it.
- One possible project would be to compile small programs with known authentication or key-handling behavior, remove their symbols, and compare manual analysis with agent-assisted analysis.
- I would want the agent to support its findings with function addresses and program evidence. I could then check whether its interpretation actually matches the program’s behavior, while recording false positives, time spent, and how much help it needed.
- Thinking about this, this could also combine with side-channel analysis. The agent could identify a suspected secret-dependent routine, and I could use measurements to test whether that routine actually leaks information.
- My goal this week was to prepare for my meeting with Esha and identify a realistic side-channel project that we could work on together this semester.
- I reviewed the side-channel repository (https://github.com/cps-vip/side-channel-attacks), the co-simulation environment, and the kickoff presentation materials. The previous team already implemented password timing attacks in Python and Rust, along with simulated AES correlation power analysis.
- The saved experiments showed that password recovery became less reliable as the deliberately added work decreased. With 101 samples per candidate, the recorded iteration sweep had 20 successful recoveries out of 20 at 10,000 work iterations, but only one out of 20 at 500 iterations. These are the previous semester's team’s saved results, which we still need to reproduce.
- Based on this, I narrowed down a possible project: inspect how a compiled authentication check behaves, measure its timing leakage, and evaluate a constant-time comparison as a defense.
- I am interested in both sides of this work. Assembly and debugging could help explain the execution path, while the measurement scripts could show whether an observer can actually distinguish the timing differences.
- I looked into dudect (https://github.com/oreparaz/dudect) for statistical timing testing and BearSSL’s explanation of constant-time cryptography (https://www.bearssl.org/constanttime.html). These helped understand why looking at code alone is not enough prove that it resists timing attacks.
- I think that doing the experiment on a Raspberry Pi could be very good, but we don't know yet about hardware availability.
- A possible initial division is for me to focus on the target, assembly inspection, and defense, while Esha focuses on the measurement harness and analysis. We would reproduce the baseline together and review each other’s work, but we still need to agree on this division during our meeting.
- My goal for this entry was to finalize our side-channel project direction with Esha and prepare our goals and tasks for the kickoff presentation.
- We agreed to focus on demonstrating a realistic timing attack against a naive password checker and implementing a constant-time version of the same program as a countermeasure.
- We plan to reproduce an existing attack first, then reduce and remove the deliberately added delays or workloads to investigate whether password recovery is still possible.
- We organized the work into three tasks: review and refine the existing checker, develop and evaluate the timing attack, and implement and test the countermeasure.
- I am interested in inspecting the compiled comparison in assembly to understand its early-exit behavior and connect that behavior to our measurements. We also want to distinguish timing measured directly around the function from response times observed through a separate process.
- I collected supporting resources, including BearSSL’s explanation of constant-time cryptography (https://www.bearssl.org/constanttime.html) and dudect’s statistical timing-testing approach (https://github.com/oreparaz/dudect).
- I started the side-channel timing attack project by reproducing the inherited Rust password checker baseline in
side-channel-attacks/timing_attack_rust2. The checker reads guesses from stdin, rejects guesses with the wrong length, compares the guess byte-by-byte against Pa55word123, exits on the first mismatch, and sleeps for 9 ms after each matching byte. This is an intentional amplification of the timing to prove it works.
- I installed Rust on my Mac and built the checker in release mode.
- The main vulnerable source path is:
if attempt.len() != SECRET.len() {
return false;
}
for i in 0..attempt.len() {
if attempt_bytes[i] != secret_bytes[i] {
return false;
}
thread::sleep(Duration::from_millis(9));
}
- I also inspected the assembly given by
cargo rustc --release -- --emit=asm. The assembly first checks length 11, then compares each byte against constants for P, a, 5, 5, w, etc. Each correct byte comparison branches to a call to std::thread::sleep; each mismatch branches to the same failure path.
cmp x25, #11
b.ne LBB5_68
ldrb w8, [x26]
cmp w8, #80 ; 'P'
b.ne LBB5_68
bl std::thread::sleep
ldrb w8, [x26, #1]
cmp w8, #97 ; 'a'
b.ne LBB5_68
bl std::thread::sleep
...
ldrb w8, [x26, #10]
cmp w8, #51 ; '5'
b.ne LBB5_68
bl std::thread::sleep
- This means a longer matching prefix causes more sleep calls before the checker returns. Because the sleep is 9 ms per matched byte, this baseline is easy to attack but it's not very realistic.
- I modified the inherited Python harness to record more evidence. The updated harness logs each measurement row with run number, password position, candidate, sample number, phase, elapsed nanoseconds, response, and submitted guess. It also verifies the final recovered guess by sending it back to the checker and requiring an
OK response.
- I used a smaller bounded reproduction than the previously done 50-sample call: 10 measured samples plus 3 warmups per candidate, three independent runs, and a 15-minute limit per run. The command was:
python3 harness.py --runs 3 --samples 10 --warmup 3 --max-seconds 900 --output-dir results/2026-09-23-amplified-baseline
- All three attempts recovered and verified the secret:
| Run |
Recovered |
Verify response |
Success |
Elapsed seconds |
Requests |
| 1 |
Pa55word123 |
OK |
true |
482.596 |
8867 |
| 2 |
Pa55word123 |
OK |
true |
484.868 |
8867 |
| 3 |
Pa55word123 |
OK |
true |
486.479 |
8867 |
- The inherited demo works because every matching byte adds a millisecond-scale delay. The next step is to reduce and remove that amplification, then compare the vulnerable checker with a constant-time implementation.
- The goal for this week was to decide the next direction after the amplified timing-attack baseline and identify ARM/macOS tools that could help measure whether an natural timing signal still exists.
- I met with my subteam and discussed the next steps. Since we already replicated the attack with artificial timing amplification, we agreed that the next natural step is to remove that amplification and see whether the secret can still be recovered from smaller timing or CPU-level differences.
- Because I am using an Apple Silicon Mac, I will focus on ARM/macOS tooling. Another teammate focus x86/Windows options, since he has a Windows machine.
- The first tool that I found is Apple Instruments, especially CPU Counters, CPU Profiler, and Processor Trace. These tools are relevant because Apple documents Processor Trace as showing instruction and cycle information on supported Apple Silicon machines: Apple Processor Trace documentation.
- Now I also needed to search for a second tool option for collecting timing or clock cycles data.
- Another option I looked into is
xctrace, which is Apple's command line interface for recording and exporting Instruments traces. This is useful for not using a visual application and just use the command line.
- The main thing to check next is whether my exact Mac model supports the newer Processor Trace workflow, or whether I should rely on CPU Counters/CPU Profiler instead. Here's the
xctrace manual page.
- This week I had a shoulder surgery for a Bankart repair and Hill Sachs repair, which limited how much technical work I could do, so I focused on a smaller research task.
- I reviewed
dudect, a tool and methodology for detecting timing leakage by comparing timing distributions for different classes of inputs. This looks useful because it can help detect if there's still timing-leakage with unamplified timing.
- The main thing this could be useful for is to help us test whether the vulnerable comparison leaks timing information before trying to turn that leakage into full password recovery. Supporting artifact: dudect GitHub repository.
- I also looked at the Rust
subtle as a potential tool.
- The
subtle::ConstantTimeEq trait is relevant because our project eventually needs to compare the vulnerable early-exit password checker against a protected version. By using this we make the compiler avoid optimizations in the assembly that could cause timing leakage of information.
- One important limitation is that
ConstantTimeEq breaks when slice lengths are different, so in the future we should always keep the password inputs fixed-length when evaluating timing behavior. Supporting artifact: subtle::ConstantTimeEq documentation.
- My goal this week was to write my initial CS VIP Capstone Proposal and define how my side-channel project could develop over the three semesters.
- I organized the proposal around the contributions I want to do: working on the target programs, inspecting their compiled behavior, implementing countermeasures, and comparing experimental results.
- For Fall 2026, I plan to move from the amplified password-checker baseline to unamplified measurements on Linux with the new server, then evaluate a constant-time comparison. For Spring 2027, I plan to extend the experiments to AES, followed by hardware power analysis in Fall 2027 if equipment is available.
- Writing the evaluation plan helped me distinguish between an attack failing and a defense actually preventing measurable leakage. I plan to compare recovery success, requests required, attack duration, timing distributions, and performance overhead while keeping the vulnerable program as a control.
- I also identified uncertainties that I could find in the future, including measurement noise, and hardware availability. The proposal includes a software-based fallback so progress does not depend entirely on receiving hardware.
- Supporting resource: My CS VIP Capstone Proposal.
- I also reviewed the Linux Server Tutorial. The server will let us have a shared environment for simulation tools and software side-channel experiments.
- I learned how an SSH configuration can save the server address and username so future connections only require
ssh vip. The tutorial also explains setting up SSH keys for authentication.
- Since I use a Mac, I focused on the XQuartz instructions. XQuartz allows graphical applications running on the server to display on my computer through X11 forwarding. The tutorial uses
xeyes to check that this works.
- I also reviewed the VS Code Remote - SSH workflow, which would let me edit files on the server from my laptop.
- For our timing project, this could provide a shared environment for testing the password checker that's the same for everyone.