Hacking Unoffical -- USBloader_GX(S)

[kyle007]

yeah i get your point lightyear, as i said i can compile just fine, a monkey can compile software lol i just can't modify existing code to suit my exact needs unfortunately. Assuming your the LY im thinking of xD are you hanging around the chatbox? i can come there and help ya with compiling stuff at least

 

[retKHAAAN]

Here's a start as far as setting up your environment and compiling sneek/uneek. Just replace the original source files with the ones he uploaded here.

then you need to add the functions to your loader and compile (they can go just about anywhere)

as far as compiling in general goes, once you have your environment set up it's as simple as opening a command prompt, going to the directory your source is in, typing make, and pressing enter

 

[gameking66]

then you need to add the functions to your loader and compile (they can go just about anywhere)

This is the part those who can't code are stuck on. They don't know WHERE to put the code from his pastie.

 

[nIxx]

Well you need sneek for it ,unpack the games and so on.
I don´t say that it´s crap but in this state it´s a messy hack (and i don´t mean this offensive) and not really usefull especially since you need sneek.
I mean who is really going to use sneek and do all this stuff just to play some games that can already be played on the usuall way !? (not even mentioned that the IOS reloading problem seems to be fixed for cIOS, at least if you play from dvd´s for now)

@lightyear: http://wiibrew.org/wiki/Homebrew_development is always a good starting point

.

 

[gameking66]

Well you need sneek for it ,unpack the games and so on.
I don´t say that it´s crap but in this state it´s a messy hack (and i don´t mean this offensive) and not really usefull especially since you need sneek.
I mean who is really going to use sneek and do all this stuff just to play some games that can already be played on the usuall way !?

@lightyear: http://wiibrew.org/wiki/Homebrew_development is always a good starting point

.

Because Disc Emulation brings 100% compatibility.

 

[kyle007]

Old8oy, apparently you've made a loader, since you know for sure you can put the code anywhere, and you obviously tested it and know it works lol i just wish GP would chime in and give us even some basic instructions for getting a loader compiled

 

[ChokeD]

In theory you could just add the game list/change codes to tinyload (a small disc loader by marcan) and you would have a finished USB-Sneek loader. Just a small menu in text mode, which lists the games, mount the game and run game from (emulated) disc drive on A-button. Shouldn't take more than half an hour even for a noob like me (I also got a simple libwiigui USB-loader (just a button with cover for every game, no settings) before wiiflow and GX arrived because libwiigui and the usb loader code are quite easy to change, the code you need now is a lot easier). But as I go on vacation tomorrow I won't to it in the next two weeks

I'm already curious what will be changed in the Wii/SNEEK scene when I get back home

@mousex or others,

It would be really nice if you or someone could help us out here with the whole process of compiling this thing by means of a highly detailed tutorial and or just doing what you do best as stated above.

it's not that I can't or don't want to and it's not that I want everything handed to me on a silver platter, it's just really hard to find the time to figure out every in/out of this to get past it and move on to other things.

I don't have devkit set up or any other environment set up to compile anything but I did happen to get an original version of sneek going for myself, by myself, when it first came out. I'm pretty proud of that.

I still have it.

It's seems lazy of me to say this, I know, but I wish some one would just make it so we had to come up with the ninty file and click a batch file and presto. But that would be asking a lot of someone.

I do enjoy the reading of the different threads I love reading the knowledge people are passing around and I understand a lot of it, but it just all gets overwhelming and confusing trying to keep up with sneek, this, and all the other stuff I'm in to in the Wii scene and other consoles.

Well, thanks for listening everyone and keep up the good work,
ChokeD

I'm simple like that.

 

[retKHAAAN]

then you need to add the functions to your loader and compile (they can go just about anywhere)

This is the part those who can't code are stuck on. They don't know WHERE to put the code from his pastie.

how about here?

line 129 and down in the usbloader functions pastie would probably have to replace line 126 and down here

 

[gameking66]

While I doubt that the changes will simply work without a hitch I'll try to compile it like that.

EDIT: But the new SNEEK won't even work for me, it blackscreens, so the most I could do is compile it.

 

[kyle007]

and old8boy, we also need to get rid of cios calls and wbfs stuff lol but thanks for the little hint

 

[FenrirWolf]

While I doubt that the changes will simply work without a hitch I'll try to compile it like that.

EDIT: But the new SNEEK won't even work for me, it blackscreens, so the most I could do is compile it.

Do you have di.bin on the USB drive?

 

[gameking66]

