A Potpourri of Pwn

Jevin Sweval
For Apple Inc.
2018-12-06
 About Me
• Worked at Arxan Technologies for six years

• Anti-tamper and obfuscation protection

• EnsureIT - LLVM/Clang based product operating on LLVM IR

• PS3 port to Power 64 and Sony’s custom ABI

• Countless hours spent understanding libc’s/runtime linkers and

reversing iOS internals

• GuardIT - Binary based project decompiling customer binaries,

protecting, and reassembling/relinking

• Port x86 engine to support ARM/Thumb v7 for Android protection

• Research Team

• ENABLE_BITCODE - Port EnsureIT to work on bitcode only

without a binary-based post-linker step

• Automatic App Protection for Android APKs

• Discover and develop PoC of new protection techniques

 About Me
• Lots of hacking as a hobby
• PS3
• Reverse engineering undocumented dev-kit internals
• Working on exploiting Flash 9 after Sony xed WebKit based CFW
vector in latest PS3 rmware update
• PS4
• Working with a global team on replicating failover 0w’s hardware SCA
to recovery root console keys from south bridge and APU security
module
• Android/iOS
• Tegra SoC bootrom attacks
• Tweaks to unlock restricted functionality in applications
• Whitebox Cryptography
• iTunes album art encryption
• FairPlay application DRM
fi
fi
fl
iOS Debugger Detection
• dyld/src/glue.c
void _dyld_debugger_notification(enum dyld_notify_mode mode, unsigned long count, uint64_t
machHeaders[])
{
// Do nothing. This exists for the debugger to set a break point on to see what images
have been loaded or unloaded.
}

• Just RET in ARM/ARM64

