Hacking Bypassing first-boot DRM efforts

[admin]

Hello everyone,

I have a pair of day-one and overall old Xbox one PHAT consoles that were never used. They were never booted and therefore, when turning them on now, request you to establish an internet connection, link an account, and update the console's firmware. This is a DRM problem that affects not only unused consoles, but also factory-formatted consoles, which afaik also require you to update them and link an account. This is a huge preservation and repairability problem.

So I wanted to document the efforts and things I have attempted at bypassing the initial DRM, in case someone wants to help me research it. I have tested all the following things in consoles from 2018 and before

• Booting into Kiosk Mode: by placing a file called MSXB_Kiosk in a NTFS USB drive it is possible to boot a console into kiosk mode. This does not seem to have any apparent effect in uninitialized consoles

• OSU (Offline System Updates): I haven't tried this yet, but it is possible to perform an offline update of the system to a more actual firmware version through a USB. I reckon this would still require you to connect to the internet after the update is completed.

• Arbitrary HostOS VBI loading EXPLOIT: This is probably the most promising idea. Assuming Xbox One consoles ship with some basic capabilities certificate, and it is not generated the first time they connect to Xbox Live, which is what we are just trying to bypass. This exploit allows to replace the SystemOS or GameOS with your own custom Virtual Machine. Someone on the forums mentioned that there was a person working on booting a custom firmware through this method. However, assuming that the initial DRM screen the Xbox One shows is handled by SystemOS, that would mean the rest of the system (i.e.: HostOS) are capable of working without connecting to xbox live and the exploit may work. We don't need a custom firmware, I believe it would be possible to dump the SystemOS VBI from an already updated/valid console, and put it into the locked console hard disk drive (following the exploit steps basically) to make it boot into an already valid SystemOS VM. I'm sure at some point the donor SystemOS will complain and crash because of the hardware IDs being different, but it would be a good starting point. Additionally, in the previous custom firmware discussion mentioned above and in the exploit page, it seems like there are no signature checks being performed on the system.vbi file, which may allow for patches made to ignore the different hardware IDs.

I have yet to discover how to dump SystemOS's system.vbi from a retail console (or even from an SRA $19 devkit), but unless I'm missing something important, the last method could be a potential way to unlock and get code running on non-initialized Xbox Ones before 2017.

What do you think about this?