Fixing an NZXT Signal 4K30 part 2: the green/pink video bug

Recorded: Sept. 15, 2026, 6:01 p.m.

Original

Summarized

Downtown Doug Brown » Fixing an NZXT Signal 4K30 part 2: the green/pink video bug

Downtown Doug Brown
Thoughts from a combined Apple/Linux/Windows geek.

Home
About
Mac ROM SIMMs
Software
Microcontroller lessons
Contact

Sep
13

Fixing an NZXT Signal 4K30 part 2: the green/pink video bug

Doug Brown
AI, Bug fixes, Reverse engineering
2026-09-13

Last year, I repaired an NZXT Signal 4K30 USB capture device that I bought on eBay for cheap. It was completely dead, and the cause turned out to be a bad solder joint on an inductor, which prevented power from getting to a crucial part of the board.
After I fixed it, I tried using it to capture signals from a bunch of different HDMI source devices to make sure it worked correctly. As I said in my last post about it:

I did find one 720p60 HDMI source that it doesn’t like — the captured video shows up as pink and green.

In that post, I also pointed to a few Reddit threads (1, 2) where similar issues had been observed on a PS5 and Nintendo Switch, respectively.
Here’s a snapshot of what captured video looked like from the one HDMI source that it didn’t like:

You can see that the colors are green and purple. They’re completely wrong. I knew from past experience with video encoders and decoders that this is very typical behavior if you have a mismatch between RGB and YUV video. I doubted it was faulty hardware, especially since other people on Reddit had seen the exact same symptom.
I left it at that. I didn’t care that this one device wouldn’t capture correctly, and I didn’t bother contacting NZXT about it. I’ve noticed that since then, the device seems to have completely disappeared from the market. You can’t buy it on Amazon or Newegg anymore, and NZXT’s website doesn’t mention it anywhere except under support. It’s pretty clear that NZXT exited the capture card market. If I contacted them now, I’d be shocked if they could do anything about it.
Last night, a thought randomly jumped into my mind. I’ve been using Claude to do some pretty in-depth reverse engineering and bug investigations lately. For example, here’s a reverse-engineered Linux kernel V4L2 driver for the Elgato Game Capture HD60 S that I investigated in depth a couple of years ago. What if I had it look into this problem? It would be a nice way to completely finish off the first post where I repaired the hardware problem. Together, could we fix the final issue, which I assumed was a firmware problem?
During the hardware repair, I had already documented all of the different components used in the device, so I gave that all to Claude, along with a description of the problem, pictures of the issue from the Reddit posts, NZXT’s last firmware update for the device released in 2022, and a checkout of a GitHub repository containing ITE’s driver for the IT6805 HDMI receiver IC used by the Signal 4K30. I also pointed out that I suspected it was some kind of RGB vs. YUV mismatch because I’ve seen this happen in the past when developing firmware for video devices.
15 minutes or so later, Claude got back to me with results. It agreed that it was a YUV vs. RGB mismatch issue. It pointed out what it thought were a few bugs in the firmware that looked promising. To be sure, it asked me to verify a few things about the detected signal. It told me that the Cortex-M0 microcontroller has a UART with debug output. I found the unmarked debug header on the PCB, figured out which pin was the TX pin (and the baud rate) with my portable oscilloscope, captured its output with the problematic HDMI source device attached, and pasted it back. I also used my reverse-engineered Game Capture HD60 S Linux driver listed above to provide more details about what type of signal the problematic source was outputting.
The source device was outputting in DVI mode instead of HDMI mode. This was a major clue. DVI mode means it doesn’t have some of the extra packets that are included with newer HDMI sources, such as AVI InfoFrames.
Claude pinpointed a section of code in ITE’s stock IT6805 driver that looked wrong, and confirmed this code was also present in NZXT’s firmware. Here’s a trimmed-down snippet:

// REG6B[5:4]: Reg_ColMod_Set Input color mode set 00: RGB mode - 01: YUV422 mode, 10: YUV444 mode, 11: YUV420 mode
chgbank(0);
if (iTE6805_Check_HDMI_OR_DVI_Mode(iTE6805_DATA.CurrentPort) == MODE_HDMI)
{
HDMIRX_DEBUG_PRINT(("---- CSC HDMI mode ----\n"));
...
hdmirxset(0x6B, 0x30, iTE6805_DATA.AVIInfoFrame_Input_ColorFormat << 4);// seting input format by info frame ??? do not need ???
...
}
else
{
...
HDMIRX_DEBUG_PRINT(("---- CSC DVI mode ----\n"));
hdmirxset(0x6B, 0x30, 0x10); // seting input format to RGB
...
}

