Hacking Cfg USB Loader 70r78.8 released

nitraiolo · Mar 15, 2015

Hello,
the new patched version of Cfg USB Loader has just been released on http://cfgusbloader.ntd.homelinux.org/trac/CfgUSBLoader.

Changelog:
Compilation - code cleanup to remove all compilation warnings
GC - updated nintendont config support to version 0x00000003
Internals - added Wii / vWii identification capability
GC - fixed wide screen support in vWii for nintendont (untested but should work)
GC - added nintendont memory card sizing
GC - added nintnedont shared memory card support
Internals - added "mem_card_emu" and "mem_card_size" keys for games configs in "settings.cfg"
Build - added revision number to version as suffix ".<rev>" (70r78.8)

Please note that due to the "settings.cfg" change, all previously NMM configured GC games have to be regonfigured. Memory card emulation now is triggered by "mem_card_emu=1" and not by "country_patch". "mem_card_emu=2" is used for shared mem card (ninmem.raw).

Despite the shared mem card functionality I suggest to use separate 251 blocks cards. This way a mem card corruptions involves only a single game.

Bye.

AbdallahTerro · Mar 15, 2015

Thanks!
Still waiting for ios58 support. Any plans for this

nitraiolo · Mar 15, 2015

Hi!
the ios58 branch is still alive but almost frozen. More or less I'm at the same point of 1 month ago...

bm123456 · Mar 16, 2015

nitraiolo said:
Hi!
the ios58 branch is still alive but almost frozen. More or less I'm at the same point of 1 month ago...

Thank you for sharing your mod.

Cyan · Mar 16, 2015

It's nice to see other loaders still updated and adding support for nintendont.
I added a way to identify nintendont version in r324 (search the string "$$Version:x.xxx", where x are the major/minor version, 3.324) in the dol.
I don't know if you need to check the version, but it will be better than using compile date string in the dol.

nintendont will probably not add more settings, but it can be used to display the detected nintendont version in the loader.

AbdallahTerro · Mar 17, 2015

Was building and testing CFG loader Mod by nitraiolo and made a tweaked version of Nintendont mod to fix titles.txt and custom game themes loading when using this CFG version
(This fix will also work with all other CFg mods)
CFG Mod 70.78.8: http://copy.com/vRN3HgFVyk9u7YuB/Public/cfg_mod_70_78_8.7z
Nintendont Mastermod 3.324 for CFG loader: http://copy.com/vRN3HgFVyk9u7YuB/Public/3.324_for_CFG_mod.7z

P.S> both apps should be on same device for this combo to work

nitraiolo · Mar 17, 2015

Cyan said:
It's nice to see other loaders still updated and adding support for nintendont.
I added a way to identify nintendont version in r324 (search the string "$$Version:x.xxx", where x are the major/minor version, 3.324) in the dol.
I don't know if you need to check the version, but it will be better than using compile date string in the dol.

nintendont will probably not add more settings, but it can be used to display the detected nintendont version in the loader.

Good job!
This is a very interesting solution. I was planning to build an hash map to do this but now it becomes useless.
I'm not a big expert in dol binary file format, so I ask to you: do you think it is possible to force a fixed offset to avoid a full file scan?

Thanks!

nitraiolo · Mar 17, 2015

AbdallahTerro said:
Was building and testing CFG loader Mod by nitraiolo and made a tweaked version of Nintendont mod to fix titles.txt and custom game themes loading when using this CFG version
(This fix will also work with all other CFg mods)
CFG Mod 70.78.8: http://copy.com/vRN3HgFVyk9u7YuB/Public/cfg_mod_70_78_8.7z
Nintendont Mastermod 3.324 for CFG loader: http://copy.com/vRN3HgFVyk9u7YuB/Public/3.324_for_CFG_mod.7z

P.S> both apps should be on same device for this combo to work

