Old notes

Author: rickmark

_docs/rickmark/Abusing_the_Titan.md

@@ -0,0 +1,53 @@
+# Abusing the Titan
+
+# tl;dr
+
+A specially crafted version of ABOOT is capable of being installed to a device with critical flashing unlocked, and in doing so can suppress the insecure notification, modify the booted image, and lie about the unlock or lock status of the device.  The only way to detect this for pixel devices is to enter EDL mode and run an image to validate the boot environment, which is not provided at this time.  This may not be possible either, given that the DWC3 (USB-C controller) similar to the ACE in the Apple ecosystem, if corrupt, may prevent connection to EDL.
+
+
+# Method on Pixel 8
+## Theory 1
+- OEM Unlock
+- Access Fastboot
+- `fastboot oem gsc sjtag-cfg` - Provides JTAG
+- Reset
+- Flash to EVT before lockdown in RO region
+- Provides ripcurrent bootloader
+- Board 0?  
+- Can read Dauntless with `fastboot oem gsc header <RO_A|RO_B|RW_A|RW_B>` 
+- `fastboot oem gsc` - Access to Dauntless (Second Gen Titan-M)
+- `fastboot oem gsa` - Access to Titan-M trustee applets
+- 
+## Theroy 2
+- OEM Unlock
+- fastboot flashing unlock_critical
+- Reboot to Exynos EBM
+- Stream sb1
+- ?
+- Get to Aboot or some other state
+- Stage evt.bin for Titan (having side-stepped anti rollback)
+- Recover titan
+- Now in factory mode
+- set new root of trust
+- EL2
+- ABOOT that lies
+- Remainder of image is blue pill
+
+
+
+# Recommended Fix
+## PROM Fuse to Set Minimal Version (Epoch)
+
+Apple has a similar concept but only roll this value when there is a known reason to do so.  This is totally foolish as many exploits are not discovered for a number of years and rolling back is a simple attack.  With only 16 bits of PROM you could easily increment every week to the current version of the Titan-M firmware.
+
+
+## Do not allow a MP AP to flash EVT Titan-M firmware
+
+This seems like a simple statement, but the determination of what makes an MP is difficult.  Similar to above, the determination of if the Titan-M is MP or EVT should not be based on the firmware but a PROM value that can only ever fuse downward from EVT → MP
+
+## Support EDL / EUB modes on recovery / restore google sites
+
+
+## Properly Document the EVT → MP and Titan-M security functionality
+
+

_docs/rickmark/Is_This_Thing_On.md

@@ -0,0 +1,11 @@
+# Is This Thing On?
+
+## Photo of a microphone on a stand with a finger tapping it
+
+  As I sit here typing on my laptop, I look around.  I can count microphones in my laptop (and countless others sitting in a pile nearby), my phone, tablet, watch, an Alexa and a HomePod, and even two remotes for the TV and satellite receivers.  If you told this to someone from just a few decades ago they would have been incredulous or physically recoil.  We’ve invited the vampire into our home.
+
+- Faraday bag, think of a Maxwell Smart-esque cone of silence for digital devices
+- Turn your phone off, no really turn it off.  Can you remove the battary.  Is the screen black, do you believe it?
+- T2 and the always on processors
+- 
+

_docs/rickmark/Jailbreaking_the_T2_with_checkra1n.md

