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.
GitHub: https://github.com/BestPig/LADX-Disassembly-Pocket
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> |
endrift has recently written an article on a new method she discovered for dumping the GBA's BIOS, different from the MidiKey2Freq method currently used. This article is about a third method I've discovered that is different from those two.
I've been having a very recent fascination with the Game Boy Advance. The hardware is simple relative to more complex modern handhelds and the CPU is of an architecture I'm already familiar with (ARM7TDMI), making it a rather fun toy to play with. The GBA is a console where cycle counting is important. In order to learn more about the hardware, I have been reading documentation that others have produced (like Martin Korth's GBATEK) and writing small programs to test edge-cases of the hardware that I didn't quite understand. One example of this was the BIOS ROM.
The
| 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 |
