Broadly speaking, the wasm stuff is only there as a method of getting the browser to execute shellcode, its a pretty standard lump of code for turning a memory

Broadly speaking, the wasm stuff is only there as a method of getting the browser to execute shellcode, its a pretty standard lump of code for turning a memory bug into code execution in v8. What this shellcode does is open calculator when the browser's sandbox is disabled (`--no-sandbox`). In general in v8 exploitation, once you've reached a point where you can read and write arbitrary memory, you find that v8 will only create either RW or RX pages for you when the JIT compilation happens. WASM is a neat little trick for getting a handle to a RWX page. At first glance to me, the core bug is actually in abusing an array enough to get an unsigned int into a function that expects them all to be signed, causing an off-by-one error and leveraging that into a memory leak (to get the pointer to a FixedArray for floats and a pointer to a FixedArray of objects) and then replacing one with another to create a type confusion and read/write arbitrary memory through that. r4j will probably correct me on the subtlety here though! Source: extremely similar to HackTheBox RopeTwo, which I spent more time than I am prepared to admit solving. Disclaimer: am noob at v8 exploitation, but have done enough of it to know some of the tricks. See also, an article that helped me previously, much of the code is similar (eg: the WASM stuff, the addrof() and fakeobj() methods): https://faraz.faith/2019-12-13-starctf-oob-v8-indepth/ https://faraz.faith/2019-12-13-starctf-oob-v8-indepth/