Hacking Cfg USB Loader 70r78.8 released

nitraiolo

Well-Known Member
OP
Newcomer
Joined
May 5, 2013
Messages
65
Trophies
0
Age
43
XP
191
Country
Italy
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.
 
  • Like
Reactions: AbdallahTerro

nitraiolo

Well-Known Member
OP
Newcomer
Joined
May 5, 2013
Messages
65
Trophies
0
Age
43
XP
191
Country
Italy
Hi!
the ios58 branch is still alive but almost frozen. More or less I'm at the same point of 1 month ago...
 

Cyan

GBATemp's lurking knight
Former Staff
Joined
Oct 27, 2002
Messages
23,717
Trophies
4
Age
44
Location
Engine room, learning
XP
15,426
Country
France
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.
 
  • Like
Reactions: nitraiolo

AbdallahTerro

da KiNG
Member
Joined
Jan 14, 2012
Messages
6,052
Trophies
0
Location
Ideas factory :)
Website
ccabz.wordpress.com
XP
2,996
Country
  • Like
Reactions: nitraiolo

nitraiolo

Well-Known Member
OP
Newcomer
Joined
May 5, 2013
Messages
65
Trophies
0
Age
43
XP
191
Country
Italy
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

Well-Known Member
OP
Newcomer
Joined
May 5, 2013
Messages
65
Trophies
0
Age
43
XP
191
Country
Italy
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)
 

nitraiolo

Well-Known Member
OP
Newcomer
Joined
May 5, 2013
Messages
65
Trophies
0
Age
43
XP
191
Country
Italy
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 :blink:
 

Cyan

GBATemp's lurking knight
Former Staff
Joined
Oct 27, 2002
Messages
23,717
Trophies
4
Age
44
Location
Engine room, learning
XP
15,426
Country
France
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

Well-Known Member
OP
Newcomer
Joined
May 5, 2013
Messages
65
Trophies
0
Age
43
XP
191
Country
Italy
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.
 

Attachments

  • readdol-0.01.zip
    20.5 KB · Views: 190
  • Like
Reactions: Cyan

Cyan

GBATemp's lurking knight
Former Staff
Joined
Oct 27, 2002
Messages
23,717
Trophies
4
Age
44
Location
Engine room, learning
XP
15,426
Country
France
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

Developer
Member
Joined
Aug 11, 2009
Messages
2,291
Trophies
1
Location
Germany
Website
wiimmfi.de
XP
1,462
Country
Germany
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
 

Wiimm

Developer
Member
Joined
Aug 11, 2009
Messages
2,291
Trophies
1
Location
Germany
Website
wiimmfi.de
XP
1,462
Country
Germany
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.
 
  • Like
Reactions: nitraiolo

You may also like...

General chit-chat
Help Users
  • No one is chatting at the moment.
    Veho @ Veho: https://i.imgur.com/B6xTZgn.jpg