All Activity

No. Though I'm sure anyone who decompiles the 3944 kernel would find the same code section. I'm simply the person who thought it was relevant to point out as it relates to our ongoing conversation here, as it denotes similarities to your project in a similar fashion to what you've pointed out in Equinox's project, showing that many minds (including Msft devs) may arrive at the same conclusion (on IDE timings anyway).

No disrespect to Muramasa was intended. There are a lot of false claims from LMHz to address, and it's unfair to expect someone outside looking in to understand all the intricacies of the accusations, the lies, and the truths. My links regarding VSCs were about methods we in the Xbox Data Preservation community were unlocking oprhaned hard drives connected to a computer (or later with PicoPromSD) and have nothing to do with PromOS's VSC unlocking code. Those links to applications and forum posts were not just used for end users to unlock drives. EqUiNoX may have used some of the same resources we did, but I can't say with any certainty. The HDD Super Clone open source code exposed some of the raw Vendor Specific Codes needed to unlock WD drives that was later added to FatXplorer. Once again these codes are owned by WD, not Eaton, not WD Marvel demo, not HDD Super tool, not Ace Labs and certainly not LMHz. LMHz again makes a deceitful comment and changes their story to claim the PromOS code was stolen from other applications based on these shared links. Instead of coming at this conversation with clear intent, they claim they just wish to speak about the overwhelmingly false accusations levied by them, then switch to underhanded comments claiming the victims of their false accusations are stealing from other people too. LMHz needs to stay on topic and address the proof that their misleading and deceitful claims are false. LMHz needs to address that "clarifications" about myself and Op_enX_HD directly contradict the statements still in the dishonest and malicious blog post. https://github.com/Team-Resurgent/PrometheOS-Firmware/issues/15 This was not an honest attempt to clear the air. This is a fishing expedition where LMHz is trying to collect an admission of guilt from EqUiNoX for whatever future legal action they are planning. https://github.com/github/dmca/blob/master/2025/07/2025-07-09-make*mhz.md This was the second step on the same duplicitous and underhanded behavior. LMHz filed another DMCA takedown notice they know to be completely without merit. What this false DMCA takedown claims is any FTP client and IRC client is illegal as it can be used to obtain copyrighted works. This was done entirely to try to obtain personal information from members of Team Resurgent through a DMCA counter claim. The deceitful and at this point illegal actions just never end. "I have questions about this too. @GoTeamScotch is this the above screenshot from Equinox too?" This response is feigning ignorance, another extremely common deceitful tactic by LMHz. The screenshot clearly shows xboxkrnl-3499.img at the top, which is from an Xbox BIOS source code leak, leaks which LMHz at the very least knows about. This screenshot is of an Xbox source code leak still on github today that clearly shows the exact same functions and delays in the same order LMHz is claiming PromOS contains and stole from LMHz's modchip. This points to the clear possibility that LMHz code contains leaked (or as they claim, stolen) source code from Microsoft. The same source code they continually attack the entire Xbox homebrew community for referencing or using. All the while LMHz has in their posession multiple Xbox debug/development kits that sill belong to Microsoft legally. "Both releases are closed source. That is Project S_tellar and the PrometheOS build in question; which would also include the later source code releases of a different version. But the disassembled code speaks for itself. " LMHz admits they have disassembled code, which is an approximate reconstruction of source code through decompilation/deconstruction of the original code. By definition this code has gone through a translation which makes it not match the original code. Different code achieving the same functions when compiled will of course look the same, once decompiled they would look identical. LMHz again acts as if their vague show of decompiled code, which looks exactly like source code leaked from Microsoft, is proof that they have been stolen from. When it comes to Foxbat, Nemesis and clones, I literally owe LMHz nothing. They made countless baseless accusations, several of which they know to be completely false. They only thing owed between LMHz and myself is them owing me an apology for every single claim they knew to be false, every single slanderous and libelous comment, every single lie they told. However in the interest of being open with the rest of the community I'm more than happy to share information about Op_enX_HD. I can attempt to make some comments on the ridiculous demands made by LMHz. "I believe we both can agree that Team Foxbat and Nemsis' work is just theft. If 'Team Foxbat' was removed from the Discord server and not able to be part of the discussion then I would feel a lot better." My opinion on the matter doesn't matter, but I did agree earlier in this forum thread that Nem's work looked like a clone, and Foxbat themselves admitted their work was a clone on Milenko's twitter: https://x.com/TeamFoxbat/status/1940911097584013330 I don't have the ability to remove anyone from the discord server I am sharing Op_enX_HD development on. If foxbat has ever contributed any ideas or suggestions it certianly hasn't been over the past year and a half and nothing that had anything to do with cloning, reverse engineering or taking inspiration from HD+. I freely admitted I saw a picture of Foxbat's clone and blatantly stole the idea of offset resistor arrays. This is a design choice to make soldering easier that I have seen other hardware, and can be seen on Foxbat's github repo today. Once I moved the ADV7511 toward the right side of the board (a request by Siktah), it gave me space to enact this change. Any other similarities in the design come from Foxbat clearly using Ryzee119's original schematic, and copying pinouts and connectors I posted publicly before Foxbat even shared their design. Foxbat's design steals from Ryzee119's board and Op_enX_HD as much as it steals from HD+. The only people actively giving me design ideas or feedback to solve my issues within the last year are Professor_Jonny and Ryzee119. It's been a constant cyclic struggle of test hardware, research problems, think of probable solutions, iterate on the design, produce new hardware, repeat. I have shown this with public pictures of 10 sequentially numbered flex cable revisions and over half a dozen main PCB revisions. If that's not clear enough. Foxbat is not actively giving any feedback, as far as I can tell they don't even have access to the private dev channel. A channel that Ryzee119 and dtomcat have access to by the way. I have directly asked dtomcat and others to expose any inappropriate or nefarious behavior if they ever spot any. It's unfair to ask Ryzee119 to sit in the middle of this, but I have no doubt if he saw any of us doing something that infringes on LMHz' work, everyone would hear about it immediately. "But "Team Foxbat" is there giving feedback directly. I'm just asking for good faith for that not be allowed since it answers Harcroft's question of who we have an issue with." No, they're not. I do not owe LMHz anything in good faith at this point. They have been underhanded, duplicitous, deceitful and misleading during the entire exchange on this forum, in their blog post, on twitter as well as Blusky. The last I heard Foxbat is still on LMHz discord server. Does that make LMHz a tainted source of information because they've spoken to Foxbat too? The same ridiculous mental gymnastics and logical fallacies apply to LMHz too. Furthermore LMHz' blog post still specifically claims Op_enX_HD is an attempt to clone HD+. The blog post also still says that "Public reverse engineering of Xb_oxH_D+ continues to guide its development." LMHz blog still "calls me out" for "...repeatedly shown a disregard for intellectual property, copyright, and the work of others..." This again is directly opposed to the "clarification" that says "We are not accusing Harcroft or the OX_HD project of infringing on our work." That's not a clarification, that's accidentally admitting that you were making false claims in the first place, without removing those claims from the hit piece. This is something I said in my original response on the Xbox-Scene.info forums to LMHz' libellous blog post. "Some of the users MMHz has made accusations about in their hit-piece article have passed along ideas to me to implement into the board design. Every single one of those design ideas further differentiates Op_enX_HD from Xb_oxH_D+." Other than using a similar flex connector; every single idea brought up by random users that made Op_enX_HD more like HD+ was soundly rejected. Every idea that made it into the current design puts it further and further away from LMHz' design. I could go on and on picking apart every word LMHz has dropped in this forum but I do not see the point. They're here to lie, they're here to deceive you, they are actively attacking the community they so desperately want to own. This isn't just bad for LMHz, this is bad for the entire Xbox and to a wider degree the retro gaming community. As a show of good faith to the rest of the community I'll share this. When I designed the first research prototype for the Op_enX_HD flex cable based of Ryzee119's design I wrote a thank you note on it to Ryzee119. When I finally produced the first flex QSBs for 1.6 console revisions I decided it would be nice to thank every person who helped along the way on them too. Here is that list and at least part of what each of them contributed. Crunchbite - idea for Mini TOSLink SPDIF optical audio output (initially as a joke!) Darkone83 - testing prototype boards and producing prototype boards for testers who were unable to make their own Dtomcat - testing prototypes on different boards, a few routing/design ideas ElectronAsh - idea for standard red LED for TOSlink SPDIF based on a MiSTer design EqUiNoX - spacer and back cover 3D model design from scratch Friendo - ideas about routing and pin header connections early on in design Haguero - the demand that we use the same 24 pin FPC pinout as HD+ so end users would not have to change flex cables when choosing between HDMI boards (my flex designs are still my own original designs derived from my own research, measurements, iterating, and Ryzee119's initial design) Halo[AUS] - lots of testing on 1.0 an 1.1 revision motherboards Professor_Jonny - numerous routing suggestions, impedance calculations that exceeded my own, constantly questioning and challening my design ideas resulting in constant design improvement Ryzee119 - literally everything, every time I was stumped he offered an idea, or suggestion of something to look at Scotch - the idea to move to a 4 conductor connector for more flexibility with alternative connections on the optional (now TRRS) jack Siktah - sitting with me through literally 100+ hours of streaming board and flex design work, constantly catching small mistakes or concerns with routing during these design sessions Back to the top. LMHz; take my name and references to myself, Op_enX_HD, Skye and Eaton off of your libelous blog post. End the deceit, stop focusing on things you know you've been proven to be misleading and deceitful about. If you think you have a legitimate claim against other people, that is your prerogative.. You know as a matter of fact you are in the wrong about Op_enX_HD, myself, Skye and Eaton (for VSC unlocking). End the charade of pretending to be here in good faith, while ignoring real questions of your tainted sources and malicious intent. @OGXbox Adminas LMHz has stated they have no legal claims against Op_enX_HD / OX_HD would it be fair to unblock those words specifically? Thank you for your consideration.

