Arnau Camprubí

How web browsers work

Mon, 26 Jan 2026 00:00:00 +0000

A few years ago, I started going down the rabbithole of browser engines. I wanted to write one, so I started looking for resources. None were as detailed as I had hoped. So, I decided to simply read the official specification (rather, the set of interleaved specifications). Understanably, the spec didn’t explain how a browser engine works, just what its result should be. So I started designing a browser engine – just to find out some time later that my design was horrible from the beginning. Well… I restarted the entire project from scratch more than 10 times.

The current iteration has lasted for half a year so far, and I’m still confident it is the right design. Finally, I feel perpared to write something I wish existed when I started: an explanation of how browsers actually work.

The browser and the browser engine

A browser and a browser engine are two distinct things. The program you install on your computer is the browser. It is composed of two parts: the chrome (not to be confused with the browser of the same name) and the browser engine.

The browser engine is the part that parses HTML, does layout or runs JS, whereas you can think of the chrome as “the UI”. The browser engine doesn’t know anything about tabs, windows or downloads, those are all part of the chrome. For example, Firefox, Chrome or Opera are browsers. Blink, WebKit or Gecko are browser engines. This post will be centered around the browser engine, since it’s the core of the browser (and the interesting part).

The main pipeline

The main task for the browser engine is transforming an HTML source into a drawable page. The output of this whole pipeline will be a draw list or display list. It is a list of simple commands like “draw a rectangle of color C at position (X,Y) and of size W by H”. But doing this directly would be absurdly hard. So we split it into simpler tasks, forming a pipeline.

A diagram of the browser engine pipeline

I will explain, one by one, each of the components of the pipeline.

HTML tokenizer

The HTML tokenizer takes HTML source (text) as input and returns a list of tokens. Tokens are the most basic syntactic units. A comment is a token, a tag is a token, text is a token, etc. As an example, the following HTML source would be tokenized as follows:

<!DOCTYPE html>
<html>
  <body>
    <div id="foo">
      Hello world
    </div>
  </body>
</html>

Doctype token
Start tag token for html (no attributes)
Start tag token for body (no atrributes)
Start tag token for div (with id="foo")
Text token "Hello world"
End tag token for div
End tag token for body
End tag token for html

It is usually a simple state machine, following the spec.

HTML parser

The HTML parser (sometimes called the tree constructor) takes tokens as input and generates a DOM (Document Object Model). It does this by first creating an empty DOM and, for each token, modifying it incrementally. Again, this is pretty well-defined in the spec. The code from before would generate a DOM similar to:

Document
- html
  - body
    - div
      - #text "Hello world"

Notice that it is in this step that structure is introduced. The DOM is where elements live, and where modifications from javascript happen (causing a cascading effect onwards).

CSS tokenizer and parser

With the CSS sources we found in the DOM (<script>) and the ones included in the browser (the so-called user agent CSS) we do a process similar to the HTML tokenizer and parser. We obtain a CSSOM (CSS Object Model).

Style engine

This stage takes the DOM and CSSOM and combines them, by computing the style properties for every element, producing the style tree. Think of the style tree as a DOM with extra information for each element.

This is where CSS selector matching is checked. If we have a rule like .foo { color: red }, it will modify the color property of each element with the class foo. Other elements will have the default value for that property.

Box generation

Elements are an abstract concept of the DOM. Boxes, on the other hand, are “physical” boxes. You can think of them as rectangles with size, position, etc. But before we can give them size and position values, we need to generate the boxes. From the style tree, we create a layout tree, where nodes are boxes. Generally, an element translates into a single box. But it’s not always the case. For example, an element with display: none generates no box at all (and neither do their descendants). In some cases, an element can even generate multiple boxes (think of a <ul>, it has a “marker” box and a “content” box).

Boxes also have padding, margin, border, color, border color, display type (e.g. block or inline), etc. All these properties are derived from the associated style in the style tree. Only the position and size properties are left undefined (for now).

Reflow

We now have a tree of boxes (the layout tree). Reflow modifies the tree, giving it position and size information, according to a layout scheme. This is probably the most complex stage of the entire main pipeline, but I’ll do my best to explain it properly.

There are many types of flow, each with its own reflow algorithm. Most elements follow normal flow (position: static). In normal flow, boxes are laid out depending on many parameters, but mainly:

Block-level or inline-level
Block container or inline container

In case you’re curious, this is where display: inline-block does its thing. Take a look at the mappings:

