Gecko OS

Started by omgnowai, September 28, 2008, 03:16:02 AM

Previous topic - Next topic

omgnowai

I'm a terrible noob at this and I really need someone to explain to me what this does exactly.   I have used Ocarina and been using it since the day it came out.  That is the only other thing I have in my Homebrew channel so I thought, why not, let's add this new device.  So it works but I don't have a clue in the world what it does.  I have not downgraded my wii or anything like that... no modchip, haven't played imports or weird discs.  So, I'm just wondering what this might do for me other than loading my Ocarina codes which I can already do with Ocarina.

And if you tell me anything, please say it like you're trying to teach a hobo what you're trying to get across.  I know nothing -.-

111

Yes, with the newest version of GeckoOS, you can also load Ocarina codes on it, and also load imports.  With a USB Gecko, I believe that you can use GeckoOS to debug Wii games, and the system menu.  Since a USB Gecko can be used to edit memory in Wii games, that means that you could create your own codes for games.  However, without a USB Gecko, it is mostly just for cheats and imports.

omgnowai

Do you think that there might be any change that Gecko OS/Ocarina could be able to handle more code lines?  Like being able to have more than 256 lines of code.

111

Sorry, but you should probably ask Link or Nuke on that, as I have no idea.

hetoan2

Quote from: omgnowai on September 28, 2008, 03:27:23 AM
Do you think that there might be any change that Gecko OS/Ocarina could be able to handle more code lines?  Like being able to have more than 256 lines of code.
no it wont. I'm pretty sure Link said that somewhere. it has to do with the max in wiiRD too...

Link

It simply isn't possible.. codes are stored in memory.. memory is limited.. and the apploader starts at a certain point in memory.. once we hit the apploader.. we can't proceed any further into memory.. this is reached with 256 lines. Over!

WiiRd via USB Gecko happily overwrites the apploader.. and most of the time that works because it's just executed once!

Neo Shadow

Also, the fact that WiiRD allows you to play import games is a must. Well, for PAL users anyway since we're usually the ones limited in games out (One Piece Unlimited Adventure made it out to US but not europe... Yeah, I don't get it either) or if you speak japanese.

biolizard89

Quote from: Link on September 29, 2008, 08:28:28 AM
It simply isn't possible.. codes are stored in memory.. memory is limited.. and the apploader starts at a certain point in memory.. once we hit the apploader.. we can't proceed any further into memory.. this is reached with 256 lines. Over!

WiiRd via USB Gecko happily overwrites the apploader.. and most of the time that works because it's just executed once!
Sorry to bump an old topic, but can you elaborate on this?  Once the game is booted, is the RAM where the apploader resided now available for hackers to use?  What address range did the apploader reside in?  Is it generally safe to use that space for general purpose data storage?  Is it generally safe to store additional codes there?  How does the code handler know whether the data there is unused, used by codes, or used for generic data storage?

Thanks!

Nuke

81200000 is where the apploader gets copied to memory on an official game, after its been executed this area is just used as game code or data.

some games will use just gamecode < 81200000 but a lot will use all the memory, Zelda for example has variables for the game above the 81700000 range.

All games do have free areas, but to write good code, you need an area which is never touched which is why we use an unused exception vector area 1800-3000.

2 other ways to give more space is either manipulate the BAT, or use functions in the game which are never used, there are some Macromedia functions for example which are 0xD00 is size, these can be used as never called. The problem with these 2 methods is the SDK does change so the fingerprints to find these also change, so one routine might not work with all games. Messing with the BAT can give you space but might also crash the game.

The current way we use is the best, if hackers need larger code areas, hes probably best to just find unused ram in the game hes hacking.
0xFFFFFFuuuuuuu

biolizard89

Quote from: Nuke on November 18, 2008, 05:13:48 AM
81200000 is where the apploader gets copied to memory on an official game, after its been executed this area is just used as game code or data.

some games will use just gamecode < 81200000 but a lot will use all the memory, Zelda for example has variables for the game above the 81700000 range.

All games do have free areas, but to write good code, you need an area which is never touched which is why we use an unused exception vector area 1800-3000.

2 other ways to give more space is either manipulate the BAT, or use functions in the game which are never used, there are some Macromedia functions for example which are 0xD00 is size, these can be used as never called. The problem with these 2 methods is the SDK does change so the fingerprints to find these also change, so one routine might not work with all games. Messing with the BAT can give you space but might also crash the game.

The current way we use is the best, if hackers need larger code areas, hes probably best to just find unused ram in the game hes hacking.
Thanks for the info.  0xD00 bytes is definitely large enough for me, I only need about 0x600 bytes.  How would I find those functions with WiiRD?  Does that work for GameCube or just Wii?  In general, how would I find an unused section of RAM?  Search for 00's?  If I find a section of RAM that I think is unused, how would I verify that?  A R/W breakpoint?  A WiiRD code that sets it to 00?  Some other method that I can't think of?

Thanks!