Hello everyone, I'm looking into the purpose of "pairing data" in the NAND flash, which I assume have something to do with either the revision of console (motherboard) or perhaps it is a unique identifier. In any case, I am limited by the amount of samples I have, 1 Xenon XDK, 1 Jasper XNA and one RGH falcon. I would appreciate any NAND dumps to compare with, especially if you have similar consoles. If you want to be cautious, feel free to strip the KV data (although it encrypted with your CPU key anyways!). It will probably be between 0x4000 and 0x8000 in the dump, I can help you out there if you are interested. If you have a banned KV or are willing to trust me, there are some structures in the KV I'd like to look into as well, and a complete dump + CPU key would be greatly appreciated. While I should be able to figure this out from the data inside, if you send me a file, please include the motherboard, dashboard version and type of kit. Shoutouts to some people who can probably help me out here: @XboxSurgeon @Stipo360 Thanks guys!
I have a folder with 6.34GB of NAND Dumps varying in motherboards but my internet upload speed is whack
Are there a lot of XDK samples? If so I would pay the cost of a flash drive + shipping. Or if you could just upload the XDK ones that would also work
I don't have any experience with the XDK, but anything called "pairing data", especially when found in flash FW dumps, 99% of the time is NV BLE caching and persistence data (wireless controllers, peripherals, etc.). EDIT: I don't know if the SDKs have been leaked, but you could grep the symbols/PDBs/headers to verify if this is the case or not.
Really? If that is the case that would be very interesting. What is does NV BLE stand for? Do you have any information on how the information is generated?
Non-volatile storage for the Bluetooth Low Energy (BLE) stack. AFAIK it is the stack that most vendors went with for wireless peripherals in that era. I wrote/dealt with BLE FW from time to time, I can give you a book to read if you are interested in the interface. As far as the structs are concerned, I'm sure the XDK docs would have a section about talking to the controller, and they probably at least have some publicly-facing headers you could look at to start with (total speculation on my end however).
The 360 doesn't use Bluetooth, it uses some proprietary 2.4GHz signal but it probably does the same NV storage wise. SDK's with debugging symbols are all over the internet BTW.
Here you can find XDK Xenon and Zephyr Sample NANDs as well as Shawdowboot files. http://www.down20.com/f-757635373728838 Regards
If it's the pairing data I'm thinking of (the fields inside the bootloader headers), those are used to prevent downgrading. IIRC those fields are meant to match up with the board revision & consoles EFUSEs, if they don't match the console will refuse to boot. The fuses store the pairing data for both the CB and the kernel, each update blows 1 fuse depending on what's being updated, and then the bootloader has the pairing data modified to match (which is then encrypted/HMAC'd using the CPU key, can't really remember how but it's secured in some way) I think there was some code in RGBuild which could generate the correct pairing data for a given string of fuses, at least I remember writing some code for that anyway, my memory is the worst though and 5 years is a long time If not though I'm sure you could disassemble CB/CD and find the code that reads from those fields and what it does with them. EDIT: oh I guess I was talking about the console sequence & LDV stuff, might still be a chance the bootloaders read the pairing data field though.
Some of my standing questions right now: Why the delta patching update model? From a security perspective it doesn't make much sense to me, I guess it would make patching a bit safer? With that in mind, where is the expected number of patch slots stored? I know you can't just remove the CF/CG sections from the flash and boot into 1888, but why not? I was thinking it had something to do with the LDV, but that is earlier in the boot process?
I assume that if the CF/CG data got corrupted or something it allow to boot to 1888 and update back to what CF/CG was/updating.
I was thinking the same thing. I suppose if you are delivering updates over the internet then you should fail safe. The other information that goes into this is the fact that XDKs don't use patch slots -- XDKs don't update over the internet, only the local network or a recovery disk. I did more reverse engineering of the NAND header, and there is a flag that looks to denote the amount of used patch slots; however on XDKs there are some magic numbers. With that solved, some more questions: Can any executable make system calls to escalate its privilege? I guess in the security model any executable has to be manually reviewed and signed by MS, so it is reasonable to trust that any executable will not abuse privilege. What is the fundamental difference between test and dev kits? I'm aware they use different kernels, but what is to stop me from writing a devkit NAND to a test kit (after changing keyvaults)? What is the authority on console type? There is a flag inside the KV denoting console type, but the only values I have seen are 1 for devkits of any type and 2 for retail. This could also denote type 1 vs type 2 KV? I don't have enough data to make conclusions here
Thanks I'll look through the bootloaders. The trouble I have with accrediting the pairing data to the LDV / efuses is the fact that it exists (and is non-zero) on XDKs despite them not having blown the lockdown efuses. It must be tied to CPU key in some way. On another note I am very happy to see that you still check in here Thank you for all your contributions to the scene. You wouldn't happen to have any insight on the difference between test and dev kits? I realize they run different kernels and what not, but what would stop me from flashing a dev NAND to a test kit? There is a console type flag in the KV, is that the authoritative source for the console to know if it is test or dev? Also, as far as I can tell RGloader uses a native library (XCompress64.dll) for LZX compression/decompression, is this your own code or internal? If you don't mind I have a lot of questions I think you could answer Edit: I've just seen that XCompress64.dll is from the SDK, disregard that ^^
@stoker25 I'm looking through some of the system calls. I've found the syscall table in the hypervisor (thanks RGLoader!), but I can't find the actual syscall dispatcher. How are the values stored in the syscall table parsed? They are not addresses, that's for sure. I want to see the implementation of HvxExpansionInstall, specifically the HvxExpansion structure, how the ID is generated, and the expansion table (I'm not even sure such a thing exists, but the kernel's implementation of ExExpansionCall makes me feels like it does). I would also like to look into the differences in retail, dev kit and test kit syscall dispatchers, see if the syscalls that are disabled on retails (such as HvxShadowBoot) are really not implemented in the retail hypervisor or just blocked by the dispatcher. Are there a lot of subroutines in the hypervisor common to the kernel to make writing an IDC labeling script based off of the kernel's symbol identified subroutines worthwhile?
I've found some traces of an "XeDevWiki", which was apparently the former home of RGLoader and shared many of the same intentions I have for my current wiki. Do you have a copy of that database? I would host the wiki alone or merge them. The last trace... Edit: Evidently xdevwiki.tk is online, but only has one page regarding the 360... POST Codes by Tydye81. I'm assuming the original had more?
Getting to the HV is not trivial as it is type-1 AFAIK. Stepping through to the VMCALL dispatch is pretty easy, but picking up the call when the HV processes it is another story. Microsoft published TLFS 5.0b for Hyper-V for Server and Win10; the Xbox HV is not identical AFAIK but similar. Looking at the TLFS would be a good place to start.
"Stepping through to the VMCALL dispatch" - Do you mean to say you can do step debugging in the HV? With winDBG? I can't access physical memory 0x0 so i can't just put a breakpoint down on the vector that handles syscall interrupts? I'll look through the document, thanks.
Most user or kernel libs will link in a raw HV call routine that you can trace into with WinDBG in KD mode. Basically it boils down to setting up a code page and issuing a VMCALL instruction to cause the current partition to exit. After that you are in the Twilight Zone Also keep in mind that the HV is under very active development, so the current architecture may not match up with yours. Maybe interesting: http://blog.amossys.fr/virtualization-based-security-part2.html
Ah. Yes I am aware, my question was whether or not it was possible to trace into the HV "black hole" after the sc instruction. I've been doing "black box" testing on the HV using kernel debugging, but it would be very helpful if I could get into the HV itself. Not only is it under heavy development, it is for an entirely different architecture lol. It still might be worthwhile for the concepts behind it; I definitely won't find any implementation details in there haha
