Consoles

Consoles¶

Hardware of Consoles

PS1¶

Hardware Region locked
- CD has Region burned in to the game where CD burners could not write to
- Region was checked before starting the game then never again
  - This meant putting a Correct Region Disk then swapping it to a burnt copy of another disk worked

PS2¶

FreeDVDBoot¶

Source

Using a buffer overflow in the DVD firmware a DVD Video disk is able to load code on the PS2.

This allows a single DVD to be used to bypass the Copy Protection and can run game backups.

Patch iOS:
1. Download FreeDVDBoot ESR Patcher Gui v0.4 by Jabu.
2. Select the PS2 iOS file to Patch
3. Select the 3.10-3.11_hypred payload to patch
4. Click the Patch Button

Burning on Linux:

sudo env -u SUDO_COMMAND growisofs -speed=1 -Z /dev/sr0=All\ PS2\ Slims\ -\ English\ language.iso
sudo env -u SUDO_COMMAND growisofs -speed=1 -M /dev/sr0=/dev/zero

How it works:
1. There is a buffer overflow in the DVD Firmware reading the IFO Files.
- There is no bounds checking for the size of the IFO file and can be replaced with a 0xFFFF.
- Using the buffer overflow data stored on the DVD can be written to the 0x140bdd4 - 0x158BDBC address range
2. There is a Function Pointer for fpIndex that is located at 0x141284a.
- Modifying this offset variable allow us to jump to any address in the 0x5b9d40 - 0x5b9d40 range.
3. In this range there is a memory pointer that would map us to 0x1500014 which is in our previous DVD buffer overflow range.
4. Wait for the fpIndex function to be executed.
5. Issues needed to fix
- There are some other issues with the overwriting of data like the currentDiscBytePointer that needs to be replaced with the correct address
- There is a setFpIndex that is run after the buffer-overflow. But if 0x1412856 is set to NULL then it will not overwrite the fpIndex
- There are also Cache Issues

DVD Backup Disks¶

Needs FreeMcBoot to do the initial boot
- This is because the register to denote the DVD type is already set
- Uses FreeMcBoot as a bootloader

Deep Dive on the Drive:
1. Create a new UDF File system on the ISO
- This is created before the main file system
2. Add DVD Specific Files and Folders to the file system
- Add the /AUDIO_TS Folder
- Add the /VIDEO_TS Folder
- Add the /VIDEO_TS/VTS_01_0.IFO File
- Modify contents of the IFO file to change its own filesize header to 14336
- Add the /VIDEO_TS/VIDEO_TS.IFO File
- Renamed file from VIDEO_TS.BUP
- Modify contents of the IFO file to change its own filesize header to 12288
3. Place the Files on the Logical Disk
- PS2 Disks data starts around Logical Block Address 260. Since each block is 256 byte blocks this gives us around 250KB to add the files.
- Add the VIDEO_TS.IFO file to Logical Block Address 138
- Add the VTS_01_0.IFO file to Logical Block Address 145
- Add the ESP Loader to Logical Block Address 151
- You don't need a file for this since this will be copied into memory
4. Both of the VTS_01_0.IFO, and VIDEO_TS.IFO internal header have sizes that are greater than what the file contains. This allows a buffer overflow to gain control of the PS2

DVD Drive¶

Watermark with encrypted code in the first 16 sectors of the disk
- This area could not be burnt with a normal DVD writer
- This area also contains the Decryption Key (Encrypted)
  - The decryption key is the product code that is located somewhere in the game data in different sectors
- Using a PS2 Game like ActionReplay put it into PS1 game mode
  - Then putting a backup game PS2 backup allows the game to be run (with a mod chip)

The DVD Hypervisor (Mecarom)
- Would only boot PS2 games with DVD-ROM flag. Normal backups were DVD-R/DVD+R
- Mod chip used to switch the flag

Still vulnerable to the same attack as the PS1 Swap disk

Memory Card Upgrade¶

The Memory Card was planned to be used to update the PS2 Memory Card would trick the PS2 into thinking it was a valid update
- This allowed a custom menu called Free McBoot to be built with tools
- ESR
  - Backup Games could be run by Patching a game disk to be multi session
    - The first disk would include Video playback
    - The second disk would include the game data
    - This allows the game to boot since it thinks its a video DVD
- Open PSLoader
  - Allows game to be run from USB hard drives or over the network

PS3¶

Has Hypervisor
- Is coded for virtualization and not security. This makes it mostly useless
- Allows any page to be marked as executable with no checks
- does not enforce executables to be signed
- does not prevent copying games
Also has User mode and Kernel Mode
When getting User Mode code execution you can patch lv2 and run pirated games without any problems from lv0 or lv1

Random Number generator returned the same number every time
- Working backwards was able to get the private key

Multiman is the Universal Tool

Keys¶

Has security chip (SPU)
Each Console has its own key
- Has Signed Executables
Contains Encrypted Storage
- Storage is not signed
- Storage is encrypted with the same key and the same IV
  - Allows for decryption if can point to the memory address

Boot Process¶

