|
| ||
| Views: 1,882,411 | Main | Rules/FAQ | Memberlist | Active users | Last posts | Calendar | Stats | Online users | Search | 04-03-25 02:38 AM |
| Guest: | ||
| Main - Posts by dark_samus |
| dark_samus |
| ||
|
Newcomer Normal user Level: 7 Posts: 1/8 EXP: 1356 Next: 92 Since: 06-02-15 Last post: 3128 days ago Last view: 2929 days ago |
Keep up the good work on this, chrono trigger finally starts and plays up until the court scene and then the screen goes black when the cutscene is over and it hangs.... Also the few super metroid hacks I've tried have issues where they hang at either a black screen or other places, but still awesome work can't wait until I can play all of my snes games  |
| dark_samus |
| ||
|
Newcomer Normal user Level: 7 Posts: 2/8 EXP: 1356 Next: 92 Since: 06-02-15 Last post: 3128 days ago Last view: 2929 days ago |
I'd say most likely that this is a hardware issue.... isn't the NFC module disconnectable from the motherboard? If so it's likely that there is a connection issue and something happens (you bump the unit or move it in a certain way) that causes the connection to break again and causing the random intermittent issues... |
| dark_samus |
| ||
|
Newcomer Normal user Level: 7 Posts: 3/8 EXP: 1356 Next: 92 Since: 06-02-15 Last post: 3128 days ago Last view: 2929 days ago |
9.8 doesn't have a way to run the homebrew launcher yet... |
| dark_samus |
| ||
|
Newcomer Normal user Level: 7 Posts: 4/8 EXP: 1356 Next: 92 Since: 06-02-15 Last post: 3128 days ago Last view: 2929 days ago |
Posted by 54634564 The main "moral" dilemma is that some nasty stuff can be done with those files (like bricking a console) ofc this can be done with other methods but it's much easier to do it this way (though in argument to that it would be MUCH easier to just put a blank file there which can already be done so...) |
| dark_samus |
| ||
|
Newcomer Normal user Level: 7 Posts: 5/8 EXP: 1356 Next: 92 Since: 06-02-15 Last post: 3128 days ago Last view: 2929 days ago |
Posting this thread here, just because I felt it might be a good place for discussion
me and few others have been working on getting this working, I figured maybe with an information dump I might get people interested What is it: As suggested by the title, we're trying to completely rebuild a new NAND image from "scratch." It will most likely never be 100% from scratch, but it'll at least get you back to a functioning console even if you've completely 100% zeroed out your NAND, lost all your NAND backups and the like, with the exception of a few files (which are very small and easy to manage, whereas a NAND backup is large) How are we going to achieve it? Well, as mentioned before, we'll need a few critical files, backed up from the device before it was bricked. Many users already have these files backed up without knowing that they have them! In later versions of the OTP obtaining guide, some of the tools used automatically dump these files. Using these files, we can begin to rebuild the NAND to a state where we can get arm9 code execution, which will let us encrypt new partitions for the 3ds, sending us well on our way to a fully restored console. Needed files (list may change in the future): NCSD header from NAND before the console was bricked OTP firm0firm1 xorpad moveable.sed Secureinfo_A A decrypted CTRNAND backup from any 3ds that is the "same" model (old 3ds > old 3ds, 2ds >old 3ds, old 3ds > 2ds, new 3ds > new 3ds) Process outline: NOTE: a hardmod (access to the NAND eternally) will be needed to perform these steps, unless you somehow already have code execution on the 3ds Starting with a hardmod, flash the NCSD header into place, next we'll need to install arm9loaderhax, that won't be covered here, but the basic process will be: encrypt the FIRM images and flash into NAND at correct offset, flash stage2 payload, encrypt modified secret sector with OTP hash. Once finished, you should have arm9 code execution. From here we can go about encrypting and flashing the CTRNAND backup at the correct place in NAND. From here we'll need to recalculate the AES-CMAC hashes for the .db files contained withing CTRNAND, more information can be found on 3dbrew about how to go about this. Then, from here, we can inject our files from before the console was bricked (moveable.sed and Secureinfo_A). after this the NAND image should be mostly fixed. Depending on the damage, some other work may need to be done (TWL partitions might need to be recovered) This process, as of now, is not currently fully confirmed working and may be subject to revisions |
| dark_samus |
| ||
|
Newcomer Normal user Level: 7 Posts: 6/8 EXP: 1356 Next: 92 Since: 06-02-15 Last post: 3128 days ago Last view: 2929 days ago |
So, you mention the vdd lines, I'm curious what the voltages on those lines are... Specifically vdd12 (that's just a number and not something like "vdd 1.2v," right?) Anyways, this doesn't even sound terribly difficult to achieve on DSi with this information |
| dark_samus |
| ||
|
Newcomer Normal user Level: 7 Posts: 7/8 EXP: 1356 Next: 92 Since: 06-02-15 Last post: 3128 days ago Last view: 2929 days ago |
Looking around on the 3ds, I'm having trouble finding any sort of 1.2v line (not done looking yet, but I've found pretty much everything but) but I will continue my search for that.
Anyways, in terms of just the DSi hack, I think you're right, setting up a microcontroller would be a good idea to try and get execution interrupted early enough. I think the actual hard part of this hack is firstly, finding a method to get an exception vector to execute, which is now done (woo!) then it's just down to timing... Your method definitely isn't set up for precision, but it demonstrates that it can be done, which I think is always the first step to success 
EDIT: another idea, you mentioned messing with the clock and getting everything to run slower... maybe try combining that with the vector attack, reducing the speed of execution might get you somewhere before the lockdown |
| dark_samus |
| ||
|
Newcomer Normal user Level: 7 Posts: 8/8 EXP: 1356 Next: 92 Since: 06-02-15 Last post: 3128 days ago Last view: 2929 days ago |
Thinking on it... If I/O isn't initialized, then we may end up in a situation where we have to say "screw text" or something... Is there anywhere in TCM that isn't used? (I'm more familiar with the 3ds, so I'm not sure on that, might go peruse gbatek after this post) anyways, I think it'd be worth trying to copy some values into a place somewhere in memory that isn't disturbed by any software... DTCM, at least on 3ds, is completely unused... If that's true for the DSi, then writing there (blindly) might be a good idea, then disable /WE and maybe try to jump back to protected bootrom to get the OS to boot as normal (would that even work?) Maybe even a reboot of some type, if you could get that to happen. After that, reading out DTCM should tell you if you were successful or not
Of course, as I've said, I'm not too familiar with the DSi at the time of writing this post, will peruse gbatek soon, so I might just be spouting out things that won't work here |
| Main - Posts by dark_samus |
|
Page rendered in 0.028 seconds. (2048KB of memory used) MySQL - queries: 22, rows: 75/75, time: 0.007 seconds. ![[powered by Acmlm]](img/poweredbyacmlm.png "powering nostalgia")
Acmlmboard 2.064 (2018-07-20)© 2005-2008 Acmlm, Xkeeper, blackhole89 et al. |