LoveMHz

Blog: Theft in the Xbox Scene - Part 2

Sat, 12 Jul 2025 13:32:45 +0000

Introduction

This is a continuation of Theft in the Xbox Scene - Part 1, where I began documenting some of the challenges and setbacks we’ve faced as a result of ongoing IP theft and misinformation.

Unresolve Issues

There’s been a lot of confusion about the core issue raised in the original post. To be clear, it’s the theft of our software. That was the first and most important part of the article to be written. Everything else was added to provide background and context; but unfortunately, that also introduced a lot of noise into the conversation.

Despite the attention the post received, very little has been done to address these concerns. The key issues remain unresolved.

Unresolved

Theft of XboxHD+ logic
Theft of HDD unlocking (key recovery) logic
Theft of CPU upgrade support logic

I also believe the In-Game Reset (IGR) logic copied from rmenhal’s GPL-licensed work deserves more attention within the community. However, since this isn’t my code and we don’t use it, we’re not pursuing it ourselves.

Partially Addressed

PrometheOS has taken responsibility for incorporating XboxHD+ code. However, the issue remains unresolved, as the license terms are still not being followed. A formal request will be submitted to address this.

Since PrometheOS is built and distributed using Cerbios, we also believe the underlying Cerbios-related issues need to be addressed as part of that resolution.

DMCA

Over the past year, we have made multiple attempts to address the unauthorized distribution of XboxHD+ files on xbins. This has included outreach from others in the retro community, but so far, those efforts have not led to a resolution.

A DMCA notice was submitted to GitHub for Pandora, a tool built specifically to download files from xbins. Most of these files are not legally available through any other means. To clarify, our concern lies only with the distribution of our works without permission. If members of the Cerbios and PrometheOS teams have contacts at xbins, we hope they will step in to help resolve the issue.

We have also submitted DMCA notices to online stores selling products that include or enable unauthorized use of our protected works. This includes hardware specifically designed to circumvent the XboxHD+, such as boards marketed with phrases like “just find the firmware,” as well as, in one case, an OpenXenium product explicitly sold with Cerbios and PrometheOS preloaded.

In the case of Cerbios and PrometheOS listings, we have stepped back from issuing further notices for now. We hope the teams behind those projects will take responsibility and work to resolve the issue themselves instead of leaving the burden entirely on third-party sellers.

Theft of HDD Unlocking (Key Recovery) Logic

There has been a lot of confusion surrounding what was stolen and why it matters. To clarify: drive unlocking and drive unlocking via key recovery are two very different processes.

Drive unlocking through vendor commands is often a fallback method for manufacturers. It allows access to drives that are locked but without recovering the original key. In contrast, drive unlocking via key recovery uses a diagnostic interface to run custom payloads that extracts the drive’s unique key directly from its controller.

The Seagate U5 is a perfect example of why key recovery is not straightforward. There is no predefined command to ask the drive for its key. Unlocking it requires a custom payload, executed through an undocumented diagnostic interface, to force the controller to execute code fromo a specific location in memory that places the hardware in just the right state for the key to remain accessible and not cleared from memory.

I reached out to EqUiNoX for clarification on how their implementation works but have not received a clear response.

The initial list of resources they shared includes:

Documents covering TTY-based unlocking with and without key recovery
References to drives with completely different architectures
One closed-source program, which I have not been able to confirme to support key recovery on original Xbox drives.

The Elephant in the Room

A common challenge with publishing technical write-ups is having to respond to made-up accusations. I want to address one of them directly because it containts a direct quote from EqUiNoX of Team Resurgent.

On July 8th I was tagged in a post on Bluesky claiming that one of the many samples we provided was a direct copy of Microsoft code.

Not only is this incorrect, but the cropped screenshot being circulated is misleading. It omits surrounding context that differentiates our implementation from Microsoft’s. This kind of selective framing only fuels misinformation.

I addressed this on the OGXbox forums.

Below is the full section in question without the crop. I’ve added labels to make it clear which code is Project Stellar, PrometheOS, and the same retail Xbox kernel. This is not “leaked source code” or anything like that. It’s the exact same kernel as the one in the BlueSky post. It’s the Retail 3944 kernel with the SHA1SUM of 67054fc88bda94e33e86f1b19be60efec0724fb6 for the full 1MB backup.

This is from the same retail kernel as the cropped screenshot and was decompiled using Ghidra with default settings. Kernel exports were renamed using RenameKernelImports.py, generated from the XboxDev wiki infromation on the kernel exports, and type information was applied from nxdk.

The original code in question is a polling routine used to ensure the drive resets. It does not match Project Stellar. We included it in our list of samples because it exists outside of the kernel and the pattern lifted from Project Stellar into PrometheOS is still clear. The timings also still matter. If the surrounding logic changes, the delays could change too or be optimized away if that was the goal.

To be absolutely clear, I am are not claiming ownership over basic I/O instructions like out or standard functions like KeStallExecutionProcessor(). That would be like claiming ownership over if() statements.

Our implementation is based on the ATA/ATAPI specification, as shown below from the Information Technology - AT Attachment with Packet Interface - 6 (ATA/ATAPI-6) datasheet.

The timing values used in our implementation apply a multiplier to account for bus delays and timer resolution differences. These timers are based on the onboard crystal, and ownership of the bus from the CPU through the northbrige and to the southbridge must be queued. While the timings are not exact, our values were tested extensively to ensure stability.

But you might ask, “The PrometheOS code uses a variable to store mIdePort. Isn’t that obviously different from either implementation?”

And to that I would say this shows a basic misunderstanding of how the Xbox works. If this had actually been reverse engineered from the Xbox kernel, that variable would not exist. The Xbox has only a single IDE controller, and it is always mapped to a fixed I/O address. Anyone doing even basic reverse engineering would know this. In fact, just looking at the motherboard would make it clear that it only has one IDE controller because it only has one IDE port.

If your concern is “optimizations,” then that’s a free one. Because as it stands, mIdePort, does nothing but make it one line of code different from Stellar.

Team Resurgent’s Response

After publishing the first article, I opened a GitHub issue on the PrometheOS repository to seek clarification on the HDD unlocking logic. The goal was to ask direct, technical questions about the origins of the code and the development process behind it.

The responses from EqUiNoX were appreciated, and I want to be clear that I gave every opportunity for clarification. I asked specific questions, followed up where needed, and allowed their words to speak for themselves.

However, several of the responses raised new questions, revealed inconsistencies, or introduced claims that will need to be addressed in more detail. For now, I want to provide a summary of what was said and what is still unclear. I will expand on these concerns later in the article.

Response #1

I find the statement hddVscUnlocker::resetIdeBus <- derived from the retail kernel decompilation reset bus delays questionable. PrometheOS requires Cerbios to execute from a modchip, and both projects have worked together publicly in the past. This is important context, because Cerbios is compiled from leaked Xbox source code.

In the implementation of resetIdeBus, the oddity of using mIdePort has already been addressed above. As for the claims regarding how the remaining timing values were derived, there would need to be actual testing to validate that assertion.

The most significant red flag is the statement about Sleep() that it causes issues with background threads accessing hard drive, and that this is why KeStallExecutionProcessor() was chosen. This is simply not how the Xbox works. The Xbox uses preemptive multitasking, meaning it constantly and rapidly switches between threads.

To prevent other threads from accessing the drive, the correct behavior is to raise the interrupt request level (IRQL) to DISPATCH_LEVEL or higher to block thread switching via KeRaiseIrqlToDpcLevel.

But PrometheOS doesn’t do this. Instead, it copies Stellar’s exact logic: raising the IRQL to the interrupt level of the IDE controller by calling HalGetInterruptVector and KfRaiseIrql. And this isn’t the only way to achieve this.

