Hacking AutoRCM Implementation by Reisyukaku

  • Thread starter Thread starter CreAtor135
  • Start date Start date
  • Views Views 17,719
  • Replies Replies 93
  • Likes Likes 15
Which leads to my next question. As you seem to be a beacon of knowledge, I will be your student. :) I'm new to this shit and still learning how eveyrthing works. When AutoRCM is released to the public (non-TX version), will we be able to play our Switch games? Right now in it's current iteration, my switch games do not boot while in any CFW.
AutoRCM has already been released. We're using it now.

If you can't boot your games in CFW, then it's not a good idea for you to install AutoRCM right now.

Edit: You should wait for Atmosphere to be released, which you can boot with AutoRCM and play your games with.
 
Last edited by Lacius,
AutoRCM is already released to the public though ? Have you tried the "Boot OFW" option in Hekate to be able to play your games ?
 
AutoRCM has already been released. We're using it now.

If you can't boot your games in CFW, then it's not a good idea for you to install AutoRCM right now.
Oh it has? Neat! I had no idea..lol, thought this was just a "it can be done post" had no idea it was a release as well and working on 5.0x
 
Last edited by ,
AutoRCM is already released to the public though ? Have you tried the "Boot OFW" option in Hekate to be able to play your games ?
Unless I'm mistaken, this still uses an implementation of Atmosphere's boot code to launch Horizon. Until the services are properly rewritten, the official firmware won't function properly.
 
I've not looked into it, but can one of the headers not be corrupt and a payload loaded from there....

For the devs playing with this what happens if not all headers have been corrupted?
I'm guessing you've tried systematically checking different combinations,are any results interesting or a write up of what checks and boots in what order, and what happens at each stage if the checks fail?
 
Given the previous comments in this thread and other of my threads, i think its safe to assume im well respected enough of a dev to where i can just say "trust me" and that should be enough. I mainly work privately on switch after the cancer that was the 3DS scene so you probably wouldnt know me well enough. But if your 3DS runs ReiNAND, ReiSix or Luma you can thank me (^:
ReiSix saved my 3DS. Luma devs did some funky stuff in version 8 and up that cause my 3DS to throw exception handler errors constantly. I gave up on it and installed ReiSix and it's worked flawlessly ever since.

Rei does great work. I trust.
 
  • Like
Reactions: Reisyukaku
ReiSix saved my 3DS. Luma devs did some funky stuff in version 8 and up that cause my 3DS to throw exception handler errors constantly. I gave up on it and installed ReiSix and it's worked flawlessly ever since.

Rei does great work. I trust.
For sure!
 
Working on a getting one of my cheap portable computers to deliver the payload cuz i cant be arsed to write a bare bones USB delivery function on a teensy or FTDI.. (trying on C.H.I.P specifically)


All firms.. since its just using a "corrupt the nand intentionally" technique.
That's great to know. I'm on 4.1.0 but want to update so I can download some games from the eShop before the big storm hits and we're all bricking our systems.
 
Last edited by Clutchman,
Last edited by Don Jon,
AutoRCM is already released to the public though ? Have you tried the "Boot OFW" option in Hekate to be able to play your games ?

In my experience, even when launching stock firmware in hekate, it still freezes when going into sleep mode. I would love to leave AutoRCM installed, but I can't figure out a safe way to charge my Switch with it without risking battery de-sync or lcd burn-in.
 
Lcd burn in? That's the first time I've heard about this when using hekate. May I ask, burn in from what exactly? The only possible burn in I can think of is when we're backing up rawnand since it displays a bright white text for a very long time.

Ps. Sorry for my lack of info.

Sent from my SM-G950F using Tapatalk
 
So..please correct me if I'm wrong. There's absolutely no point on staying on old firmware anymore is there?
Superb discovery, my hat's off to you!

Ok, so I've seen a lot of people with this thought.

Firmware has never mattered once Fusee Gelee was released. Being on 4.1 or lower (IIRC) means that instead of having to connect to your computer to boot into atmosphere, you will be able to use an autoRCM type method to load atmosphere automatically.

So being on as low as possible firmware means you will have a truly untethered boot.

If you don't care or want to use the SX Pro dongle every time or your computer or raspberry pi, then go right ahead there's really no issue now that sleep mode works.

If I'm being honest, then hell yeah update if you want. I'm sticking on 4.0.1 as that means I can have easier Atmosphere loading, but that's because I'm lazy >.<.


You quoted the wrong person bro.

However, to answer your question anyway:

Using a hardware modchip that auto-injects the RCM payload on power-on would allow cold-boot on any firmware.
However, for the solderingly impaired (like myself), keeping the old firmware for Deja-vu, and using emunand would be desirable also.

It depends on what you want to do, and why.

This 1000x.
 
Last edited by saneatsu,

Site & Scene News

Popular threads in this forum