Jump to content

Search the Community

Showing results for tags 'WiiWare'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Categories

  • Pokémon
    • Pokémon (Ultra Sun/Ultra Moon)
    • Pokémon (Sun/Moon)
    • Pokémon (PSMD)
    • Pokémon (EoS)
  • Egg Groups
    • Egg Groups (Ultra Sun/Ultra Moon)
    • Egg Groups (Sun/Moon)
  • Moves
    • Moves (Ultra Sun/Ultra Moon)
    • Moves (Sun/Moon)
    • Moves (PSMD)
    • Moves (EoS)
  • Abilities
    • Abilities (Ultra Sun/Ultra Moon)
    • Abilities (Sun/Moon)
    • Abilities (PSMD)
  • Types
    • Types (Ultra Sun/Ultra Moon)
    • Types (SM)
    • Types (PSMD)
    • Types (EoS)

Categories

  • Generation 7
  • Generation 6
  • Generation 5
  • Generation 4
  • Mystery Dungeon 3DS
  • Mystery Dungeon NDS
  • Sprite Index
  • Other

Categories

  • Project Pokémon
  • Games
    • Pokémon Ultra Sun and Ultra Moon
    • Pokémon Sun and Moon
    • Pokémon Super Mystery Dungeon

Categories

  • Save Editing
    • Managing GB/GBC Saves
    • Managing GBA Saves
    • Managing NDS Saves
    • Managing 3DS Saves
    • Managing Gamecube Saves
    • Managing Wii Saves
    • Managing Switch Saves
    • Using PKHeX
    • Gen 3 Specific Edits
    • Gen 4 Specific Edits
    • Gen 5 Specific Edits
  • ROM Editing
    • Stars' Pokémon Colosseum and XD Hacking Tutorial
    • Editing ROMs with Sky Editor
    • 3DS Pokémon Games Hacking Tutorials
  • RAM Editing
    • GS ACE: Coin Case
    • GS ACE: TM17
  • Gameplay related support
    • e-reader support

Forums

  • ProjectPokemon.org
    • Announcements
    • News Discussion
    • Project Pokémon Feedback
    • Introductions
  • Event Pokémon
    • Event Pokémon News
    • Event Contributions
  • Technical Discussions
    • ROM
    • Saves
    • RAM and Live Edits
    • Hardware
    • General Development
  • Pokémon Discussions
    • Pokémon Games Discussion
    • Pokémon Online Play
    • Pokémon Franchise
    • Pokémon Trivial Games
  • Other
  • Mystery Dungeon Hacking's Discussions
  • The "I Love Cats" Club's Discussions
  • The Cool Kids Corner's Discussions
  • Team Valor's General Discussion
  • Pokemon USUM Breeder's Club's Rules
  • Pokemon USUM Breeder's Club's Post breeding stories & pictures here
  • Pokemon USUM Breeder's Club's Competitive Breeding Requests
  • Pokemon USUM Breeder's Club's Non-Competitive Breeding Requests
  • Pokemon USUM Breeder's Club's Introduce self
  • The PBOE, (Pokémon Brotherhood of Evil)'s Topics
  • Sky Editor's Topics
  • Sky Editor's Questions
  • Hoopa's Café's Topics
  • Super pokemon POWER's Topics

Calendars

  • Community Calendar
  • Pokémon Event Calendar
  • The "I Love Cats" Club's Events
  • Hoopa's Café's Important Dates
  • Super pokemon POWER's Events

Categories

  • Event Gallery
    • Generation 7 (Switch)
    • Generation 7 (3DS)
    • Generation 6
    • Generation 5
    • Dream World
    • C-Gear Skins
    • Pokédex Skins
    • Pokémon Musicals
    • Pokémon World Tournaments
    • Generation 4
    • Generation 3
    • Generation 2
    • Generation 1
  • In-Game Series
    • Generation 7
    • Generation 6
    • Generation 5
    • Generation 4
    • Generation 3
    • Generation 2
    • Generation 1
  • Unreleased/Beta PKM Gallery
  • Tools
  • Saves
  • PKM Files
  • ROM related entries
  • Misc
  • Mystery Dungeon Hacking's Files
  • Sky Editor's Files
  • Hoopa's Café's Files
  • Super pokemon POWER's Files

Blogs

There are no results to display.

There are no results to display.


Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Gender


About Me


Friend Code (Nintendo Switch)


Friend Code (3DS)


NNID (Wii U)