The only difference here being that IRQL is raised by the caller via callee. ie PrometheOS moved the KeRaiseIrqlToDpcLevel call from outside the drive functions to right inside them.

This is not for blocking other threads. It’s for blocking kernel responses to IDE controller interrupts.

This undermines the explanation that it was done for optimization. I don’t belive this is a misunderstanding on my part. It reads more like an excuse layered over copied logic.

To drive this home… Something I noticed while putting this article together, and honestly found a bit funny, is this line in the PrometheOS 1.3.0 source release:

HalGetInterruptVector(0xe, &irql); // 0xe = PNPISABus

The value 0xe is the same value as the interrupt for the IDE controller, but the comment is completely incorrect. PNPISABus is a constant from the INTERFACE_TYPE enum used to describe how devices identify themselves to the system, such as PCI or ISA. It is not related to interrupt levels in this context.

This is without a doubt a case of someone not understanding what the code is doing. The comment was likely added to make sense of a value they copied without knowing what it actually represented. It brings everything full circle.

Response #2

Lack of Source Code

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

This development approach is incompatible with open-source license requirements, especially for any project that uses GPL-licensed code. The GPL requires that the complete source code be made available for all distributed versions. That includes any intermediary versions that were released as binaries, such as v1.2.0 of PrometheOS. Failing to retain or provide this source code is a direct violation of the license.

This is not a small or technical oversight. It is a license breach that affects the legality of distributing the software itself. If you distribute a binary, you are also required to provide the full corresponding source to that binary. There is no exception for working locally or pushing code in one large commit. By not maintaining source control in a transparent and trackable way, the project undermines the trust that open-source licensing is built on.

What makes the situation worse is that PrometheOS includes code taken from XboxHD+, which is also released under the GPL. When that code is reused, modified, or redistributed, the GPL still applies. The license terms are not optional or negotiable.

PrometheOS is distributing binaries that contain our GPL-licensed code, yet it fails to:

Provide the complete source code for the versions being distributed
Properly attribute the original work
Grant the same rights to others to inspect, modify, and redistribute under the same terms

This is not theoretical. These are the exact obligations outlined in GPLv2, sections 1 and 3.

If this were simply a misunderstanding, it could have been addressed by releasing the required source for v1.2.0. Instead, the jump from v1.2.0 to v1.3.0 includes binary changes that appear deliberately obfuscated, making it harder to identify what was changed and why. The only changelog entry provided was “Improved: VSC HDD Unlocking Times,” yet the code changes go far beyond timing adjustments and raise serious questions about intent.

Sleep() and KeStallExecutionProcessor()

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.

This is not true and is covered above. KeStallExecutionProcessor() has no impact on running threads and does not read, write, or modifiy the IRQ level in any way.

Research Notes

I do remember decompiling a dos utility called zu.exe however which helped greatly.

Earlier in this article, I covered the topic of HDD Unlocking (Key Recovery) and the confusion surrounding the type of proof being requested. That context is important here, because the list of “prior research” provided in defense of the PrometheOS implementation largely references TTY-based unlocking methods or closed-source software that either does not support key recovery or does not apply to the drives in question.

One new reference introduced in this discussion was zu.exe. I had not encountered this tool before, so I asked for clarification on exactly which drives it can unlock and whether the screenshot provided was showing key recovery in action.

These details matter because the architecture of these drives varies significantly, and claiming to have “extrapolated” key recovery from closed software, without documentation or code, raises serious questions.

Still, I tested the theory in good faith. I used an Intel P4 system and a motherboard built with the exact same chipset used in the Xbox, but was unable to reproduce the result.

Response #3…

This was one of the last meaningful replies in the GitHub conversation, and it left several questions unanswered.

Obfuscations in the v1.3.0 Source Release

PrometheOS is currently hiding behind the 1.2.0 source release, but after comparing the 1.2.0 binary to the 1.3.0 release over the past few days, I’ve identified even more undeniable examples of copied code. In this case, the changes appear to have been made specifically to conceal the theft.

The release notes for version 1.3.0 only mention one related change:

Improved: VSC HDD Unlocking Times

With that in mind, we will focus on examples where the code was modified in ways that are unrelated to unlocking performance or any reasonable optimization. These changes do not improve execution speed or stability. They appear to serve only one purpose: to make the stolen code harder to recognize.

Meaningless Changes (Obfuscations)

We pressed hard for clarity on how the Seagate U5 was figured out, because as far as we know, there is no public documentation or tool that covers key recovery for it.

In comparing the 1.2.0 and 1.3.0 versions of PrometheOS, two changes stood out:

sgVscDiagExecCmd(..., "GFFF3") was changed to sgVscDiagExecCmd(..., "GFFFFFFF3") sgVscDiagExecCmd(..., "/1") was changed to sgVscDiagExecCmd(..., "/2")

These changes have no meaningful impact. In fact, the first one arguably makes things worse.

The value GFFF3 instructs the hard drive controller to begin code execution at 0xFFF3. Extending it to GFFFFFFF3 results in the same truncated address due to the controller’s address space, but it adds unnecessary characters that make the command slower to transmit and process.

The change from /1 to /2 just switches diagnostic input modes, but neither option has an effect on the controller’s behavior in this flow.

These are not optimizations. They are changes that serve no functional purpose and appear to exist only to obscure the original source of the code.

Conclusion

At this point, I’ve said everything I need to. The concerns have been laid out clearly, and the patterns speak for themselves. Unless something meaningfully changes or new information comes to light, this will be my final word on the matter.

: Theft in the Xbox Scene - Part 1 Corrections

Wed, 09 Jul 2025 11:32:45 +0000

Apologies

It’s not easy to admit when you’re wrong, but I want to start there.

My frustration comes from the people who are actively stealing and cloning our hardware and software, and from those spreading misinformation to protect or promote that theft. It’s the groups that hide behind anonymity to mask their acts while at the same time constantly shouting, “it wasn’t me.”

That said, the best apologies are short and sincere. While we may still disagree on some things, I want to apologize to Harcroft, Skye, and Eaton for involving you in this situation. My issues are not with you or your projects. I had incorrectly associated you with efforts I do have a problem with, based on the information I had at the time. Since then, I’ve received clarification and want to set the record straight.

It was unprofessional, and I will do better moving forward. I have updated the original blog post.

Blog: Theft in the Xbox Scene - Part 1

Fri, 20 Jun 2025 11:32:45 +0000

Introduction

This is not an article I want to be writing. It is not something I ever imagined I would have to write. But to explain why I am writing it now, I need to provide some history.

Corrections and Updates

Corrections and updates for this post can be found here.

Backstory

My journey with the original Xbox began about six years ago, inspired by the HDMI mods I had seen for systems like the Dreamcast and N64. Growing up, I didn’t have much. A Game Boy Color, an N64, and eventually an Xbox were the only consoles I ever owned as a kid. But it was the Xbox that stuck with me the most.

Years later, I wanted to relive that experience. I wanted to sit down and enjoy some of my favorite games again, like Fatal Frame 2 and Conker’s Bad Fur Day, but on modern hardware with a cleaner signal. That curiosity led me to explore what it would take to bring HDMI to the original Xbox.

I’ve always had a deep interest in reverse engineering. As a kid, cheat devices and emulators fascinated me. They became a kind of escape from a life that, at times, felt like it had very few constants. Around the age of ten, I discovered the memory editor on the N64 GameShark. That discovery lit a fire. I wanted to understand more, so I learned programming and started writing my own tools. Eventually, that replaced the pen-and-paper notes I had scribbled down as a child.