This code is figuring out whether the IT6805 has detected an HDMI or DVI signal, and configuring various registers based on that result. One such register tells the IT6805 how to decode the incoming video signal. If it’s an HDMI signal, it grabs the color mode directly from the AVI InfoFrame and puts it into bits 4 and 5 of register 0x6B.
On the other hand, if it’s a DVI signal, it knows that the video signal has to be RGB, so it tries to configure those same bits in register 0x6B for RGB mode.
Except…the code is wrong. The comment correctly says it should be configured for RGB in this case (“seting input format to RGB”) but what it actually does is write 01 to bits 5:4, which means YUV 4:2:2 mode according to the comment at the top.
I can’t speak for certain, but I think I see the mistake the original ITE developer made. When my eyes first jump to the comment for RGB mode, what sticks out in my mind is “RGB mode – 01”. But that’s my brain parsing the comment incorrectly. What it really says is “00: RGB mode”. I think the fact that the comment only uses that one hyphen and then uses commas for everything else throws me off. I wouldn’t be surprised if the original developer made the same kind of parsing error in their brain.
Okay, so I now had a theory. How could I test it? The debug UART unfortunately didn’t provide a way to read or write the IT6805’s registers, or I could have easily tested it out.
In exchange for a fun story and the potential to be able to release this fix for everyone, I was willing to risk bricking my device. Claude was very hesitant about this and wanted me to try accessing the MCU through SWD to back up its firmware first, but I decided to just full send it. I’ll bet the chip was locked anyway. I had Claude reverse engineer the NZXT firmware updater utility to figure out how it works, and also figure out if it would be safe to simply patch the firmware to change it to write 00 rather than 01 to those bits in register 0x6B. I was particularly worried about changing a checksum or CRC in the firmware image, but Claude was pretty sure the MCU firmware was not checksummed in any way. It fixed the bug in ITE’s driver by patching a single byte in the NZXT firmware to change a movs r2, #16 instruction to movs r2, #0.
Claude also gave me back a command-line utility that reflashes the firmware using the DLL included with NZXT’s updater. I couldn’t just use NZXT’s stock utility because it refuses to install a firmware update file if it thinks the device is already up to date.
Despite the potential that I could render my capture card completely inoperable, I decided to run the updater. It went through the whole update process, which ended looking like this:

I power cycled the capture card as the instructions told me to, and then opened up OBS to see if the behavior changed at all.
To my relief, it all still worked after the update, and even better, the bug was gone! The colors looked perfect when capturing my DVI source device.

That was definitely the bug. It’s actually a bug in ITE’s driver, so it probably affects lots of devices that just drop in this vendor code without actually testing it against a bunch of different HDMI sources and sinks.
In my case, the source device I’m using doesn’t provide InfoFrames at all, so an HDMI sink device encountering a signal without InfoFrames is supposed to assume the data is RGB. As for other people’s situations, they could hit this same problem even with a modern HDMI source device if they have an old DVI monitor attached to the passthrough port whose EDID doesn’t support HDMI mode for whatever reason.
It’s very possible that the PS5 and Switch in the Reddit posts were encountering a completely different problem that happened to have the same symptom. All I know is Claude’s bug fix actually worked for me, and now I can use this capture card to capture this particular sink device with perfect, vibrant colors!
In case it is useful for someone else in the future with the same discontinued NZXT Signal 4K30 capture card, I’m providing the firmware bug fix to the community. Here’s my GitHub repository for it, along with installation instructions: https://github.com/dougg3/nzxt-signal-4k30-color-bug-firmware-patch/
My mind is still pretty blown away by how good Claude has become at hunting for bugs and reverse engineering firmware. I didn’t run into any problems during this particular analysis, but I will say that sometimes I run into Claude’s cybersecurity guardrails when trying to track down issues. I understand why these safeguards are in place, but it can be frustrating at times. I’m not officially a cybersecurity professional, so I’m not sure if it would be worth even trying to apply to their Cyber Verification Program. But I think there are times when reverse engineering and even local hardware-in-hand exploits have legitimate non-nefarious purposes, like being able to replace a sketchy device’s buggy closed firmware with an alternative, improved open-source firmware. I wish there was a way as a hobbyist to communicate that intent to Anthropic without being hit with the guardrails!
Anyway, I didn’t run into that problem at all on this project. I would say that overall, this fix was a complete success! I tested it out with several HDMI source devices after patching the firmware, and now they all work great. It feels great to fully close the book on my Signal 4K30 repair story.
By the way, the sample picture I used for showing the color problem came from the Kodak Lossless True Color Image Suite. And yes, it was a direct capture from the 4K30 before and after the firmware fix!

Address: https://www.downtowndougbrown.com/2026/09/fixing-an-nzxt-signal-4k30-part-2-the-green-pink-video-bug/

« Fixing an eMachines EL1200 BIOS bug with Claude

Trackbackno comments

Add your comment now

Name (required)

Email (Will NOT be published) (required)

URL

Archives