Hey everyone, Update / Solution: Well, turns out the problem was incredibly simple (and a bit embarrassing to have missed!). My Xbox Series X controller wasn't working wirelessly with the OGX-Mini via the 8BitDo adapter because the 8BitDo adapter itself just needed a firmware update. I updated it, and now everything is working perfectly wirelessly. Sometimes the simplest solutions are the hardest to see! Hope this helps anyone else who might run into the same issue. Thanks for taking the time to read my initial post!

Hello everyone, I'm hoping you can help me troubleshoot a problem I'm encountering. For a long time, I've had five original OGX-360 adapters, and they work perfectly when I use them wirelessly with my Xbox Series X controller connected via an 8BitDo Adapter. Recently, I acquired some newer adapters: twelve OGX-Mini units from eBay, and four OGX-Mini units directly from ModzvilleUSA. The issue is, with all of these newer OGX-Mini adapters, my Xbox Series X controller does not work wirelessly when connected via the 8BitDo USB Adapter. They only function when a controller is plugged in directly via a wired connection to the OGX-Mini. Given that my original OGX-360s handle this setup flawlessly, does anyone have an idea what might be causing this wireless incompatibility with the newer OGX-Mini versions specifically when using an Xbox Series X controller with an 8BitDo Adapter?

I'll also add that going after anything that relates to Xbins is about the most disrespectful thing you can do with regards to the legacy of the Xbox homebrew community.