Value of `display`	Box level	Container type
`block`	block-level	block container
`inline`	inline-level	inline container
`inline-block`	inline-level	block container

Let’s assume, for the sake of simplicity, that everything is a block box (a block box is a box which is both block-level and a block container).

The way the reflow algorithm would work would be:

Determine my width from the containing block
Reflow children
Determine my height from the sum of heights of my children (or properties like height)

So, in this layout:

The steps, recursively, would be:

Reflow the red box
- Determine the width of the red box
  - Reflow the green box
    - Determine the width of the green box
    - Determine the height of the green box
  - Reflow the blue box
    - Determine the width of the blue box
      - Reflow the yellow box
        Determine the width of the yellow box
        Determine the height of the yellow box
      - Reflow the pink box
        Determine the width of the pink box
        Determine the height of the pink box
    - Determine the height of the blue box
- Determine the height of the red box

Of course this gets much more complicated with more complex layouts, but the algorithms generally work in a pretty similar way to the one I described.

Painting

We now have a complete layout tree. To paint it, we can walk the tree, emitting “commands” for each node. For example, if an element has a background color assigned, we can emit a command to draw a rectangle on screen on the correct coordinates.

When I say emit what I really mean is append it to a sequence of commands which, as we discussed earlier, will be the output of the entire pipeline. The browser (not browser engine) will then take those commands and actually draw it on screen in a platform-specific way.

That was quite long, just to explain the main pipeline, huh?

My engine

This whole time I haven’t talked about my engine at all. And honestly, that’s because I don’t have much to show. I was planning on writing a post about it when it got more advanced, but I wanted to do this post explaining concepts in general. Since we’re at it, here’s a sneak peak of what (mostly) works:

A test page rendered on my own browser engine

I know, it’s not very amusing, and the text is barely readable¹, but it shows it can render something. Here’s the exact HTML in case you’re interested:

<!DOCTYPE html>
<html>
  <head>
    <title>Test page</title>
  </head>
  <body>
    <h1>Test page</h1>

    <p>This is a test page.</p>

    <p style="color: red">The quick brown fox jumps over the lazy dog.</p>
    <p style="color: green">The quick brown fox jumps over the lazy dog.</p>
    <p style="color: blue">The quick brown fox jumps over the lazy dog.</p>

    <div style="background-color: #c00000; padding: 4px; color: white">
      <div style="background-color: #00c000; padding: 4px">
        <div style="background-color: #0000c0">
          <p>Hello world</p>
        </div>
      </div>
    </div>
  </body>
</html>

The engine source is on codeberg

Finding vulnerabilities in a cleaning robot

Fri, 28 Nov 2025 00:00:00 +0000

I’ve had a round cleaning robot of a certain brand for quite some time now. The other day I noticed a suspicious micro USB port on the bottom. So I had to do some poking around. This is the story of how I got root shell access to my cleaning robot.

After connecting it to my computer, the first thing I did was a lsusb. It basically shows all the connected USB devices. When I saw the list, I immediately got excited.

Bus 001 Device 005: ID 18d1:d002 Google Inc. Nexus 4 (debug)

Wait, so it’s a phone? No. But the fact that it’s showing up as an android device means it probably has ADB (Android Debug Bridge) support.

I fired adb shell, hoping to get access right away. But instead I was prompted for login. Weird. Apparently, /bin/login was being executed, instead of a shell. I get why they would ask for a login, but it’s not the right way to secure a device. adb shell is not the only way to access it. adb has commands like push and pull (which send and receive files, respectively). And, when using those commands, the shell (or in this case /bin/login) is not executed.

So, a simple adb pull /etc can get us /etc/passwd:

root:x:0:0:root:/root:/bin/ash
daemon:*:1:1:daemon:/var:/bin/false
ftp:*:55:55:ftp:/home/ftp:/bin/false
network:*:101:101:network:/var:/bin/false
nobody:*:65534:65534:nobody:/var:/bin/false
dnsmasq:x:453:453:dnsmasq:/var/run/dnsmasq:/bin/false

We can see the password field for root is x, which means the password is actually stored in /etc/shadow, hashed. We read it the same way:

root:$1$trVg0hig$L.xDOM91z4d/.8FZRnr.h1:17752:0:99999:7:::
daemon:*:0:0:99999:7:::
ftp:*:0:0:99999:7:::
network:*:0:0:99999:7:::
nobody:*:0:0:99999:7:::
dnsmasq:x:0:0:99999:7:::

The password is stored in MD5. So, that’s it, we can simply crack it.