When I lost my father figure not long after, programming filled that void. It gave me purpose, focus, and a sense of control at a time when everything else felt unstable.

Developing the XboxHDMI brought all of that back. The joy of discovery. The thrill of building something new. And along the way, I met people who became real friends. <3

Midwest Gaming Classic 2025

When I finally launched XboxHDMI, I had no idea what to expect. I figured it might be a fun side project. Something I would work on during weekends and maybe sell a few kits here and there. Once I recovered the initial costs, I planned to open source it.

But the launch went far beyond anything I could have imagined. Orders came in fast. Maybe it was the $60 price tag, maybe it was the timing, or maybe the Xbox still meant something to a lot of other people too.

Then COVID hit. Supply chains dried up. Shipping delays frustrated everyone. It was a hard time for many of us. But we pushed through. We kept going.

But I quit my job anyway to do this full time. It wasn’t an easy choice. I gave up a steady paycheck, time off, health insurance, and stability. I had saved enough from my day job to take the risk, and I believed in what I was building. I even had enough to fabricate the boards myself and handle everything from design to fulfillment on my own.

I wish I could say it’s been easy, or even always fulfilling, but it hasn’t. Anyone who works with me knows how much I put into this. I work non-stop, and I mean that in the most programmer sense possible. I’ve taken just a few days off a year. I answer support messages on holidays. I chip away at documentation and development deep into the night.

I wouldn’t trade it. Even when I look back on one of the worst medical experiences I’ve had, I try not to think about how differently things might have gone if I had kept my job with insurance.

I do wish I had more time with family and friends. But they understand. They know what this work means to me. This isn’t just about hardware. It’s about preservation. It’s about making something that lasts.

Project Stellar launched at the end of 2022. It was another passion project I couldn’t let go of. All the research from XboxHD+ felt like it had more to give. I wanted to keep fixing, keep improving, and keep exploring. I knew from the beginning it wouldn’t be highly profitable. It’s a more expensive product and the audience is smaller. But I had faith that the Xbox and retro gaming community would support it.

And I have to say, recreating an operating system from scratch, legally and cleanly, has not been easy. But it has been rewarding. Spending weeks to fix a single edge case in a game that has been broken for a decade is the kind of work I live for. I couldn’t imagine doing anything else.

All of that makes what I am writing now so much harder.

Because while we were focused on building something meaningful, others were quietly copying, stealing, and taking credit for work that was not theirs.

This article exists because this cannot continue.

Why Now?

When I first got involved in the Xbox community, I was pretty outspoken about theft and the general disregard for intellectual property. There are plenty of old screenshots floating around of some of my hot takes, and while I could have worded things better, I still stand by the core message. I believe we can all do better.

I’ve tried speaking out before. But every time I did, it led to personal attacks against me and against my company.

Accusations like this are not just misleading. They are part of a larger pattern used to discredit and silence anyone who pushes back against theft. This is one of the reasons I stayed quiet for so long.

I’ve stayed quiet for years to avoid the drama and protect the work we were doing.

I’m writing this now because that silence has only made things worse. It is time for things to change.

The Xbox community is better than this. This is the same community that built projects like the open-source NKPatcher, long before I came along. It proved that legally extending the retail Xbox kernel was not just possible, but practical. Projects like nxdk have gone even further by showing that legal, independent toolchain development can work and thrive.

I’m also writing this now because I’m tired. I’m tired of constantly worrying that everything I’m working on is going to be stolen the moment it is released. This is not how things should work. It’s not fair to my mental health. It’s not fair that updates to Stellar are delayed so we can implement obfuscation and anti-circumvention measures, just to slow down the people trying to take our work.

I’m writing this for the thousands of people who have put their trust in our work. We are just weeks away from reaching 10,000 orders shipped, not including retail partners. All of those people are being stolen from too, whether they realize it or not.

And I’m writing this for future developers. Even those who may one day replace what I’ve built. If the community accepts theft as normal, then there is no real path forward for anyone who wants to build something original. It becomes impossible to compete with shortcuts, and that drives real progress out of the scene.

What Needs To Change?

Stop misleading users into thinking Modxo, PrometheOS, and CERBIOS are open source. Modxo was once open source but now uses a restrictive license (non FOSS). 1 2 PrometheOS is not an operating system; it is an Xbox application built using a stolen SDK and a stolen BIOS. CERBIOS is closed source and built on leaked kernel code along with stolen work from others. 1 2 3 4 5
Stop encouraging theft of the XboxHD+ and Legacy kit by telling customers to “just find the firmware.” 1
Stop selling known counterfeits and hardware clones. 1 2 3
Developers should stop claiming they are not stealing while at the same time publishing guides that explain how to do exactly that. 1 2
Stop using alternate accounts to fish for implementation details or gain access to private work. 1
Stop making up claims that Stellar is anti-community, including false accusations like “Stellar intentionally broke support for XCAT.” The truth is that XCAT’s own DRM prevents it from working. Nothing was done on our end to block it. 1
Stop making claims that we have abandoned the XboxHD+ Legacy kit. This is the first time since the original XboxHDMI launch that the legacy, no-modchip option, has been truly out of stock. We are actively working on it. Recent trade-related issues, including tariffs, have caused unexpected delays. 1 2

This is only a small part of the harassment, theft, and misinformation we have dealt with.

Who?

Cerbios / Team Resurgent

I’m calling out Cerbios / Team Resurgent. This includes all of its members: EqUiNoX, HoRnEyDvL, Hazeno, and Dempsey_86.

These individuals have repeatedly shown a disregard for intellectual property, copyright, and the work of others. Their actions are not isolated incidents. They are part of a long-running pattern of theft.

Moderators of r/originalxbox

I’m calling out the moderators of the Original Xbox subreddit: Derf_Jagged, TXCrunchBite, OGXboxGamer, GoTeamScotch, AlbinoSheepDawg, KeepForgettingLogin, awesomesprime, Random_Shadowscale, DivideByZer0, and ulubulu.

These moderators continue to allow harassment, misinformation campaigns, and the promotion of stolen work. Some have even gone as far as promoting it directly. 1 2

Xbox Scene Discord

I’m calling out the Xbox Scene Discord for hosting and supporting ongoing theft of our work.

Others

I’m calling out darkonecustoms.com and ogxstore.com (Andr0) for selling products that rely on stolen work from the XboxHD+ project. 1 2 3

XboxHD+

Summary

To understand how the theft of XboxHD+ occurred, we need to take a step back and explain how this project began. Some of this has been shared before, but given the ongoing efforts to copy and clone our work, I want to be cautious while still providing enough detail to show how we got here.

The XboxHD+ project originally started as XboxHDMI in late 2019 or early 2020. During early development, we discovered that we could either build an expensive FPGA-based solution or implement extensive software patches. We chose software, in part because an FPGA would not fully resolve every video-related issue on the Xbox. That decision led to one of the largest software projects I have ever worked on, though I did not realize it at the time.

The initial idea was simple: patch the last retail Xbox BIOS, which supported all hardware revisions, with just enough logic to pass AV initialization and GPU configuration data to a microcontroller on the XboxHDMI. This approach worked well at first. It allowed us to inject handwritten assembly into the existing kernel with minimal disruption, which was important because there were only a few hundred free bytes available to work with. Anything more complex would have been nearly impossible in that environment.

We briefly explored porting the patches to other BIOSes, including iND BIOS, but this quickly turned into a nightmare. After significant effort, I discovered that the iND BIOS had been compiled from leaked source code and was heavily hacked together. At this time CERBIOS did not exist.

As a result, over a year’s worth of research and patching logic no longer applied. We abandoned any further attempts to port the patches and focused on building something more sustainable.