bootloader (Secure SPE Chip)
- Boot Rom embedded in the CPU
lv0ldr (Secure SPE Chip)
- Brings Up PowerPC
lv0 (PowerPC Chip)
metldr/ lv1ldr (Secure SPE Chip)
lv1 - HyperVisor (PowerPC Chip)
metldr/ lv2ldr (Secure SPE Chip)
lv2 - GameOS (PowerPC Chip)
- Has no write or execute permissions which allows writing a payload and executing it

RAM Glitching¶

Hypervisor contains the permissions for the memory page tables
When the Kernel allocates memory the Hypervisor allocates the memory makes the mapping and sets the permissions.
When this memory is removed it deletes the memory
- This part of the Hypervisor was glitched to prevent the memory from being correctly removed
- This means that there is still a mapping but the hypervisor thinks it is free
- When new memory is allocated the pagemapping table can be located in the glitched part of memory that is accessible to the Kernel.
- Using this the kernel can change the mapping in the table to map the hypervisor memory to readable memory from the Kernel.

PSJailbreak Hardware Exploit¶

Mimicked mutable usb devices behind a hub
- PWN device 1 contains the payload to be launched
- PWN device 4 contains two usb device configuration packets one with regular length and another one with length 0
  - because of the setup of the other devices it tries to read the length which will overflow the buffer
  - This allows an overwite or the Function VTABLE for some C++ Pointers
  - The deconstruction pointer is overwritten and then the device sends a unplug packet
    - This allows the Deconstruction function to be called and allows code to be executed

USB Device that could push unsigned code
- This is what is used by sony to put the device in service mode or recovery mode

Downgrading a PS3¶

Special Service mode is available when a certain usb hub is plugged in to the console.
- This negotiates a cryptographic message to the PS3
- This cryptographic message is encrypted using a Symmetric Key and not a public/private key.
- Since these keys were stored in the PS3 these were exported and could be use to negotiate the Service Mode
- A leaked Sony Service application was leaked that allows the PS3 to be downgraded without any checks

ECDSA Random Numbers¶

Sony had encrypted ELF binaries to load executables
- This can be defeated having the process decrypt the code from the lv2 (GameOS)

To actually create a signed binary you need to break the ECDSA Signature
- Sony Returns the same random number every time (So its not random any more)
- By reusing the same random you are able to compute the private key

Blu-Ray Drives¶

Has 12 different drive models
- Most Common is Renesas
Decapsulating the Chip to get the ROM of the Drive
- This was easier because of the ROM is separated from the rest of the board
  - Use Acid to decapsulate
  - Cut tiny wires with lazer
  - rebond wires to a custom pcb
- Used documents to see that the CPU is using HS8 that IDA can decompile
Uses a Crypto Processor for communication
- Per console key
Uses SCSI for communication
- Sony Specific Commands do not have bounds checks
  - Out of Bounds Write Vulnerability in Operation Code. By specifying a longer length transfer.
  - Took too long and found other vulnerability

DSP registers are mapped as Read Write and accessible by the SCSI command
- the firmware uses them to copy data into DRAM and map DRAM in to offsets
- Except this is not used in newer models

TOCTOU bug in decryption and copying firmware
- Can dump after decrypted but before copy

Differences in CD, DVD, Blu-ray:
- CDs are read by an Infrared Laser. (700 nm – 1 mm)
- DVDs are read by an Red Laser. (625–740 nm)
- Blu Ray Disks are read by a Blue Laser. (450–485 nm)
- With the difference in frequency more data can be transmitted.

Disk Data:
- Has one key for the decryption of the disk data
- Has another key for the encryption of the save data

PS4¶

No Hypervisor
Has useless security chip
Has IOMMU
South bridge is actually a SoC that has an OS that is used in standby mode

Targeting PCIE¶

Bus Mastering
Complicated: easy to implement wrong
Robust: Easy to make hardware for
Delay tolerant: gives you time to modify and replay to messages
Drivers trust hardware but shouldn't

PCIE 101:
- Memory Reads/Writes
- IO Reads/Writes
- Configuration Reads/Writes
- Message signaled interrupts (MSI) (writes)
- Legacy Interrupts
- Completions

Has a IOMMU but it maps the data to IOMMU to copy the data
- Except you cant map any size smaller than a page table length. Which on PS4 is 64KB including its stack.
- This can be used to DMA in to the whole stack

DualShock 4 Controller¶

Source

PS4 sends 0x100 random bytes to DualShock 4
- Controller signs the random bytes using RSASSA-PSS SHA-256
- Also sends the RSA Public Key (N and e) and signs it with RSASSA-PSS SHA-256
- Each Controller has a unique key

To get non Sony devices to run you need to hack the PS4 kernel and get the key and get the key within the controller.
- Sony can also blacklist controllers with firmware update.
- If not sent within 8 mins then the PS4 stops communication with the device
  - Initial Hack was to fake a usb detach and reteach every 8 mins

Dumping the Controller Memory:
- Lazy coding was done only to get it to work with the PS4 and corners were cut
- After the Setup USB Packet the controller only expects one Data Packet.
- The USB standard has more packets that can be sent after. These trigger a buffer overflow
- Used the UART port to dump data to serial including parts of the firmware
- Using this the Flash was dumped
- But because of memory addressing overlap it was not possible to dump the Loader ROM firmware