Found 2 results

  1. Pokémon Mystery Dungeon (WiiWare) data1_XXXX.bin and data2_XXXX.bin archive information The files, data1 and data2 are archive binaries, the "XXXX" indicated in the file name, is the game code for the files, which can vary depending on the version (eg. data2_WPAJ.bin). Since data1 and data2 archive binaries are compressed with the AT7 compression algorithm, the archives must be decompressed before any data can be extracted. But here's how the decompressed data1 and data2 files are structured: Part 1 - Pointer and file name table Part 2 - Actual data of all files Part 1 - Pointer and file name table This data contains all the pointers of all files, as well as their file names. Each table row consists of: Offset Endianness Type 0x0-3 Big Endian Data location offset 0x4-7 Big Endian File size 0x8-1B Big Endian Namespace data Namespace data This data contains the filename data, and all filenames can only be in ASCII format. Filenames can only be a maximum of 19 characters long, every filename always ends with a 00 value byte and must be in the namespace data in order for it to function properly. Anything after the 00 valued byte through to offset 0x1B will be what we'll refer to it as "junk text". Junk text is the remains of what used to be a previous file that existed on that entry before it was overwritten by a different filename, either through renaming or removal of a file during development. So essentially it would be development leftovers. It's possible to create a program that would re-replicate the same type of junk data results though file namespace overwriting. For example, we have a file called adev_app_icon.tex, then we name it "app_icon.tex", it would look like this: "app_icon.tex tex". Alternatively if we renamed or removed "bg_event.sed", the file name in the table row below it called "bg.swd" would take priority and overwrite the text (and file offset data) on that table row and the namespace would look like "bg.swd t.sed", then if the file was renamed again to "b.swd", it would be "b.swd t.sed" which would look like "62 2E 73 77 64 00 00 74 2E 73 65 64 00 00 00 00 00 00 00 00" in hex. This means that an addition of a new file or renaming a file in the archive has the potential to create junk data, overwriting text in an existing entry while leaving some of it there. Part 2 - Actual data Each file data fits into this area as followed: First - File data Second - Line break filling Line break filling This data occurs between each file to show that its sepparate data, it can either be 16 or 32 bytes long, the FF value marks the end of the file data and start of the filling data, all the rest of the filling data is 00 value bytes, after that, the next file begins. The end of the entire data1 or data2 archive is marked with a FF value byte as well, but without the 00 values after it. 32-byte filling data: FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 16-byte filling data: FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Credits: MegaMinerd - For most of the research into filling data
  2. Pokémon Mystery Dungeon (WiiWare) data1_XXXX.bin and data2_XXXX.bin archive information The files, data1 and data2 are archive binaries, the "XXXX" indicated in the file name, is the game code for the files, which can vary depending on the version (eg. data2_WPAJ.bin). Since data1 and data2 archive binaries are compressed with the AT7 compression algorithm, the archives must be decompressed before any data can be extracted. But here's how the decompressed data1 and data2 files are structured: Part 1 - Pointer and file name table Part 2 - Actual data of all files Part 1 - Pointer and file name table This data contains all the pointers of all files, as well as their file names. Each table row consists of: Offset Endianness Type 0x0-3 Big Endian Data location offset 0x4-7 Big Endian File size 0x8-1B Big Endian Namespace data Namespace data This data contains the filename data, and all filenames can only be in ASCII format. Filenames can only be a maximum of 19 characters long, every filename always ends with a 00 value byte and must be in the namespace data in order for it to function properly. Anything after the 00 valued byte through to offset 0x1B will be what we'll refer to it as "junk text". Junk text is the remains of what used to be a previous file that existed on that entry before it was overwritten by a different filename, either through renaming or removal of a file during development. So essentially it would be development leftovers. It's possible to create a program that would re-replicate the same type of junk data results though file namespace overwriting. For example, we have a file called adev_app_icon.tex, then we name it "app_icon.tex", it would look like this: "app_icon.tex tex". Alternatively if we renamed or removed "bg_event.sed", the file name in the table row below it called "bg.swd" would take priority and overwrite the text (and file offset data) on that table row and the namespace would look like "bg.swd t.sed", then if the file was renamed again to "b.swd", it would be "b.swd t.sed" which would look like "62 2E 73 77 64 00 00 74 2E 73 65 64 00 00 00 00 00 00 00 00" in hex. This means that an addition of a new file or renaming a file in the archive has the potential to create junk data, overwriting text in an existing entry while leaving some of it there. Part 2 - Actual data Each file data fits into this area as followed: First - File data Second - Line break filling Line break filling This data occurs between each file to show that its sepparate data, it can either be 16 or 32 bytes long, the FF value marks the end of the file data and start of the filling data, all the rest of the filling data is 00 value bytes, after that, the next file begins. The end of the entire data1 or data2 archive is marked with a FF value byte as well, but without the 00 values after it. 32-byte filling data: FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 16-byte filling data: FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Credits: MegaMinerd - For most of the research into filling data
×
×
  • Create New...