Hacking M3 Real - Boot issues - Anyone got boot.0 format?

[Hidekiadam]

Hihi

I have an M3 Real I just recently bought

However, the software it comes with clearly sucks

I've been examining the boot.0 file (and indeed the pda.0 file) to see how they're started since they're clearly not NDS roms

I still don't know how it works but I have noticed the format is quite different

NDS ROM: 16K Header, game follows that

.0 file: 256K header (Seriously, 0x40000 bytes all containing 0xFF) then what looks like an index of a number of files presumably with filename, offset etc., then what I assume to be the files themselves, definitely seeing signs of moonshell in there and I believe the default skin...

Wondering if anyone has documented this or better yet produced a tool to take apart and rebuild the files

I could do with having it run something other than internal moonshell and that godawful PDA software it comes with, if I can't change the menu items (and it seems I can't), then perhaps I can replace the files that are loaded with the binaries for moonshell/dsorganise... I'd quite like dslinux on there and there is the room but no way by the looks of it

These people should be taken by the throat and encouraged to release their source...

Thanks ^^

 

[OSW]

yeah... well i always like to take a look at cart loaders to see if i can do any small modifications with them etc. M3's loader looks no so simple to a newb like me.

so... i'm also interested.
and i'm sure they won't release their source.

 

[Hidekiadam]

Hihi

Yeah, I'm not overly optimistic on seeing the source but at least knowing how it booted and how to start nds games would mean I could code my own interface...

Want to make a proper LCARS one and the lack of crucial features in the skins (such as positioning elements) is preventing me from doing so with the stock software

 

[cory1492]

As far as I know so far, g6dsload.eng (or .whatever your region is) is "chain loaded" by the hardware's bootstrap (see M3_REAL_WORLD dump or whatever it's called) and it handles loading everything else. From the info iq_132 found in this thread the first chunk is simply xor'd, meaning it should be possible to replace the initial menu program so long as you xor the header again.

Generally though, the flash cart companies never release the method they use to actually load commercial games/homebrew (in an attempt to stop cloners?), so if you want that you'd either have to make a method yourself or reverse it. If you were capable of reversing, though, I doubt you'd have any questions to ask in this forum regarding booting things.

 

[OSW]

Ah yes, true point.

On a tangent, I was having fun dumping some flashcarts today (fun? 0_0, dunno, well it was cool to be able to) but i couldn't dump my ezpass (3?).

is it dumpable?

Also cory1492, do you know whether flashcarts that autoboot achieve it through their hardware or their firmware?

 

[cory1492]

There is a bit in the game header that sets autoboot, cards like R4 have the bootloader permanently set so that can't be changed. From what I see, M3R has a flash chip, so it might be possible to update the bootloader though I don't know for certain at this point.

There are a few cards that won't dump because they don't reset properly on reinsert, and a few may not dump because they don't have intelligible data in the header. Really depends on the dumping program, though. For example, my MK6 save cart wouldn't dump using Rudolphs tools, but when I used a custom version of FW Nitro flashed to my old DS it dumped it like a champ (mainly because there was no reinsert I presume).

 

[OSW]

cheers for the info.

since supercard one has an updatable internal firmware, i'm assuming it could possibly be modified to boot normally? (not that i plan to right now)

is the autoboot part of the game header easily identifiable? (by how it looks or where the offset is located)

 

[cory1492]

http://nocash.emubase.de/gbatek.htm#dscartridgeheader

 Â01Fh  Â1   Autostart (Bit2: Skip "Press Button" after Health and Safety)
       Â(Also skips bootmenu, even in Manual mode & even Start pressed)

Adjust the bit, fix the crcs and there ya go, no more autoboot.
http://nds.cmamod.com/ez5/headfixv_v1.zip
Should handle fixing the crc

(though, I still presume that SCDS1 has a preloader that is run before the updater and never overwritten when updating to prevent unrecoverable devices; it's what I'd do to reduce end user support if I had to sell the things. IIRC they call it the "microcode" or similar, so even that might be updateable...)

 

[Hidekiadam]

Hihi

If people are quite done hijacking my thread, any chance of an answer to one of my original questions?

Namely, what is the format of the boot.0 (and pda.0) files, they appear to contain 256K of 0xFF then a directory of sorts (filenames followed by other data), then the files themselves...

 

