Navigating the Materials

The course is comprised of both lesson sections and exercises, which are divided into modules / chapters. Use the sidebar on the left to navigate. Exercises are labeled with an 'E' e.g. 1.3.E1.

The natural start is the first section: 1.1.1 Browser Overview and Components

See a full listing here.

Some simpler exercises are done in-browser (e.g. in a JavaScript REPL) while others utilize the VM environment. Feel free to jump right into the material then revisit this page once you reach a point that requires the VM (explained below).

Using your Virtual Machine

To perform the exercises throughout the training, a pre-configured VM is provided for your exclusive use. It will be running Ubuntu Linux and have all the tools you need along with pre-built browser components.

All you need to access the VM is an SSH client and a VNC client.

For SSH: on Linux or macOS you can use the builtin client. Windows also has a builtin client, or you can use PuTTY.

For VNC: we recommend RealVNC Viewer. On Linux, various other clients are likely provided by your package manager. On macOS you can also use the builtin client through the "Screen Sharing" app. If you encounter any weird GUI behavior, you can try a different client. If your client ever fails to connect, try the "Restart VNC Server" button on the VM page (linked below and in top bar).

See the VM page for more info on managing the VM and connecting.

Tmux and Screen are installed if you'd like to use them.

Running Exercises

Exercises use different versions of the browser componenents patched / customized in various ways. Each version exists in a separate container. The exercise command provides the workflow for spinning up each of these exercise-specific environments.

Basic usage is exercise run exercise-name. Most of the exercises only involve the JavaScript engine (jsc or v8), and you'll be dropped into the corresponding JS REPL.

Some useful options are:

• --debug or --release : run a debug (default) or release build
• --gdb : start a gdb session with the relevant arguments
• --shell : spawn a shell in the container

Additional arguments are passed directly to the binary. For example, exercise run --release jsc --useConcurrentJIT=0 ./ex.js will run a release build of jsc with concurrent JIT disabled, passing a script to execute.

Container Filesystem

Each of the browser engine configurations are in their own containers, and therefore have unique filesystems. The two directories that are mounted and shared between host and each container are /tmp and the home directory (/home/ubuntu).

Any exploit scripts or files needed in the containers should be under one of these directories. Relative paths are fine, e.g. if currently in the home directory writing ex.js, exercise run v8 ./ex.js will work.

A useful consequence of the shared home directory is that configuration files stored there will also apply to the containers. This is most relevant if you'd like to change the GDB configuration in .gdbinit. Feel free to download and use GDB plugins of your choice (pwndbg is present by default).

A Tip for Debugging

When debugging, you'll likely want to break into the debugger at arbitrary points in your script. There are a couple convenient ways you can do this:

• use builtin breakpoint functions
• jsc: run with --useDollarVM=1 and use $vm.breakpoint()
• v8: run with --allow-natives-syntax and use %SystemBreak()
• read from stdin and ctrl-c into the debugger
• jsc and v8: readline() reads until newline
• set a breakpoint on an otherwise unused function
• this can be useful for debugging the full browser, which may not have the REPL-specific functionality you'd use normally
• e.g. for jsc JSC::mathProtoFuncMax is the native function implementing Math.max