|
| ||
| Views: 1,611,768 | Main | Rules/FAQ | Memberlist | Active users | Last posts | Calendar | Stats | Online users | Search | 12-03-24 05:36 PM |
| Guest: | ||
| 0 users reading Get BOOTROM/Key Scrambler? | 2 bots |
| Main - Reverse-engineering - Get BOOTROM/Key Scrambler? | Hide post layouts | New reply |
| gudenau |
| ||
|
Member Normal user Level: 14 
Posts: 16/34 EXP: 11586 Next: 1485 Since: 07-29-15 From: /dev/random Last post: 3123 days ago Last view: 3068 days ago |
I was wondering if there has been any progress getting the BOOTROM and key scrabler from the (n)3DS. From what I recall you need to decap the chips for this.
So, any info? |
| Syphurith |
| ||
|
Member Normal user Level: 18 Posts: 54/59 EXP: 26136 Next: 3761 Since: 10-26-15 Last post: 3246 days ago Last view: 3196 days ago |
1.Decapping Fundraiser that started by Jl12 was late proven to be fake. So no fundraiser now.
2.OTP dumping is not possible at current research level. Well and i don't know more info about it. 3.Key scramber? Oh this is totally left cause the research on the hardware. BTW i'm not the guy that certificated to show any proofs - i'm not REing it. Nor do I have hardware skill. And this kind of development is not so fashion as the exploit finding, and I don't think you can get someguys to raise the money. Yes i do doubt if there is anyone tried that in private. And, those pirates don't care really about homebrew or even RE it - well they're just gamers. That's all what i know about your question. Yes. |
| profi200 |
| ||
|
Member Who knows? Level: 19 Posts: 42/70 EXP: 34568 Next: 1209 Since: 05-21-15 From: Germany Last post: 3005 days ago Last view: 2873 days ago |
For hb neither of those matters. It is only interesting for pirates (mainly) and for the sake of fully documenting the hw. |
| StapleButter |
| ||
|
Member blarg Level: 30 
Posts: 156/184 EXP: 151609 Next: 14260 Since: 10-27-14 From: France Last post: 2660 days ago Last view: 2571 days ago |
Knowing the keyscrambler function would only let you decrypt shit on a PC, given you know the keys-- without them, it's useless. Similarly, the keys are useless without the keyscrambler function.
The boot ROM might have more interesting things: * exploits allowing more control and/or some form of persistent exploit * keys (although again, they're useless if the keyscrambler function isn't known) Dumping the boot ROM is probably impossible without a hardware attack. It permanently disables itself on the way out. Maybe a carefully timed glitch could cause the lockdown instruction to be skipped. This would require measuring how long the boot ROM takes to do its thing, ensuring the timing is reliable (it could be different every time), assuming the lockdown instruction is the last one to be executed... Let's also mention another decapping effort: http://gaasedelen.blogspot.fr/2014/03/depackaging-nintendo-3ds-cpu.html That one looked promising (actual proof it was going somewhere), but then they fell into the CTF blackhole and vanished. ____________________ blargSNES -- SNES emu for 3DS More cool stuff |
| 54634564 |
| ||
|
Newcomer Normal user Level: 7 Posts: 6/7 EXP: 1064 Next: 384 Since: 11-14-15 Last post: 3086 days ago Last view: 2976 days ago |
Posted by StapleButter According to the first entry here: http://3dbrew.org/wiki/3DS_System_Flaws#Hardware It should be slightly easier than trying to glitch out one specific instruction. Looks like you have a small window of time right after the bootrom starts running to cause a hardware glitch and gain code execution. Wonder if anyone has done it yet and just not publicly announced it. |
| gudenau |
| ||
|
Member Normal user Level: 14
Posts: 17/34 EXP: 11586 Next: 1485 Since: 07-29-15 From: /dev/random Last post: 3123 days ago Last view: 3068 days ago |
I know the key stuff is not that useful, mainly interested in that info for documentation; to lead to better emulation down the road. Someone said they glitched the bootrom, but I doubt it based on what they have said about it. |
| nocash |
| ||
|
Normal user Level: 20 Posts: 46/77 EXP: 39067 Next: 3372 Since: 10-09-15 Last post: 2110 days ago Last view: 2025 days ago |
Posted by 54634564 Yes, that should work. The bios might initialize the exception vectors a few cycles after reset (or possibly much later after reset), so there should be at least a short timeframe where one could trigger 'uninitalized' exception vectors. The timing should be rather don't care: It shoud be no big issue if crashes are also triggered before & after that timeframe, ie. like this: - start unstable mode, provoking exceptions - wait a second or so - issue reset - wait a second or so - resume stable operation Same should also work on DSi, the DSi exception vectors are: DSi ARM7 debug vector = 3FFFFDCh (internal ram) DSi ARM9 debug vector = 2FFFD9Ch (external main ram) if neccesary, one could even stretch the timeframe to 'infinite' on ARM9 side (by deactivating the main ram write signal). The main question is How to crash the ARM CPUs? Does anybody have any experiences with that? Crashing ARM CPUs intentionally? Or even unintentionally, eg. by doing some unsuccessful overclocking mods? The debug exceptions are triggered on FIQ, Prefetch Abort, Data Abort, und Undefined instruction. FIQ (fast interrupt) is probably disabled in CPSR so it's probably not usable (even if CPU should have a FIQ input somewhere). Prefetch and Data abort probably won't work either (unless the CPU has external inputs for such aborts somewhere; I haven't spotted any such inputs on DSi, if they are there, then they probably hardwired to VCC/GND underneath of the BGA chip) (don't know if the 3DS CPU has any useful pins for that purpose). So that would leave the Undefined instruction exception... the bootcode is executed in internal ROM, so one obviously can't 'patch' the opcodes, but one could probably cause unstable opcode fetches... my two ideas for doing that would be: - Overclocking the CPU, or, - Lowering the CPU's power supply Any other ideas? Or ideas how to best implement any of those two ideas? |
| nocash |
| ||
|
Normal user Level: 20 Posts: 48/77 EXP: 39067 Next: 3372 Since: 10-09-15 Last post: 2110 days ago Last view: 2025 days ago |
I've tested crashing the DSi CPUs... with some success on crashing the ARM9... but without actually managing to dump any bootroms yet, and without any success on crashing the ARM7 yet. What I've done so far:
- attached two wires to the oscillator - cut CL1,CL2,CL4 (VDD13,VDD18,VDD33) and bridged them with 220 ohm potentiometers - wired a push-button to mainram /WE and VDD18 - and, of course, hooked to 2FFFD9Ch/3FFFFDCh vectors by software The 220 ohm pots were the smallest ones I had around, 50 ohm or 100 ohm might be a bit more suitable (especially for VDD33). See the Power Managment Device section on the http://problemkaputt.de/twl-core.jpg image for details about the VDDxx lines. For the oscillator I've only tried to attach a 2nd osc (in 16Mz,17MHz,45MHz,100MHz ranges) in parallel with the on-board osc, hoping that it would somehow disturb the clock, but nothing seemed to have happened at all (maybe it'd work better when injecting some amplified clock signal). And, just fiddling with the two wires: Nothing happened when touching only one of the wires, but touching both wires with sweaty fingers made the DSi run a lot slower, and video showed flickering scanlines - but the software just kept running as normal. Lowering VDD12 for a moment does work quite reliable for crashing the ARM9 and trapping the 2FFFD9Ch vector, sometimes it does work out, but I've got it working dozens of times. Displaying LR and CPSR showed these values: LR=FFFF010Ch (retadr to debug handler) and CPSR=600000DBh (cpu in "_und" undefined instruction mode). Lowering VDD18 for a moment just seems to hang the console, the picture on screen freezes, and neither the main program nor the crash handler seem to be executing. Lowering VDD33 didn't got me any useful results either, and worst, the potentiometer prevented the console from booting up (even when setting the pot to "0 ohm" position), the DSi booted only when briding the pot with a screwdriver during power-up (and then worked without the screwdriver; probably the screwdriver was needed only for charging up some huge capacitor). So, the best results have been with VDD12. And to make use of it, one would need to lower VDD12 after Reset (while the bootrom is unlocked), and, best ensuring that the bootcode doesn't overwrite the previously installed 2FFFD9Ch vector (hence the push button on the ram /WE signal). I've got it working this way: - hold down the push button (shortcut /WE to VDD) - tap the power button (to issue a Reset) - release the push button - lower VDD12 for a moment (to jump to 2FFFD9Ch) That procedure doesn't work perfectly reliable, but I got it to execute the 2FFFD9Ch handler a couple of times... However, I haven't yet managed to display any text on the screen (after the Reset, I merely managed to change the backdrop color by writing increasing numbers to the palette at 5000000h, which works fine & produces some sort of snow/stripes on the screen). Maybe text output would work when re-initializing more I/O ports (or if that doesn't work out: Just changing the screen backdrop color should be enough to transfer data to PC serially). But, I didn't manage reading the ARM9 bootrom yet. I've tried reading ROM via a LDR opcodes (and also by calling the FFFF0808h BIOS memory copy function in case the BIOS can be read only by BIOS code; and that FFFF0808h function is specifically used for that purpose)... and programmed the crash handler to do the screen blinking only if [FFFF8000h] is nonzero... and unfortunately that didn't work out yet. Theoretically the ROM should be mapped at FFFF8000h after reset, so maybe it's been just bad luck that I didn't manage to read it, or maybe there's some nasty feature that disables ROM access in certain situations (like when trapping exceptions, or when the bootcode noticed that ram writing didn't work or whatever). Anyways, I am still hoping that there is some chance to get it working... best give it a try yourself, too! |
| StapleButter |
| ||
|
Member blarg Level: 30
Posts: 178/184 EXP: 151609 Next: 14260 Since: 10-27-14 From: France Last post: 2660 days ago Last view: 2571 days ago |
Maybe the boot ROM can only be read when PC is within that region. ____________________ blargSNES -- SNES emu for 3DS More cool stuff |
| Normmatt |
| ||
|
Newcomer Normal user Level: 6 Posts: 6/6 EXP: 822 Next: 85 Since: 05-09-16 Last post: 3010 days ago Last view: 3001 days ago |
or your executing the exploit too late and that area is already locked down...
could check if the keys have been copied into ram... oh wait no you can't because it can't write to ram... maybe you need to just block writes to the vector addresses and not all of ram. |
| nocash |
| ||
|
Normal user Level: 20 Posts: 49/77 EXP: 39067 Next: 3372 Since: 10-09-15 Last post: 2110 days ago Last view: 2025 days ago |
Posted by StapleButter Yup, that's why I've used the FFFF0808h BIOS memory copy function (it's explicitely intended for copying data from the upper half of ARM9 ROM, so that should work). Posted by Normmatt Blocking only the vector address would require a main ram hack (which, scanlime has given that hack away... to somebody who seems to have disappeared). The keys are written to TCM (not main RAM), so they could be actually written, and yes, good idea, I could check that. But the boot process seems to involve some main ram handshaking, so, with /WE blocked, I would doubt that it could ever reach the end of the bootrom's boot code (in so far I would be more afraid that the boot code might be doing something like "if some error occurs then shutdown withs roms disabled"). But, yeah, I should check the TCM keys to make sure that it didn't just reach the "normal" end of the boot process... which... that could be relatively easily prevented by unplugging the wifi daughterboard). Oh, I've fixed the text output issue (I just have been doing something wrong when trying to map vram via port 4000204h). So now I am no longer "blind" when viewing the test results. |
| dark_samus |
| ||
|
Newcomer Normal user Level: 7 Posts: 6/8 EXP: 1333 Next: 115 Since: 06-02-15 Last post: 3008 days ago Last view: 2808 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 |
| nocash |
| ||
|
Normal user Level: 20 Posts: 50/77 EXP: 39067 Next: 3372 Since: 10-09-15 Last post: 2110 days ago Last view: 2025 days ago |
I've tried reading TCM 1FFC400h, and it's actually containing C3,02,93,DE, ie. the bytes from ROM address FFFF87F4h. So the bootrom did apparently really reach the stage where it did relocated the keys to TCM (and disabled ROM access thereafter).
Tried to unplug the wifi board before reset, to prevent the above stuff, but as by now that gave me only white screens after reset. VDDxx are the official names for the supply lines as shown on PCB text layer, and yes, they have a meaning in volts: 1.2V for VDD12. And yeah, it's not a very difficult hack, the most challeging part is having to reboot the console for each test (and my potentiometer/pushbutton circuit is a totally amateurish approach, maybe it'd be better to control that part by some microprocessor; so one could get the crash timed to occur shortly after reset). |
| dark_samus |
| ||
|
Newcomer Normal user Level: 7 Posts: 7/8 EXP: 1333 Next: 115 Since: 06-02-15 Last post: 3008 days ago Last view: 2808 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 |
| nocash |
| ||
|
Normal user Level: 20 Posts: 51/77 EXP: 39067 Next: 3372 Since: 10-09-15 Last post: 2110 days ago Last view: 2025 days ago |
I've replaced the /WE push-button by switch - so, after having uploaded my crash handler, I can disable ram writes once and forever, that's allowing to crash/reset the console hundreds of times without needing to re-upload the test software. Of course, the program may not use stack & variables in main ram in that case.
For VDD12, the critical boundary is 4.7ohm, which drops the supply to around 0.95V - 1V (varies depending on what the cpu is doing). At the moment I have the VDD12 potentiometer replaced by a voltage divider: 4.7ohm, and a push-button with a 7.3ohm pull-down resistor. That 7.3ohm isn't always working, for example, the bootrom error screen (with the "0000FEFX" error codes) doesn't react at all at 7.3ohms. It does react at 0 ohm pulldown (ie. when dropping VDD12 to 0V), but it looks as if 0 ohm is causing the cpu to do a Reset, instead of doing a crash. I'll have to try other pulldown values between 0 and 7.3 ohm. As by now I've managed only to get crashes after roms got disabled. Or actually, I seem to have gotten some crashes before that point, but they did only show "0000FEFX" error codes, or just blank white screens. The latter effect might be due to some I/O ports not being initialized at that point (so screen output won't work even if the crash was successful), but, I am relocating ROM data to VRAM (done only if ROM is visible, and only if it wasn't already relocated), so the relocated data should show up in later crashes (which have working video output)... But that VRAM relocation didn't work out a single time yet. Maybe VRAM isn't writeable during early boot period, or maybe the DSi just refused to enter my crash handler during early boot. Slowing down the clock might be also useful. For avoiding ROM-disable it shouldn't be required (normally, the DSi should load hundreds of kbytes from eMMC before disabling ROMs, so there should be a fairly huge window for crashes, probably huge enough to trap the crash manually via push-buttons). The ARM7 might have a smaller window because it can overwrite the 3FFFFDCh vector regardless of the main ram /WE signal. So, if somebody finds a way to crash ARM7, then slowdown might become useful. |
| dark_samus |
| ||
|
Newcomer Normal user Level: 7 Posts: 8/8 EXP: 1333 Next: 115 Since: 06-02-15 Last post: 3008 days ago Last view: 2808 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 |
| nocash |
| ||
|
Normal user Level: 20 Posts: 52/77 EXP: 39067 Next: 3372 Since: 10-09-15 Last post: 2110 days ago Last view: 2025 days ago |
Okay, I give up for now. I didn't get ARM7 crashed at all. And only got ARM9 crashed shortly after the ROMs were disabled. Just some final notes...
VDD33 didn't get me anywhere, just lowering it a little causes the power managment device to shut down the power supply (though there should be a way to rewire to board to lower only the CPU supply, still making the power managment device to think that everything is fine). VDD18 seems to have very low power consumption during boot, the boot code is still working when passing it through 220 ohms (whilst in later boot/game stages the console produces some scratch sound and hangs when passing it through maybe 10-50 ohms), maybe values higher than 220 ohm would do something during boot; though getting VDD18 to low may also erase the crash vector in main ram, at least when applying the lower voltage to ALL chips for too much time. I didn't manage to crash the ARM7 directly, however, there's a way to get control of the ARM7 from within the ARM9 crash hander (after boot ROMs are disabled): The ARM7 is executing code in WRAM, and the WRAM control is granted to ARM9 side (via port 4004060h), so the ARM9 can map custom code to the ARM7, it's working more or less stable (and maybe it'd work perfectly stable when finding some opcodes that can be executed in both ARM and THUMB mode). Being able to run code on ARM7 is nice for reinstalling the 3FFFFDCh crash handler (for further attempts to crash ARM7 directly). And, it's allowing to test the behaviour of the normal disabled SCFG registers on ARM7 side, or to access the SD/MMC ports, eg. for installing dsiwarehax (without needing to wire the eMMC chip to a PC card reader; of course one would still need some soldering for the crash, but it be slightly easier than the card reader approach) (I haven't tried if the power managment device survives shortcutting VDD12 to GND, but if it does, then one could theoretically hack the console with a paper clip, without resistors or soldering). And of course, one would still need some exploited DSi cart like biggestloser to install the crash handler (or a NDS cart, when GNDing the upper two main ram address lines for mirroring the 2FFFD9Ch vector to 23FFD9Ch). |
| ahezard |
| ||
|
Newcomer Normal user Level: 3 Posts: 1/1 EXP: 55 Next: 73 Since: 07-13-16 Last post: 3001 days ago Last view: 2844 days ago |
Wow it is nice to see that such kind of exploit are still researched for the dsi. But you can test arm7 SCFG registers already on 3ds in dsi mode without any special hardware. I have implemented successfully for example the slot 1 power off via SCFG_MC or the switch to ds mode bios via SCFG_ROM. By the way your emulator is not perfectly accurate in some cases in respect to the real hardware. |
| ApacheThunder |
| ||
|
Member Normal user Level: 12 Posts: 1/24 EXP: 6441 Next: 1480 Since: 09-14-16 Last post: 2342 days ago Last view: 2191 days ago |
That's interesting. If you manage something out of that I may actually get a DSi at some point. As for what ahezard said, yeah a lot of low level stuff we can now do on 3DS courtasy of modified TWL_FIRM environment. You simply enable bit31 of 0x1b8 in the DSi Extended header of a custom homebrew SRL to keep scfg unlocked for arm7 in DSi mode.
So these are the things we've managed to do with that: https://github.com/ApacheThunder/NTR_Launcher https://github.com/ahezard/nds-hb-menu https://github.com/ahezard/NitroHax Of coarse things will be different on DSi. Would be fun to see how these projects behave on a DSi. Sounds like you are working on trying to run code on a DSi before it's had a chance to launch boot2/Retail Launcher? I can imagine you'd run into problems. I tried a similar thing replacing dev launcher in TWL_FIRM with hbmenu and get a GURU exception. (so it sorta booted but crashed) Somethings are definitely not setup right. Maybe your work here may allow custom dev launcher for TWL_FIRM too by coincedence. Been trying to get retail launcher running on 3DS. Almost there. Got valid tickets and system apps installed to TWLN and DSi System Settings can finish a system update sequence now. But Retail Launcher hangs on white screen if I attempt to boot it. (it seems to fail very early on as it doesn't even get a chance to write to the log file on TWLN) It probably won't boot unless it somehow boots inplace of dev launcher and to do that I'd have to either replace dev launcher with it (which is impossible because there's not enough ram reserved for it in FCRAM to jam retail launcher there in it's current configuration without a major rewrite of low level stuff in TWL_FIRM) or run some kind of custom loader in place of Dev launcher to boot it from SD/NAND. Maybe replacing boot2/bootloader with DSi one would be the more feasible route. But now I'm dragging this off topic with things I may never get to finishing. 
Maybe you can try and make something that runs in dev launcher place and use it on DSi for what you ar doing here. I'm thinking the environment is similar enough at this early bootstage of TWL_FIRM that what you do there can be used on DSi pre launcher environment. But what you are doing seems to occur even before boot2 starts because it looks like your trying to get at the bootroms.... |
| nocash |
| ||
|
Normal user Level: 20 Posts: 54/77 EXP: 39067 Next: 3372 Since: 10-09-15 Last post: 2110 days ago Last view: 2025 days ago |
Just some more notes...
I've meanwhile got the ARM9 crashed hundreds of times - but only AFTER the bootrom stage. The reason is probably that Main RAM (=including the Undefined Instruction exception handler) isn't enabled during bootrom stage (it seems that Main RAM gets enabled by setting EXMEMCNT.bit13 at the begin of the 2nd boot stage). One thing that might work is getting an unstable ARM9 opcode to jump to a "wrong" memory address (for example, ITCM and New WRAM are known to be enabled at some point during bootrom stage, and VRAM might be also enabled; at least when displaying HEX error codes upon boot errors). That approach would probably require to reboot the console hundreds or millions of times, until eventually getting it to do what it should do (and making sure that the auto-crash-reboot procedure stops at that point). And ARM7... it seems to be possible crash ARM7 by holding the supply voltage low for some LONG time (about a second or so). But I've never managed to get that effect to occur during bootrom stage... For doing so, one might need to start lowering the supply voltage a while before rebooting, but even then: no luck so far. It's also possible that the power consumption drops during bootrom phase (so one might need some heavier pulldown to get the supply voltage lowered in that boot stage). Ah, and some notes from derrek (who dumped the 3DS bootroms using some similar approach): * Desoldering the CPU's capacitors might help (that is: those very tiny (almost invisible small) capacitors "under" the CPU / on the PCB's "back" side). * Spraying all kinds of RAMs with jump opcodes might help (rather than relying only on the exception vectors). * And using some FPGA to control the glitches & stuff might also help. Of those, I didn't try the capactitor desoldering. In later tests I have sprayed most of the RAMs (with ARM+THUMB code), and used a PC parallel port (and some transistors) to control the reset signal & supply voltage (not as accurate as an FPGA timing wise, but maybe timing isn't too critical when just intending to crash the CPU via unstable/random conditions; ie. one could only guess when ITCM and New WRAM are getting enabled anyways). Ah, and I've used the RTC signals for transferring data to PC, that's been working fine (but to be actually useful, one would need to manage to crash the ARM7 during bootrom stage). |
| Main - Reverse-engineering - Get BOOTROM/Key Scrambler? | Hide post layouts | New reply |
|
Page rendered in 0.042 seconds. (2048KB of memory used) MySQL - queries: 28, rows: 103/103, time: 0.006 seconds. ![[powered by Acmlm]](img/poweredbyacmlm.png "powering nostalgia")
Acmlmboard 2.064 (2018-07-20)© 2005-2008 Acmlm, Xkeeper, blackhole89 et al. |