In April 2021, we rebranded XboxHDMI as XboxHD+ and launched firmware version 2.0.0. The new name was meant to reflect that it provided “HD plus more.”

At this point, we moved away from manually patching the kernel on every update and introduced a system I developed called kpatch. This was a minimal loader that ran at boot and executed what we called the XboxHD+ runtime. We made kpatch open source to make it easier to integrate, and it became the foundation for future development.

The runtime would detect which Xbox revision it was running on and load the appropriate module. Each module was written in C and compiled specifically for that hardware revision. This let us replace hardware-specific kernel functions with reimplemented versions optimized for each system. It also gave us more space to work with, since we could target unused or replaceable code in a structured way.

This architecture made it possible to fix longstanding issues and improve video output beyond what the original Xbox ever supported. We added upscaling, better widescreen handling, and even per-game fixes. Because the runtime could be updated separately from the BIOS, users could upgrade features just by replacing a file. The kpatch build system and the XboxHD+ runtime became the foundation for what would eventually evolve into Project Stellar.

This design was intentional. It allowed for modular development, future porting to other BIOSes, and easy updates for users. But that is not the path CERBIOS chose.

Instead of using or building a system like kpatch, CERBIOS appears to have copied the XboxHD+ runtime logic directly into its kernel. This was not an integration. It was a transplant.

As we will highlight throughout this article, the design decisions made by the CERBIOS team do not reflect original development. The methodologies appear to be copied directly from the XboxHD+ runtime, which is copyrighted and not public.

The first red flag is their handling of the function AvSetDisplayMode. This is a relatively straightforward kernel export responsible for setting up the GPU and video encoder based on the selected video mode. On the original Xbox, most of this work is done using lookup tables, with minor conditional logic based on the encoder type. Under XboxHD+, these lookups are redirected to the microcontroller.

CERBIOS takes a very unusual approach. They re-implemented AvSetDisplayMode three separate times, once for each encoder. This makes no practical sense. It triples the code size, increases complexity, and does not follow the design of the original kernel. More importantly, it closely mirrors the XboxHD+ runtime structure, where we split modules by hardware revision to reduce memory usage. That design made sense in a boot-loaded runtime. It makes no sense inside a BIOS kernel unless it was copied directly.

Anyone reverse engineering the Xbox video subsystem would have seen that a single function with conditional logic is the right approach. Duplicating the logic three times is not only inefficient but also suggests that it was taken from a system designed to be loaded dynamically at runtime, not built directly into a BIOS. That kind of structure only makes sense when you have the flexibility and memory overhead that a separate runtime allows. This matters because the Xbox kernel has strict size limits. Without additional memory, like what Project Stellar provides, pushing memory usage higher introduces uncertainty. It increases the risk that existing software will behave unpredictably or fail entirely.

That is not all.

Other parts of the project have also been copied. Code that was released under the GPL for the XboxHD+ application has shown up in PrometheOS as well. This includes struct definitions that only exist in our released source code and cannot be reconstructed by reverse engineering. These structures have been copied almost verbatim, with only minor changes such as capitalization. This is not reverse engineering. This is copy and paste. And it is a clear violation of the license and theft of our work.

The Important Questions

If CERBIOS truly developed their work independently, why does their code mirror the structure of the XboxHD+ runtime, which was never publicly released?
Why would anyone re-implement AvSetDisplayMode three separate times, when conditional logic in a single function is the clear and correct solution?
How did struct definitions from our GPL-released userland application end up in PrometheOS, when those definitions cannot be recovered through reverse engineering?
Why are memory usage patterns and hardware handling strategies identical to ours, even down to function placement?
Why would a BIOS be written in a way that pushes it closer to unknown memory limits, unless the design was copied from a system intended to run as a boot-loaded runtime?

Theft in Plain Sight

The comparisons in this section focus exclusively on code and behavior that were never part of the original public domain release of the XboxHDMI patch. The early patch I released was minimal, designed only to initialize video output and hand off control. It does not include subroutines for the virtual SMBus tables, configuration, or initialization.

What follows are similarities that exist only in the private, copyrighted runtime and cannot be explained as reimplementations of public work. These are not isolated coincidences. When viewed all together, I believe they show a clear pattern of copying.

The same logic of applying the exact same delay after storing the video mode.

As part of the XboxHD+ runtime, I introduced a small helper routine for setting the current virtual page. Functionally, it’s extremely simple as it’s just a single register write with a hardcoded offset. It duplicates logic that already exists elsewhere in the runtime, and looking back, even I’ll admit it should have just called the standard register write function.

There was no technical reason to split it out. It was a quick decision made during development, and it remained because it worked.

The screenshots below show that CERBIOS includes the exact same kind of helper routine, with the same structure and purpose. This is not a common design pattern. Anyone writing this from scratch would have just used the existing write register subroutine. The fact that this unnecessary and oddly specific function appears in both runtimes is not a coincidence. I believe it is another clear example of copied code.

Identical virtual page setter routine found in both XboxHD+ and CERBIOS. The logic duplicates existing write functionality that I believe would not have been independently re-created without copying.

Another example appears during the XboxHD+ initialization sequence. In early XboxHDMI firmware, we encountered a bug where, in I2C software mode, the microcontroller could overflow before it entered hardware mode. To resolve this, we added a very specific delay and call pattern in the initialization logic of the XboxHD+ runtime. This fix ensured reliable behavior under edge conditions caused by queued SMBus transactions in the Xbox kernel.

This delay is subtle and internal. It would not be visible externally, because SMBus operations are abstracted and queued within the Xbox kernel. There is no way to observe or infer this behavior by watching from the outside.

Yet, somehow, CERBIOS includes the exact same logic. The same call structure. The same delay in the same place. The only difference is that CERBIOS omits this delay in unrelated areas, which further highlights how deliberate its inclusion is here.

CERBIOS initialization includes a delay and call structure identical to XboxHD+, originally added to fix a microcontroller overflow issue in I2C software mode. This behavior is not externally observable and would not appear without access to the XboxHD+ implementation.

The next example is not just a design copy. It’s a direct copy of source code.

The screenshot below shows the PrometheOS source code defining a settings struct that matches our own, almost line for line. This struct was published as part of the open source XboxHD+ application under the GPLv2. But in PrometheOS, it has been taken without attribution, and more importantly, used in a way that is not compatible with our license. This is not just a license violation. It is source-level theft.

What makes this even more telling is that they copied struct members that are not implemented in their own code and could not be reverse engineered. These fields serve no purpose under the XboxHD+ runtime or in PrometheOS but appear exactly as they do in our code, with the same names and the same unused placeholders. That cannot happen by coincidence.

PrometheOS struct copied directly from GPLv2 XboxHD+ source code, including unused and unimplemented fields that cannot be reverse engineered. No attribution. No license compliance. This is source-level theft.

Where Does the Theft End?

Since the release of XboxHDMI, there has been a consistent effort within parts of the Xbox scene to clone, copy, and steal whatever they can. This is not new. It has been happening in the open for years.

At least four separate projects have attempted to recreate or reverse engineer XboxHDMI or XboxHD+, not through original development but by following, dissecting, and imitating our work as closely as possible. With CERBIOS and PrometheOS, the line between inspiration and theft is not blurry. It no longer exists.

Even now, it is difficult to find a major project in this space that is not either directly benefiting from CERBIOS’s stolen work or openly working to copy and replicate what we have built. What started as quiet imitation has become a public ecosystem centered around copying. And somehow, this behavior continues to be rewarded and normalized.

