Show HN: Wirebrowser – A JavaScript debugger with breakpoint-driven heap search

Posted by fcavallarin 5 days ago

Counter72Comment15OpenOriginal

Hi HN!

I'm building a JavaScript debugger called Wirebrowser. It combines network inspection, request rewriting, heap snapshots, and live object search.

The main experimental feature is BDHS (Breakpoint-Driven Heap Search): it hooks into the JavaScript debugger and automatically captures a heap snapshot at every pause and performs a targeted search for the value or structure of interest. This reveals the moment a value appears in memory and the user-land function responsible for creating it.

Another interesting feature is the Live Object Search: it inspects runtime objects (not just snapshots), supports regex and object similarity, and lets you patch objects directly at runtime.

Whitepaper: https://fcavallarin.github.io/wirebrowser/BDHS-Origin-Trace

Feedback very welcome, especially on whether BDHS would help your debugging workflow.

Comments

Comment by klaushougesen1 4 days ago

Great effort!, this stuff is hard to do - so applause for getting something shipped! popped an issue into you issues list.

I sometimes find these tools crash hard when pushed via large memory items, huge blobs of code, long base64 strings etc. Even chrome dev tools crash hard on large WS Messages.

Also perhaps post the video near the top instead of hiding it in the origin paper :), kids like videos these days.

https://www.youtube.com/watch?v=WA5nHk-6UJc

Comment by fcavallarin 4 days ago

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.

Comment by paulirish 4 days ago

Very impressive to see the primitives of CDP be used for such a different DX than what's in existing devtools. Really well done.

Comment by fcavallarin 4 days ago

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.

Comment by core-explorer 4 days ago

This is very cool. I am a big believer in tools analyzing a sequence of heap snapshots to automate the time-consuming parts of manual debugging.

I am working on doing something similar in C++, where there is an additional obstacle of recreating the objects from a memory snapshot without runtime support.

Comment by fcavallarin 4 days ago

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.

Comment by doomerhunter 4 days ago

Looks very cool. Wondering what the client-side security researchers will be able to find with that. A friend of mine is developping DomLoggerpp [1] notably to monitor and debug JavaScript sinks.

[1] https://github.com/kevin-mizu/domloggerpp

Comment by fcavallarin 4 days ago

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.

Comment by Sn0wCoder 4 days ago

Only had a minute to install, build and use the app; but wow this is great! Thank you for building and showing us Wirebrowser. Are you building this because other tools do not meet your needs? I have not run across any tool(s) that combine all of these features into one package so hoping you all success with this release.

Comment by fcavallarin 4 days ago

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.

Comment by Vinnl 4 days ago

I kinda needed to see a video to get an idea of what this does. There's one linked at the bottom of the page: https://www.youtube.com/watch?v=WA5nHk-6UJc

Nice work!

Comment by Veserv 4 days ago

BDHS seems strictly less powerful than a time travel debugger. You can just set a hardware breakpoint and run backwards until the value is set.

Why not just do proper time travel? Is that absent for Javascript?

Comment by fcavallarin 4 days ago

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.

Comment by acemarke 4 days ago

We actually built a full-blown time travel debugger for Javascript at Replay.io:

- https://www.replay.io/devtools

Comment by fcavallarin 4 days ago

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.

Comment by ridwanc 4 days ago

[dead]