We did that Nintenwont

[qzxcvbn]

I posted that we have developed a fix for the RCM exploit for the Tegra X1 V1 switches, Just to update you Nintendo said "Out Of Scope", that shocked me. A company that screams piracy at anyone, chose not to stop piracy on that model. We also showed them a proof of concept for the Switch 2, again "Out of scope". It seems Nintendo needs piracy more than it needs to secure its devices.

 

[masagrator]

Mod asked for proof and you still don't provide one.

Can we ban this guy?

 

[qzxcvbn]

Mod asked for proof and you still don't provide one.

Can we ban this guy?

Proof of? Proof Nintendo said no, Proof of the fix, Proof of the code, Proof of the method? What proof, If anyone you read my original post it tells you what the fix does!

 

[AllOver]

Bruh

 

[The_Chaotician]

Proof of? Proof Nintendo said no, Proof of the fix, Proof of the code, Proof of the method? What proof, If anyone you read my original post it tells you what the fix does!

All of the above as a bare minimum if you ever want to be taken seriously by a site like this.

Put simply, claims ≠ proof. I'd put money on the fact this thread will be nuked by the end of today without any.

 

[InsaneNutter]

I posted that we have developed a fix for the RCM exploit for the Tegra X1 V1 switches

This is why what you are doing is a problem.

 

[AmandaRose]

I posted that we have developed a fix for the RCM exploit for the Tegra X1 V1 switches, Just to update you Nintendo said "Out Of Scope", that shocked me. A company that screams piracy at anyone, chose not to stop piracy on that model. We also showed them a proof of concept for the Switch 2, again "Out of scope". It seems Nintendo needs piracy more than it needs to secure its devices.

Ok so in your previous thread that was shut down you claimed to have shown all of your findings to the top security experts (your words) for the Switch.

I will ask you the exact same question you never answered in the previous thread.

Name these experts because once again I will remind you that myself and a number of others on this site are friends with them so go ahead give me the names of the experts you have discussed this with. I look forward to your answer because the only way I will believe your bullshit is by seeing the names and then talking to the people you have allegedly discussed this with.

Thank You

 

[plasma]

I posted that we have developed a fix for the RCM exploit for the Tegra X1 V1 switches, Just to update you Nintendo said "Out Of Scope", that shocked me. A company that screams piracy at anyone, chose not to stop piracy on that model. We also showed them a proof of concept for the Switch 2, again "Out of scope". It seems Nintendo needs piracy more than it needs to secure its devices.

yeah and i have a nintendo switch 3 (ns2 is old news) that is hacked and full of warez but i wont show it because i want internet points and reddit karma

 

[Jayro]

@Flame You're gonna need to lock this useless thread too, as he's still provided no proof.

 

[YoureALoser]

I posted that we have developed a fix for the RCM exploit for the Tegra X1 V1 switches, Just to update you Nintendo said "Out Of Scope", that shocked me. A company that screams piracy at anyone, chose not to stop piracy on that model. We also showed them a proof of concept for the Switch 2, again "Out of scope". It seems Nintendo needs piracy more than it needs to secure its devices.

If there were a fix for the rcm exploit, Nvidia themselves would have fixed it, & trust me when I say this, they are far smarter than you will ever be.

 

[qzxcvbn]

OK, this post is not about the switch or the fix, iThis is the sanitized version we sent to Nintendo "

Technical Analysis: Firmware-Level Mitigation for Tegra X1 RCM Exploitation (CVE-2018-6247)​

1. Abstract​

The Fusée Gelée vulnerability (CVE-2018-6247) allows for arbitrary code execution in the Tegra X1 BootROM by exploiting a race condition in the USB control request handling. Due to the immutable nature of the BootROM, this vulnerability remains an unpatchable attack vector for millions of deployed units. This report proposes a firmware-deployable architectural mitigation that shifts the security boundary from the compromised BootROM to a presence-based authentication mechanism implemented in the eMMC-based boot chain.

2. Threat Model & Context​

• Target Asset: Nintendo Switch Tegra X1 (Pre-July 2018 Revision).
• Vulnerability: BootROM race condition (USB control request, RCM mode).
• Attack Vector: Exploitation occurs before the secondary bootloader (BCT/Bootloader) is initialized.
• Current State: Persistent exploitability in the boot chain allows for arbitrary payload injection.

3. Proposed Mitigation: Presence-Based State Validation​

The core of this proposal involves intercepting the boot flow immediately post-BootROM execution, effectively creating an "authenticated boot" barrier using existing hardware state vectors.

3.1 Mechanism Overview​

The proposed solution does not attempt to "fix" the BootROM race condition. Instead, it assumes the BootROM is compromised and implements a Post-Exploit Validation (PEV) layer within the firmware update chain.

3.2 Technical Implementation Path​

1. State Vector Analysis: During the early boot stage, the firmware intercepts key hardware signals (e.g., power management status, specific GPIO triggers, and wake-source interrupts).
2. Cryptographic Handshake: A volatile-memory-resident handshake is initiated between the hardware state vectors and an eMMC-signed module.
3. Millisecond-Window Authentication: Encryption keys required for the next stage of the boot chain are generated in volatile memory (SRAM) for a window measured in milliseconds. If the state vector analysis detects an unauthorized RCM-mode entry context, the keys are wiped, causing a controlled boot-time failure rather than payload execution.

3.3 Security Impact​