There are clone devices already on the market. Sellers advertise them and tell buyers they “just need to find the firmware”. These are not throwaway comments. Members of Team Resurgent have previously written guides on how to bypass our copyright protections in the past, and those same techniques are now being used to install stolen firmware onto unauthorized hardware.

This is not about gatekeeping. It is about respecting the time, effort, and work that go into creating something new. The theft is not some distant danger; it is already happening behind closed doors. Stolen work is being rebranded, repackaged, and quietly sold back to the very community it was taken from.

HDD Unlocking

Summary

On December 29, 2023, we released firmware version 1.4.0 for Project Stellar. This update introduced, for the first time, fully integrated support for unlocking original Xbox hard drives directly from a running system. This feature had been in development for over a year.

Our work was based on in-depth reverse engineering of original Xbox hard drive firmware. To our knowledge, outside of private commercial data recovery tools targeting specific models, there were no known public methods for unlocking these drives. No documentation existed that demonstrated how to apply these techniques in the context of the Xbox, and no prior tool supported all drive variants over IDE from a running system.

Even more significant, this was an entirely new side channel attack that allowed drive unlocking to be performed directly over the IDE bus.

Later that same day, Harcroft, a member of the Xbox Data Preservation Discord and other related projects, publicly replied to our announcement, stating:

We've been doing this for the better part of a year with free software tools and $2 USB/TTL boards.

Twitter Post

The implication was clear: that this was old news, that what we had built was nothing new, and that the feature had already been available in the scene for some time.

The Important Questions

If this had already been done before, why does no one now seem to understand how Stellar works?

Public Chat on Jan. 8th 2024 - Xbox Data Preservation Discord

If you’re not reverse engineering Project Stellar, how would you know that the unlocking logic was moved to a separate XBE?

Public Chat on Jan. 8th 2024 - Xbox Data Preservation Discord

If this is your own original implementation, why does the code match our patterns and not yours? Ours was originally written for the Stellar kernel, which lacks a full runtime library and was only moved to an XBE at the last minute. Your version uses direct kernel calls instead of the common RTL functions found throughout the rest of your codebase, which are provided by the stolen XDK environment.
How is it that the temporary sleep and delay values that we implemented, down to the microsecond, also appear in your code?
Why was the source code for the first release of PrometheOS with this feature never released? Seems odd for an “open source” project.

GitHub

Who is this mysterious “Phantom” member that joined the team? They haven’t been seen since… Scapegoat?

Public Chat on March 1st 2024 - Xbox Data Preservation Discord

Theft in Plain Sight

In this section, we’ll present direct comparisons between disassembled code from Project Stellar and PrometheOS, showing unmistakable similarities that go far beyond coincidence. Screenshots and annotated listings will follow to allow anyone to verify the claims for themselves.

On February 25, 2024, nearly two months after Stellar’s 1.4.0 firmware release, Team Resurgent published PrometheOS v1.2.0. [1] This version introduced a new feature: support for unlocking original Xbox hard drives.

We’ll start with the smoking gun.

The HDD unlock logic in Stellar was originally written as part of the kernel itself but was moved to an embedded application (XBE) just before release. Because of this, the core logic remained unchanged. Inside that logic, we rely on lower-level system functions due to the limitations of the Stellar kernel, which does not include a full runtime library. Simple functions like Sleep or SleepEx are not available, nor are many standard helper functions. As a result, we used KeStallExecutionProcessor as a crude but effective way to introduce delays between command sequences.

This approach is completely inconsistent with how PrometheOS typically handles delays. PrometheOS is built using a stolen version of the official Xbox Development Kit (XDK) and has full access to Sleep, SleepEx, and other XAPI-based runtime functions. Their codebase contains over 150 references to Sleep-related calls, and only three references to KeStallExecutionProcessor. All three appear in a legacy method named SendATACommand() that was originally released by Team Assembly in 2003.

Anyone who has written debug or delay-heavy logic using printf or timing functions knows how unpredictable and arbitrary these values can be. The same applies here. But now consider this: KeStallExecutionProcessor introduces delays in microseconds, not milliseconds or seconds. These are one-millionth-of-a-second intervals.

So what are the chances that two completely independent implementations, written by different people in different environments, would not only use the same low-level delay function, but also choose the exact same timing values down to the microsecond?

This comparison of disassembled code represents the bulk of the new HDD unlock logic. It shows a repeated pattern of identical pause logic, matching code structure, and even small but telling details like the use of the same temporary buffer sizes. For example, both implementations allocate a 2048-byte buffer to handle roughly 500 bytes of data. There is no technical justification for that size. It only makes sense if the implementation was copied.

The few differences that do exist appear to be superficial refactoring. In Stellar, we access hardware registers directly through inline instructions. In PrometheOS, these same accesses are routed through member functions. This is another inconsistency that calls the originality of their code into question. Why would you go to the trouble of introducing microsecond-precision delays using KeStallExecutionProcessor, only to throw away that timing accuracy by introducing indirect hardware access? It does not add up unless you consider the possibility that the original logic was copied, then lightly restructured to appear different.

I don’t believe Dream is a developer for PrometheOS when they’re not playing Minecraft. And I don’t believe this code was written independently.

Theft of CPU Upgrade Support

Summary

One of the latest signs of copying appears in CERBIOS’s recent attempt to add support for upgraded CPUs. This is a technically complex area and we are not disclosing any implementation details at this time.

What we can show is a block of handwritten assembly in CERBIOS that matches code found in Stellar with near exact precision. This is not compiled C code or something taken from documentation. This is hand-written assembly, written instruction by instruction, with specific intent. It reflects deliberate choices made during development, not something a compiler would generate on its own.

Side-by-side comparison of handwritten assembly in Stellar and CERBIOS. The instruction sequence is nearly identical. This is not coincidence. This is not reverse engineered. This appears to be copied.

Yet somehow, CERBIOS includes what appears to be the same sequence of instructions, in the same order, performing the same task. These are not high-level abstractions. These are low-level, manual decisions.

It appears that CERBIOS has not yet completed the remaining logic needed to make this functional. But that is not what matters here. This appears to be yet another case of theft. The code has no reason to exist in this exact form unless it was copied. The chances of two developers independently writing the same hand-crafted assembly, down to the instruction and layout, are virtually zero.

Theft of the Xbox Kernel Source Code

Summary

It is no secret that an older, pre-production version of the Xbox kernel source code was leaked years ago. What is also widely known, though rarely acknowledged publicly, is that CERBIOS is that stolen code.

This is not speculation. It is easily verifiable.

The screenshot below shows how quickly the match can be confirmed. By using symbol signatures from debug and retail kernels prior to version 5000, we were able to identify 1,478 out of 1,638 functions in CERBIOS with no additional effort. Only 160 functions remained unmatched. With a small amount of tuning or adjustments, it would likely be possible to identify nearly 100 percent of the original symbol map.

Out of 1,638 known functions, 1,478 match the Xbox kernel without modification. CERBIOS is not clean-room. This is direct use of stolen Microsoft IP.

This is not a clean-room implementation. This is not reverse engineering. This is just recompiling stolen code.

It is a slap in the face to every developer who has chosen to do the work the right way. Many of us have spent years reverse engineering legal, retail kernels and building our understanding from scratch. That work is slow, difficult, and often thankless. But it is necessary for anyone who respects the boundaries of intellectual property and wants to build something sustainable.

CERBIOS throws that effort away. It relies on a stolen base, masks it with superficial changes, and presents it as original development. It is not.

Theft of the Xbox Development SDK

Summary

Yet another open secret in the scene is the widespread illegal use of the official Xbox Development SDK. This is not a rare case. It is routine. And it is required to build PrometheOS.

