4dsdev
Views: 614,232 Main | Rules/FAQ | Memberlist | Active users | Last posts | Calendar | Stats | Online users | Search 11-24-17 09:12 PM
Guest:

Main - Posts by nocash

Pages: 1 2 3
nocash
Posted on 05-16-16 09:21 AM, in no$gba v2.8c update - with more DSi emulation and DSi specs Link | #1030
Posted by gudenau
I *might* be able to make a stack that makes a directory act like a FAT partition.

Posted by Normmatt
DeSmuME already does that... so he could look at how that works and re-implement it.

Yeah, something like that is planned - sooner or later. At the moment I am focusing on getting the SD card CMD's and ACMD's working (and stick with a SD card image for now).

And creating a "virtual" SD card image from a directory: The creation wouldn't be too difficult.

Creating a "full" image (with actual data files in it) would be probably quite slow, so I would prefer to create only the FAT+directory (and keep the actual data file at their original locations) (ie. using some list that tells which "cluster" is in which file, and at which file offset).

The problems would be handling changes to the files...

The first issue would be if the file gets changed on the PC (by some other application). I guess one couldn't do much against that(?) or would it be possible (and desired) to "lock" all files in the directory?
Otherwise one could just tell the users not to touch the files during emulation.
Or maybe trap timestamp changes and force the emulator to eject-recreate-reinsert the SD card.
Any ideas how to handle that? Or info how DeSmuME is doing it?

And the other issue would be handling changes by the emulator: Changing/adding/deleting files, and somehow reflecting that changes to the directory when the emulation stops.
Or maybe even instantly reflecting it upon any changes to FAT or directory, so a file would get instantly deleted in the directory when the emulated software is deleting it in the SD image.

nocash
Posted on 05-25-16 08:02 PM, in no$gba v2.8c update - with more DSi emulation and DSi specs (rev. 2 of 05-25-16 08:06 PM) Link | #1036
Another update, no$gba v2.8d...

This version supports DSi games and system files with unencrypted "rsa" signatures (done by hooking the rsa bios functions). This should be very useful for developing & testing DSi stuff without knowing Nintendo's private key.

And, SD Cards are now emulated, too. The no$gba package includes a blank 128MByte SD Card image ready for use (if you want to use it: please unzip the "dsi-sd.zip" file). This should be also very useful for developing and testing anything that accesses the external SD Card slot.

http://problemkaputt.de/gba.htm - no$gba homepage
http://problemkaputt.de/magicflr.htm - sample for a homebrew DSi cartridge with working/unencrypted signature

