VCS Unlock Logic

[LoveMHz]

I'm seeking clarification from @EqUiNoX-Labs on the statement regarding the VCS unlock logic in PrometheOS-Firmware.

Reference: https://bsky.app/profile/goteamscotch.com/post/3ltgi7ggm7227

---

1. Is @EqUiNoX-Labs the sole provider, and author, of the source code located in hddVscUnlocker.cpp and hddVscUnlocker.h?

2. Are the delay values present in the functions and methods below derived only from SendATACommand; and as stated "[the values]. As part of the the optimization it was natural to start with 100ns and try other values like 10, 1000 etc. until things work well. I just settled with 100."?

hddVscUnlocker::resetIdeBus
hddVscUnlocker::waitForDrive
hddVscUnlocker::sgOemUnlock_ST310014A
hddVscUnlocker::sgVscDiagSendCmd
hddVscUnlocker::sgVscDiagReadByte

3. Aside from the use of SendATACommand from XKUtils, is the code in hddVscUnlocker.cpp and hddVscUnlocker.h an original implementation? Or was it based on any other source, reference code, or prior work?

Thank you for your time.

[EqUiNoX-Labs]

@LoveMHz

1. Yes

hddVscUnlocker::resetIdeBus <- derived from the retail kernel decompilation reset bus delays
hddVscUnlocker::waitForDrive <- just started from 100
hddVscUnlocker::sgOemUnlock_ST310014A <- just started from 100, then 1000, until got to 100000
hddVscUnlocker::sgVscDiagSendCmd <- just started from 100, then 1000, until got to 10000
hddVscUnlocker::sgVscDiagReadByte <- no delay present here

Above I generally used https://github.com/Team-Resurgent/PrometheOS-Firmware/blob/main/PrometheOSXbe/PrometheOSXbe/XKUtils/XKHDD.cpp#L193 as a starting point, however where I changed from 100 and multiplied by 10 was me just experimenting until reliability increased (i.e. reduced stalled reads and so on).

There were cases where Sleep() would cause issues with background threads accessing hard drive, so is another reason I chose to use KeStallExecutionProcessor.

3. it's my own implementation based on information from the Data Recovery industry and lots of research from archived forums and tools.

Regards

EqUiNoX

[LoveMHz]

Is there any commit history that shows this progression?

There were cases where Sleep() would cause issues with background threads accessing hard drive, so is another reason I chose to use KeStallExecutionProcessor.

So it was written using Sleep() before the optimizations?

it's my own implementation based on information from the Data Recovery industry and lots of research from archived forums and tools.

Is this the list of resources you're referring to?

• on Llamma.com: https://web.archive.org/web/20060208043709/http://www.llamma.com:80/xbox/Unlocking Seagate Xbox Hard Drive.htm
• in the source code for HDD Super Clone: https://github.com/thesourcerer8/hddsuperclone
• in WDMarvel Demo: https://arch7rt.com/en/demo/
• on various old forums: https://www.os2museum.com/wp/seagate-serial-talk/
• on various old private blogs: https://jessiesbloggerific.blogspot.com/2011/10/unlocking-my-st310014ace-completed.html"

[EqUiNoX-Labs]

@LoveMHz

1. Unfortunately no, when working on a new PrometheOS version I tend to work locally and when ready to push, push as one commit, and then maybe subsequent fixes I may need to do.

2. I had trouble with Sleep() because it doesn't halt background threads from accessing the drive whilst unlocking is taking place. KeStallExecutionProcessor() will halt any background threads, along with raising the IRQL.

3. Some of those if memory serves me correctly, and I think some others not in list, it has been a while, I do remember decompiling a dos utility called zu.exe however which helped greatly.

[LoveMHz]

Thanks again for the info. @EqUiNoX-Labs, just two more questions, and I believe that will resolve this GitHub issue.

1. Just to clarify. Aside from the reset delay (which is a chipset limitation), was there anything else from the kernel or tools used to guide the implementation? Even for behavior or timing reference?

2. Regarding the retry logic in hddVscUnlocker.cpp:
   

   PrometheOS-Firmware/PrometheOSXbe/PrometheOSXbe/hddVscUnlocker.cpp

   Line 499 in f2ac588

   sgVscDiagRead(discard, 0x29, 30000);

   
   Was this pattern determined through testing, or does it follow the same "increment until it works" approach you mentioned earlier?

[EqUiNoX-Labs]

@LoveMHz

1. Not really except the general status retry counts

2. Are you talking about line 499 specifically? I don't remember exactly why as it has been a while since I looked at VSC code. I think it was to give the device enough time after issuing the soft reset command. Unless you are talking about sgVscDiagRead() in general, then yes it was used quite a bit, and in order to get the best performance other than incrementing in the multiples of 10 as mentioned. I would scale back by half so from 100000 to 50000 and then to 25000 which would of meant a final rounding to 30000.

   The "expLen" parameter for sgVscDiagRead() is what I called the "expected length" of the output from the device. This helps shortcut the return instead of waiting and thus allowed for faster device unlocking speeds.