Team Resurgent relies on the stolen SDK as part of their build process. This is not speculation. Their source code contains headers, symbols, and dependencies that come directly from Microsoft’s proprietary SDK. Without it, the project would not compile.

What makes this worse is that there are legal, open-source alternatives available. Toolchains like nxdk have been built from the ground up by developers who respect licensing and legality. Despite this, the team behind PrometheOS continues to take what is not theirs and justify it with silence.

Because the SDK is stolen and unlicensed, no project that depends on it can be considered open source. It does not matter how much code is published. If your toolchain requires pirated software to function, your project is not open. It is not legal. It is not yours.

The use of the stolen SDK is not just a technical shortcut. It is another example of how core parts of these projects are built on theft. The foundation is illegitimate, and the work that follows carries that forward.

Theft of In-Game Reset Logic

Summary

In 2004, rmenhal released an open-source implementation of “In-Game Reset” (IGR) under the GPLv2 license. It is a clever and unique approach that works by injecting logic into the KeRaiseIrqlToDpcLevel function. The key idea is to detect if the function was triggered during the XAPI USB controller input interrupt by inspecting the call stack. Since Xbox applications embed their own copies of the USB driver, this method allows the kernel to detect controller input with as little of a memory footprint as possible.

It is a smart solution to a difficult problem, but it comes with a tradeoff: performance. Because this check runs inside KeRaiseIrqlToDpcLevel, it is triggered on every interrupt raised to DPC level. That adds overhead, especially in systems that already handle a high number of interrupts.

Project Stellar avoids this entirely. Our implementation of in-game reset does not rely on IRQ-level detection and does not hook into KeRaiseIrqlToDpcLevel.

CERBIOS, on the other hand, simply copies the original GPL-licensed implementation.

The screenshot above shows the beginning of KeRaiseIrqlToDpcLevel in CERBIOS. The in-game reset logic is clearly visible and matches exactly to rmenhal’s GPLv2 implementation. It is theft.

This is only a portion of it. There is significantly more IGR-related logic elsewhere in the codebase that is also copied but not shown here.

Other Concerns

There are several additional areas of concern that reflect ongoing issues with code theft, GPL violations, and uncredited reuse. These examples, while not covered in depth above, continue to follow the same pattern of taking work that does not belong to them and presenting it as original.

CERBIOS Virtual DVD (ISO) Support

CERBIOS’s Virtual DVD support behaves identically to rmenhal’s GPL-licensed implementation. Based on decompiled analysis, it appears they have merged rmenhal’s virtual drive and image-handling logic. This is not a coincidence. The same gameplay bugs and edge cases present in rmenhal’s code also appear in CERBIOS.

Conclusion

This isn’t the article I wanted to write. But after years of dealing with theft, misinformation, and targeted harassment, it became clear that staying quiet was only helping the people taking advantage of the work we’ve built.

What you’ve read here is just part of a much larger story. For every example shown, there are many more. Every product we release, every line of code, and every idea ends up with someone ready to take it, remove the credit, and pass it off as their own.

But this isn’t just about me. It is about the thousands of people who have supported our work, who expect better from this community, and who believe in doing things right. It is about building a space where legal, creative, and original work can grow without being buried under theft and deception.

If nothing else, I hope this post makes it clear that this behavior is not going unnoticed. It is not acceptable. And it will be called out.

I will keep going. I will keep improving Project Stellar, supporting XboxHD+, and doing the hard work the right way. If you believe in that too, thank you for being here.

This is only part one.

Blog: DIY Wifi Enabled Fish Tank

Sat, 19 Mar 2016 11:32:45 +0000

I recently purchased a Aquarius AQ11204 BettaView Brite Corner Tank and a cheerfully blue betta fish. The tank is a simple corner shaped tank that fits perfectly on my desk and adds a bit of life to the mountain of technology that every other inch of my office occupies. This particular tank also incorporates a multi-mode RGB LED that can cycle through different modes by pressing the button at the top. Overall, even without modifications, it’s a great tank!

But.. the lighting is a bit lacking. The light can only be toggled to stay on for a few hours after a complicated sequence of long and short button presses. The lighting modes are quite boring with only a few solid colors and an awkward attempt at PWM control of the LEDs for the fading. Now this got me thinking how I could improve this. I’ve had a bag full of ESP8266 boards for a while now, almost 6 months, that I haven’t done anything with.

For those who do not know anything about the ESP8266; it’s specs are as follows:

Cost is less than $2 shipped!
Wi-Fi chip with full TCP/IP stack
80 MHz Microcontroller
64 KiB of instruction RAM
96 KiB RAM
External 512 KiB flash.

In short, a powerful enough WiFi enabled microcontroller to control both the IO devices and host a basic HTTP server on the cheap!

So let’s get started! The goal for this project were as followed.

Weekend project. Shouldn’t take more than two days from start to finish.
Monitor and record water temperature every 30 seconds.
Text message alert if the water temperature reaches a concerning level.
Mobile friendly web interface for changing the color and effect mode. (Constant color, fading, etc)

Parts List

The links provided below are through the Amazon Affiliate program. If you want to do this project, and don’t mind waiting for the parts, then I highly recommend buying most of them off of eBay. Buying from eBay should lower the project cost (minus the tank) to around $12 bucks!

Name	Qty	Price
3.3V 950mA LD33V Voltage Regulator	x1	$1.50
ESP8266 WIFI Module	x1	$5.99
Waterproof Temperature Sensor DS18B20	x1	$5.99
10uF Polarized Capacitor	x1	< $0.08
0.1uF (100nF) Capacitor	x1	< $0.08
5V DC Wall Power Adapter	x1	$7.98

Brief Overview

On top of the tank is a removable, oblong puck shaped module that encloses the RGB LEDs, the big blue button for controlling the LEDs, a 5V power barrel input port and a battery slot for 3 AAA batteries.

LED Module

Inside of the LED Module, for the lack of a better name, consists of a few bare components. From left to right we find the PCB, battery contacts and the 5v power connector at the rear.

LED PCB

The LED PCB pictured above is a simple layout consisting of MCU (removed in the picture), an NPN transistor array with pull down resistors for each channel of the RGB LEDs, self-power off logic(transistor + capacitor) and power button. The MCU was not investigated due to it being unmarked and most likely being a masked ROM. In the picture I’ve highlighted the pinout from the MCU footprint for each of the RGB LED transistor leds and the button.

Deconstruction

Deconstruction was quite easy. Started by removing all of the components and breaking the plastic pieces of the battery separator. In the future, I hope to find the right Dremel bit for cleaning up such tasks. Not a lot of time was spent freeing up space as there’s plenty on the inside for what I wanted to do.

Schematic

The schematic for this project is actually quite simple and is built of a couple sections. Were saving a lot time by directly controlling the transistors on the LED PCB. The LEDs, wired in parallel, would normally pull too much current for the ESP pins to handle, but in this case we should be fine since we’re only controlling the transistors directly.

Power Input - The power input is the barrel jack located on the device and provides 5v to the LED PCB and to the LD1117V33 voltage regulator.

Power Input -> 3.3v - This is the 5v to 3.3v regulator along with the associated stability capacitors. Datasheet

RGB PCB IC - This section represents 4 of the MCU/IC pins found on the PCB as described previously in the PCB LED section.

ESP8266 - In this project I’m using the ESP8266 ESP-03. CH_PD must be tied high, 3.3v, for the ESP8266 to turn on and GPIO15 must be tied to ground. (More information about the different board variations of the ESP8266 can be found here.) GPIO0, also know as PROG, must be tied to ground on power to enter programming mode.

An optional decoupling cap of 0.1uf on the VCC/GND pins may be added, but was omitted.