26 May 2016 - version 2.8d
- dsi/rsa: supports unencrypted "rsa" signatures (via hooked RSA swi functions)
- dsi/sdmmc: supports NDMA sdmmc start condition (for SD data32 read/write)
- dsi/sdmmc: supports SD card initialization (CMD0,2,3,7,8,9, ACMD6,13,41,42,51)
- dsi/sdmmc: created/included empty sd-card-image (file dsi-1.sd, in dsi-sd.zip)
- dsi/sdmmc: fixed irq-retriggering (recurse irq_stat on irq_mask changes)
- dsi/sdmmc: adjusts insert/eject and write-protect flags depending on dsi-#.sd
- dsi/sdmmc: prevents RXRDY in DATA32 mode (@@skip_rxrdy_in_data32_mode)
- dsi/help: added notes on EMPTY sd-image (dsi-#.sd) (DSi SD/MMC Images chapter)
- dsi/help: added notes unencrypted signatures (see BIOS RSA Functions chapter)
- dsi/help: added notes on encrypted twl-*.der files (in "verdata" NARC file)
- dsi/help: added CRC32 checksums for currently known/dump-able DSi-BIOS areas
- dsi/debug: shows insternal sd/mmc registers in iomap screen (cid,csd,csr,src)
- sample: updated magic floor gba/nds version, now with working dsi cart header

nocash
Posted on 05-26-16 04:20 PM, in RSA Questions Link | #1038
About the 1st question: Somebody pointed me on this https://github.com/mborisov1/rsa_embedded - it's less than 200 lines of code - and it contains everything needed to decrypt RSA signatures!
That's about a million times simplier than trying to understand polarssl source code, or trying to disassemble the DSi bios functions.
I've ported it to ASM, and it's actually working for the DSi signatures. When changing two things:
The .h files defines MPI_NUMBER_SIZE=128, counted in 16bit units (ie. 256 bytes), for the DSi that must be changed to half of that size.
The source/dest/key values must be little-endian, whilst the DSi does have them stored in big-endian.
And the parameters for the "mpi_powm65537" function are then "m=source/dest buffer", and "n=key".

nocash
Posted on 05-31-16 12:47 AM, in DSi Whitelist Link | #1040
Found one weird detail: The RSA signatures in the DS Cart Whitelist aren't verified in DSi firmware v1.4E.
Other (older and newer) firmware versions like v1.3U and v1.4.5E are verifying those signatures, but v1.4E doesn't verify them - that firmware version doesn't even include the Whitelist's RSA key.

nocash
Posted on 06-19-16 02:59 PM, in DSi Font File Format (rev. 4 of 06-19-16 04:02 PM) Link | #1044
One more DSi mystery getting solved: the 843Kbyte "\sys\TWLFontTable.dat" font file. As one may assume, it does contain fonts, and it's been fairly obvious that it's compressed somehow, but without actually knowing how the compression works - or even where the compression starts.
The answer is surprising simple (and a bit weird): The fonts are compressed backwards; the compression starts at the end, and ends at the start.

The exact decompression function can be found in Flipnote (EUR) at address 20BF8E4h (which is mainly doing error checking, and then calling the actual decompression function at 20BF938) (Flipnote does also contain several custom fonts, the TWLFontTable.dat file is used only for Flipnote's "Help" function).
The decompression is about same as the BIOS/SWI "LZ77" decompression function, but processed backwards, with some extra footer, using 8bit flags, and 4bit len(+3), and, oddly, 12bit disp(+3) instead of disp(+1).
And, it's intended to store the compressed and decompressed data in the same memory block, so that the compressed data will get overwritten during decompression - that would cause problem on worst-case compression ratios (which can require 9 compressed bytes for 8 uncompressed bytes; and which would actually cause problems at the begin if the file; assuming that the bytes in the chunk headers aren't occuring elsewhere in the font data). To avoid still unprossed data getting overwritten in such cases, the first some bytes (usually 15h bytes) are left uncompressed, and the decompession stops when reaching that location.

In decompressed form, the font tiles are looking as so:
http://problemkaputt.de/dsifontl.png - Large Font, 16x21pix, 2bpp, 7365 characters
http://problemkaputt.de/dsifontm.png - Medium Font, 12x16pix, 2bpp, 7365 characters
http://problemkaputt.de/dsifonts.png - Small Font, 10x12pix, 2bpp, 7365 characters
The three fonts seem contain exactly the same characters (and do differ only by the font size). The font width's are proportional, eg. the 16x21pix font be max 16 pixels wide (plus spacing), but most characters are using than 16 pixels (as defined in the Font Width chunk).
From what I can see, the font seems to cover english letters, european letters with accent marks, greek, cyrillic, several symbols & punctuation marks, and... something for some eastern language(s) that I am not really familar with.
If I should guess: It's probably japanese. Or, it might be some rather incomplete mixup of japanese, chinese, and/or korean.

Anyways, I am still having some questions...

1) Can somebody confirm if it's japanese and/or chinese and/or korean?

2) If it's ONLY japanese: Can anybody check if chinese/korean DSi consoles do have a different file, or extra font files?

3) Can somebody check how many letters are actually legible? The symbols seem to have underwent some ugly resampling process, resulting in rather smeared/dirty character glyphs. The large font might be still 95% legible (?) but the Small font... is anybody able to deciphier more than 10% of those characters? Or well, maybe you can intuitively identify everything if you are familar with the language, even if the letters are only smeared gray rectangles with a few black dots here and there?

4) Does the 3DS have the same font (in the DSi partition)? And do all DSi's have same font version? That is, if it's same as mine, then the RSA signature at the begin of the file should start with 23h,8Bh,F9h,08h,...

