4dsdev
Views: 603,500 Main | Rules/FAQ | Memberlist | Active users | Last posts | Calendar | Stats | Online users | Search 10-18-17 10:42 AM
Guest:

Main - Posts by dark_samus


dark_samus
Posted on 06-02-15 08:08 PM, in blargSnes -- SNES emulator for the 3DS Link | #166
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 :D

dark_samus
Posted on 06-05-15 04:08 PM, in Certain apps crash on launch; problem is persistent across NAND images. Link | #177
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
Posted on 07-15-15 11:51 AM, in blargSnes -- SNES emulator for the 3DS Link | #260
9.8 doesn't have a way to run the homebrew launcher yet...

dark_samus
Posted on 11-23-15 05:51 PM, in Decrypting the NAND title.db / import.db Link | #765
Posted by 54634564
Wow, when did you become admin here profi? Congrats on the promotion!

That's it, d0k3. Might as well just delete your posts, can't discuss this. So saith lord profi200.


On a serious note...I don't think people have looked into these files too extensively. That's the reason you probably won't be getting any answers, not any "moral" stuff.
Hell, yellows8 thought there was extra crypto on the tickets in tickets.db up until late last year(there isn't):
http://3dbrew.org/w/index.php?title=Title_Database&action=historysubmit&diff=9857&oldid=8384


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
Posted on 07-25-16 08:55 AM, in Building a new NAND image from "scratch" Link | #1055
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
Posted on 09-06-16 06:17 AM, in Get BOOTROM/Key Scrambler? Link | #1082
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
Posted on 09-06-16 01:36 PM, in Get BOOTROM/Key Scrambler? (rev. 2 of 09-06-16 02:49 PM) Link | #1084
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
Posted on 09-08-16 02:32 AM, in Get BOOTROM/Key Scrambler? Link | #1086
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.037 seconds. (2048KB of memory used)
MySQL - queries: 22, rows: 75/75, time: 0.026 seconds.
[powered by Acmlm] Acmlmboard 2.064 (2015-10-07)
© 2005-2008 Acmlm, Xkeeper, blackhole89 et al.