The Custom Crypto Block Cipher was found. Since the

Blu-Ray Drives¶

Has 6 different drive models.
- Most Common is Renesas
  https://wololo.net/2022/06/13/ps4-ps5-blu-ray-attacks-theflow-shares-his-presentation-slides/
  https://github.com/TheOfficialFloW/Presentations/blob/master/2022-hardwear-io-bd-jb.pdf

Exploits Info¶

PS4 Kernel Exploit Code
PS4 Kernel Exploit Blog Post
Introduction to PS4's security, and userland ROP Part 1-3
Analysis of sys_dynlib_prepare_dlclose PS4 kernel heap overflow
CVEs for PS4

Version 1.X:
Full PS4 1.76 Exploit source code

Version 4.X:
NamedObj Kernel Exploit Overview
"NamedObj" 4.05 Kernel Exploit Writeup
4.0x WebKit Exploit Writeup

Version 5.X:
PS4 Exploit FWs below 5.07

Xbox¶

No Hypervisor
Boot Rom embedded in the CPU
Very similar hardware as a PC
Uses signed executables
Encrypted executable code is written to memory
- Use to get code injection
- Use to snoop on memory

DVD Drive¶

Disks Had two partitions
- PC could only see partition 1 because of the partition table
- Flashing a dvd drive with custom firmware allowed wripping of the sectors of the drive

Uses the XGD1 for DVD Security
- Modified firmware for a PC DVD reader allowed the game to be ripped
DVD Rom drive flash memory was found and reflashed

Legacy Mode¶

Flash memory was encrypted
- first 512 bytes was not encrypted
  - old version of secret rom used to obfuscate the memory
  - Did not contain the retail key
- Hardware was made to sniff the transport bus (Sniff Address and Data lines)
  - Got the key and dump the secret rom. And dump the flash memory
  - Key was on the south bridge

Removing the flash chip allowed the CPU to interface with the LPC Serial header and read a rom

Legacy feature of the x86 CPU in the Xbox
- Grounding a Pin allowed the boot process to start at another address region bypassing the secret rom.
  - Since the Secret rom was still in addressable memory it allowed the secret rom to be dumped.

Save Games exploits¶

Save games were not signed
- This allowed access to the internals of the Xbox since the game had full control over the xbox
- This also allowed the community to find a vulnerability in the Font files since they were not signed
- When the font and save game exploits were patched the dashupdate executable is always run to update the dash board.
  - This update also had the same font files which were replaced

Xbox 360¶