5) Is there more info about the Nitro Font format? The stuff that's known to me (see link below) is still a bit incomplete on some chunk header entries.

PS. some more info about the overall .dat file format, and about the decompressed Nitro Font format can be found here:
http://problemkaputt.de/gbatek.htm#dsisdmmcfirmwarefontfile

nocash
Posted on 06-22-16 10:22 AM, in Get BOOTROM/Key Scrambler? (rev. 2 of 06-22-16 10:22 AM) Link | #1048
Posted by 54634564
Looks like you have a small window of time right after the bootrom starts running to cause a hardware glitch and gain code execution.

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
Posted on 06-22-16 08:45 PM, in DSi Font File Format (rev. 2 of 06-22-16 08:49 PM) Link | #1049
Thanks for confirming that it's really japanese! Didn't knew that kanji is shared for different languages, I though japanese would be totally different than chinese and korean, and that chinese and japanese would each have more than 6000 symbols, and sum up to more than 12000 for both languages. But with shared symbols... they would sum to something ways less?

I guess nobody has ever dumped the eMMC filesystem from chinese/korean DSi or 3DS yet, or did anybody do so?
Aside from the font file, the chinese DS was also known to contain an extra font in Wifi FLASH memory. I am not absolutely sure if or how games were allowed to use that font - if they were allowed to do so, then chinese DSi and 3DS should also include that old DS font somewhere for backwards-compatibilty.
And maybe same for korea - but I don't even know when (and if) the DS was ever sold in korea, if yes, if it did contain some similar extra font in Wifi FLASH as in china.

Oh, and one note on the character sets supported in the TWLFontTable.dat file. It has been said to support
ASCII ;english
ISO 8859-1 ;english+european
ISO 8859-7 ;english+greek
CP 932 ;english+sjis
CP 1252 ;english+european
CP 1253 ;english+greek
JIS X0201 ;english+jis8bit
JIS X0208 ;english+jis16bit
but that isn't exactly right. The Char Map chunks are containing only one set of character numbers (though split into separate chunks). The character numbers are probably 16bit Unicode (as indicated by the "Encoding" byte in the Font Info chunk). There isn't anything related to ISO/CP/JIS character numbers in the file. Of course, one could use some external translation table to convert such numbers to unicode.

