# spidermonkey Published articles for spidermonkey. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## wastrel milestone: full hoot support, with generational gc as a treat DevFeed: [wastrel milestone: full hoot support, with generational gc as a treat]() Original publisher: [Read original article]() Author: Andy Wingo Published: 2026-04-09T13:48:04Z Content type: article Language: en Sources: [wingolog]() Topics: [WebAssembly](), [scheme](), [toolchain](), [gcc]() Tags: [binaries](), [garbage-collection](), [gc](), [gcc](), [hoot](), [optimization](), [repl](), [scheme](), [spidermonkey](), [toolchain](), [treats](), [v8](), [wasm](), [wastrel](), [web](), [webassembly]() ### AI overview The article describes a Wastrel milestone: compiling WebAssembly files produced by the Hoot Scheme toolchain into native binaries, including a console-based read-eval-print loop. It covers the build process, runtime modules, binary size, dependencies, and initial performance observations. ### Source excerpt Hear ye, hear ye: Wastrel and Hoot means REPL! Which is to say, Wastrel can now make native binaries out of WebAssembly files as produced by the Hoot Scheme toolchain, up to and including a full read-eval-print loop. Like the REPL on the Hoot web page, but instead of requiring a browser, you can just run it on your console. Amazing stuff! try it at home First, we need the latest Hoot. Build it from source, then compile a simple REPL: echo '(import (hoot repl)) (spawn-repl)' > repl.scm ./pre-inst-env hoot compile -fruntime-modules -o repl.wasm repl.scm This takes about a minute. The resulting wasm file has a pretty full standard library including a full macro expander and evaluator. Normally Hoot would do some aggressive tree-shaking to discard any definitions not used by the program, but with a REPL we don't know what we might need. So, we pass -fruntime-modules to instruct Hoot to record all modules and their bindings in a central registry, so they can be looked up at run-time. This results in a 6.6 MB Wasm file; with tree-shaking we would have been at 1.2 MB. Next, build Wastrel from source, and compile our new repl.wasm: wastrel compile -o repl repl.wasm This takes about 5 minutes on my machine: about 3 minutes to generate all the C, about 6.6MLOC all in all, split into a couple hundred files of about 30KLOC each, and then 2 minutes to compile with GCC and link-time optimization (parallelised over 32 cores in my case). I have some ideas to golf the first part down a bit, but the the GCC side will resist improvements. Finally, the moment of truth: $ ./repl Hoot 0.8.0 Enter `,help' for help. (hoot user)> "hello, world!" => "hello, world!" (hoot user)> statics When I first got the REPL working last week, I gasped out loud: it's alive, it's alive!!! Now that some days have passed, I am finally able to look a bit more dispassionately at where we're at. Firstly, let's look at the compiled binary itself. By default, Wastrel passes the -g flag to GCC, which results in bi ## A journey into IonMonkey: root-causing CVE-2019-9810. DevFeed: [A journey into IonMonkey: root-causing CVE-2019-9810.]() Original publisher: [Read original article]() Author: Axel "0vercl0k" Souchet Published: 2019-06-17T15:00:00Z Content type: tutorial Language: en Sources: [Diary of a reverse-engineer]() Topics: [Exploit](), [spidermonkey](), [JIT](), [Optimization](), [Compiler](), [Firefox](), [Assembly](), [Mozilla]() Tags: [assembly](), [browser](), [cve](), [exploit](), [exploitation](), [firefox](), [ion](), [ionmonkey](), [javascript](), [jit](), [mozilla](), [optimization](), [spidermonkey]() ### AI overview This article examines the root cause of CVE-2019-9810, an IonMonkey issue in Mozilla's speculative JIT engine. It describes the author's investigation of Ion's codebase, including the issue's alias information and the related AliasAnalysis optimization pass. ### Source excerpt A journey into IonMonkey: root-causing CVE-2019-9810. Introduction In May, I wanted to play with BigInt and evaluate how I could use them for browser exploitation. The exploit I wrote for the blazefox relied on a Javascript library developed by @5aelo that allows code to manipulate 64-bit integers. Around the same ... ## Introduction to SpiderMonkey exploitation. DevFeed: [Introduction to SpiderMonkey exploitation.]() Original publisher: [Read original article]() Author: Axel "0vercl0k" Souchet Published: 2018-11-19T16:25:00Z Content type: article Language: en Sources: [Diary of a reverse-engineer]() Topics: [Exploit](), [spidermonkey](), [Firefox](), [JavaScript](), [JIT](), [Windows](), [Shell](), [ctf]() Tags: [blazefox](), [ctf](), [exploit](), [exploitation](), [firefox](), [interpreter](), [javascript](), [jit](), [mozilla](), [payload](), [spidermonkey](), [ttd](), [windows]() ### AI overview This blog post explains the development of three exploits targeting the SpiderMonkey JavaScript engine and Mozilla Firefox on 64-bit Windows. It progresses from a WinDbg JavaScript extension and a build-specific interpreter exploit to dynamically resolving targets and using the baseline JIT to generate ROP gadgets or native code payloads. ### Source excerpt Introduction This blogpost covers the development of three exploits targeting SpiderMonkey JavaScript Shell interpreter and Mozilla Firefox on Windows 10 RS5 64-bit from the perspective of somebody that has never written a browser exploit nor looked closely at any JavaScript engine codebase. As you have probably noticed, there has been ...