Interesting!
What is you building environment? I saw that you boot.dol (1.922.528b) is almost 25Kb larger than the one i build (1.897.472b) with devkitPPC 27...
(http://cfgusbloader.ntd.homelinux.org/trac/CfgUSBLoader/chrome/site/binaries/dol/r8/cfg70r78.8.dol)

AbdallahTerro · Mar 17, 2015

Latest devkit with few extra libs

nitraiolo · Mar 17, 2015

This is very interesting.
asap I'll check the differences in the debug file

I have only libntfs and libext2fs as extra libs... If not referenced extra libs should not be used in linking proces, this means that we should get the same size

Cyan · Mar 17, 2015

nitraiolo said:
I'm not a big expert in dol binary file format, so I ask to you: do you think it is possible to force a fixed offset to avoid a full file scan?

I don't know how to do it, but it's possible with linking script, but I don't know how it works.
Maybe Fix94 knows how to fix the offset.

What can be done is to align it to 16bytes, or 32k or something like that, and the file scan can advance few bytes at a time instead of one by one.
Argsboot string is using this method.
static const char ARGSBOOT_STR[9] ALIGNED(0x10) = {'a','r','g','s','b','o','o','t','\0'}; //makes it easier to go through the file

for(u32 i = 0; i < filesize; i += 0x10) // 16 by 16

but it doesn't work with the version string.
It will probably need to be done differently.

nitraiolo · Mar 20, 2015

I studied a little bit the .dol format, that is a very simple one. I've wrote a simple tool (readdol) to render header values in a human readable format.

Code:

C:\wii-dev\readdol-0.01>readdol.exe loader_r324.dol
Readdol v. 0.01 by NiTRo THe DeMoN
 
Filename: loader_r324.dol
 
.text
section[0]
  file offset = 0x00000100
  mem address = 0x80004000
  size = 812704 bytes
section[1]
  unused
section[2]
  unused
section[3]
  unused
section[4]
  unused
section[5]
  unused
section[6]
  unused
 
.data
section[ 0]
  file offset = 0x000c67c0
  mem address = 0x800ca6a0
  size = 799680 bytes
section[ 1]
  unused
section[ 2]
  unused
section[ 3]
  unused
section[ 4]
  unused
section[ 5]
  unused
section[ 6]
  unused
section[ 7]
  unused
section[ 8]
  unused
section[ 9]
  unused
section[10]
  unused
 
.bss
mem address = 0x8018da60
size = 537472 bytes
 
entry point
mem address = 0x80004000
 
padding
00000000 00000000 00000000 00000000
00000000 00000000 00000000

I tried to add a new elf section ".version" using the __attribute__((__section__(".version"))) and a linker script to map the ".version" section immediately before ".data" but I doesn't work. I got no building/linking error, but even no new ".version" section (tested with readelf).
Due to .dol format, I think the only way to have a fixed offset in the file is inserting a uint32_t in the padding area with the numerical versions (example 0x00000cfc = 3324 for 3.324). Anyway a solution with a fixed offset in a ".data" section is good too, but I was unable to do it.

Cyan · Mar 20, 2015

The version and compile date seems to be always at the bottom of the file.
I guess parsing the buffer in reversed order will speed up the search.

I'll make some test to see the time difference with reverse order.
I'm currently parsing the full file from the start to the end. It's taking a little noticeable time when launching a game. (I'm checking the version based on compilation time to determine which settings to send, etc.)

Thanks for the tool
I won't have to check it manually next time I want to look at a dol header.

Wiimm · Mar 20, 2015

nitraiolo said:
I've wrote a simple tool (readdol) to render header values in a human readable format.

wit does it too:

Code:

# wit dump main.dol

Dump of file main.dol

  Real path:        .../main.dol
  File size:            2a36a0/hex =    2766496 = 2702 KiB
  File type:        DOL

  Memory map of DOL file:

           unused :  off(beg) ..  off(end) :      size : section
     -----------------------------------------------------------------------
                  :         0 ..       100 :       100 : DOL header
                  :       100 ..      2560 :      2460 : text section T0
                  :      2560 ..    240080 :    23db20 : text section T1
                  :    240080 ..    240640 :       5c0 : data section D0
                  :    240640 ..    240ee0 :       8a0 : data section D1
                  :    240ee0 ..    240fa0 :        c0 : data section D2
                  :    240fa0 ..    240fc0 :        20 : data section D3
                  :    240fc0 ..    254680 :     136c0 : data section D4
                  :    254680 ..    2a0140 :     4bac0 : data section D5
                  :    2a0140 ..    2a1500 :      13c0 : data section D6
                  :    2a1500 ..    2a36a0 :      21a0 : data section D7
                  :    2a36a0 ..    2a36a0 :         0 : --- end of file ---

  Memory map of DOL image:

           unused :  off(beg) ..  off(end) :      size : section
     -------------------------------------------------------------------
     .!           :  80004000 ..  80006460 :      2460 : text section T0
     !.           :  800060a4 ..  800060a4 :         0 : entry point
                  :  80006460 ..  80006a20 :       5c0 : data section D0
                  :  80006a20 ..  800072c0 :       8a0 : data section D1
                  :  800072c0 ..  80244de0 :    23db20 : text section T1
                  :  80244de0 ..  80244ea0 :        c0 : data section D2
                  :  80244ea0 ..  80244ec0 :        20 : data section D3
                  :  80244ec0 ..  80258580 :     136c0 : data section D4
                  :  80258580 ..  802a4040 :     4bac0 : data section D5
     .!        40 :  802a4080 ..  8038917c :     e50fc : bss section
     !.           :  80384c00 ..  80385fc0 :      13c0 : data section D6
                  :  80386fa0 ..  80389140 :      21a0 : data section D7

If adding --long (or -l), the following table is also printed:

Code:

  Delta between file offset and virtual address:

           unused :  off(beg) ..  off(end) :      size :    delta : section
     ----------------------------------------------------------------------
                  :  80004000 ..  80006460 :      2460 : 80003f00 : T0
                  :  80006460 ..  80006a20 :       5c0 : 7fdc63e0 : D0
                  :  80006a20 ..  800072c0 :       8a0 : 7fdc63e0 : D1
                  :  800072c0 ..  80244de0 :    23db20 : 80004d60 : T1
                  :  80244de0 ..  80244ea0 :        c0 : 80003f00 : D2
                  :  80244ea0 ..  80244ec0 :        20 : 80003f00 : D3
                  :  80244ec0 ..  80258580 :     136c0 : 80003f00 : D4
                  :  80258580 ..  802a4040 :     4bac0 : 80003f00 : D5
            e0bc0 :  80384c00 ..  80385fc0 :      13c0 : 800e4ac0 : D6
              fe0 :  80386fa0 ..  80389140 :      21a0 : 800e5aa0 : D7

nitraiolo · Mar 21, 2015

Thanks a lot!

I never used wit with .dol... WIT is a real swissknife!!

Wiimm · Mar 21, 2015

Sorry for offtopic!

My way to implement something is to analyze it before. I do analysing by programming analysers, and a structure dump is a kind of analysing. Inserting a command into wit/wwt is much easier than creating a new tool. So wit is full of dumping and verifying code. And the advantage is, that this verifying code is called hidden before operations. For example wwt will analyse a WBFS partition before each access and also repair simple things like the very often broken used-block-table in the background.

Here you find a complete list of commands: http://wit.wiimm.de/wit/#cmd
The dump command detect the file formats and print many infos.

Hacking Cfg USB Loader 70r78.8 released

Well-Known Member

da KiNG

Well-Known Member

Well-Known Member

GBATemp's lurking knight

da KiNG

Well-Known Member

Well-Known Member

da KiNG

Well-Known Member

GBATemp's lurking knight

Well-Known Member

Attachments

GBATemp's lurking knight

Developer

Well-Known Member

Developer

Similar threads

Popular threads in this forum