All Activity

We now know the code alleged to have been copied 1:1 relating to the unlocking of a hdd when you don't have the password could never be used in court. After that, it was unexplained as to how these other devs arrived at this solution. In other words, the assumption was there was really only one way for them to come up with this and that is by copying LMHz's works. Based on this thread, it's unlikely any attorney would bring suit based on it and if they did they would handily lose once defense admitted this thread. We now have an explanation of how cerb + prom came about the logic to get it done and reverse engineered zu.exe. Since that would get them to the end goal independent of LMHz's works, that's all that's needed to give reasonable doubt in this scenario. As I said previously, this particular count is not a winner for the plaintiff and we must move on to the other two. I'm not likely to entertain much more discussion on this count. It's as settled right now as it could ever get. To be clear on why: The first allegation was that the code matched exactly. Evidence was provided to prove that but said evidence actually dispelled that entire notion and made it impossible to prove since MS put out the exact same code 20 years prior. Both disputed works are likely to have copied from them or at least it can't be proven otherwise. As such, the work alleged by the plaintiff to have been copied can't be proven to be an original work itself and thus this particular claim is null. So then we fell back to the fact that even though we can't say it matched exactly, it MUST have come from LMHz's works. (This honestly didn't matter at all given that we now couldn't prove that LMHz's works were entirely original based on the prior discoveries.)[Again, I'm not alleging that they(LMHz's works) somehow are not original. I'm being very clear in that we can't PROVE it is original.] It couldn't have come from anywhere else because nothing else existed to do exactly what LMHz's software does. Then they(The defendant) provided how they actually came up with it and that argument fell flat. There is now no way to craft a compelling argument that this code was lifted from LMHz's works let alone beyond any reasonable doubt. There are too many other alternate avenues that they may have taken and we can't prove they went down the one the plaintiff alleges. Therefore this count is moot. PM me if you have more to add to this thread and I can open it back up. If it's related to this unlocking count, it would have to be VERY compelling for me to allow it. https://www.xbmc4xbox.org.uk/forum/viewtopic.php?p=36220#p36220 Also please note that the screenshot answers the question before it was asked.

Yes but the temp sensor is in Xcalibur rather than Xyclops. Given that it powers off quickly, I think the temp sensing is still working fine. In the overheated state, I believe the xbox stays on with the fan at 100% until it sees the temperature drop below a threshold. Does your fan go to 100% before it shuts down?

Have you tested the supply voltages and the CPU voltages ? Test the CPU voltage at L2F1 and from memory it should be around 1.75 volts Cheers SS Dave Soft modding is like masturbating, It gets the job done but it's nothing like the real thing.

What color filament is that green?

Sounds like you’re talking about the Adm1032 chip that’s the temp sensor. I don’t think they’re the same on the 1.6 boards though. I swear I remember something about integration in to the xyclops chip and possibly looking for trace corrosion from that chip. @KaosEngineer am I remembering that correctly about the 1.6 rev?

Did some more testing, dashboard shows temperature of CPU and GPU starts at 45 degrees Celsius, and slowly creeps up over time. It does not go over 60 degrees, even while a game runs. I put a timer to it, and it reliably crashes after 3 and a half minutes of being up.

Hey, all! First time posting here, hoping I'm doing this right. I have a 1.6 XBOX I just finished up modding. When I was done, the console would flash an orange ring and power off. The console runs cool when this happens, no heat from the fan or heatsinks, and this typically happens after about 5 minutes. I can use my dashboard and load games just fine, it's just a matter of time before it crashes from 'overheating'. I've read a lot around here about what could be happening, and I know I don't have any solder traces / splashes on the board, and no capacitor corrosion. The most likely thing is that while replacing the capacitors, someone mentioned the am1032 temperature sensor could go bad, but that the temperature sensor is integrated into the Xcalibur video encoder on 1.6 models. As of right now, that's my theory of the issue is just a bad temperature sensor, but I don't know if that applies to my revision or if it can even be fixed. If there's an idea of what could be causing this, it would be really helpful to know! If it's also helpful, here are all the mods I have on this: (Prior to all of them being installed, this issue was present when the Modchip and Capacitors were applied, so even with the stock fan) Modchip (The forums prevent me from saying its name, so I'll just say 'Operation Galaxy') High Definition Video mod for Operation Galaxy New Capacitors from Console8 Replaced Thermal Paste for CPU and GPU from Noctua Noctua 60mm Fan Replaced Power Supply SSD with Startech IDE to SATA adapter 80 Wire IDE cable from LazerBear Industries

I'll lock the thread shortly and then we'll await further developments such as a response form Equinox. I understand everyone's feelings now, but I don't think we should do feelings dumps. We should stick to the facts. Equinox has been responding, but LMHz is awaiting another response. https://github.com/Team-Resurgent/PrometheOS-Firmware/issues/15

@LoveMHz Before I continue, I am asking you once again (since it was not addressed in your reply) formally requesting you to remove this section of your blog post. It is factually and demonstrably untrue. As I have mentioned this is specifically the ability to unlock WD drives and WD drives only, and this information was sourced from the previously linked publicly available source code to HDDSuperClone. FATXplorer has no logic to unlock orphaned Seagate drives without the EEPROM key, user-extracted User Password via UART serial or Master password. Furthermore, additional functionality in to unlocker newer WD drives with FATXplorer is not in your product. And if it is, I expect credit from you for the discovery. My response does cover all of the drives, just not the logic used to interact with Rubber Jacket and Slim drive's normally UART terminal over the ATA bus. It does cover all of the commands, and since pedantry is on the menu-- Allow me to be the pedant. This response is about what Harcroft posted in reply to your tweet. What this was referring to has nothing to do with anything Equinox has done with the Seagate logic, this was in reference the pooled community efforts to unearth and publish commands to make unlocking orphaned drives easier to the general public without purchasing a $100+ chip. And you know it. Stop trying to deflect.

It does not cover all of the drives and methodology used that was taken from S_tellar. There's nothing I can do but wait for clarification from EqUiNoX on this since they're the ones to have discovered these methods. --- @OGXbox Admin I'm done here until that response is provided.

I've told him this twice on page two. As Harcroft says he simply ignores, miss-quotes and re-directs each time. I think he'd make a good politician actually, but not in any legal setting for sure!

My question is, why is it when you're the one accused of code theft, a simple explanation is ok. But when you're accusing other people, nothing is satisfactory even when they prove you wrong repeatedly? Like, you're arguing the same concepts and responses you used to justify things, while continuing to make accusations as if they're factual. Edit: Link

This was communicated in the response to EqUiNoX. It does not cover all of the drives and methodology used that was taken from S_tellar. There's nothing I can do but wait for clarification from EqUiNoX on this since they're the ones to have discovered these methods.

look if were going to play detective here, lets at least follow law & order rules, not phoenix wright: ace attorney logic. The burden of proof isnt some nebulous concept, its a fundamental of society. if you're going to accuse someone of lifting code, youve gotta bring more to the table than vibes and a hunch. "prove you didn't steal this" isn't how any of this works, unless were suddenly operating in a pseudo courtroom where the judge is a magic 8-ball (come to think of it haguero's head is kind of shaped like one, but thats irrelevant) and lets be real, i feel like someone like you would understand that " i feel like they probably did it" doesnt hold up under cross-examination. You want a perry mason moment? show the receipts. point to the lines, the structure, the smoking git commit. otherwise we're just doing fanfiction, not data forensics. no more red herrings (pun absolutely not intentional), no more false equivalencies, no more "well, if they cant explain it, then OBVIOUSLY". If you've got concrete evidence, lay it out. if not, maybe take a breath and move on with this woefully cyclic argument.

It seems to be that you did not read (at the very least) my part of the community response where link and screenshots were provided for the research and resourced that were unearthed which lead myself to independently identify the Seagate terminal commands used to dump the password sector. Note that this is unrelated to the logic behind interacting with the drive's terminal over ATA. Allow me to rectify this since you could not be bothered to look into this yourself before replying Links to the sources used for the commands for Rubber Jacket Seagate drives: https://alpha-root.livejournal.com/2195.html https://www.elektroda.pl/rtvforum/topic355819.html The link to the source for HDDSuperClone, which has the Vendor Specific Commands used to dump and read SA module 42 on OG WD drives: https://github.com/thesourcerer8/hddsuperclone/blob/main/hddscripts/wd_dump_mod42 And last but not least, my own social media post featuring heretofore publicly undocumented Vendor Specific Commands used to dump SA module 02 on newer ROYL firmware WD hard drives. This new command is needed due to newer drives (newer than about 2008) locking down SA DIR access when an ATA lock is present: https://twitter.com/SkyeHDD/status/1798350788324098354 https://x.com/SkyeHDD/status/1798350788324098354 It needs to be stressed to the ends of the earth that the last link I provided is for functionality that is not present in your product, which was integrated into FATXplorer. You very heavily implied that this functionaliy (which I will remind you is not present in your product) was stolen from your product to be implemented into a commercial product. I, frankly, resent the heavy implication and would like to take this time to formally request you remove that portion of your post and issue a retraction and an apology.

When LMHz "evidence" is called into question, they switch to attacking something else. Something else in this case I have already addressed both in this forum yesterday and in the original Xbox-Scene response to their article. This misdirect is another straw man argument. Misdirect, deceive, shift focus, repeat. LMHz knows that my comment they quote here specifically mentions unlocking orphaned stock Xbox HDDs on a computer. They know damn well we never hooked up a USB/TTL (UART) adapter between an Xbox and a hard drive to unlock it. I'll address the false equivalency LMHz is making regardless. September 26th, 2023 on the Xbox Preservation discord #drive-unlocking-instructions room; I posted a 20s video on how to recover the user password from orphaned stock WD hard drives. This information was gathered by Siktah during his research, I also included a screenshot of the original first draft PDF he made to use this method. I can include the PDF in a later message if people require it. I can't fit it within the 4mb storage allowed in this post. The short video in question: key recovery.mp4 This the HDD Super Tool aka HDD Super Clone I've repeatedly mentioned. Source code here: https://github.com/thesourcerer8/hddsuperclone Onto Seagate HDDs: September 28, 2023 Skye posted detailed instructions on the newest VSCs we had collected for Seagate HDDs. We had shared this info publicly previously, but after repeated prodding she made simple and clean directions with screenshots for reference. A few hours later I shared a set of pictures to show how to connect to these two drives. One of these images are still consolemods.org today https://consolemods.org/wiki/Xbox:Drive_Locking#Service/Technician_mode_unlocking An example of me sharing these instructions on the xbox-scene discord server on September 27, 2023. I posted it in my previous response, which LMHz refusing to read or refusing to respond to, these unlock methods were developed or recovered through the links I previously provided in my first response, and Skye's experimentation with these HDDs. Skye offered me these links to add to my previous links to show proof of more of the commands we are using were in the wild as far back as 2006 and 2010. llamma.com's guide predates these pages too. https://alpha-root.livejournal.com/2195.html https://www.elektroda.pl/rtvforum/topic512021.html LMHz stop trying to conflate your separate claims of myself, Eaton, Skye and the Xbox Data Preservation Discord stole your work, and the claim that Team Resurgent stole your work for PromOS. They are completely different unlock methods that may use same of the publicly available VSCs, but do not use the same hardware or user interaction method. I have given more than enough proof that the Xbox Data Preservation Discord goup including Eaton and Skye researched and shared our unlock methods months before your methods appeared in your modchip firmware. LMHz refuses to reply or address my response to their claims of bad actors or tainted influences regarding Op_en_X_HD as they know they are in the wrong. Once again: remove my name and all references to myself from your deceit filled blog post remove all references to Skye and Eaton from your deceit filled blog post drop the claim that Op_enX_HD is tainted, you have absolutely zero even circumstantial evidence of this if you wish to keep up your claims that an Xbox HDMI adapter other than yours simply can't exist, I have no complaints with that, you do know that is also misleading though stop trying to deceive and misdirect this forum with your duplicitous actions, stay on topic

Why are people supposed to accept your word that your implementation is original work and not stolen from somewhere else without attribution? Isn't the burden of proof for theft on you, yet you will not explain how your method was developed?

Please don't use these pictures as an example of how to solder your new capacitors, soldering iron not hot enough to flow solder and an absence of flux.

It has been over a year and a half since we released our HDD unlocking implementation. Within 22 minutes, Harcroft responded with "We've been doing this for the better part of a year with free software tools and $2 USB/TTL boards." Yet here we are, still without a clear answer to how this was supposedly done, where it was documented, or what prior work it was based on. That question has gone unanswered, while the burden keeps shifting back to me to explain details of our own implementation. If this was truly based on existing public knowledge, that should be easy to show. Instead, the focus has been on deflection and demanding justification from the party whose work appears to have been copied. I am not going to provide more technical details or help build a justification until these very basic questions are answered. The responsibility to explain and demonstrate originality lies with the person making use of the code.

It was my understanding that (legally) the burden of proof falls on the accuser, not the accused. What you have provided has been flimsy, circumstantial or even disproven by others in the thread. This, in combination with an outright refusal to elaborate on something as simple as why a buffer size is why it is leads me to believe that this code is indeed not yours. You should explain something if it's legitimacy and relevance are being called into question. You claim "There is no technical justification for that size" but clearly it was done intentionally else you could just adjust the buffer according to the amount of data being read.

That's pedantic on wording. So let me be clear. This is not something I should be explaining. The burden of explanation falls on Equinox, who stole the code in question and has yet to release the v1.2.0 source as required by the licenses involved.

So would it be fair to say that if Equinox wrote it, that you did not write it?

This is not something I should be explaining. The burden of explanation falls on Equinox, who wrote the code in question and has yet to release the v1.2.0 source as required by the licenses involved. That lack of transparency makes it difficult to reach any conclusion other than that the code was copied. If there is a legitimate technical explanation or a credible source for the unlocking logic, it should come from the person who implemented it. Speculative questions directed at me do not resolve the core issue.

To help add some clarification on things since you say the timing and delays are important in the context of the rest of the code: Hard drives expect to be interacted with in certain ways according to ATA specification. Registers read and interacted with need those timings if they are to succeed, as I'm sure you're aware of. Frankly, this even being mentioned or included just seems disingenuous and (to me) seems to be used to bait those who don't know any better into thinking that this is indeed a stolen chunk of code. Also, since the rest of the code context is important, you brought up a buffer size of 2048 in order to read ~500 bytes of data. If this is suspicious and not just a booby trap in your code, why did you use a 2048 byte buffer to read ~500 bytes of data? Since you are unwilling or unable to post the source of this chunk of code (and if this code is indeed yours as you claim,) the least that can be done is provide an explanation as to why you used it if "There is no technical justification for that size."

I see what you’re saying, but there is an important distinction that’s being overlooked. The reset sequence on its own does not mean anything. The specific values used, including the port writes and delays, only make sense when viewed in the context of the surrounding code. In the case of 3944, this logic exists inside an internal function. It is not exported . The timing and values in that implementation are shaped by the structure of the code around it. In Project S_tellar, the same reset behavior is implemented within a different structure, with its own surrounding logic and control flow. That is what makes it original. It is not about the use of port IO or delays by themselves, but how those values were chosen based on the rest of the system. The argument is not whether a reset sequence appears elsewhere. It is whether the structure, timing, and integration reflect original work or are the result of direct copying. Taking one part and removing it from context does not tell the full story. --- This would be much easier to verify if the source code for v1.2.0 had been released as required. By withholding it, multiple licenses are being violated, including ours, and it becomes difficult to demonstrate anything other than that the implementation was stolen. Setting aside the timing and flow for a moment, let’s look at the unlocking logic specifically. It continues to be described as something that was already solved in the past or based on existing public information. However, when asked for that information, the only references provided are outdated or unrelated.