Discussion in 'Xbox 360 Development' started by Liniseda, Oct 1, 2017.
That's not for devkits. The files in the picture are for hacked retails.
XDK's use a modified 17489 filesystem and a shadowboot rom.
RGL is a devkit kernel, so yes, these are for devkits. He is trying to update RGL instead of just using whatever BS shadowboot image is being passed around
For future people who find this thread, his questions were answered in PM / on other forums.
RGL applies a set of patches to a devkit kernel / hypervisor to make it friendlier to use. These patches include retail XEX decryption, disabling signature checks for some syscalls and DVD verification, and replacing syscall 0 with the HvxPeekPoke syscall from XeBuild.
What you see in the picture is that patch set split into a couple files. Because RGL is only publicly released up to dashboard 17150 (XDK 21256.12), OP is looking to update these patches for dashboard 17489 (XDK 21256.18), which is the most recent leaked recovery at this time.
In order to do this, you need to get a 21256.12 kernel (xboxkrnld.exe) and HV, disassemble them and look what the 17150 patches are doing. You then need to open the 21256.18 version of this file and find the same logic in order to update the patch location.
With the kernel, this is fairly easy because we have the symbols for both 21256.12 and 21256.18; OP is asking for these symbols. With the hypervisor, this is a bit more involved: you need to get the HV from either a shadowboot image or a NAND dump.
Either of these will contain the devkit bootloaders (SB, SC, SD, SE). The 5th bootloader (5BL, SE) contains both the hypervisor and the kernel; however, it is stored cold both encrypted and compressed. There are a couple of ways to decrypt and decompress, one being RGbuild.
I'm going to shamelessly plug my own cross-platform command-line tool that can do the decryption and extraction, but not (yet) decompression: https://github.com/acabey/flash-dump-tool/ . This will also only work with shadowboot images.
I don't think the HV has changed in a LONG time. It's mostly been kernel changes.
Edit: Even then it's mostly just changing offsets to work with any minor changes between newer versions. The core RGL patches are fairly easy to port. JTAGs might be trickier since Ty uses someone elses source and doesn't enable compile time patching. Those would have to be changed in the actual .rglp file.
Edit2: If on a JTAG add this to the end off your .rglp file to stop KdNet from corrupting your NAND and preventing the console from booting twice.
basically patching this....
Mar 27 16:01:32 <Dwack> nice, she boots twice!
Mar 27 16:01:37 <Dwack> with kdnet
Mar 27 16:02:22 <Dwack> .text:801B3DF4 bl memcpy
Mar 27 16:02:22 <Dwack> .text:801B3DF8 addi r3, r1, 0x50
Mar 27 16:02:22 <Dwack> .text:801B3DFC bl KdpNetSaveParameters
Mar 27 16:02:22 <Dwack> .text:801B3E00 addi r1, r1, 0xE0
Mar 27 16:02:22 <Dwack> .text:801B3E04 lwz r12, -8(r1)
Mar 27 16:02:42 <Dwack> threw in a nop to stop the call to savekdnetparameters
well, atm i have been stuck on a black screen without boot (xell accessible (i use a corona v3 RGH2))
have you tried kdnet to see if you can track down the error. RGBuild should set it up for you when it builds you NAND. All you have to do is run the .bat script that comes with rgl on your PC
Yes but it’s just waiting for a response:/
So then you're stuck in BLs or early HV init. KDNET kicks in very early on. Id double check your patches.
I'd like to have a go at this so if someone could help out with 21256.18 symbols i'd appreciate it. Think the latest i have right now is 17349. Thanks
can you pm me really quick?
Locked by request of the topic creator
Separate names with a comma.