ESP8266 - Debug Header - In this project I used a simple 1x4 pin header to breakout a connection for the TxD, RxD, 5v, and GND. This allowed me to program and debug with a 3.3v USB serial cable that also provided 5v for the LED PCB.

ESP8266 - Temp Probe - The temperature probe is a DS18B20 and was chosen as it comes in a waterproof enclosure. The DS18B20 communicates over 1-Wire and a 4.7k pull down resistor is used on the VDD/DQ pins.

Hardware

The hardware is pretty straight forward. Following the schematic along with a bit of hot glue. The connections were made on top of a piece of prototyping board. As this is a one off prototype and won’t be moving around I was not worried about using hot glue or the appearance of the internal circuitry. Yummm hot glue.

Software

The software is easily the most interesting part of this project for myself. The project as a whole really demonstrates that the industry for IoT devices is currently possible with the low cost of the hardware required. However, in a lot of ways we lack the software needed to connect everything together. For this project, the web interface is made of simple HTML, CSS and Javascript. For a quick UI I went with Bootstrap. This provides a clean and responsive interface both for desktop and mobile.

Initially, I wanted to code this simple project using Angular or React, but was worried about packing everything up on the ESP8266’s somewhat limited 512 KiB of storage. So in the end, I went with a more traditional solution of using jQuery for the basic UI switching and GET based communication.

The C/C++ side of things was pretty straight forward as it’s using the ESP8266 library for hosting and routing the HTTP server. The build process consists of using the PlatformIO platform along with a Python script to build and compress the HTML resources into C headers. The LED functions were initially coded by myself, but later I came across “Arduino-RGBEffects”, which I found to be better structured and already had a clean cube/fade effect implemented.

Another great feature of ubidots is the event system. This allows me to set up events for any condition based on the sensor I have installed which, in this case, was the water temperature sensor. Currently, I have a text message alert setup for, if the water temperature reaches an unsafe level of less than 65 °F or greater than 80 °F, I will be alerted via text message.

The World of IoT

While there’s an increasingly large number of IoT implementation and tracking services being released everyday, I chose to go with the ubidots due to it’s easy to use REST API and free tier of 0.5 million sensor updates (dots) per month, with 1 month of historical storage. This allows me to track the water temperature at a conservative rate of every 30 seconds and view the resulting data for the month online from anywhere in the world.

Using this service solved one of my original concerns for this project on how to implement tracking, both efficiently and quickly. Luckily, by using ubidots, I went from a working prototype to having it fully implemented within an hour.

Conclusion

Now that I’m the NSA of fish metadata tracking, I can sit back and think over the project. This was a really fun project and I’m happy to say that I was able to accomplish the original goals I had set out to complete.

The ESP8266 has been a wonderful chip to work with and the community support, taking full advantage of it, has made it a breeze to use. This will most definitely not be the last project I take on using the ESP8266.

In the future, I hope to more closely evaluate using Node JS instead of C/C++ for the main code. Alongside implementing a proper REST API, I hope to also incorporate the MQTT protocol for a more complete IoT device.

Blog: KF-Mario_64 - Map Release

Mon, 14 Mar 2016 11:21:21 +0000

Project Page Steam Workshop

It’s not everyday that I get to sit down and work on something that excites me as much as this project. Over the years I’ve taken great joy in working on video game related projects. When Killing Floor 2 entered Early Access on Steam last year I knew I wanted to finally make a mod for this game.

Screenshots

3D Modeling

The 3D modeling aspect of this project was fairly straight forward. The map is based off of the amazing Peach Castle by mStuff. Most the work myself was optimizing textures, fixing geometry, and simplifying the ground model to work better in the Unreal Engine without having to create collision meshes.

The inside of the castle was ripped from Super Mario 64 using modified debug code I had written for Love364. Most of the work there was fixing vertices and some oddities from development optimizations in the game. The UV Map was completely redone by hand.

The map consists of 116,681 Verts, 89,222 Faces, and 178,422 Tris.

Unreal Engine 3.5

It’s been awhile since I’ve worked with the Unreal Engine, and the first time I’ve used anything newer than Unreal Engine 2, but it’s interface and options over the years are for the most part the same.

Most of this project consisted of working inside of the Unreal Editor. Tweaking, and even more tweaking, pathing was one of the more challenging aspects. The key to any good Killing Floor map is setting up an unseemingly predictable paths with AI spawners behind every corner. Additional work was performed on adding blocking elements to prevent exploitable map spots.

Skybox, global lighting, normal mapping, etc was applied. Currently, Killing Floor 2 doesn’t support custom Materials and instead requires creators to use a limited set of premade Materials via Material Constants. Due to this, a lot of time was not spent trying to improve the lighting beyond simple world settings due to limitations. (All the textures have prebaked shadows and the lack of additional lighting tricks isn’t visual missed)

Steam Workshop

Not much to say about the Steam Workshop, but I did want to talk about it none the less. Starting this project was I unsure of the submission process involved and put it off until the map was completed. I was very surprised to find out that through a simple upload tool provided with the SDK I was able to click a few buttons and it uploaded to Steam. Since then I’ve added screenshots and descriptions. Already in the last few weeks I’ve had amazing feedback. It appears Steam has created a great platform for game content.

Conclusion

At the end of this I must say I’m really happy with how everything turned out. It was a short project, 3-4 days, but seeing other people enjoy something you created is none the less as enjoyable. It was also a great refresher in 3D modeling and the Unreal Engine. Hopefully, in the near future, I will return and either improve this map or create something new entirely. Though I may wait until Tripwire adds proper support for Unreal Materials.

Blog: Reverse Engineering a Bluetooth Enabled Battery Charger

Sat, 30 Jan 2016 02:45:18 +0000

Overview

Through the never ending stream of connected devices on the market we have yet another. Today, I look at and tear into the workings of Efest’s latest product, the Efest LUC BLU6 OLED Intelligent Charger.

The goal of this project is to identify, reverse engineer, and evaluate the safety of this device. Through this process I’ll also be writing a simple interface library in Go as a working exercise in my pursuit to become more efficient in this new programming language.

What You Will Need

Basic Java knowledge
Bluetooth LE compatible computer
Android Development Environment

Analysis

Analysis starts off with looking at companion app. We will be downloading the Android version of the app due the fact that it’s generally easier to disassemble.

After looking at the device on a mobile device, or via running it inside of Android x86 and Virtualbox with Bluetooth passthrough, we can see that it’s very simple app that displays information about each charging slot. (Current voltage, charging current, status, and charging progress chart). Also it has the option to change each charging slots’ charging current.

Now let’s peek inside the app. All Android applications are packaged into an APK file. APK files are simply ZIP archives and can be easily extracted. The easiest way I’ve found to download the application’s APK is to first find the app on the Google Play website, retrive the app id, and use a third party website to download the APK. For example, this app can be found at https://play.google.com/store/apps/details?id=cn.efest&hl=en. Note the id parameter in the url. Now that we have the app id we can use a site such as apkpure.com to download the APK. Once downloaded, extract the APK as a zip.

Once extracted the files should look like the screenshot above. Now the first thing I do is check to see if it’s bundled with any native libs, normally located in a /libs folder if any exist. Luckily in this case there isn’t any. So at this point we can carry on and disassemble the Java code. The easiest and quickest method I’ve found for doing this is a site called http://www.decompileandroid.com/

Great! Now we have the app and the decompiled Java code so let’s start looking around.

MainActivity.java

package cn.efest;
import android.bluetooth.BluetoothAdapter;
import android.bluetooth.BluetoothAdapter.LeScanCallback;
...
public class DeviceScanActivity extends ActionBarActivity {
...
   private void scanLeDevice(boolean enable) {
...
      adapter.startLeScan(this.mLeScanCallback);
...
   }
}