Or rather, we can delete that x in /etc/passwd using adb push, and the password will be completely diasbled (not like they use PAM or anything…).

Now, if we do adb shell, we are prompted for the user, but we no longer need the password.

TinaLinux login: root


BusyBox v1.24.1 () built-in shell (ash)

 _____  _              __     _
|_   _||_| ___  _ _   |  |   |_| ___  _ _  _ _
  | |   _ |   ||   |  |  |__ | ||   || | ||_'_|
  | |  | || | || _ |  |_____||_||_|_||___||_,_|
  |_|  |_||_|_||_|_|  Tina is Based on OpenWrt!
 ----------------------------------------------
 Tina Linux (Neptune, 57513AA3)
 ----------------------------------------------
root@TinaLinux:~#

There you go, we have a shell!

Network access

Sure, someone can get root access to your cleaning robot, but they’ll need to physically connect to it. At that point they might as well steal it. So it’s not a big deal, right?

Right…?

Guess what, the cleaning robot is running an SSH server, with password login enabled. So you don’t even need to connect via ADB, you can connect via SSH.

Anyone on the local network can deploy their code to your cleaning robot, even in an automated way (the password is the same for all the robots of a specific model). In some cases, a leftover open port in the home router firewall configuration¹ can allow that kind of attack from anywhere on the internet.

Key takeaways

Multiple things can be learned from this.

If you want to add authentication to something, don’t implement your own hacky and quick solution – do it the intended way.
Don’t allow password login for SSH. Or, if you do so, don’t use MD5.
Never assume your device will be behind a NAT. Don’t make its security dependant on that.

Thanks for reading! ;)

Creating a game in assembly

Tue, 07 Oct 2025 00:00:00 +0000

Coding in assembly imposes some challenges and difficulties that make it fun, the same way a puzzle is fun. I recently decided to create a game in assembly. Not for the final result, but for the fun of writing assembly. This is the first post about the project. I might not “finish” it, but again, it’s not the goal of the project anyway.

I wanted it to be x86 (as that’s the architecture family I know the most), but I didn’t know which specific architecture would be best. At the end, I decided to do it for 16-bit real mode, as that’s the mode every x86 CPU boots in. That way, I am as close to the hardware as possible. Also, writing assembly for a 16-bit CPU is more challenging than a 32 or 64-bit one – and therefore more fun.

A “challenging” to “fun” chart

Booting

When a computer powers on¹, the BIOS looks for disks containing a magic byte sequence at the end of the first 512-byte sector. When it finds one, it loads the entire sector into memory and jumps to it.

The boot.asm file looks like this:

org 0x7c00 ; BIOS loads us at 0x7c00, absolute references should have this offset
BITS 16 ; Default to 16-bit mode instructions

start:
    ; All the code goes here...

times 510-($-$$) db 0 ; Pad with zeros to make it 510 bytes long
dw 0xAA55 ; Add two more bytes (the magic bytes)

This does works, and the code under start will run. The start label is used here to make it easier to understand. In reality the BIOS just jumps to 0x7c00, so it will execute the first instruction in the boot sector.

Now we can write the game, and that’s it! Well, not quite. As our game grows larger and larger, it will eventually be too big to fit in the 512-byte boot sector. The solution is to write a boot sector that loads more sectors, and put the game on those extra sectors. In case you’re curious on how this works (it’s pretty low-level, feel free to skip it), here you have the code:

org 0x7c00
BITS 16

SECTORS_TO_LOAD equ 64 ; 32 KiB

start:
    ; Disable interrupts
    cli

    ; Set the stack on segment 0 (ss=0) and address 0x7c00 (sp=0x7c00)
    ; Since the stack grows downwards, it won't interfere with our code
    xor ax, ax
    mov ss, ax
    mov sp, 0x7c00

    ; We will load the "stage 2" code at 0x1000:0x0000 (physical address 0x10000)
    mov ax, 0x1000
    mov es, ax
    xor bx, bx

    ; Start from cylinder 0, head 0, sector 2 (sector 1 is the boot sector)
    xor ch, ch ; cylinder
    xor dh, dh ; head
    mov cl, 2 ; sector
    mov si, SECTORS_TO_LOAD

load_loop:
    ; Call the BIOS function to read the sector
    mov ah, 0x02 ; read sectors
    mov al, 1 ; 1 sector
    int 0x13
    jc disk_error

    ; Increment the offset by 512
    add bx, 512

    ; CHS increment logic
    inc cl
    cmp cl, 19
    jl cont_chs
    mov cl, 1
    inc dh
    cmp dh, 2
    jl cont_chs
    mov dh, 0
    inc ch