That same logic could be applied to your 5838 patch system for St_llar. It's built to extract files and assembly code, then flash firmware that helps users bypass DRM and play backups. Any legal consequences from that fall squarely on the user. Your St_llar modchip's purpose is no different. It's specifically made to bypass DRM and run unsigned code. The intention behind this software is obvious, it's meant to get around the limits of a closed system. By your logic, that kind of intent isn't exactly innocent. Pandora, on the other hand, isn't built to bypass DRM. It's just to download files from xbins that can't be hosted elsewhere. It's not cracking protections or enabling unsigned code. So if we're talking intent, it's important to make the difference clear. The DMCA against Pandora is just a pure bullying tactic as is most of this blog post full of accusation with very little substance outside the direct clones which you have every right to shut down.

I will wait for you to respond to the claims in order before passing further judgement.

I'm trying to answer everything in order to avoid confusion. Who's making this statement? I've already asked @GoTeamScotchfor clarification.

This is very damning and should be addressed directly.

@LoveMHzI would like an explanation for how you claim Project St_llar/you to be a clean legal people who are in no way involved in anything unscrupulous when you have been documented as possessing the confidential property of Microsoft (physical Xbox XDK units, including at least one that has a Microsoft asset tag sticker on it). Are you willing to say that those pictures (that you posted on Twitter) are fake? As you know, Microsoft never sold XDK units to any third parties - game developers or whatever. They were always leased, not sold and remain the property of Microsoft to this day. Do you think it is wise to be seen with stolen Microsoft hardware while talking about how using the SDK that was made to be used *with* that hardware is evil?