For the meaning of the various bytes in the chunks, the Glyph chunks is fairly simple:
Character Glyph (Tile Bitmaps)
00h 4 Chunk ID "PLGC" (Character Glyph)
04h 4 Chunk Size (10h+NumTiles*siz+padding)
08h 1 Tile Width in pixels
09h 1 Tile Height in pixels
0Ah 2 Tile Size in bytes (siz=width*height*bpp+7)/8)
0Ch 1 Underline location
0Dh 1 Max proportional Width including left/right spacing
0Eh 1 Tile Depth (bits per pixel) (usually 1 or 2, sometimes 3)
0Fh 1 Tile Rotation (0=None/normal, other=?)
10h ... Tile Bitmaps
... ... Padding to 4-byte boundary (zerofilled)
The rotation byte is usually zero (meaning of other rotation values are rather unclear).
Byte 0Dh seems to be the "max proportional width" (ie. the biggest value from the Char Width chunk) (not 100% sure, but I've examing about 10 nitrofont files, and it does match that rule with all of those files.
Byte 0Ch might be the underline location. But it's hard to tell for sure because the "upper part" of the character is usually always "square", so the byte could be either related to the underline location, or to the bitmap width (unless any games are actually drawing underlined text (?) then one could check if those games use that byte).

Character width is also quite simple...
Character Width
00h 4 Chunk ID "HDWC" (Character Width)
04h 4 Chunk Size (10h+NumTiles*3+padding)
08h 2 First Tile Number (should be 0000h)
0Ah 2 Last Tile Number (should be NumTiles-1)
0Ch 4 Unknown/unused (zero)
10h+N*3 1 Left Spacing (to be inserted left of character bitmap)
11h+N*3 1 Width of Character Bitmap (excluding left/right spacing)
12h+N*3 1 Total Width of Character (including left/right spacing)
... ... Padding to 4-byte boundary (zerofilled)

But the Font Info chunk is pretty unclear:
Font Info Chunk
00h 4 Chunk ID "FNIF" (Font Info)
04h 4 Chunk Size (1Ch or 20h)
08h 1 Unknown/unused (zero)
09h xxx 1 Height ;or Height+/-1
0Ah xxx 1 Unknown (usually 00h, or sometimes 1Fh)
0Bh 2 Unknown/unused (zero)
0Dh xxx 1 Width ;\or Width+1
0Eh xxx 1 Width_bis (?) ;/
0Fh 1 Encoding (0/UTF8, 1/UNICODE, 2/SJIS, 3/CP1252) (usually 1)
10h 4 Offset to Character Glyph chunk, plus 8
14h 4 Offset to Character Width chunk, plus 8
18h 4 Offset to first Character Map chunk, plus 8
1Ch (1) Tile Height ;\present only
1Dh xxx (1) Max Width or so +/-? ; when above
1Eh (1) Underline location ; Chunk Size = 20h
1Fh (1) Unknown/unused (zero) ;/(version 0102h)
Most of the entries seem to be duplicated stuff that's also found in the Character Glyph chunk (ie. the width/height/underline stuff). Which would be rather useless if it's really like that. And it would be even weirder because there newer 20h-byte chunk version invented more of those useless entries.
And in case of the "xxx" marked entries, the values aren't even exact dupes (in the files that I've tested, they are sometimes +/-1 bigger or smaller as in the Glyph chunk; there might be some reason for that, or maybe somebody just didn't iniatialize those bytes properly).

I haven't checked the open source stuff recently (but used sources like those last year when trying to understand the nitrofont format, and least back then, they couldn't explain all bytes in the Font Info chunk either).

Anyways, at the moment, the biggest font mystery would be what's going on in china and korea.

nocash
Posted on 09-06-16 05:03 AM, in Get BOOTROM/Key Scrambler? (rev. 7 of 09-06-16 05:22 AM) Link | #1078
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!

nocash
Posted on 09-06-16 05:59 AM, in Get BOOTROM/Key Scrambler? (rev. 3 of 09-06-16 06:02 AM) Link | #1081
Posted by StapleButter
Maybe the boot ROM can only be read when PC is within that region.

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
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.

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.

nocash
Posted on 09-06-16 07:04 AM, in Get BOOTROM/Key Scrambler? Link | #1083
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).

nocash
Posted on 09-07-16 09:20 AM, in Get BOOTROM/Key Scrambler? (rev. 2 of 09-07-16 09:22 AM) Link | #1085
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.

nocash
Posted on 09-09-16 07:11 AM, in Get BOOTROM/Key Scrambler? (rev. 2 of 09-09-16 07:12 AM) Link | #1087
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).

nocash
Posted on 11-04-16 01:17 AM, in NTR chipid bit 31 questions Link | #1109
Bit31 should be mainly related to Secure Area (KEY1 commands), but possible that it does also affect the cart header...

For original NDS carts (without DSi features) it doesn't really matter since the NDS header is less than 200h bytes (it should be zeropadded to 1000h bytes, but there's no official code (from Nintendo) for reading that much of header data for NDS carts).