After looking at the MainActivity.java we can see that it’s using the Android Bluetooth API to do a Bluetooth LE, low energy, scan. Knowing this will come in handy when we start playing around with the connection. Now let’s figure out how data is handled.

MainActivity.java

import com.iwit.bluetoothcommunication.util.encodeUtil;
...
public class MainActivity extends ActionBarActivity {
...
    private Pattern mChannelPattern;

    public MainActivity() {
...
        this.mChannelPattern = Pattern.compile("CH(\\d):(\\d),([0-9.]+)V,([0-9]+)mA,([0-9]+)per,(\\d)(\\d)", 2);
...
    }

    private void handleData(byte[] buf) {
        this.notifyString += StringUtil.hexStr2Str(encodeUtil.decodeMessage(buf).toUpperCase());

        /* RE Note: Is the device turning off? */
        if (this.notifyString.contains("AT+OK+SCROFF\r\n")) {
            this.closingOLED = false;
            invalidateOptionsMenu();
            this.notifyString = BuildConfig.FLAVOR;

        /* RE Note: Is this an update? */
        } else if (this.notifyString.contains("\r\n")) {
            String[] arr = this.notifyString.split("\r\n");
            if (arr.length >= REQUEST_ENABLE_BT) {
                parseData(arr[0]);
...
            }
        }
    }

    private void parseData(String data) {
        if (data != null) {
            Matcher m = this.mChannelPattern.matcher(data);
            List<SlotStatus> list = new ArrayList(6);

            while (m.find()) {
                SlotStatus cs = new SlotStatus();
                cs.setName("Slot" + m.group(REQUEST_ENABLE_BT));
                cs.setOrder(Integer.parseInt(m.group(REQUEST_ENABLE_BT)));
                cs.setStatus(Integer.parseInt(m.group(2)));
                cs.setDianYe(m.group(3));
                cs.setDianLiu(Integer.parseInt(m.group(4)));
                cs.setPercent(Integer.parseInt(m.group(5)));
                list.add(cs);
            }
...
        }
    }
}

Even better! Looks like data is handled either of two ways through handleData(), it either notifies the app that the device is turning off or that it has an update which is then passed to parseData() and updates the UI. Now it does looks like it’s calling an internal Java class function encodeUtil. During my research I was unable to find any information on this encoding scheme, but in the end we will just port this function to Go.

encodeUtil.java

package com.iwit.bluetoothcommunication.util;

...
public class encodeUtil {
    public static String decodeMessage(byte[] reciverBytes) {
        int i;
        String decodeData = BuildConfig.FLAVOR;

        int tou = reciverBytes[0];
        reciverBytes[1] = (byte) ((reciverBytes[1] ^ tou) - 1);

        int Onum = tou ^ reciverBytes[2];
        reciverBytes[2] = (byte) Onum;

        for (i = 3; i < reciverBytes.length; i++) {
            reciverBytes[i] = (byte) (reciverBytes[i] ^ Onum);
        }

        for (i = 3; i < reciverBytes.length; i++) {
            int num = reciverBytes[i];
            if (num < 0) {
                num += AccessibilityNodeInfoCompat.ACTION_NEXT_AT_MOVEMENT_GRANULARITY; // ACTION_NEXT_AT_MOVEMENT_GRANULARITY = 256
                reciverBytes[i] = (byte) num;
            }

            String mm = Integer.toHexString(num);
            if (mm.length() == 1) {
                mm = "0" + mm;
            }
            decodeData = new StringBuilder(String.valueOf(decodeData)).append(mm).toString();
        }

        return decodeData;
    }
..
}

We can greatly simplify this function in Go while also rewriting the function to output the string instead of the hex equivalent as does the original function.

efest6bay.go

func decodeMessage(reciverBytes []byte) string {
    var decodeData string

    var oNum byte = reciverBytes[0] ^ reciverBytes[2]
    for i := 3; i < len(reciverBytes); i++ {
        decodeData += string(reciverBytes[i] ^ oNum)
    }

    return decodeData
}

Now that we have the code ported to Go we can test decoding messages with output from gattool. Jared Wolff has written a well written article on using gatttool located here.

(The charger constantly sends updates without having to request data) With the use of gattool and our decodeMessage() function we should be able to decode something like this.

CH1:3,4.20V,0mA,100per,31,CH2:3,4.20V,0mA,100per,21,CH3:3,4.20V,0mA,100per,21,CH4:3,4.20V,0mA,100per,21,CH5:3,4.20V,0mA,100per,21,CH6:3,4.20V,0mA,100per,31

Fantastic, now let’s look at the encode function and do the same.

encodeUtil.java

public static byte[] encodeMessage(byte[] bytes) {
    byte[] encodeByte = new byte[(bytes.length + 3)];

    encodeByte[0] = (byte) 84;
    encodeByte[1] = (byte) bytes.length;
    encodeByte[1] = (byte) (encodeByte[0] ^ (encodeByte[1] + 1));

    int num = (int) (Math.random() * 10.0d);
    encodeByte[2] = (byte) (encodeByte[0] ^ num);

    for (int i = 0; i < bytes.length; i++) {
        encodeByte[i + 3] = (byte) (bytes[i] ^ num);
    }

    for (byte b : encodeByte) {

    }

    return encodeByte;
}

efest6bay.go

func encodeMessage(bytes []byte) []byte {
    encodeByte := make([]byte, len(bytes) + 3)
    encodeByte[0] = 84

    encodeByte[1] = encodeByte[0] ^ byte(len(bytes) + 1)
    num := byte(rand.Int())

    encodeByte[2] = encodeByte[0] ^ num
    for i := 0; i < len(bytes); i++ {

        encodeByte[i + 3] = bytes[i] ^ num

    }

    return encodeByte
}

And there we go! Now we can decode and encode messages to the device. Now there’s two functions left that I haven’t coded in Go yet, the setCurrent() and queryChart(). For these implementations feel free to check the project on my GitHub!

private void setCurrent(int order, int value) {
    SampleGattAttributes.sendMessage(getAppContext().getBluetoothService().getBluetoothGatt(), StringUtil.str2HexStr("AT+CRT" + order + BuildConfig.FLAVOR + value + "\r\n"));
...
}

private void queryChart(int channel) {
    SampleGattAttributes.sendMessage(getAppContext().getBluetoothService().getBluetoothGatt(), StringUtil.str2HexStr("AT+CH" + channel + "+chart\r\n"));
    this.notifyString = BuildConfig.FLAVOR;
}

That pretty much concludes the bases of reverse engineering this charger. Over the new couple of weeks I will be uploading my Go interface library to GitHub. If anything interesting comes out of fuzzing commands to the device I’ll make a new post with all the details!

Blog: XBENext

Tue, 14 Jan 2014 20:13:41 +0000

Blog: <3 Kinect

Sun, 21 Aug 2011 03:14:54 +0000

Unfortunately, it seems that the original images have been lost during recovery of the site.

Blog: Super Mario Wars 3D Anaglyph Rendering Test

Thu, 18 Nov 2010 13:19:27 +0000

Blog: [Release] Super Mario Wars 1.8 Beta 2 Port

Fri, 12 Nov 2010 10:05:15 +0000

What’s this? Another release from LoveMHz?.. Yeah well you know I couldn’t stay gone forever now.. So yeah, this a newer port of the fantastic game Super Mario Wars 1.8 Beta 2. Nothing much to say about besides it’s an amazing game.

New Features: http://72dpiarmy.supersanctuary.net/viewtopic.php?f=1&t=1024