You mean the "open source version" of leaked XDK source code modifications? Since thats exactly what the author describes it as, Complex leaked the source code. Complex !Loader was modified from said source code. EvoX M7 was a modified BIOS built from said source code. You're now admitting on a public forum, that the source code you use, is tainted by the leaked source codes legacy in your S_tellar modifications. You really like throwing around the word "theft" when it was misattribution to software you released to the public under an open source license, and it was rectified. They added the license. Nothing they did here was illegal, or an admission of theft. You did something similar with your "typo" calling your firmware GPL. They simply forgot to attribute source code properly.

When these here from the xbox kernel; I have questions about this too. @GoTeamScotch is this the above screenshot from Equinox too?

I can understand the frustration, but please don't twist what I said. Equinox is the only developer in question that has responded. Harcroft has made it very clear they're not involved at all and had no part of it. And Equinox has made it clear that he's the sole provider, and author, of the code in question. I'm working on a response. This takes time and I have no reason to stop the conversation. I respect that Equinox is responding to the HDD unlock questions, but remaining silent on this is his choice. Along with the other members. I understand this, but it does not justify theft. It's a repeated pattern of Cerbios from their first release to take the work of others and claim it as their own, even when legal options existed. The pathway to having support was provided via kpatch, but instead the closed source runtime was stolen. It's almost never the technology that is the issue. It's the intent behind it. Pandora was designed to download only files from xbins and only exists because those files can't be hosted elsewhere. PrometheOS has already admitted to at least some theft and that has yet to be fully resolved. Not to mention the other issues with the X_boxHD+ files hosted, Cerbios, and PrometheOS as they relate to the article.

Further to @GoTeamScotch 's reply. I was about to say the same that indeed Equinox has responded to your requests and has shown how he derived at those results. Also, as OGXboxAdmin said earlier and looking at the following two screenshots (one being your own), you need to be more clear on how you can possibly say; When these here from the xbox kernel; Look identical to; and do appear to be both the same timings and layout. From the point of view as a neutral bystander, there appears to be absolutely nothing wrong.

"So far, only one developer has stepped up to answer questions about a single issue. Everyone else involved, especially those tied to the other topics being raised, has either stayed silent or had someone else speak on their behalf." Not everyone is on ogxbox.com. For more responses, see the thread of responses on xbox-scene.info You brought up several, including OX_HD and VSC's being stolen, which Harcroft has replied to here, and Skye has replied to in the link above. Prometh_OS's developer, Equinox, has responded to your Github issue about IDE timings. He explains how he arrived at the timings he did, and the last message invites further questions if you have them. This is far from people "staying silent". I'd encourage you to continue that conversation if you have more questions. The other developer/group that has not responded is Team C_rbios. Nobody knows who the C_rbios development team members are. It's an anonymous group that rarely interacts with the public. If you're expecting them to join this thread, that is (probably) unlikely to happen. Nobody in this thread is a representative of their group, and we are unlikely to hear from them directly about this topic. I also want to point out that you benefit from C_rbios supporting HD_+. You are making extra sales from the $60 HD_+ from people who want an all-digital HDMI solution but don't want to be forced to use St_llar's BIOS (or Legacy). Yes, this includes clones, but not exclusively. This move affects your real, legitimate customers (limited in relative quantity though they may be). Personally, I hope they do drop support for HD_+, regardless of the code's lineage. Seems like it's more headache than its worth keeping it. It would piss off some people, but not at Team C_rbios. Lastly, filing a DMCA against Pandora was in poor taste. Pandora itself does not host any binaries. It's an IRC client and FTP server wrapped in a singular program for convenience. If it is illegal, then so should be web browsers, cURL, and other apps used to download resources from 3rd party URLs. Or torrent software, for that matter. C_rbios and Prometh_OS are two apps amongst a myriad of apps that are hosted on Xbins. I hope you're aware of the public-perception implications this may lead to.