What I am doing for reading both NDS and DSi cart headers is always setting ROMCTRL to AC3F1FFFh (=read 1000h bytes at once).
From what I remember, that setting was required for some NDS cart headers (eg. for Tony Hawk's Sk8land). And I've also used it for dumping two DSi titles (System Flaw and Cooking Coach, one of them having Bit31 set, the other doesn't).
So I guess the 1000h-byte read mode should work for ALL cart headers, no matter if Bit31 is set, and no matter if it's a NDS or DSi title.

nocash
Posted on 01-17-17 09:29 PM, in Get BOOTROM/Key Scrambler? (rev. 3 of 01-17-17 09:38 PM) Link | #1111
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).

nocash
Posted on 02-11-17 12:45 PM, in no$gba v2.8e released - 11 Feb 2017 Link | #1112
Time to uninstall your wanna-be virus scanners: http://problemkaputt.de/gba.htm ; )

Major news is heavily extended documentation - including for some first specs on the TeakLiteII processor. The built-in assembler does now support both Xtensa (Wifi) and Teak (DSP) assembler source code, so it's now actually possible to run hardware tests on that processors (not that I would expect anybody to do such things, so just forget about it). Other weird stuff includes the DSi memory dumper - most recent version is released here: http://gbatemp.net/threads/dswifi-asm-port-and-bugs-in-dswifi-hll-version.447174/#post-7009852 - to my knowledge, that's the first tool ever that could dump the DSi/3DS camera device ID's, the newer Wifi-ROMs and such stuff (again, just forget about it, the program must be in run in DSi mode, and there are currently only 2-3 people who could do such things). Anyways, the good news is that there are now wide parts of the DSi hardware documented, and that we could theoretically start to reverse-englneer the remaining unknown details at some day in future.

11 Feb 2017 - version 2.8e
- gba/bugfix: forces WAITCNT.15=readonly (for DKong:KingOfSwing, thanks endrift)
- dsi/teak/a22i: added TeakLite II assembler (supports most TL+TL2 opcodes)
- dsi/teak/help: specs for teak cpu flags (which opcodes affect which flags)
- dsi/teak/help: specs for memory mapped I/O ports on teak/dsp side
- dsi/teak/help: specs for teak CPU registers, details for operand encoding
- dsi/teak/help: specs for teak st0-2,icr plus undoc stt0-2,mod0-3
- dsi/emmc: detects/supports debug-version eMMC images (tweaks port 4004024h)
- dsi/help: cleaned up some RSA descriptions, notes on debug-version RSA keys
- dsi/help: first attempts on describing SCFG_xxx registers for ARM7 side
- nds/wifi/help: added details on ds-download-play's openpgp-rsa-sha1 signature
- dsi/boot: mimmicked support for booting with AR6013 (when WifiFlash[1FDh]=2)
- dsi/dsdump: released dumping tool for dsi memory areas and chip IDs
- nds/wifi: released dswifi ASM port (and bugfixes for original dswifi-library)
- dsi/wifi/a22i: added assembler support for atheros/xtensa instruction set
- dsi/wifi/disass: fixed bugs for ANY/ALL/4/8 and EXTUI-based SHR pseudo-opcode
- bugfix: handles 16bit (not 32bit) return value of GetKeyState/GetAsyncKeyState
- nds/wifi/help: added note on W_IF acknowledging for counter half-overflows
- dsi/tmd/help: added age ratings and public/private .sav entries in .tmd specs
- dsi/devicelist/help: added DSi SD/MMC Device List chapter (for carthdr[1D4h])
- dsi/startdirect: initializes device list, aes keys, etc. (still imperfect)
- fontfile/help: more info on dsi font file (compression, nitrofont, characters)
- lz/help: added pseudo code for lzss, lz11, and lzrev decompression
- bootinfo/help: SHA1 WifiFlash[00h..27h] and eMMCBootInfo[00h..FFh,180h..1FFh]
- whitelist/help: info on RSA-SHA1's, SHA1-HMAC's and missing RSA check in v1.4E
- flipnote/help: info on various flipnote files, rsa, md5, xor-encryption
- rsa/help: added info on rsa basics, rsa pseudo code, rsa big-endian format
- rsa/help: added note on SWI 23h using OpenPGP Message Format (RFC 4880)
- rsa/bios: 80x86 dsi bios clone supports RSA bios functions (SWI 20h..23h)
- nds/bugfix: disables dsi I/O ports in DS mode (avoids misdetecting DS as DSi)

PS. "we" is the hacking community, but I don't know where it is.
Pages: 1 2 3

Main - Posts by nocash

Page rendered in 0.042 seconds. (2048KB of memory used)
MySQL - queries: 21, rows: 86/86, time: 0.020 seconds.
[powered by Acmlm] Acmlmboard 2.064 (2017-11-20)
© 2005-2008 Acmlm, Xkeeper, blackhole89 et al.