[LoveMHz]

@EqUiNoX-Labs

1. Do you mean the reset delay here? hddVscUnlocker::resetIdeBus or an addition to something else?

2. Just in general on the different timeout values, unless there's something that stands out from memory. I believe your response answers that.

[EqUiNoX-Labs]

@LoveMHz

1. It was in addition to resetIdeBus. The kernel has "spinWait" loops whenever it is reading or writing to the drive, this helped inform my "spinWaits" as well.

2. Ok, let me know if you want me to answer any more questions

[LoveMHz]

Earlier you mentioned:

"When working on a new PrometheOS version I tend to work locally and when ready to push, push as one commit."

Was that also the case for the v1.3.0 update? In other words, was everything committed as a single change from 1.1.0 to 1.3.0?

If not, and there’s any Git history or diffs from v1.2.0 to v1.3.0, can you add any clarification to what was changed between these two versions? The patch notes only list:
Improved: VSC HDD Unlocking Times

---

I've heard of zu.exe, but Google indicates that it does not support the Seagate drives used in the Xbox. I took the time to examine sf.exe quickly, but it appears that it only accesses the firmware and configuration sectors.

I feel like I've exhausted the resources provided for Seagate drives and tricked the drive into diagnostic mode. Can you cite any sources for the Seagate drives?

[professor-jonny]

@LoveMHz There is a lot of resources on the Russian forums probably yet to be looked at, much of the initial hacking of hdds were developed by sniffing vsc commands during firmware updates and by looking at logs on disk after issuing random commands by many Russian pioneers.

Now days most software including commercial is based of leaks from of vendor tools and documents there has been many leaks in the past of vsc tools such as winfof etc for the seagate drives.

[LoveMHz]

Expect, it's not from firmware updates in this case. Stellar is an original implementation. That's why I'm curious about how @EqUiNoX-Labs arrived at the same solution.

I believe clarification is called for since the commit history is missing.

[EqUiNoX-Labs]

@LoveMHz

Yes, ZU.EXE can unlock OEM Seagate drives, note the model number. Once I was able to figure out how it worked, I was able to extrapolate it to the other model and use that model's terminal commands. If you want a little more info on ZU.EXE, you can check here:

https://linustechtips.com/topic/964430-remove-hdd-password-zu/

In light of new DMCA actions against Pandora and amicable resolution does not appear to be something you're willing to come to, I will refrain from any further comments.

You could've been part of the community that open-source's the firmware and makes technical write-ups explaining how you found your discoveries that benefits the rest of the community as a whole. Of course the community would credit you for said discoveries (assuming they remembered, and you asked them nicely if they forgot). Also, there's nothing stopping you from making and selling your own awesome hardware mods, even with extra features like extended RAM, that uses said open-source firmware, like a fork of Ryzee's firmware for XboxHD+ or perhaps an open-source version of StellarOS. That way, others can collaborate with you and we can pool our collective talents together. We're all here learning together how far we can push the Original Xbox and unlock its full potential.

As for the commit history, that IS the commit history as I said I only commit in large chunks.

[LoveMHz]

Just to confirm. You're saying that ZU.EXE is able to recover the drive key for the ST310014 and ST310211? And that Team Resurgent is not reverse engeering Project Stellar?

[professor-jonny]

It has been known and publically avalable that zu is able to unlock seagate drives I have used it my self.
There is even a post on the xbmc4xbox from splidit almost a decade ago who also is the owner of hddoracle.
His post outlines most brands of drives with free tools how to unlock them:
https://www.xbmc4xbox.org.uk/forum/viewtopic.php?p=36220#p36220

[incursion64]

Just to confirm. You're saying that ZU.EXE is able to recover the drive key for the ST310014 and ST310211? And that Team Resurgent is not reverse engeering Project Stellar?

Not sure why you need to re-confirm (again) what you were told in this entire conversation above. Are you going to retract your dmca claim against this project and Pandora?

[LoveMHz]

Not sure why you need to re-confirm (again) what you were told in this entire conversation above. Are you going to retract your dmca claim against this project and Pandora?

I'm seeking clarification so that all of this can be resolved as quickly as possible.

@professor-jonny

It has been known and publically avalable that zu is able to unlock seagate drives I have used it my self.
There is even a post on the xbmc4xbox from splidit almost a decade ago who also is the owner of hddoracle.
His post outlines most brands of drives with free tools how to unlock them:
https://www.xbmc4xbox.org.uk/forum/viewtopic.php?p=36220#p36220

Unlocking and key recovery are entirely different processes. That’s why I’m asking for clarification on how two separate individuals arrived at the same solution, given that there are many other ways it could have been implemented differently.

I've yet to see anything that can do this for the ST310014A. In good faith, I've attempted to test ZU with a ST310014A drive and have had no luck.