Homebrew PassMe2 Header [devkitPro, libnds]

[Exxod]

This is what I need in my NDS file, in line 399 to 401 of ndstool github devkitPro/ndstool/blob/master/source/ndscreate.cpp
are the sections that add the header. I cannot find any arguments to add the header with Makefile
is there any way to do this?

To clarify: YSMenu and R4.dat (the one that made the b9s card) Kernels have this header and they can be both used as R4.dat on the SD card without the ? MENU error followed you replaced the magic bytes that the R4i Card checks for before booting the kernel. Without this header, on my own homebrew application, I replace the bytes and rename the file to R4.dat and the card boots up saying ERROR in a red SD card shape. At first I thought this was some PALib thing since R4.dat used PALib, but YSMenu has no references to PALib. So I did alot of digging to find ndscreate.cpp which showed where the header was created but I cannot find a way to make that header show up in my NDS binary. Instead I get the standard header

 

[Exxod]

I managed to do this by adding "-h 0x200" to ndstool but the code does not start at 0x200 like the R4.dat file, just the DLDI interface at 0xa00

 

[edo9300]

I think it'd be easier for you to just make a Python script that takes the generated nds and manually adds the header once it's built

 

[Exxod]

I think it'd be easier for you to just make a Python script that takes the generated nds and manually adds the header once it's built

No I have got the header now but in the R4.dat file (and others like YSMenu etc.) the code starts at 0x200 but mine starts alot further down, in ndstool source, it says -h 0x200 is for older homebrew i'm not sure if this means an older build of devkitpro would compile it like this, but if the nds file is not compiled like this the R4 says Error when trying to load the homebrew

 

[Coto]

I'm not sure I follow. You want to use a custom header instead the standard one when a new NDS binary is being created (from ARM7.bin and ARM9.bin). I assume this is NTR mode you are referring to.

BTW, the NTR header on every devkitARM NDS binary starts at 0x0, and not 0x200 , unless overriden, by the -h flag. Thus, the header should be at 0x0 and its length is 0x170‬ bytes.

NTR header:
https://problemkaputt.de/gbatek.htm#dscartridgeheader

I think you should understand the header's contents first, since even if you update some strings the new header (you want to add) still has important bits such as :

 020h    4     ARM9 rom_offset    (4000h and up, align 1000h)
  024h    4     ARM9 entry_address (2000000h..23BFE00h)
  028h    4     ARM9 ram_address   (2000000h..23BFE00h)
  02Ch    4     ARM9 size          (max 3BFE00h) (3839.5KB)
  030h    4     ARM7 rom_offset    (8000h and up)
  034h    4     ARM7 entry_address (2000000h..23BFE00h, or 37F8000h..3807E00h)
  038h    4     ARM7 ram_address   (2000000h..23BFE00h, or 37F8000h..3807E00h)
  03Ch    4     ARM7 size          (max 3BFE00h, or FE00h) (3839.5KB, 63.5KB)

Or to put it simply, find a way to merge a custom header and the standard header so it has the strings you want, while also keeping the above values from the standard header, since these were calculated by NDSTool and ARM7.bin , ARM9.bin are physically in the absolute address(rom_offset) of the NDS binary having each their own entrypoint (entry_address).

 

[Coto]

I am researching some stuff, and I updated this tool:

https://bitbucket.org/Coto88/ToolchainGenericDS-ndstools/get/HEAD.zip

/release folder has a binary precompiled so you can run it in the DS through SLOT-1 cards.

From readme:

Button (Start): Basic file browser. -> Supports compressing(slow)/decompressing LZSS files. (NDS Bios native compressor/decompressor) -> Allows to extract a (homebrew) NDS Binary, and a logfile with specific details around these binaries (you can rebuild a NDS Binary with these)

So basically you copy your NDS Binary, execute this little tool and you'll extract an ARM7.bin, ARM9.bin and a logfile pertaining details of each ARM settings out of such NDS Binary (of which you can re-use to reassemble it again).

This will export the addresses (and other stuff), required by each binary, required by the homebrew header.


Log of r4igold.cc's _DS_MENU.DAT

0://_DS_MENU.DAT Sections:
[arm7.bin]:arm7BootCodeOffsetInFile: 0x5f400 -- arm7BootCodeSize: -> 7480 bytes [@ EntryAddress: 0x2380000]
[arm9.bin]:arm9BootCodeOffsetInFile: 0x200 -- arm9BootCodeSize: -> 389408 bytes [@ EntryAddress: 0x2000450]

And by following ARM7 Binary EntryAddress I could open the crt0 section disassembled:


Which makes sense.