• When LLDB attaches, it nds this RET and replaces it with BKPT
• Find this symbol at runtime and see if it is RET or BKPT to detect
LLDB
• dyld/src/dyld_gdb.cpp
static void gdb_image_notifier(enum dyld_image_mode mode, uint32_t infoCount, const
dyld_image_info info[])
{
switch ( mode ) {
case dyld_image_adding:
_dyld_debugger_notification(dyld_notify_adding, infoCount, machHeaders);
break;

• The noti er subroutine is called when dyld loads or unloads an image

fi
fi
iOS Debugger Detection
• Finding _dyld_debugger_notification is a simple matter of walking
dyld’s Mach-O load commands to nd the __TEXT,__text segment
symbol table info and then iterating over the symtab to nd the symbol

• I use LIEF in this example but wrote a freestanding Mach-O and ELF
parser in C++ at Arxan that avoided heap allocations and never left
the target symbols as plaintext in memory

• How do you nd dyld’s Mach-O header to parse?

• _dyld_get_image_header() but that can be hooked

• It can be replicated by parsing dyld_all_image_infos but that must

be found with dyld’s Mach-O header as well

• Just call __builtin_return_address(0) in a constructor to get a

pointer into dyld’s __TEXT,__text
• Mask that pointer to 4 KB and walk back 4 KB until you nd
Mach-O magic (works with 16 KB page devices too)
fi
fi
fi
fi
 iOS Anti-Debug
• What if we called _dyld_debugger_notification
ourselves instead of letting dyld have all the fun?

• And passed in lies for the parameters?

• dbg_notify_fptr(dyld_notify_adding,
0x7FFFFFFF, nullptr);

• Xcode is not happy.

• Older versions of Xcode consumed > 32 GB of RAM

before crashing

• Current Xcode beachballs while lldb-rpc-server chews

up an entire core
iOS Anti-Debug
iOS Anti-Debug
iOS Anti-Debug

😈
 A Fun Heisenbug
• Customer reports protected app rebooting phones

• Can’t reproduce locally, customer won’t provide artifacts, log

issue and move on since customer can work around using a
di erent protection seed

• Second customer reports a similar issue

• Provides artifacts, we nd it only reproduces on certain devices

• Again very sensitive to the protection seed but seems to happen

in FP-heavy code

• Reproduce using Fhourstones, vastly simplifying further debugging

• Used delta debugging (LLVM bugpoint and Delta) to somewhat

minimize repro
ff
fi
 A Fun Heisenbug
• No API calls, no syscalls around reboot. No kernel panics, just WDT timeout!

• Instrumenting app with logging and tracing would usually make the issue disappear

• Issue is found to only occur on Apple A8 CPU… is this an erratum?

• Nothing found by digging around LLVM source, even Apple FOSS releases

• Using Xcode clang to assemble asm xes the issue. Di erences in bitcode between
FOSS and Xcode determined not to matter

• Disassembly of the Xcode assembled asm reveals that clang is assembling

movi.2d vX, #0 as movi.16b vX, #0

• Further reversing reveals that the above transformation is the complete erratum
workaround

• Fixed by LLVM ag -fix-16473581 “Fix for rdar://16473581”

• Still not part of open source LLVM/Clang releases today. Unsure if App Store
checks ever started looking for this DoS.
fl
fi
ff
 Tegra Bootrom Exploitation
// If this is asking for the DEVICE's status, respond accordingly.
if(setup_packet.recipient == RECIPIENT_DEVICE) {
status = get_usb_device_status();
size_to_tx = sizeof(status);
}
// Otherwise, respond with the ENDPOINT status.
else if (setup_packet.recipient == RECIPIENT_ENDPOINT){
status = get_usb_endpoint_status(setup_packet.index);
size_to_tx = length_read; // <-- This is a critical error!
}

Simpli ed code and diagram by Katherine Temkin (@ktemkin)

fi
 Tegra Bootrom Exploitation
• Bootrom readout after rst 1 KB is blocked by a write to a PMGR security register as last
step in bootrom before jumping to next stage bootloader

• Ported Tegra X1 bootrom exploit originally developed for Nintendo Switch to Denver
(Nexus 9), 3 (Nexus 7, Honda CRV, Tesla Model S), 2 (Asus TF101, WIP)

• Di erent o sets, packet header sizes

• Debugging di cult, lack of UART, use reboot to signal success, store values in
always-on PMGR registers and SRAM that survive reset

• Teams spent much time dumping bootrom. It turns out Nvidia reused bootrom code
in miniloaders (think iBEC) that are publicly available and contain the same
vulnerability

• Tegra 2 contains the vulnerability but is not easily exploited

• Working on two phased attack where the payload loaded to SRAM, bootrom
manipulated to reset SoC, then exploit the vulnerability using payload persisted in
SRAM from rst phase

• Working on Tegra support in QEMU to discover a method to reset SoC after payload
loading
ff
ff
fi
ffi
fi
Tegra Bootrom Exploitation
• Tegra uses an SBK encrypted (later encrypted + RSA signed) “warmboot
blob” to restore PLLs / DRAM peripherals after waking from deep sleep

• The warmboot blob header speci es the address for the bootrom to load
it into SRAM

• Load address is not checked! Set load address before bootrom stack
and overwrite return address to return to custom payload in blob

• Spray copies of bootrom or secure boot key to end of SRAM and

dump from Android after boot using /dev/mem or kernel module

• NOP out SBK key disable in Asus TF101 aboot bootloader to enable
encryption of exploit warmboot blob, then overwrite original blob with
properly encrypted exploit blob

• aboot is encrypted with SBK but it conveniently encrypts and ashes

any unveri ed bootloader written to an update partition
fi
fi
fl
 iTunes Album Art Whitebox Crypto
• Back in 2012 when I used to meticulously curate my
music library, iTunes provided the highest resolution
album art

• Some time prior, Apple started encrypting the album art

• Encrypted art 20 bytes larger than decrypted art

• Reversed iTunes.dll to discover RC4 decryption of data

after 20 byte header

• Header contained some key but not the key fed to RC4

• My rst discovery of whitebox crypto

fi
 iTunes Album Art Whitebox Crypto
• Used OllyDbg to identify outermost key transformation subroutine

• Trace every instruction executed and memory accessed during that subroutine

• From traces, all code and data tables (27.5 KB total) used in whitebox were
identi ed and lifted to source form

• With a Python script to search and download encrypted art, I was able to decrypt it
using my code lifted whitebox that now ran on any platform
fi
iTunes Album Art Whitebox Crypto
iTunes Album Art Whitebox Crypto
iTunes Album Art Whitebox Crypto
• After getting hired at Arxan and learning about their whitebox
product, I became interested in extracting the normal AES keys

• In 2016 I used SideChannelMarvel’s Daredevil to attempt key

extraction using CPA

• Could not nd the right parameters to get a full key but

Daredevil believed it had found every odd byte of key

• Last month I revisited the topic and used the newer JeanGrey
tool to perform a DFA attack

• Keys recovered in fewer than 40 lines of Python and less than

10 seconds (single core) for each of the 64 subkeys

• My 2016 CPA attempts were on the right track, the odd key
bytes were indeed correct
fi
FairPlay App Binary DRM
• As part of the ENABLE_BITCODE project at Arxan, I investigated
using Apple’s existing code signing as an alternative for requiring
a post-linker step that hashed compiled code

• Soon realized that the code signature is on the FairPlay encrypted

binary, not the decrypted version that would be hashed at runtime

• How to get the decrypted binary to hash?

• Jailbroken device dumping binary from a live process

• Authenticated backdoor to dump out binary upon receiving a

signed request

• What could go wrong?

• Reverse engineer FairPlay?

FairPlay App Binary DRM
• Initial investigations focused on iOS 3.0 since it was the rst
version to include App Store and a quick glance showed it
had weaker obfuscations than newer iOS

• Cloakware identi ed by “Standard-Eta”, “Standard-Beta”,

“Standard-Theta” XOR encrypted strings

• Shelved the project until I improved my iOS kernel hacking

skills

• Originally planned to use Kirk Swidowski’s VERTIGO

microvisor to trap MMIO access to CDMA peripheral

• Last month I reversed iOS 7.1.2 FairPlayIOKit some more

and realized it didn’t directly access CDMA peripheral and
went through AppleCDMA.kext
fi
fi
FairPlay App Binary DRM
• Used xerub’s kexty project to get an easy to use kernel
mode working environment with my own custom kext

• Overwrite AppleCDMA vtable’s _performAES pointer to

point to my dumper subroutine that dumps key, IV, key ID,
16 bytes of plain/ciphertext and any extra data in
IOAESAcceleratorRequest

• Load the target application and walk every page to get

FairPlayIOKit to decrypt every page, logging keys/IVs over
UART

• Result: Every page is encrypted with a unique key/IV pair.

Complete o ine decryption is possible with dump log.
ffl
 FairPlay App Binary DRM
• key_id 300

• IOAESAcceleratorRequest has an extra 32 byte bu er that is

some kind of table for a “FairPlay descrambler” implemented in
the CDMA hardware

• Still unsure how the descrambler works

• Decrypted all 0 key/IV/PT with all 3 bit bit ips of all zero
scrambler bu er and recorded PTs

• No di erence between CBC and ECB mode so IV is not involved

• No simple XOR mask, LFSR, GF(2^8) multiplication, or AES S-

Box application of scrambler bu er found

• Working on statistical analysis

ff
ff
ff
fl
ff
 Q&A
Source code is available upon request.