[OSW]

don't you just love hijacking threads?

 

[cory1492]

Hihi

If people are quite done hijacking my thread, any chance of an answer to one of my original questions?

Namely, what is the format of the boot.0 (and pda.0) files, they appear to contain 256K of 0xFF then a directory of sorts (filenames followed by other data), then the files themselves...

Well, considering I DID answer your question as best I could considering the info you provided... (since you are asking about at least one "boot.0" file that I was not able to find in the recent updates, I assumed "the first file to be loaded by the bootstrap")
CODE>>M3G6_DS_Real_v2.7d_E13_EuropeUSAMulti (**some assumptions made)
------------------------------------------------------------------
INTRO_GB.BIN (GBA EMU)
INTRO_SMS.BIN (SMS EMU)
Program.lib (crypted? appears to be the media extend)
Program1.lib (GBA in game menu)
cheat.db (cheat database)
dldi_ds.g6 (G6 dldi)
dldi_ds.m3 (M3 dldi)
g6dsload.1 (unicode tables, DF's ndsloader.bin)
g6dsload.2 (per game patch info?? 11 gamecodes listed in this release)
g6dsload.eng (first file loaded by hw bootstrap - handles region selection)
homebrew.eng (homebrew loader, dldi autopatching, VRAM based?)
intro_PCE.bin (PCE emulator)
intro_nes.bin (NES emulator)
lic.dat (??)
menu.eng (main menu - english, 114+30 gamecodes found at 0x3E1E0, presume rumble/DL-P list)
minigame.eng (ROM loader?)
setting.dat (default skin???)
version.dat (version string plain text)

plausible chainload:
hw bootstrap -> g6dsload.eng -> menu.language -> homebrew.eng (to boot a passed file on FAT)
-> minigame.eng (to boot a passed file on FAT)
-> program.lib (media extend?)
*chainload from g6dsload.eng to menu.language can be observed as a white screen flash which was not present in
pre-multilang kernels.
*chainloading may well execute without ever replacing arm7's bin loaded from the initial hw loader, could explain the odd
header format of the decrypted system files. Regardless, the header need not correspond to regular nds files as they are
loading them using their own loader (hw bootstrap) wrather than relying on the DS's normal header methods.
*the hw bootstrap seems to name a bunch of files that don't seem to exist, almost appears to be a semi crypted IMFS
style bit embedded in the arm9 which may correspond to those files.
** basic first glance at arm9 disasm of the hw bootstrap and some hexing of the other system files provided the
information found

if you are talking about g6dsload.1, it is plainly a resource file, with a file size following the file name, each file being aligned to 0x200. menu.language appears to be the actual menu.

Any rate, don't hold your hopes up for a hack, M3 seem to like to change their file crypt formats any time someone has them figured out.

 

[Hidekiadam]

Hihi

Yes, you did, sorry, tend to get a bit testy after a couple of hours banging my head off a brick wall coding -.-

I did mean g6dsload.1, not sure why I misrememberd as that, probably something else I've been looking at...

Only want to make a few changes to the software, to adjust what it loads when you select PDA/Media, plan to write an OS myself, perhaps with plugins for booting things so others can deal with that problem

I note the new acekard is open source, perhaps that'll encourage the others to be a bit more forthcoming although I'm not holding my breath

do the M3 updates reflash the card itself? if not, I can't see how they could change anything important, particularly if something else boots first, seems there's a boot.ini which you can use to bypass the software...

 

[cory1492]

M3R has a 4Mbit (512KiB) flash EEPROM chip inside, I'd presume this is what is holding the bootstrap data and that it can be updated somehow as I have not seen it being used for anything else at this point (though I doubt it, it may also have been put in there as a "cross our fingers and hope we don't need it, but if we do it's there" type of thing.) No update yet has noticeably changed the bootloader, but I wouldn't leave that out of the realm of possibilities.

I think I did see a boot.0 in one of the files somewhere, but like I said above in the file summary I believe it is in some type of crypted imfs (implanted file system) - if it exists at all in there.

I for one expect the pda/extend to be crypted, as they'd not want to make it simple to use on other cards, but I could be wrong. What I saw of program.lib suggested to me it was crypted. I'll spend some time on the disasm, if I turn up anything else I'll post back (I for one am looking for a way to access that flash chip directly)