Test Kit to Development Kit

I've ran the "Test to Dev" xex floating around but it did not allow kernel debugging or detecting shadowboot files off of my HDD. Is there any other way to go about doing this? I have a Zephyr Test Kit with a sidecar.

 

@XboxSurgeon @Stipo360 @fate6 @Borman

 

AFAIK the test to Dev doesn't allow anything more than just changing the XShell to say Development Kit and changes it to the devkit xshell background. I could be wrong though, but my understanding of Shadowbooting always required a legitimate development kit and NOT a test kit regardless of it being "converted".

 

A buddy of mine ran the executable, it does indeed patch XBDM it allowed for him to be able to shadowboot on a slim test kit but it is not doing the same fo my fat console.

 

Alongside i'm able to mess around with xbsetcfg but not successfully run KDNet, which I couldn't even screw with xbsetcfg as a test kit

 

This pretty much sums it up:

 

Could someone post a before and after recint.ini in the flash when the run the Test to Dev executable? I don't think there are any fundamental differences in test and dev that would stop you from permanently changing one to the other (by making a custom flash).

 

Code:

[xbdm]
drivemap internal=1

Thats all you need to add to a slim to enable full dev functionality(minus DVDemu of course)
On a Phat it enables reading and writing to every storage/partition on the system just like on a slim but does not change it to Dev from Test.

 

So it does the same thing as the internal drive linker? That is strange. It is a shame that there is no mention of recint in the SDK docs or any headers I could find -- I've seen some strange things on used kits I've purchased.

 

The issue here is the XBDM on a phat is missing whatever the Slim has that gets activated by this.
That test to dev xex copies some modded XBDM plus adds that to the ini afaik.

 

So where is the authoritative source identifying test from devkit that causes it to reset with recoveries? The keyvault? That is one of the only persistent pieces of data across recoveries (usually)

 

I have no idea :|

 

Thanks for the help anyways, I'll put it on my growing list of things I'll look into later

 

There is a console flag inside the KV.

 

I've seen that, it is 0x1 for all dev kits that I have seen and 0x2 for retails. What is it for test kits? I don't have any test kit NANDs / KVs. I'd also be curious to see the first fuseline on a test kit, I thought the value in the KV was verified against that

 

has to be on 20353 or lower

 

This is one of those things I always found kinda frustrating about the Xbox scene, the lack of detail, like why does it need to be 20353 or lower? iirc there is a HV exploit there but why exactly is it needed?

 

The only real difference between retails and devkits from in terms of their security is the key(s?) that xex and xcontent packages are signed with, where XDKs will use a private key stored somewhere within the SDK. This gives us arbitrary unprivileged code execution, but the hypervisor is still completely protected. To run code in HV/privileged context, we can either use the HvxExpansions or HvxKeysExecute system calls -- which are both "official" but internal functions and require a signature of their payloads signed presumably with an internal, inaccessible private key -- we can use the 4532 HV bug (king kong), or we can use shadowbooting to remove the signature check from HvxExpansions, which is what RGLoader does IIRC.

Im assuming that program uses expansions to get HV context and patch the kernel. The trouble is, as far as I can tell, the private key for expansions changed after 20353, so the expansions install will fail.

It isn't an HV "exploit," but a key leak... from somewhere... I'm doing my best to find the key and what not, but as you can guess it's a needle in a haystack without anything to work from.

 

Are there any advantages for a devkit?

 

Kernel debugging and *easier* shadowbooting.