• Attack Surface Reduction: By requiring a presence-based state vector check, an attacker would need to not only trigger the RCM race condition but also simultaneously spoof the physical hardware state to complete the cryptographic handshake.
• Persistence: The solution uses standard Nintendo update infrastructure, allowing for a seamless deployment without hardware revisions.

4. Conclusion​

While the Fusée Gelée vulnerability is a fundamental silicon-level flaw, the "unpatchable" narrative is an architectural limitation, not an immutable reality. The transition to a presence-based authentication model effectively moves the chain of trust to a firmware-controlled layer, neutralizing the exploit’s effectiveness."

 

[AmandaRose]

OK, this post is not about the switch or the fix, iThis is the sanitized version we sent to Nintendo "

Technical Analysis: Firmware-Level Mitigation for Tegra X1 RCM Exploitation (CVE-2018-6247)​

1. Abstract​

The Fusée Gelée vulnerability (CVE-2018-6247) allows for arbitrary code execution in the Tegra X1 BootROM by exploiting a race condition in the USB control request handling. Due to the immutable nature of the BootROM, this vulnerability remains an unpatchable attack vector for millions of deployed units. This report proposes a firmware-deployable architectural mitigation that shifts the security boundary from the compromised BootROM to a presence-based authentication mechanism implemented in the eMMC-based boot chain.

2. Threat Model & Context​

• Target Asset: Nintendo Switch Tegra X1 (Pre-July 2018 Revision).
• Vulnerability: BootROM race condition (USB control request, RCM mode).
• Attack Vector: Exploitation occurs before the secondary bootloader (BCT/Bootloader) is initialized.
• Current State: Persistent exploitability in the boot chain allows for arbitrary payload injection.

3. Proposed Mitigation: Presence-Based State Validation​

The core of this proposal involves intercepting the boot flow immediately post-BootROM execution, effectively creating an "authenticated boot" barrier using existing hardware state vectors.

3.1 Mechanism Overview​

The proposed solution does not attempt to "fix" the BootROM race condition. Instead, it assumes the BootROM is compromised and implements a Post-Exploit Validation (PEV) layer within the firmware update chain.

3.2 Technical Implementation Path​

1. State Vector Analysis: During the early boot stage, the firmware intercepts key hardware signals (e.g., power management status, specific GPIO triggers, and wake-source interrupts).
2. Cryptographic Handshake: A volatile-memory-resident handshake is initiated between the hardware state vectors and an eMMC-signed module.
3. Millisecond-Window Authentication: Encryption keys required for the next stage of the boot chain are generated in volatile memory (SRAM) for a window measured in milliseconds. If the state vector analysis detects an unauthorized RCM-mode entry context, the keys are wiped, causing a controlled boot-time failure rather than payload execution.

3.3 Security Impact​

• Attack Surface Reduction: By requiring a presence-based state vector check, an attacker would need to not only trigger the RCM race condition but also simultaneously spoof the physical hardware state to complete the cryptographic handshake.
• Persistence: The solution uses standard Nintendo update infrastructure, allowing for a seamless deployment without hardware revisions.

4. Conclusion​

While the Fusée Gelée vulnerability is a fundamental silicon-level flaw, the "unpatchable" narrative is an architectural limitation, not an immutable reality. The transition to a presence-based authentication model effectively moves the chain of trust to a firmware-controlled layer, neutralizing the exploit’s effectiveness."

You still haven't answered my question

 

[jceggbert5]

Dude, your document reads like you dumped a ChatGPT response into a PDF.

 

[masagrator]

The core of this proposal involves intercepting the boot flow immediately post-BootROM execution, effectively creating an "authenticated boot" barrier using existing hardware state vectors.

Guy doesn't understand that Nintendo tried doing post authentication MANY TIMES and every time it was mitigated. That's why they gave up.

Dude is 6 years behind

Also since it was AI generated, here is my AI review:

While the text is technically literate and uses accurate terminology regarding the Tegra X1 and CVE-2018-6247, it bears several hallmarks of a sophisticated Large Language Model (LLM) at work.
Here is a breakdown of why this reads like an AI "hallucination" of a technical whitepaper:
1. The "Perfect" Structural Template
The text follows a classic academic/technical report structure (Abstract → Threat Model → Mechanism → Impact → Conclusion) that AI models default to when asked for a "formal analysis." Humans usually write with a bit more stylistic friction or specific intent, whereas this is very "by the book."

2. The Logic Gap (The "Giveaway")
The technical proposal actually contains a fundamental logical flaw that a hardware security researcher likely wouldn't make:
The Exploit: Fusée Gelée exploits the BootROM before it checks the eMMC (internal storage).
The Flaw: The text suggests mitigating this by using an "eMMC-based boot chain" to validate the state.
The Reality: If an attacker has already exploited the BootROM to run their own code (the "payload"), they have already bypassed the hardware's ability to trust anything coming from the eMMC. You can’t use a later stage of the boot process to "police" an earlier stage that has already been compromised.

3. "Technobabble" Phrasing
AI is excellent at stringing together high-level concepts that sound authoritative but are slightly redundant. Phrases like "volatile-memory-resident handshake" and "presence-based state validation" are "flavor text"—they sound impressive but don't describe a standard or practical engineering workflow for this specific hardware vulnerability.

Btw. if you send file with "Nentendo" in file name no wonder they ignored you

 

[linuxares]

Magic word here is WINDOWS. Closing. Post proof of concept or just don't bring it up over and over.