September 2026 (1)
August 2026 (1)
December 2025 (1)
November 2025 (1)
August 2025 (1)
June 2025 (2)
May 2025 (2)
March 2025 (2)
January 2025 (2)
December 2024 (1)
November 2024 (1)
October 2024 (2)
September 2024 (1)
August 2024 (1)
July 2024 (3)
June 2024 (4)
May 2024 (1)
April 2024 (2)
December 2023 (1)
November 2023 (2)
September 2023 (3)
August 2023 (3)
June 2023 (1)
May 2023 (1)
April 2023 (1)
March 2023 (2)
January 2023 (1)
December 2022 (3)
August 2022 (1)
May 2022 (2)
March 2022 (1)
December 2021 (1)
June 2021 (1)
April 2021 (1)
January 2021 (1)
September 2020 (1)
August 2020 (1)
July 2020 (1)
May 2020 (1)
June 2019 (1)
April 2019 (1)
December 2018 (1)
August 2018 (1)
May 2018 (1)
April 2018 (3)
February 2018 (1)
October 2017 (1)
July 2017 (1)
May 2017 (3)
March 2017 (1)
October 2016 (1)
June 2015 (1)
March 2015 (1)
November 2014 (1)
August 2014 (3)
July 2014 (1)
April 2014 (1)
March 2014 (1)
February 2014 (1)
November 2013 (1)
August 2013 (1)
June 2013 (3)
April 2013 (1)
March 2013 (1)
January 2013 (2)
December 2012 (2)
August 2012 (1)
July 2012 (2)
June 2012 (1)
May 2012 (1)
February 2012 (3)
January 2012 (1)
November 2011 (1)
October 2011 (2)
August 2011 (3)
May 2011 (1)
April 2011 (1)
March 2011 (2)
November 2010 (2)
October 2010 (3)
July 2010 (5)

Recent Comments
Doug Brown on Adventures of putting 16 GB of RAM in a motherboard that doesn’t support itDoug Brown on A small update on my Windows 10 upload speed problemChris on A small update on my Windows 10 upload speed problemDoug Brown on Repairing a Microsoft IntelliMouse Explorer 4.0knick knack on Fixing a knockoff Altera USB Blaster that never workedAlex on Modifying an HDMI dummy plug’s EDID using a Raspberry PiMichael Tsai - Blog - Mac Easter Eggs on Finding a 27-year-old easter egg in the Power Mac G3 ROMJeff Walther (Trag) on Revisiting programmable Mac ROM SIMMs in QuadrasNick on How I fixed the infamous Basilisk II Windows “Black Screen” bug in 2013SteveD on More fun with Apple’s internal tools: creating a PDS card
Spam Blocked

356,183 spam blocked by Akismet (opens in a new tab)

Downtown Doug Brown · coogee theme · 2008 · Privacy Policy

RSS Feed · WordPress · TOP

A detailed analysis of the issues encountered while repairing an NZXT Signal 4K30 USB capture device reveals a complex interaction between hardware soldering issues, video encoding protocols, and firmware logic. The initial repair involved fixing a bad solder joint on an inductor that was preventing power delivery to a critical board component. However, after the hardware was functional, the user encountered a persistent video bug where signals from certain HDMI sources appeared distorted in green and pink, suggesting a fundamental mismatch between the video color space and the device's output configuration. This observation led the user to suspect a theoretical discrepancy between RGB and YUV video formats, supported by external reports from online communities regarding similar issues with other devices.

Further investigation involved reverse engineering the device's firmware and associated drivers to pinpoint the software cause of the visual error. The process utilized external assistance for in-depth bug investigation, where the user provided details regarding the hardware components, the reported symptom, and relevant firmware versions. This led to the conclusion that the problem resided in the interaction between the ITE6805 driver, which handles HDMI and DVI modes, and the device's firmware. The user determined that the HDMI source in question was outputting a DVI signal format instead of the expected HDMI format, which lacked necessary informational packets, leading the signal processing to misinterpret the color data as YUV 4:2:2 mode when expecting RGB.

Through detailed reverse engineering and analysis, the user identified a specific logical error within the ITE6805 driver code contained within the NZXT firmware. The analysis exposed that the code incorrectly handled the conditional logic for setting color modes based on the detected port mode, failing to properly configure the necessary registers when DVI mode was detected. This flaw resulted in the system erroneously setting color mode bits to indicate YUV 4:2:2 mode instead of the required RGB mode for DVI input. This error was rooted in an incorrect interpretation of comments within the original driver code, which the user noted was likely a source of developer error.

To rectify this systemic issue, the user devised a patch targeting a specific instruction within the NZXT firmware. The objective was to modify the instruction that caused the erroneous register write to ensure the correct RGB configuration was applied, rather than the incorrectly calculated YUV setting. The fix involved patching a single byte in the firmware to alter a specific machine instruction, which was determined to resolve the misalignment in the driver’s execution path.

The implemented firmware patch was tested by power cycling the capture card and observing the input from various HDMI source devices. The results confirmed that the bug was successfully eliminated, allowing the device to correctly handle signal formats from multiple sources with accurate color reproduction. This successful remediation indicated that the root cause was not solely a hardware defect but a bug embedded within the vendor-specific driver implementation, which could potentially affect other devices lacking rigorous testing against diverse video inputs. The experience underscored the value of reverse engineering in troubleshooting complex embedded systems and the potential for software-based fixes in hardware-related anomalies.