Boot Rom embedded in the CPU
- Key storage in the CPU
Encrypted executable code
Has Hypervisor (128 Kb)
- Only allows signed code (Microsoft's private key)
- Runtime memory is encrypted and hashed to prevent glitching
- The base original kernel is on the xbox 360 and updates are applied onto the kernel.
- Each Console has its own key

Has EFuse to prevent downgrading
Uses Secure boot with chain of trust in side the CPU
- Nothing sent over the bus
- Each Xbox 360 had a unique key
  - If the xbox unique key is known than the efuse check could be bypassed

Executable is signed but the assets(Images, leveldata, sound and video) are not signed
- In update 4532 there was a bug that allowed the hypervisor to make system calls in to user memory and exec code.
  - The King Kong Game was patched with a shader that allowed code from user memory to be run.

The System Management Controller was patched to not disable the jtag port after boot
- A timing hack was implemented to bypass the efuse check.
  - By extracting the Base Kernel and patching with the current firmware. Using the System Management Controller
  - Kernel Version and efuses are check against a LockDown counter
  - Lockdown Counter is hashed and encrypted but is brute forcible at 16 bytes
- Kernel 4532 is put in to memory and a soft reboot is run because of stability reasons from the timing hack

Reset Glitch Attack
- Set the CPU clock speed to the lowest mode through the Scaler Chip on the Xbox 360 called the Hanna
  - During normal operation the CPU will think there is a problem and shutdown the CPU after 3 trys
  - The CPU is teased ever 100ns to reset the processor when the CPU is in a bad state
  - When executing code in a thread the registers are reset
    - The default registers when cleared as perceived as a valid check and are bypassed
- brute force CPU thread Management

Uses the XGD2 for DVD Security
- Using a Modified Xbox 360 DVD firmware allows the disk to always be marked as a 'secure medium'
- A copy of the medium is stored in memory but the challenge and response from the south bridge would be patched to always give correct response
- Firmware was needed to be dumped from the disk drive to be patched since each Xbox 360 had a different key
  - There was a trigger to access the debug mode that was used to dump the flash
- Microsoft used CRC checks on medadata parts of the disk
  - Security Sectors
  - Disk Manufacturing information
  - Physical Format Information (PFI)
  - Video Partition
Uses the XGD3 for DVD Security
- Changes the partitions to have dual layers
- Have metadata that was outside the size capacity of a regular disk

DVD Kamikaze Hack¶

The flash chip on the DVD had the write enable pin set to disabled.
Hackers found that the pin that connected the outside to the internal SoC could be severed.
- By drilling at a correct spot on the chip you disconnect the write enable chip that would usually go to ground.
- This allowed a custom dvd firmware to be reflashed to the chip.

Tony hawk buffer overflow¶

https://icode4.coffee/?p=954

Nintendo 64¶

Gameboys¶

3DS¶

ARM11 Regular CPU
- Has NX enabled
- Can use ROP chains
- svcControlProcessMemory is not accessible from the game
- Dynamic libraries are signed
- No way to reprotect or map new pages as RWX from userland
- No ASLR
- Save games are encrypted and authenticated per console

ARM9 Security CPU
- Some secret memory
- CPU has a kernel and usermode but there is a Kernel syscall that allows anything to be run in Kernel mode
- Everything is Encrypted and Signed
- Signature are checked at install and runtime

Initial Exploitation¶

Browser Exploitation
- Uses an old version of webkit
Cubic Ninja
- Can share games through QR codes. These are great for Crashing the game.
Has NX enabled
- Can use ROP chains
- svcControlProcessMemory is not accessible from the game
- Dynamic libraries are signed

Sandbox Escape¶

The GPU has access to read and write to memory.
- The GPU cant access all memory
  - the menus heap is located in the GPU write location and can be over written
- Using this we can write in to the application's .text section
  - This Bypasses DEP
  - This gives us access to a new service to kill and start processes
  - Gives us access to SD card
  - Allows decrypting and dumping games
  - Allows access to access and overwrite extdata

Homebrew Launcher¶

Kills current application
Opens application with nessecery permissions
Takes over app with gspwn
Sets up service handlers

Secondary entrypoints
- Exploit faulty theme handling to run homebrew on startup
- Save Game exploit for "Ocarina of Time 3D"
- Save Game exploit for "Ironfall: Invasion"
- And more

Nintendo Shell (NS)¶

This application lets us downgrade titles
- This is done by uninstalling the title then installing the old title bypassing the version check
This application lets us access Module specific System calls
This is partially in the region that can be modified by the GPU
- So the solution is to modify the location where the code is allocated in memory
- If we kill the application with start and stop service
- Then allocate memory blocks in the upper part of memory pushing the block to a lower address the NS code will be allocated into memory blocks that can be modified by the GPU.
  - But NS is needed to launch NS and you cant have two titles launched at the same time
  - Solution There is a backup title for every title with a different ID. While it doesn't let both to be run there is a "New 3DS NS" and that can be run along side the original NS

This gives us execution under a system module granting us access to more syscalls

ARM11 Kernel Exploitation¶

Lots of panics
No KSLR
No Stack Protections
User land is mapped
NX in kernel
- A RX and a RW Virtual Mapping come from the same Physical Address so writing to the RW mapping changes the RX mapping

Memory Allocator of ARM11¶

Kernel Structures in (Fast Cycle DRAM) FCRAM
- This is accessible from the GPU through DMA
- Overwrite memchunk headers through GPU and gain an arbitrary Kernel Write
- This was fixed with an update from Nintendo

This Function has a race condition because the GPU can still write memory in between mapping the memory to userspace and adding the information to the kernel process.

Time of Check time of use Vulnerability for mapping userland memory into kernel space
- Need to set Kernel Objects
- Request memory and after it is available patch the pointer of the next member
- Overwrite the mapped memory with SlabHeap pages
  - This is a huge chuck of allocated data with fake Vtable objects
- Call scvCloseHandle to deallocate KObjects

ARM9 Security Processor¶

Same Chip used on the NDS
Running similar kernel to the ARM11
No MMU
- the .data and the stack are executable
- .text is writable

Using the Shared memory between the ARM11 and ARM9 you can create a buffer overflow by changing the bounds of the byte transfer since its mapped in the same memory.

Boot9¶

Reads code from NAND
- Could also read from SPI flash
- Must be encrypted and signed
  - Two different keys are used one for NAND flash and the other one from non-NAND flash
  - Two different keys are used from retail and dev mode

RSA Signatures:
- Using 2048 and PKCS
- Embedded ASN.1 Encoded SHA-256
- Since SHA-256 is only XX bytes long it needs padding
- Padding is deterministic
- Parser is bad
- There is a should check padding flag
- Bad bounds checking
- Lets point the valid hash to the checked hash
- This allows the checker to only check the last few bytes of the signature making it easy to brute force

ARM9Loader¶

Version 1.0:
- Calculate the SHA256 Hash of the OTP
- Read the Key-sector for NAND
- Decrypt the first key using the OTP hash and put it in the keyslot 0x11
- Use the 0x11 key to generate a bunch of keys
- Verify the 0x11 key by encrypting a fixed test-vector
- Decrypt binary
- The Key is not cleared here
- Using this key we can regenerate all of the keys using the 0x11 key when getting code execution
- Jump to entry point

Version 2.0:
- Calculate the SHA256 Hash of the OTP
- Read the Key-sector for NAND
- Generate all the previous keys for compatibility
- Decrypt the second key from NAND
- Decrypt binary using the second key
- Forget to verify the key by the fixed test-vector
- Clear the 0x11 key
- Jump to entry point

Because the key2 is not checked against the test-vector we can use any key2.
We can change the NAND key on the NAND flash physically as well as add a payload on the the initial firmware
- The first firmware is loaded but it does not match the hash.
- The second firmware that is smaller overwites that part in memory other than the payload that is added to the NAND flash. This is because the first blob is larger than the second and none of the memory is cleared.
- The hash is valid for the second loader.
- The firmware is decrypted using the invalid key making random data
- Then just keep trying different keys until it jumps to the code. This is easier since alot of data is jumps in ARM.

StreetPass 3DS to 3DS communication¶

Automatically communicate with other 3DS systems to share data.

Pairing:
1. Both Master and Client Randomize Mac Address
2. Client Sends Probe request.
3. Master Checks its titles and sends a response with matches.
4. Confirmation of the matched titles.
5. Derive Key
6. Communicate encrypted

Session Key Derivation:
- Uses Master and Client CID and MAC address as data input to generate a HMAC.
- The key is a hard coded key (CECD) HMAC Key
- The output of the HMAC is the Counter that is used for encryption .
- The encryption uses AES-CTR
- The output is the session key

AES Engine¶

Write only AES keys
Key is never exposed to CPU
- normal_key = F(keyX, keyY)

Initial Analysis:

normal_key = F(keyX, keyY)

encrypt(zeros, keyX=1<<n, keyY=0) == encrypt(zeros, keyX=0, keyY=1<<(n+2))

F(keyX, keyY) = G((keyX<<<2) ^ keyY)

Since this is also used in the WiiU but the WiiU does not have two keys then using WiiU keys should work.

With more analysis G() if a bit is flipped then only one or two bits are flipped in the result. This bit flip is moved left by 87 or more never less.

Breaking G(x,y):

#Guess
normal_key = ((x <<< 2) ^y ) + C <<< 87

#Assume
(normal_key1 >>> 87) < (normal_key2 >>> 87)
((x <<< 2 ) ^ y0) + C < ((x <<< 2) ^y1 ) + C 
((x <<< 2 ) ^ y0) < ((x <<< 2) ^ y1 )

If y0 and y1 are equal except for 1 bit then the smallest yN has the same value as x in that bit.
- This works because of XOR is only set to 1 when both are different. This makes it larger than the other one since its set to 0.
This can be repeated and can get all bits of the key
- This can be used to calculate the constant C

NFC Fail:
- Firmware 8.1+ uses the Normal AES Key
- Firmware 9.3+ uses a hardcoded keyY.
- This gives us a pair of the matching keys

Hacking the custom sound library¶

If a MPEG file has a Unicode BOM byte in the Songname then it uses the size of the tag for memcpy
- This is a basic heap overflow
- Basic Heap unlink arbitrary write issue

Still no control over the instruction pointer so we need a stack pivot
- A stack pivot is used to control the Stack pointer so we can make a fake stack and control the stack and return address.
- After this its just a regular ROP chain

UAF in Kernel¶

Only counts Users access to KObjects. Does not increase counter for internal references
- This allows an UAF in the Kernel Timer module
- Closing the handle to the timer after it has run once but not run again allows an UAF

Glitching the ARM9 Security Processor¶

ARM RAM is not cleared on reboot
- This makes it possible to setup custom ARM Vectors in RAM
- Most of the exceptions we can trigger will be disabled at boot
  - Glitching a exception we trigger to another exception is possible

Fixing issues¶

Giving access to physical memory is dangerous even of you think you have protected the sensitive data.
Shared IO is dangerous
Only checking your data before decryption is a bad idea
- Not Checking the Key when it could be modified by an attacker.
Hardware Secrets are great unless you leak them in firmware

Gamecube¶

No code signing
Obfuscated data information on Disk

Remote Download¶

Phantasy Star Online was an Online game that used patches from the PSO Server to update the game
- Messing with the DNS allows an user to push unsigned code to the game cube
  - This allowed the Game cube to dump full disks over the network

BCA data was located on different location on the disk but encrypted
- Getting the unencrypted data from the Phantasy Star Online exploit was possible
- Bypass was found that the location data and right after was the encrypted data allows the data to be booted
- Attackers used the Action Replay disk to patch code in the Gamecube memory to run code from the memory card.

Hardware Crypto¶

Initial Program Loader aka IPL (GameCube Bios) was encrypted but could be replaced with hardware flashing
- Data that is sent into the bus is shifted right but never cleared. This allowed hardware hackers to get the keystream

Save Game Exploits¶

Save Game exploits on many titles

Nintendo Wii¶

Backwards compatible with GameCube
No Hypervisor
Isolated user processes

Boot Process¶

Boot Rom embedded in the (ARM CPU)
- Key storage in the (ARM CPU)
Read Only boot0 (ARM CPU)
Read Only hash of boot0 in boot1 (ARM CPU)
boot2 ARM chip (ARM CPU)
- boot2, OS and Menu are signed with RSA.
PowerPC chip

Software¶

Every Game are called titles
Title MetaData contains sha1 hashes of the content
- Also contains permissions gids and Regions
eTicket is the license to the title
- Contains the encrypted AES key to decrypt the title
  - Master key to decrypt the AES key is in One Time Programmable ROM
- May contain time limits for games (Demo)
TMD and eTickets are signed with RSA-2048
eTickets are specific to the console

DVD¶

Similar to the GameCube DVD drive
Modified DVD Dual-layer disk (obfuscated)
- Encrypted with AES and the eTicket
- uses hash tree to sign blocks and then the final master hash is signed.
Could play DVDs with a bit patched in the OS

Tweezer Attack¶

The upper 48MB of RAM is not cleared when the PowerPC chip is rebooted into GameCube mode.
- Normally the Gamecube can not access these lines but if you always set the high bits of the address lines high then you can read these parts of the chip.

Keys¶

Each console has its own ECC private key
- Hardcoded in the ARM chip
Each Console has its own ECC public Cert that is signed by Nintendo
- Hardcoded in the EEPROM of the ARM chip
NAND flash is encrypted with AES and HMACed
- Hardcoded in the ARM chip
Common Key 0
- Hardcoded in the OS and in the ARM chip
Key to Encrypt Save Games
- Hardcoded in the OS
Nintendo Root Certificate
New Korean key (Common Key 1)
- Hardcoded in the EEPROM of the ARM chip

RSA Hack¶

Uses RSA to decrypt the XXXX without padding
Then uses strncmp to compare binary numbers which breaks on the null byte
- This can be bruteforced until you have input data the creates a null byte in the first character

Twilight Hack¶

Exported save game is signed the consoles ECC private key
Extracting the ECC private key allows to resign save games
Using a stack buffer overflow in the save game exploit in Twilight Princess
Then load code from a septate save game and run ELF file on the PowerPC

OS (IOS)¶

Multable versions of IOS are stored on the secure ARM chip
When a game is run the PowerPC tells the secure ARM chip which version of the OS to run because it doesn't check which process it came from.
This allows privilege escalation to sudo
- This allows to rewrite any game and fake the signature using the RSA hack

Conclusion¶

RSA Hack in signature verification
Keys stored in external RAM unencrypted
Memory not cleared when entering Game Cube mode
Signature only verified at install time
- Chain of trust breakable by NAND access
PowerPC can reload older version of the OS
- Some API calls does not check the process it is calling from
- No re verification of the parameters

Nintendo WiiU¶

Improvements from the Wii¶

RSA Signature are now Checked at launch
Process Isolation and memory management (Kernel)
- Kernel Enforced NX
  - Except for the web browser
  - Otherwise can't mprotect
System Menu is encrypted
Will only boot encrypted and signed code

Bootrom¶

BootRom Design Flaw
- The boot rom suffers from a TOC/TOU vulnerability when checking RSA and decrypting the encrypted System menu.
- By replacing the memory after decryption has started allows unsigned code.
- This happens before comparability mode is enabled.
- Can use as a decryption Oracle

Dumping the Emulated Wii Rom:
- Bootrom dumped using a soft reset and overwriting the reset vector memory address.
- This is after L2 is flushed but not unmapped
- Using a specific hard reset with timing just under the specified value of 255 cycles allows code to be run
- The CPU is "Drunk" skipping some instructions etc. But dumping enough times gets the memory and can piece it back together
- This is fine for the fuses with the keys
- There is a register to renable the emulated Wii mode
- When this is reenabled boot0 is mapped

Hacking the Web Browser¶

Webkit is released under the LGPL license so they must provide the source code to view.
- Look at the Changelog for the version
- Changelog has the SVN commit
- Has many vulnerabilities
- Security Vulns are never released to the public
  - But they are mentioned in the SVN commits
  - With Unit tests
  - Grep for which SVN bug URLS in the SVN commits and which ones are behind a login gets you the security bugs

No Vtable/struct layout, Allocator, compiler information, or crash logs
- Got a heap overflow to dump memory
- NX can be bypassed with mprotect only on the web browser process
- No ASLR
- Lots of Bugs
- Uses Dynamic Linking
- Function Names are not stripped

Interfacing with the WiiU¶

Serial over the Sensor Bar
- Output only and slow
HCI over USB
- Input and Output but slow
Use GPIO pins on motherboard

Kernel¶

No ALSR
140 Syscalls
use safe copy_in copy_out for copying data from user mode to kernel mode
IPCKDriver_SubmitRequest contains an indirection.
- An indirection is a nested structure. They don't check the second level
- using this you can get a kernel arbitrary write but its hard to pull off.
- Changing the syscall pointer table you can change one byte of the syscall and point the call to a gadget.

Fault Injection in Boot0¶

Boot0 loads its self into RAM at D4100000
Boot1 header is loaded into D4000000 and not verified but checks length
- Create a different longer boot1
- Glitch the check for the size
- Boot1 overwrites boot0 and we have code execution on boot0

USB Descriptor parsing Exploit¶

https://garyodernichts.blogspot.com/2022/06/exploiting-wii-us-usb-descriptor-parsing.html

Switch¶

Lots of fuses
- fuse secure boot key 128 bits
- downgrade protection 32 bits
- SHA256 of RSA key 256 bits
- Bootrom patches 320 bytes
Use ASLR
Uses a micro kernel
Custom Vulkan-like Nvidia graphics driver
3DS / Wii U / Switch parental controls master key generator.

Security Model¶

TrustZone (Crypto)
Kernel (Process Isolation, IOMMU)
Kernel Modules (file system, service manager, etc)
MicroServices (Bluetooth, Wifi, etc)
Game/Applications

Application Sandbox:
- Syscall filtering (45/103)
- Service Whitelist (40 user services)
- Perprocess "file systems"
- Container for own process files

Service Sandbox:
- Syscall filtering (65/103)
- Service Whitelist
- No file access
- Sometimes MMIO mapped (kernel maintains IOMMU for all bus masters)

Base Service Sandbox:
- Bundled inside the kernel package
- Syscall filtering (65/103)
- NO Service Whitelist (Because they enforce the whitelist)

Breaking the Security Model¶

pl:u Service
- User accessible service
- Crashes on big values
- Array out of bounds read allows dumping of .bss, .text and other segments.

Service Manager Base Service:
- You send the PID of the service in the smInitalize() function and it checks to see if your pid is valid
- If you don't call the smInitalize() function the data is uninitialized (and will be 0)
- The process now thinks that your pid is 0 and you get access to all services

Kernel:
- The fsp-ldr is used to mount code in memory.
- The kernel enforces that only one session can have access to the file system at a time.
- If you crash the Loader process the session is released by the garbage collector and can read the binaries

Boot Sequence¶

BootROM in the ARM7 (Boot Processor and Power Management Processor)
- Also Possible nvtboot recovery
Basically stock with some custom patches from Nintendo
Loads offset and signature for next boot (SecureMonitor)
Has recovery but needs to be signed with Nintendo's Private Key
Package1 has two parts one that decrypts the other

Glitching the Switch¶

The Package1 secret key is used to decrypt the kernel loader
It uses RSA-PSS to sign the bootloader signatures
- The SHA2 hash of the RSA Public key is in the fuses
What happens if we can glitch the SHA2 comparison
- To get the timing for the glitch you monitor the eMMC bus getting the timings and the difference between the messages.
- When the hash is valid there is a long time between the next emmc command.
- When the hash is invalid there is a short time between the next eMMC command since it trys to read the next hash.

Breaking the Kernel¶

Cannot execute Userland code because of Privileged NX bit
Same DRAM is mapped to one address range as R-X--X and to another address range to RW----
- Because of the second X they also mapped the Kernel Memory into Userland and made it executable
- Because of the Privileged NX bit this is mostly useless but you can use that memory for ROP Gadgets
  - This has the benefit of KASLR bypass with those gadgets since they are mapped to the location each time
Objects on the Heap are allocated using SlabHeap
- This makes Use after frees difficult to exploit because they are fixed sizes
Kernel implemented IOMMU prevents DMA access to other memory
- Since it is an off the self device their is an official datasheet with instructions on how to bypass the IOMMU
  - This can be done by the GPU by setting a specific bit in a register.
  - Since this is in hardware it is not fixable
- Another way to bypass the IOMMU is through the fs Base Service (kernel module)
  - Requests from the fs service are trusted and not checked.
  - This can be used to access the memory controller so we can manually change the mappings in the kernel module memory
- Unfortunately this does not work for the rest of the kernel because other DMA protections in the kernel
  - Upon looking at the code there is a case for small and large allocations.
  - Large allocations use a Pool that is not protected by the DMA protections
    - Overwriting the kernel handle table allows mapping it to the current process

Trust Zone (SecureMonitor)¶

SecureMonitor is the boot code for the main ARM CPU
- This boots the Horizon Kernel
- Use the Tegra Security Engine for the Crypto tasks
- Starting and Stomping the CPU Cores
- Start and Stop Sleep Mode

Sleep mode SOC is turned off other then the power management processor and the DRAM
- Encrypted TrustZone Ram is saved to external DRAM.
- Is also authenticated
Walking Up using the warmboot.bin
- Decrypts and verifies the DRAM to TrustZone RAM
- This can be used to get code execution in the

Trust Zone (Tegra Security Engine)¶

Hardware Crypto Engine for AES, SHA, RSA, RNG
Allows 16 AES Key slots
Allows 2 RSA Key slots
Key Slots can be individually locked
Operations can be preformed on Registers, other Key slots, DMAed memory

Request KEK from Non-Secure World
Generate and Wrap KEK and send to Non-Secure World. This is a per boot key
Unwrap and decrypt request using the encrypted key in the Secure World.
Final key is retrieved in the Non-Secure World

NVIDIA Tegra X1¶

How and Why Glitch works

Pressing the correct keys on boot launches the NVIDIA Tegra X1 chip into recovery mode.
The operates over USB and can send messages to the chip.
- Needs Valid Crypto private key to send messages
- But there is a parsing vulnerability in the USB message protocol layer
- Sending a large data puts data into memory asynchronously
- Then before sending all of the data through usb you can request the status of the transfer which trys to copy the data but uses the length field from the send data packet.
- Should be a static 2 bytes but uses the data in the packet sent by the attacker
- Then is used in a memcpy to copy the data from the stack to the USB DMA buffer located before the stack.
- Since the destination is before the stack you can just make the memcpy long enough to include the 16Kb of the USB Buffer and the 12Kb of the stack.
- This copies the data from your USB request to a shorter data area which overwrites the stack.
- This overwrites the whole stack are are able to get code execution before the signature is checked for validation

How to Glitch Properly:
- Use Clock Synchronization between the glitching and the target board. This allows you to glitch on the rising edge of the clock cycle where the flip flops can change state.
- Try to get a start time that is close to the start of where you want to glitch
- Make sure you start your timer at a stable spot

USB Exploit steps:
1. Connect to USB
2. Read ECID
3. Download Code with Invalid Signature
4. Don't finish the code transfer
5. Send a GET_STATUS control transfer command with a large wLength
6. Gets coped over the stack and we control the return pointer

Exploit Info¶

The Switch - A Memoir

Extracting the AES Key¶

https://gist.githubusercontent.com/plutooo/733318dbb57166d203c10d12f6c24e06/raw/15c5b2612ab62998243ce5e7877496466cabb77f/tsec.txt

PlayStation Portable¶

Wipeout game had download-able content. This with DNS redirection attacks allowed the rendering of a browser.
- The web browser allowed access to the internal file system of the PSP.
- This dumped the flash and reversed the EBOOT.bin file format.
- Linux Elf binaries were also able to be executed.

Firmware 1.0 allowed for unsigned code
Firmware 1.5 allowed for unsigned code when you swap the memory card during boot
- Sprinf vulnerability in folder names allows unisgned code to be run
  - One folder called "REminiscence" with the file metadata
  - One folder called "REminiscence%" with the EBOOT.bin allowed code execution

Firmware 2.0 added a Web browser, image viewer and other features
- Buffer overflow in tiff file
  - Allowed downgrade to Firmware 1.5
  - Allowed Homebrew menu
  - Exploit was not totally patched until 2.8

Firmware 2.01 - 3.03
- Save game buffer overflow exploit was found in GTA Liberty City Stories
- Firmware 2.5 and 2.6 opened up kernel mode
- Rockstar revoked old version of GTA Liberty City Stories with newer ones

Released Custom Firmware to run games that needed newer versions of the PSP

Pandora Battery¶

Restore Bricked PSPs
Restore to any firmware
Could not be fixed by software

PSVita¶

Sony's Best Crypto to date
- Simple secure boot
- Security Co-processor
- Modern Exploit mitigation on ARM processor
But they did not use a random Bootloader decryption key
- Instead they used AAAAAAAAAAAAAAAA

Levels of the Vita:
1. F00D Loader
- Makes sure the F00D Loader is valid
- Allows Revoking of keys
2. F00D Kernel
3. ARM TrustZone/ARM Kernel
- User Processes
- WebKit
- JIT
- System Processes
- PSP Mode

Breaking in to the Security Co-processor¶

Is named the F00D Kernel
Contains the Keys
Uses a Custom RISC instruction set similar to MIPS
- Has no virtual memory
- Is not hardened for security

Applet Loading:
- Applets are basically different libraries that can be loaded to use certain features.
- Since ARM operates in Virtual Addresses and F00D operates in physical addresses there is a list of mappings
- Since the list is in DRAM it can be modified and pointed to F00D's internal memory.
- So now we can copy memory into any location in the internal DRAM. (So you cant writeout)
- But since the signature is checked. (So you can't exec arbitrary data)
- But since there is a way to overwrite data in that memory and there is a way to check that the same value before is the same value after you have verified that data.
- Only one applet can be loaded at a time
- Applets are signed and encrypted and transmitted from the ARM to the F00D to be verified and decrypted

Applet RPC Calls:
- Applet RPC from ARM to F00D to Applet and back to ARM

Applet Unloading:

Controlling all Input into F00D and its not checked
- But remember still signed and encrypted
- Step 1 Lets dump the memory so we can see what the Applets look like decrypted

Glitching the F00D Loader¶

Find the Voltage pins
- Find a Datasheet.
- If not removing the layers and trace them
Find the Voltage rail that you need to glitch
- Write a simple code that has predictable outputs and run it.
- Glitch all of the rails and see which ones are corrupted
Find the correct part of the code
- Bypass size check to overwrite data
- Sniff other data like DRAM and external storage
Guess and Check
- Reset the system
- Detect Partition read packet
- Wait N cycles
- Start Glitch
- Wait M cycles
- Stop Glitch
- Was the bootloader read? (Success)
- If not and still on. (Increase M)
- If still nothing. (M=0, N++)
- Goto top
Sync clocks of the Glitching board and target board
- Also Slow the clock it reduces noise

Exploits¶

PSVita 3.65-3.68 Kernel exploit Writeup
3.7X PSP Emulator escape