snx90

Installing V8 on a Mac

Prerequisites

• Install Xcode (Avaliable on the Mac App Store)
• Install Xcode Command Line Tools (Preferences > Downloads)
• Install depot_tools
  • $ git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git
  • $ nano ~/.zshrc
  • Add path=('/path/to/depot_tools' $path)

snx90

#!/usr/bin/env python3
from subprocess import Popen, call
from time import sleep

threads = 8
mem = 8
eth0mac = '52:54:00:12:34:56'
bootSplash = '/home/tux/vms/splash/boot.jpg'
ovmfCode = '/home/tux/src/1git/macos-kvm-pci-passthrough/OVMF_CODE.fd'
ovmfVars = '/home/tux/src/1git/macos-kvm-pci-passthrough/OVMF_VARS.fd'

snx90

#!/bin/bash
############################################################
# Script to install everything needed
# to build PongoOS on Linux.
# tested on Debian and Ubuntu
#
# to clean : sudo rm -rf /opt/ios-arm64e-clang-toolchain \
#                        pongoOS /usr/share/sdks
############################################################
set -e

snx90

There is a bug in SEPROM, at least up to A10 (the one I reversed), in the trustzone bounds checks.
The trustzone is setup by the main AP in an early boot stage and because of that SEPROM has to verify that it's setup correctly before continuing to boot SEPOS. 
Otherwise the AP could write to SEPOS RAM and with that it might be able to get code execution on the SEP.
The verification is done by first checking if the trustzone values are locked and then if they are correct.
Those values are stored in hardware registers that both processors share.
The registers are 32 bit tho and because of that apple decided to shift the address down by 12 bits before putting it into the registers.
This means that if you want to lock down 0x1000000 to 0x2000000 you will actually write 0x1000 and 0x2000 to the registers.
On the other side SEPROM loads these values from the hardware registers again.
But instead of just comparing them against some constant it shifts up all of those values by 12 bits again before doing any check on 

snx90

This bug was also called moonshine in the beginning
Basically the following bug is present in all bootroms I have looked at:
1. When usb is started to get an image over dfu, dfu registers an interface to handle all the commands and allocates a buffer for input and output
2. if you send data to dfu the setup packet is handled by the main code which then calls out to the interface code
3. the interface code verifies that wLength is shorter than the input output buffer length and if that's the case it updates a pointer passed as an argument with a pointer to the input output buffer
4. it then returns wLength which is the length it wants to recieve into the buffer
5. the usb main code then updates a global var with the length and gets ready to recieve the data packages
6. if a data package is recieved it gets written to the input output buffer via the pointer which was passed as an argument and another global variable is used to keep track of how many bytes were recieved already
7. if all the data was recieved th

snx90

Keybase proof

I hereby claim:

• I am snx90 on github.
• I am santitox (https://keybase.io/santitox) on keybase.
• I have a public key whose fingerprint is DC69 D81F 04BB D8FE DABA E26F 39AF 43F6 6319 E9BB

To claim this, I am signing this object: