D
Deleted User
Guest
what does it need the camera for?Looking into it. Btw, if you like crashing GM9, I have something for you. Will require a good smartphone camera, though.
https://transfer.sh/iGKTg/GodMode9.firm
what does it need the camera for?Looking into it. Btw, if you like crashing GM9, I have something for you. Will require a good smartphone camera, though.
https://transfer.sh/iGKTg/GodMode9.firm
nice! battery indicatorTest crashing with it, maybe? Don't worry, nothing bad will happen.
That's weird, it should display a register, stack and code dump. Works fine on my system (O3DS) + phone (XiaoMi Redmi 4X) combonice! battery indicator
also I got the qrcode
dont have time to scan it rnView attachment 99340
Edit: scanned and it took me to an invalid googleplay app
so it shoild just display the contents of the exception dumps?That's weird, it should display a register, stack and code dump. Works fine on my system (O3DS) + phone (XiaoMi Redmi 4X) combo
Your phone is probably trying to make you download an app to scan the QR code properly. Try scanning any other qr code, if it takes you to the same gplay link it's an issue with your phone.so it shoild just display the contents of the exception dumps?
I wonder why it takes me to google play
ill try that laterYour phone is probably trying to make you download an app to scan the QR code properly. Try scanning any other qr code, if it takes you to the same gplay link it's an issue with your phone.
Not only for websites, actually for anything. Text up to and beyound 1000 chars is supported.So we can display QR codes for websites now. This is a cool trick. I'm not sure how useful it will be, but I like it. Somehow, seeing this conjured up a very comical (and admittedly unlikely) concept in my mind of kids showing Santa their wish list in .gm9 format this year -- "I want this, and this, and, Santa, you have to scan them with your phone or you won't know what I want!"
Do you want to make the commit yourself, @Kazuma77 ? I'd just make a few minor changes to those scripts after the pull request. I'm also a little unsure if I want to keep full restore script for SysNAND, and I still have some concerns cause a 'safe' restore can actually brick for an unhaxed console (and you don't check hax here).I see. Since it won't fail, I'll redo them and upload new versions.
EDIT: OK, here they are. I left the verify line commented out in the regular EmuNAND and Safe SysNAND varitants, and include my reasons in the comments. In the case of EmuNAND, it is neither vital to the system nor does it even use it's firm partitions. In the case of a safe SysNAND restore, the firm partitions are not being touched, so, it hurts nothing to let someone try restoring a bricked NAND. Maybe it's just the firm partitions that are bad, after all. If it doesn't work, they can try again with a good backup. The full one remains pretty much the same, though I changed the warning to mention not using EmuNAND images (because it just recently hit me, those will verify even if their firm partitions contain an outdated NF that doesn't match CTRNAND's, but any attempt to prevent this makes it not a full restore), and the forced full one is gone, since the full one already did what I intended to enable (I just didn't know it). I did disable the preview on them all, and all of my scripts for that matter. I think it's great for troubleshooting things I'm still working on, but might be TMI for end users. Feel free to make any changes you like (if you even decide to use them).
Do you want to make the commit yourself, @Kazuma77 ? I'd just make a few minor changes to those scripts after the pull request. I'm also a little unsure if I want to keep full restore script for SysNAND, and I still have some concerns cause a 'safe' restore can actually brick for an unhaxed console (and you don't check hax here).
@Kazuma77 - the new chk command should be pretty helpful in making your restore scripts a little safer. If you add the respective checks, I'll add the scripts to GM9.
OK, that will definitely help to make sure there's an appropriate exploit when doing a safe restore. Now if there was just a way to look for NF mismatch when a NAND image is retail (and preferably automatically fix it -- updating a GW EmuNAND's firms should not have any negative effects). Or even just a way to check for retail (I could say "use the retail script" on the error and have that one extract the CTRNAND copy). If such things as 9.2 EmuNANDs with 4.5 firm partitions could be removed from the equation, the full restore process would be completely safe.
For the console running from, you can just do chk $[RDTYPE] "retail". For NAND backups - no proper way, but you honestly shouldn't care. If you try to restore a retail backup on a devkit or vice versa, the verification will fail anyways, cause the NAND backup will be not from the same console .
HOME button -> more -> set RTC clockthe date and time from Godmode9 is not match with my 3ds system..How do I set up the time ?
Oh, now I understand what you want to do. Not a bad idea! You can just pull the NATIVE_FIRM out of the NCCH. Mount the NCCH, then copy it, also see here.So the RDTYPE would be more for, say, double checking when installing an exploit like B9S. Well, I highly doubt anyone with a dev kit is going to be using my AIO pack anyway.
My desire to check for whether a NAND is retail (maybe I should say OFW) has nothing to do with that though. I would ultimately like the "full" script to become a "full exploit" script and have a "full retail" script alongside it. I basically want the former to reject any OFW NAND dump, so that I can have people run the latter, which will use the NF in CTRNAND and completely ignore the FIRM partitions. This would prevent an EmuNAND updated with old versions of Gateway (which used to protect EmuNAND's firm partitions) from bricking a device. For example, I once bricked a device by restoring an EmuNAND dump that had 9.2 on CTRNAND (but it had 4.5 on the FIRM partitions, so I ended up having to dig out the soldering iron).
But if that just isn't possible/feasible, then it is as safe as it can get, I think.
I would ultimately like the "full" script to become a "full exploit" script and have a "full retail" script alongside it. I basically want the former to reject any OFW NAND dump, so that I can have people run the latter, which will use the NF in CTRNAND and completely ignore the FIRM partitions.
HOME button -> more -> set RTC clock
Oh, now I understand what you want to do. Not a bad idea! You can just pull the NATIVE_FIRM out of the NCCH. Mount the NCCH, then copy it, also see here.
Or, do I? Unsure . What would these two script do different?
Okay, @Kazuma77 - I looked over your restore scripts and changed a few things. My changes are mainly to reduce strings sizes (I want to keep compatibility with the legacy font) and to improve the formatting (more empty lines). I also reenabled the scripting preview cause processing speed should not be a concern here and I want a unified look to these scripts.
Now, as for the relevant stuff:
Can you review my changes and tell me what you think? If you're okay with them, we can add those scripts to GM9. Also, I don't have my console available for testing rn. I did pay attention in my edits, but, can you maybe do a test run on each?
- Safe restore (SysNAND): Disabled on ntrboot now (cause no defined state of the system). I also changed it so that 'allow' and 'find' is called for the three relevant partitions.
- Full restore (SysNAND): I toned down on the warnings a bit. This only runs from ntrboot now, so that should be okay.
- Full restore (both): I used 'inject' instead of 'cp'. Why? Because there may be cases where a NAND is totally borked, and in those the 'nand_minisize.bin' file is not available. 'nand.bin', on the other hand, is always available. So, this makes this scripts work in more use cases.
There's not really a way to ensure a NAND backup has a (working!) exploit installed. I personally think it would be better to have a separate exploit uninstaller, anyways. There's a script for exploit uninstallation written by me somewhere on the web (can't even find it myself right now). Additionally to fixing the NATIVE_FIRM, you'd have to fix the secret sector.Basically the "full with exploit" would be the true full restore because the NAND image has an exploit installed. And the "full with retail" (or "full with OFW") one would pull the NF from the NCCH, as you said, to bypass the aforementioned problem with some GW EmuNAND backups.
It's about the target audience for these scripts. Someone who knows their way around the 3DS and GM9 will have an easy time fixing anything from ntrboot. Someone who has not... will perhaps run this script (cause, who doesn't want "safe"?) and be surprised by the results.I'm fine with most of the changes. However, I'm confused as to why you would disable safe restore with "ntrboot" though. It's true that you don't know the state of the system. Still, if they're using NTRBootHax, well, if they brick it, they can fix it, right? So there's no need for such concern.