Thanks! Tools like DomLoggerpp are super interesting for browser security work.
I’ve worked in this area too (e.g., https://github.com/fcavallarin/domdig).
Wirebrowser comes at it from a different angle - no instrumentation, just inspecting the live heap and following how values propagate. Curious to see what people end up exploring with these approaches.
Replay is really impressive - having a record/replay runtime that can capture all the inputs to the JS engine and reproduce execution deterministically is in a completely different category from what CDP exposes. That’s what enables true time-travel debugging.
Wirebrowser sits at the other end of the spectrum: it attaches to any unmodified browser that supports CDP and works directly with the live runtime. The workflows end up being very different, but it’s fascinating to see what becomes possible when the runtime itself participates in the recording.
Thanks! JavaScript snapshots make this feasible because the runtime exposes a complete object graph — types, edges, arrays, strings, everything.
Doing similar work in C++ is on a totally different level: raw memory, no type info, pointer chasing, layout inference... Very curious to hear how you’re
approaching it.
Good point - in theory a full time-travel debugger is more powerful. The practical limitation is that time-travel for JavaScript usually requires instrumenting the code or running inside a custom record/replay environment.
Today, JavaScript doesn’t expose any record/replay mechanism, access to hardware breakpoints, or the internal VM state needed to run execution backwards.
The browser’s debugging API (CDP) also doesn’t provide a way to capture or rewind engine state without modifying the application.
BDHS works within the constraints of zero instrumentation: it relies only on Debugger.paused and heap snapshots, so it can trace where a value originates without altering the code being debugged.
Thanks! Yes - the motivation came from repeatedly switching between DevTools, Burp, and ad-hoc scripts whenever I needed to understand how an object ended up in the heap.
Wirebrowser started as an experiment to unify those workflows and make it possible to follow those values directly instead of stitching together multiple tools. It grew from the pain points I kept running into.
Thanks a lot! It started as a small experiment with parts of CDP to solve some real-life debugging problems I kept running into, and it ended up opening workflows I hadn’t expected.
Thank you! And thanks for opening the issue - handling very large memory objects is definitely an area of improvement for Wirebrowser. It’s something I plan to harden as the tool matures.
Good point about the video ;) I’ll surface it more prominently, the whitepaper ended up a bit dense, so having the visual demo earlier probably helps a lot.
Wirebrowser comes at it from a different angle - no instrumentation, just inspecting the live heap and following how values propagate. Curious to see what people end up exploring with these approaches.