@@ -0,0 +1,57 @@
+# Jailbreaking the T2 with checkra1n
+
+## What is Jailbreaking a Mac Anyway?
+
+This is a question we get a lot.  What does it mean to “jailbreak” a Mac, since you can already run any code you want (if you bypass code-signing, SIP, SecureBoot and Gate Keeper anyway).  When we say “jailbreak a Mac” what we mean is jailbreaking the AppleSilicon T2 processor.  This core runs a iOS derivative called `bridgeOS`.  Until now Apple has not allowed or supported any non-Apple code executing on this core.  Since this core comes up and aids in the operation of the Intel processor, it allows for a bunch of possibilities not possible before, such as completely replacing the Mac’s EFI.
+
+An overview of the process is:
+
+- Get a copy of `checkra1n` and `libimobiledevice`
+- Place the Mac into DFU mode using the Apple support guide
+- Connect to the technician workstation (yes you need a second computer)
+- Run checkra1n
+- Connect to SSH
+
+
+## `checkra1n` 0.11 and T2 Support
+
+With the release of 0.11 checkra1n began to support the T2 and bridgeOS as a target.  You will need to have downloaded (and in the cases of a Mac, run at least once to bypass Gate Keeper) this tool before proceeding.  If you haven't done so go on over to https://checkra.in to get a copy.
+
+In order to access SSH you’ll also need the tools from https://libimobiledevice.org.  If you’re on a Mac you can install this from home-brew with `brew install libimobiledevice` and you can install on Linux by installing the package for your distribution. 
+
+
+## Placing the T2 Into DFU Mode
+
+Fortunately for us, Apple has provided instructions on how to place a T2 based Mac into DFU.  This is in their support guide “[Revive or restore Mac firmware in Apple Configurator 2](https://support.apple.com/guide/apple-configurator-2/revive-or-restore-mac-firmware-apdebea5be51/mac)”.  Per their instructions a USB-C to USB-C or USB-C to USB-A cable is required.  Thunderbolt is not supported.  Once you find the model of your Mac, connect the DFU port to the computer where you have installed `checkra1n`.  Follow the model specific guidance in that support article to place the computer into DFU mode.  Once that’s done, you can verify by running `lsusb` on Linux and `ioreg -p IOUSB` from a Mac.  You should see an `Apple Mobile Device (DFU)` mode attached if you successfully entered DFU.
+
+A DFU device in `lsusb`
+
+![](https://paper-attachments.dropbox.com/s_FA6AAA07030DF3145418B8DEBD132850C234EAA3DCDD633D14D24C758773CF23_1602572131766_t2_dfu_linux.png)
+
+
+**A DFU device in** `**ioreg -p IOUSB**`
+
+![](https://paper-attachments.dropbox.com/s_FA6AAA07030DF3145418B8DEBD132850C234EAA3DCDD633D14D24C758773CF23_1602572421525_t2_dfu_mac.png)
+
+## Running `checkra1n`
+
+Currently checkra1n can only be run in CLI mode (running any GUI mode will inform you the device is not supported).  If you have issues you can increase the debug output with `--verbose-boot` and `--verbose-logging`
+
+**From a Mac**
+`sudo ./checkra1n.app/Contents/MacOS/checkra1n` `--``cli`
+
+**From Linux**
+`sudo ./checkra1n` `--``cli`
+
+![Running checkra1n against a T2](https://paper-attachments.dropbox.com/s_FA6AAA07030DF3145418B8DEBD132850C234EAA3DCDD633D14D24C758773CF23_1602572505677_t2_checkra1n_public.png)
+
+## Connecting to SSH
+
+Once the device has run checkra1n, it’s ready to accept a connection to dropbear for SSH.  You connect to SSH with a T2 by proxying the connection over `usbmuxd`.  The SSH server runs on the T2 on port `44` due to specialized handing of `22` in the kernel.  Also you will have to keep connected to the T2 because once the USB connection is broken, it will return the port to the Intel.  As always, the password like an iPhone is `alpine`
+
+
+    $ iproxy 44 2202
+    $ ssh root@localhost -P 2202
+![A successful SSH session to the T2](https://paper-attachments.dropbox.com/s_FA6AAA07030DF3145418B8DEBD132850C234EAA3DCDD633D14D24C758773CF23_1602572565080_ssh_checkra1n.png)
+
+

_docs/rickmark/Linux_Command_Parameters.md

@@ -0,0 +1,59 @@
+# Linux Command Parameters
+
+- debug
+- nopv
+- ignore_loglevel
+- stacktrace
+- sched_debug
+- rootwait
+- ring3mwait=disable
+- retain_initrd
+- hibernate=no
+- rcutree.dump_tree=on
+- profile=schedule,sleep,kvm
+- printk.devkmsg=on
+- prink.always_kmsg_dump=y
+- pnp.debug
+- pci=earlydump,nodomains
+- noresume
+- no_console_suspend
+- nf_conntrac.acct=1
+- iwlwifi.blacklist=1
+- blueooth.blacklist=1
+- bthci.blacklist=1
+- hci_vhci.blacklist=1
+- nfs.blacklist=1
+- nfsd.blacklist=1
+- nfs4.blacklist=1
+- sunrpc.blacklist=1
+- xen.blacklist=1
+- kvm.blacklist=1
+- mce
+- lsm.debug
+- iomem=strict
+- iommu.strict=1
+- intel_pstate=disable
+- integrity_audit=1
+- initcall_debug
+- keep_bootcon
+- efivar_ssdt=off
+- efi=debug
+- earlyprintk=efi,keep
+- early_ioremap_debug
+- nopku
+- dma_denug=on
+- disable_ipv6=on
+- debugpat
+- debug_objects
+- earlycon=keep
+- audit=on
+- bootmem_debug
+- audit_backlog_limit=4096
+- acpi_osi=
+- acpi.debug_layer=0x02
+- acpi.debug_level=0xffffffff
+- acpi_enforce_resources=strict
+- acpi=strict
+- acpi_no_memhotplug
+- log_buf_len=256M
+

_docs/rickmark/Loki.md

@@ -0,0 +1,58 @@
+# Loki
+
+- Disconnect battery and all devices technician
+- Disconnect antennas
+- Read firmware from technician via Medusa
+- Use off net loaner to read Medusa to cold storage
+- Use loaner to identity and locate clean FD file
+- Use loaner to identify and locate clean SMC & Updater
+- Use loaner to identify and locate clean Thunderbolt & Updater (From the AV adapter update)
+- Use loaner to prepare rEFInd and shell USB drive
+- Write FD from loaner to Medusa
+- Disconnect internal storage in technician
+- Read serial number from technician machine
+- Remove power technician
+- Write FD from Medusa to technician
+- Reset SMC using external contact switch
+- Write serial number to technician
+- Boot technician from reFINd
+- Reset SMC using external contact switch
+- Attach power
+- Perform SMC update
+- Perform Thunderbolt update
+- Power off technician
+- Verify technician via Medusa
+- ASSERT: Firmware should be clean
+- Attach persistent storage
+- Target disk mode technician
+- Read disk raw to backup
+- Zero disk
+- Power off technician
+- Attach other devices
+- Restore OS
+- Verify that KDP works
+
+Purchase:
+Write-prevent USB (One of OS, one for rEFInd)
+Thunderbolt -> Firewire
+Sufficient size backup drive, mirror to DBX
+Remaining items:
+Disassemble SMCUpdater
+Disassemble ThorUtil
+Knowledge:
+TouchBar will not be online without persistent storage
+Concerns:
+After EFI clean, must make sure boot-device is external with rEFInd to prevent re-infection
+Assertion:
+Loaner is clean out of box
+Not on network (lateral movement via SSH)
+Secure Enclave will be off-line
+Places where persistence may occur: Thunderbolt, SMC, EFI
+Questions
+Can we remove keyboard and mouse from equation?
+Can we disable network via nvram (previous data suggests yes)
+Firmware for disk controller (NVM)
+Can we prove all bits of disk accessible, write byte stream of random and generate hash, then verify. Ensure number of bytes against another machine. What about bad pages? Do they have spare area?
+What if we restore to a clean external disk to verify firmware before trusting internal NVM
+Is booting from optical media still supported? (Read only, and or observable change)
+

_docs/rickmark/Modern_Apple_Threat_Models.md

@@ -0,0 +1,29 @@
+# Modern Apple Threat Models
+
+# Being Trapped in a Demoted Device Through the PMGR
+
+
+# Having a Device Swapped with a PVT (Production Validation Test Unit)
+
+
+# Being Enrolled in Sandbox APNS / MDM / DEP
+
+
+# Silent Application of MDM Settings
+
+
+# Kernel Personas
+
+
+# Various forms of Modern Trustjacking
+
+
+# Factory Restore Process
+
+
+# Abusing Backup / Data Migrators
+
+
+# Being Trapped in Recovery
+
+

_docs/rickmark/Modern_Defense_Against_the_Dark_Arts_(AKA_2024_SEC.md

@@ -0,0 +1,38 @@
+# Modern Defense Against the Dark Arts (AKA 2024 SEC)
+Modern devices have adopted numerious technologies designed to defend against attackers, but the same such systems can be used to cover up evidence.  We now need to look at how to balance the use of high integrity and security devices with those devices that are also subject to investigation and checking of integrity.
+
+
+
+## The Loss of th SIM
+
+We over the last five years have effectively phased out the SIM card for majority of US subscribers.  But the issue at heart here is that there is not method to interrogate and validate the correctness of the eSIM since it is soldered onto the device. 
+
+
+
+## The Mis-Use of Enclaves
+
+**Fixing Fasboot**
+
+
+
+## Undocumented Boot Modes
+
+**The world of USB-C and USB-PD**
+
+
+## Radios Everywhere
+
+
+
+## Lack of Correlating Identifiers
+
+
+## Lack of Security and Integirty Training
+
+**BMW and the Issues Related to Vehicle Integirty**
+
+
+
+
+
+

_docs/rickmark/More_Then_SecureBoot_-_PKI_Based_Device_Identity.md

@@ -0,0 +1,23 @@
+# More Then SecureBoot - PKI Based Device Identity
+
+# Let’s not get ahead of ourselves…
+
+Today we have much larger problems in IoT devices such as the use of secure protocols, firmware SecureBoot and full encryption.  Those issues do in fact need to be solved, and this paper is more about what to do next.
+
+
+
+# If You Control the Ecosystem, Create a PKI
+
+Let’s use Alarm / Camera company ACME Alarm.  Since they know that ACME door sensors will be used with their own base stations, they should include a PUF (physically inclinable function) that provides the entropy for the private key of an EC key.  The device should then have an x509 certificate burned into ROM providing a strong device identity.   This key and certificate should be used only for the derivation of new credentials, not for the communication itself, as is required by PFS (perfect forward security).
+
+
+## You Can Warn or Deny When Out of Ecosystem
+
+The ACME security base station could then throw up a caution screen if the pairing process results in a end to end security stance that indicates the device’s origin doesn’t come from ACME Inc.  The Z-Wave initiative actually enforces that no provider can deny access to a Z-Wave network because it comes from outside the manufacturer ecosystem.  This however does not prevent ACME from warning when it’s not ACME certified hardware, or from an ACME trusted partner.
+
+
+
+## You Can Have a Hardware Key and a Use Key
+
+While the hardware key should be based on both confidential private key and a burned in certificate, a good implementation should use this simply to be an attestation allowing the device to derive a private key for a particular user / session, and requesting a certificate for that to be stored in mutable storage.  This prevents the general usage of hardware key for communication between nodes, while also providing a hardware based root-of-t
+

_docs/rickmark/NOTES_Crouching_T2,_Hidden_Danger.md

@@ -0,0 +1,18 @@
+# NOTES: Crouching T2, Hidden Danger
+
+- **completely exposing your macOS (and iPad Pro) - the debug cable may be compatible with the iPad Pro, but since checkm8 is not this isn’t the case**
+- The T2 is not the SEP, the T2 contains the SEP
+- The boot sequence fully brings up the T2 / bridgeOS before the Intel is released from reset and allowed to boot EFI at all
+- No T2 has SATA, it uses NVMe and PCIe to talk to NAND storage
+- The T2 / bridgeOS is fully booted and stays on even when the computer is off, so the boot sequence holds here for the power button
+- This is not the “next boot disk” since each processor has it’s own system volume, also replace “APFS encryption” with FileVault2 as that is a more accurate term
+- Read: http://michaellynn.github.io/2018/07/27/booting-secure/
+- The T2/bridgeOS is charged with approving kexts during load
+- Filesystem seals: correctly called SSV (Signed System Volumes) is a iOS 14/Big Sur feature
+- Break SSV and SIP apart
+- Debug cable requires demotion, which is possible with checkm8
+- I suggest leaving out the commands until checkra1n publishes the instructions since you have gaps in it
+- `smcutil` is for older T1 and prior
+- Cannot decrypt FV2, but likely can brute force it (waiting on PoC to confirm that though)
+- 
+