Let's not hide names please. We have a very slim chance to put this all to rest. It only happens if we can communicate without attacks and where we know who we're talking to.

PM's are being sent due to the thread being locked at various times. It was MY decision to not reveal a name.

Hiding behind private messages isn’t helping. If someone has information that can clarify things, they should be saying it publicly where both sides can respond. So far, only one developer has stepped up to answer questions about a single issue. Everyone else involved, especially those tied to the other topics being raised, has either stayed silent or had someone else speak on their behalf. The logic here clearly shows it's part of a larger function that has been conveniently cropped out. I've already shown this section here. As soon as it's mentioned that S_tellar's logic was original implemented to live inside of the kernel, you then now have the narrative that "derived from the retail kernel decompilation reset bus delays" from a project that's co-authored with a group directly compiling the leaked kernel source. If this is was true, then the resulting structure should match the kernel; not S_tellar. It doesn’t. It matches our layout, our timings, and our implementation. None of this adds up.

Recieved another pm from a very respected scene member.. "May want to point out to MH that what he’s still comparing is also found in the official binaries of all Xbox bios. So he can’t use that as a way of proving theft. As he’s skipped over that image completely" The image in question is this.

We're having to show comparisons between the assembly because source code for the first release of PrometheOS with this feature does not seem to exists. In the write up there's multiple of these screenshots showing the Ghidra disassembler side by side with M_akeMHz on the left and Cerbios/PromethOS on the right. Inside these windows you will see the assembly code in the middle panel and the C code approximation in the right panel. When we say the code was stolen, we’re not saying they had access to our original C source. Which is entirely possible, especially with modern disassemblers and decompilers. What we’re showing is that at every opportunity where an implementation could differ in structure, timing, or control flow that their version consistently matches ours. Each of those decisions could have gone a different way, but they didn’t. The outcome isn’t random chance. It’s copying. This has been a problem in the past and as recently as the Grand Theft Auto 3 reverse engineering project that Take Two forced to shutdown. This is because copying the output of a decompiler does not make a work transformative. --- It's taken two weeks for to get a response on one part of the code theft and we have not heard anything from Equinox, or the other members of Cerbios, about the other issues. --- I'm trying to figure out the next step here. I did open a GitHub issue on the PrometheOS here. But it seems to have created more questions than answers so far. - GitHub history of the development process doesn't exist. - It seems other closed source software may have been used.

You'd think though that there would be or could be a whole load of homebrew solo card games including Solitaire and Hearts made for the OGXB. Marble/Peg Solitaire too. The OP's post appears to be spam but it does raise the quite interesting question as to why versions of those relative simple, easy play games haven't been ported/adapted.

I'll unlock for a response if you so choose. This is more of a "my ignorance" question. This appears to be the code that unlocks a drive even with no key. Code that is in question and that you've alleged that you created and was stolen from your published works. If your assembly / machine code was stolen, how do they have the C++ code? My understanding is that a compiler is a one-way operation. It takes the type of code above and translates it into machine language, stripping comments and any other unnecessary but human-friendly things out on the way. This means there is no possible backwards translation or decompilation back into C++. They should only have the allegedly stolen block of assembly and not C++. Even if they did somehow manually translate the assembly into C++, based on previous comments here it should not compile back into exactly the same machine language. How is this possible?

PM RECIEVED FROM @Harcroft. Info is relevent to this thread. "My talk of VSC research was entirely for PC side and Serial interface unlocking. Most of the research was done by Siktah, but many of the resources can still be found today. My links were all to address the accusations thrown at Skye and Eaton. NOT to do with the Stellar and PromOS Xbox side unlocking. They were separate "concerns" raised by MM. muramasa is connecting them when they should not."

All this huffing and puffing and legal DMCA stuff is successfully achieving is driving a MASSIVE wedge through the middle of the scene. The regular scene users on one side and St_llar users on the other. Personally I dont see any end to this episode so we better get ready to split sites like this in two, one for the usual scene and one for the St_llar camp.

Thanks @Rocky5, I just checked my Filezilla was set to auto. I am building another drive and will change it to give it a go.