While I doubt that the changes will simply work without a hitch I'll try to compile it like that.

EDIT: But the new SNEEK won't even work for me, it blackscreens, so the most I could do is compile it.

Do you have di.bin on the USB drive?

Is that required for SNEEK/SD? I'm not using UNEEK.
edit: Yea I have it. Can it be 2 partitions? I have NTFS/WBFS on my external drive.

 

[FenrirWolf]

No, that's only needed for this particular mod of SNEEK. Shouldn't be necessary for the normal builds.

EDIT: Pretty sure SNEEK only will read a FAT32 partition.

 

[W hat]

Would this decrypted disc dumper give a file structure similar to what you see in WiiScrubber? I love messing with Wii ISO's, but I don't know if the new disc dumping tool would be any different than what I already use.

 

[gameking66]

No, that's only needed for this particular mod of SNEEK. Shouldn't be necessary for the normal builds.

EDIT: Pretty sure SNEEK only will read a FAT32 partition.

I meant on my normal sneek compile. Should r78 be black screening if I don't have a USB drive plugged in?

 

[giantpune]

@w hat
yes the decrypted files are identical to what you get in wiiscrubber. they are just put into a couple small folders to keep them less messy.

Spoiler

when using the part.bin files, you just throw those in the same folder as the tmd and ticket.

and yes, what nIxx says is correct. since usb loaders are made to deal with games in terms of the game ID, these methods are a little bit on the dirty side. they were made for a drag & drop replacement. IE, replace WBFS_GetCount() with DVDGetGameCount(), replace WBFS_GetHeaders() with WDVD_GetHeaders(), and replace Disc_SetWBFS() with WDVD_OpenDisc(). WDVD_GetIOS() is added to get the correct IOS that the game wants.

as far as the actual game loading and the path the data goes on its way to and from the PPC, i dont see this as any dirtier than the way current cIOS works. In cIOS, the request for data goes through no less IPC calls than this so i dont see how it can be considered less dirty.

normal cIOS:
PPC -> DI -> EHCI -> HDD -> EHCI -> DI -> PPC

this method:
PPC -> DI -> FFS -> HDD -> FFS -> DI -> PPC

 

[Wiimm]

fst creator / boot.bin updater http://pastie.org/892752
tested and working on ubuntu amd64 9.10. the fst.bin created is not identical to the original one, but it works fine with these modules. if the fst.bin changes size, that new size needs to be written in the boot.bin.

Found in your code:
CODEu32 be32( unsigned int i )
{
ÂÂÂÂreturn ( i > 24 ) | ( ( i > 8 ) &0xFF00 );
}
This is *not* a big endian function. It is a swap endian function.

try something like this ...
CODEu32 be32 ( u32 data )
{
ÂÂÂÂu32 result;
ÂÂÂÂu8 * d = (u8*)&result;
ÂÂÂÂ*d++ = data >> 24;
ÂÂÂÂ*d++ = data >> 16;
ÂÂÂÂ*d++ = data >>ÂÂ8;
ÂÂÂÂ*d++ = data;
ÂÂÂÂreturn result;
}

... or use htonl().

 

[giantpune]

what exactly is the difference? ive not messed a bunch with these things, so i just grabbed one i had laying around from another program. when i change to your function, i get the exact same output file, so what is it doing that im missing?

 

[WiiPower]

what exactly is the difference? ive not messed a bunch with these things, so i just grabbed one i had laying around from another program. when i change to your function, i get the exact same output file, so what is it doing that im missing?

I would say Wiimm's code always returns big endian, no matter what system it is running on, the other only returns big endian on little endian systems. I guess if the current code was copied to be used for the other processor that it might produce some problem while Wiimm's code should be safe. Well as long as the return value is really expected as big endian.

And i can't say for sure if Wiimm's code is correct, i still have problems with the shift operators. I would even say Wimmm's code is wrong because of the shifts instead of using division...

 

[Wiimm]

what exactly is the difference? ive not messed a bunch with these things, so i just grabbed one i had laying around from another program. when i change to your function, i get the exact same output file, so what is it doing that im missing?

On x86 machines there is no difference because they are little endian machines.

The difference is when using a machine with big endian like mips (or mixed endian like old dec vax). Then you write the data in little endian because of swapping (or something other on vax).

The system functions ntohs(), ntohl() htons() and htonl() knows the local representation of ints and do translate always from/to big endian (=network byte order),

name mangling:
n-to-h-s = network to host short (u16)
h-to-n-l = host to network long (u32)