These are just some notes on my current understanding of the subtleties of the AGX memory model and the TLB/caching issues I'm seeing.
TLBI instructions do not broadcast to the GPU from EL1 with stage 2 translation enabled. That's it. That's what the bug was.
Those patches are to convert GameBoy ROM to .pocket ROM. This allows you to play games from the SD Card on your Analogue Pocket.
Feature like RTC and Link cable seems to be unsupported by the Analogue Pocket in GB Studio mode.
Both iPhone and Watch ship with a Secure Enclave processor. Both are also H11-class SoCs. As such, there are broad similarities between the different blocks. Embedded cores present on-die use firmware written with RTKit, which is Apple's own broadly-used RTOS on cores codenamed Chinook. The codename for the eSIM platform on both the iPhone and Watch is Vinyl. The NFC (+Apple Pay?) controller is named Stockholm, and the Apple Watch Series 4 + iPhone Xs and Xr ship with version 5.
| choose(DAWindowController)[0]->installWindowsDirect = true |
So you want to decrypt switch content ? Well, the good news is that all the tools required to do that are written up! The great news is, since this is crypto we're talking about, you'll have to find the keys. Yourself. Like it's easter.
So here you can find a template of the $HOME/.switch/prod.keys file that hactool uses to decrypt content. It contains all the SHA256 and location of the keys and seeds, so you can find them yourselves.
Note that all the seeds (the keys that end with _source) are used along with the master_key_## to derive an actual key.
If you have somehow obtained the key without the seed, you can rename xxx_source to xxx_## (where ## is the master key number) and put your key there.
| ; ModuleID = 'code.ll' | |
| source_filename = "code.ll" | |
| target datalayout = "e-m:e-p:32:32-i64:64-n32:64-S128" | |
| target triple = "wasm32" | |
| %swift.type = type { i64 } | |
| %swift.type_metadata_record = type { i32, i32 } | |
| %T4code5StrctV = type <{ %TSi, %TSi }> | |
| %TSi = type <{ i64 }> |
| <?xml version="1.0" encoding="UTF-8"?> | |
| <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> | |
| <plist version="1.0"> | |
| <dict> | |
| <key>DomainsWithAssociatedCredentials</key> | |
| <array> | |
| <array> | |
| <string>comcast.net</string> | |
| <string>xfinity.com</string> | |
| </array> |
| PRD-63116-001/nPRD-63116-003/nPRD-63116-005/nPRD-63116-007/nPRD-63116-009/nPRD-63116-010/nPRD-63116-013/nPRD-63116-017/nPRD-63116-020/nPRD-63116-021/nPRD-63116-027/nPRD-63116-033/nPRD-63117-003/nPRD-63117-011/nPRD-63117-015/nPRD-63117-019/nPRD-63117-023/nPRD-63117-025/nPRD-63117-027/nPRD-63117-028/nPRD-63117-029/nPRD-63117-041/nPRD-63117-703/nPRD-63117-704/nPRD-63118-001/nPRD-63734-001/nPRD-63734-002/nPRD-63763-001/nPRD-63764-001/n |
| #include <string.h> | |
| #include <stdlib.h> | |
| #include <unistd.h> | |
| #include <mach-o/dyld.h> | |
| #include <mach-o/nlist.h> | |
| #include <mach-o/dyld_images.h> | |
| #include <mach/mach_vm.h> | |
| /* Dyld is the OSX Dynamic Linker | |
| * /usr/include//mach-o/loader.h |
If you've not seen my résumé, that is what this post is about, and you should probably look at it first to get an idea of what's happening.
PDF and ISO9660 are two very different file formats. PDF is actually a surprisingly human-readable (but, sadly, not very human-writable) plain-text format, technically descended from PostScript. PDF is not very forgiving on changes, as it stores tables of offsets to various elements, so it is very difficult to insert or remove content manually without going through a robust PDF manipulation library.
ISO9660 is a disk filesystem, meant to be written once and read many times on many different kinds of hardware. As it is sector-based, it expects data structures to be at particular absolute offsets.