cont_chs:
    ; Loop if there are sectors left to load
    dec si
    jnz load_loop

    ; Set the data segment (ds) to 0x1000
    mov ax, 0x1000
    mov ds, ax

    ; Far-jump to code segment 0x1000 at offset 0x0000
    jmp 0x1000:0x0000

disk_error:
    ; Report the error...

    ; Halt forever
    jmp $

times 510-($-$$) db 0
dw 0xAA55

That’s it! Now, we can append a “stage 2” after the boot sector in our binary, and it will load and run it.

VGA

Most games have graphics. But right now, how do we draw to the screen? That’s where VGA modes come in. We can ask the BIOS (via BIOS services) to set up a specific VGA mode. Each mode has a set resolution, color depth, etc. We’ll be using VGA mode 0x13 (also called mode 13h). It has a resolution of 320 by 200 pixels and a 256-color palette.

So, before we draw anything, we must set up mode 0x13. We do so with the BIOS interrupt 0x10 with ah=0. After the interrupt call, the video mode will be set to al.

    mov ah, 0x00
    mov al, 0x13
    int 0x10

Now, at physical address 0xa0000 we have the framebuffer. Because of the way segmentation works, this corresponds to segment 0xa000 at offset 0x0000. So, we could simply do something like:

    ; Set es=0xa000
    mov ax, 0xa000
    mov es, ax

    ; Set di=0 (top-left pixel)
    xor di, di

    ; Write at byte 0xa000:0x0000
    mov byte [es:di], 0x04 ; dark red

The problem is that the computer is repeatidly displaying what’s on the buffer. So, what happens if it displays the framebuffer while we’re still drawing a frame? The user will experience visual artifacts, such as tearing. The solution is double buffering. We’ll draw to a side buffer and, when we’re done drawing the frame, we copy it to the actual framebuffer.

A timeline of a program with double buffering

As you can see in the diagram, while the drawing buffer contains invalid (incomplete) frames most of the times, the actual framebuffer always contains a valid frame.

To do this, we can write to our own framebuffer at address, say, 0x90000, and then copy it to 0xa0000 once we’re done. To do this copying, we can write this:

present_framebuffer:
    pusha ; push all the general registers to the stack
    push ds
    push es

    ; set es=0xa000
    mov ax, 0xa000
    mov es, ax

    ; set ds=0x9000
    mov ax, 0x9000
    mov ds, ax

    ; set di=0 and si=0
    xor di, di
    xor si, si

    ; set cx to the length of the framebuffer (in words)
    mov cx, SCREEN_WIDTH*SCREEN_HEIGHT/2

    ; copy cx words from [(ds):si] to [es:di]
    cld
    rep movsw

    pop es
    pop ds
    popa ; pop all the general registers from the stack
    ret ; jump to the popped address (to return from a `call` instruction)

Then, when we’re done rendering, we do call present_framebuffer.

Calling convention

“Functions” and “arguments” are high-level concepts that mean nothing in assembly. That’s why, if we want to have similar constructs, we must establish a calling convention.

For this project, I used a calling convention similar to cdecl. The arguments are pushed to the stack before calling the function. Then, the function is called using the call instruction, which pushes the return address and jumps. When it returns, it’s the caller responsibility to clean up the stack. So, a basic call might look like:

    push grass_texture ; texture address
    push 32 ; texture width
    push 32 ; texture height
    push 100 ; x position
    push 100 ; y position
    call draw_texture
    add sp, 10

Having the responsibility to clean the stack on the caller, combined with clever argument order, allows us to do something really interesting. Often, you want to draw the same texture multiple times, at different positions. Since only the last two arguments change, we can do the following:

    push grass_texture ; texture address
    push 32 ; texture width
    push 32 ; texture height
    push 100 ; x position
    push 100 ; y position
    call draw_texture
    add sp, 4
    push 200 ; x position
    push 50 ; y position
    call draw_texture
    add sp, 10

The actual game

As for the game itself, I have little to show. I have a tile-based terrain renderer, a scrollable camera, and some basic UI elements. I haven’t even fully decided the gameplay style yet. I hope in the next post about the project I can show some gameplay, but for now I don’t have anything worth showing.

To give a sense of how low-level the development is, the project already has more than 600 lines of assembly and I barely have anything. So don’t expect much.