Hacking *~Auto Injectuwad Injector~* -kept updated-

  • Thread starter Thread starter Nightstalker
  • Start date Start date
  • Views Views 223,793
  • Replies Replies 542
mario tennis is reported as failure.

but maybe u can try with this release and report back.
 
Thanks, so, all wad packers are using the same code. That explains it partially at least. The one you were using in 2.x never gave the same file size twice, this one at least does that much. If I could make a patcher that deletes those exact bytes, I'd have it made -- patching the 06 at 0B to 00 is simple and can be done using just about anything, it's finding a patcher that will allow me to delete the other 64 bytes that's a pain.
 
uhh...... what are u talking about? version 2.x and even the old cmd prompt version always generated same size files for me!
why do you want to delete some bite some bytes of?
 
No one has had success on injecting Mario Party 2 yet?!?
unsure.gif
 
Kazuma77 said:
Thanks, so, all wad packers are using the same code. That explains it partially at least. The one you were using in 2.x never gave the same file size twice, this one at least does that much. If I could make a patcher that deletes those exact bytes, I'd have it made -- patching the 06 at 0B to 00 is simple and can be done using just about anything, it's finding a patcher that will allow me to delete the other 64 bytes that's a pain.

The faulty wads have more errors than just a 64 byte trailer. They are encrypted incorrectly, attempting to decrypt them results in corrupt app files.
 
zant said:
mario tennis is reported as failure.

but maybe u can try with this release and report back.I just tested several ROMs of both Mario Tennis and Mario Golf injected into Paper Mario. All of them hung on the Classic Controller screen. Bummer.

QUOTENo one has had success on injecting Mario Party 2 yet?!?
unsure.gif
The Wiki says it doesn't work.
 
I wonder if the emulator is stored where the rom is as well? Mario Picross (PAL) has an emulator in that forces the WAD file to run under 60HZ instead of 50HZ. If it turns out to be the same size as the 50HZ emulator that SNES WAD files come with, providing the data is the same size, it might be possible to replace the emulator data.
 
RadioShadow said:
I wonder if the emulator is stored where the rom is as well? Mario Picross (PAL) has an emulator in that forces the WAD file to run under 60HZ instead of 50HZ. If it turns out to be the same size as the 50HZ emulator that SNES WAD files come with, providing the data is the same size, it might be possible to replace the emulator data.
All you have to do is edit the file table sizes, size of file doesn't matter.
 
I never said it was a 64 byte trailer. The exact locations of the extra bytes are ee, 373, 422, 45A, 534, 954, and A47 to A80. They're actually all near the beginning of the file. And yes, once removed, and that 06 byte at 0B is changed to 00, they work. At least that's what's happening here. And they unpack fine. Tested and working with both Final Fantasy and Phantasy Star II (not saving, used Comix Zone, tried Sonic 3 and it didn't work, might try it manually later).

That's nice zant, you must have a different processor or something. I can't believe the person who wrote the repacking tool made it CPU-specific. Apparently that's the cause of it though. My repacks are always 64 bytes larger, the old repacker gave me random sizes. As explained above, removing these causes everything to line up when compared with working hacked wads of the same games (how I figured this out). The games both play and unpack fine when this is done. I'd like to know wtf causes yours to work right without having to do this, any details you can provide about your system might be taken into account when I build my next PC. Then again, it could be OS-based for all I know, I've heard of people switching and it working. I'm about to switch to 2K3 because XP is acting up and seems to require "major surgery" once a month, so this problem might solve itself when I do.
 
Kazuma77 said:
I never said it was a 64 byte trailer. The exact locations of the extra bytes are ee, 373, 422, 45A, 534, 954, and A47 to A80. They're actually all near the beginning of the file. And yes, once removed, and that 06 byte at 0B is changed to 00, they work. At least that's what's happening here. Tested and working with both Final Fantasy and Phantasy Star II (not saving, used Comix Zone, tried Sonic 3 and it didn't work, might try it manually later).

I stand corrected! Thanks for pointing this out, I'm looking through a faulty wad now and see the extra bytes, but they are at slightly different addresses: ee, 372, 420, 456, etc...Also, the extra bytes always seems to be 0D (so far). If you find any other info post it. Thanks again.

EDIT: It seems the the 0D always precedes a 0A. Oddly, 0D0A is the byte pattern for end of line in windows. 0D is the byte for end of line in unix (and the rest of the sane computer world). I wonder if there is a version of a library module in the windows system that does some strange string formatting. Can you explain what you found in bytes A47-A80, or maybe even upload that chunk is a .bin somewhere?
 
RadioShadow said:
I see. Which file contains the table data?
Well, the 00000005.app/.des is an archive, near the top it lists the filesizes of all the files (rom, manual archive, etc...) and their offset. Only propblem is that the rom is usually near the start, so all offsets after the rom must edit as well.
And the tmd.x file contains the size of the 00000005.app/.des file, this also needes updating.
 
Yes, if you delete as you go they're at ee, 372, 420, 457, 530, 94F, and A41 to A7A (the A41 to A7A are just extra 00s -- there's an 01 00 01 series in the middle of what otherwise is a field full of 00s that starts at A41 on a correct wad, so I took the 58 bytes before the 01 out, I have no way of knowing which 00s are the actual added ones, though technically it doesn't matter, it just has to line up). And yes, those first 6 are all 0D. Very odd.
 
Yeah silly me, of course offsets change as I delete....ha. What system types have you tried? I'm wondering if these incorrect bytes are always at the same offset regardless of wad size/wad type.
 
So far just NES and Genesis, but I'm inclined to believe it will be the same with SNES and TG. It's all so close to the start of the file I have reason to believe all these errors occur way before you get anywhere close to the emulator or ROM, in fact, it's highly likely that all .wads are identical up to that point.
 
(Thanks for the other problem)
More problems happened for me...

1) Injecting "Zelda Master Quest" from any source into any "Zelda Ocarina of Time" wad doesn't create the wad, it juste creates the 000blabla documents and the other things. But no wad.
2) I can't freaking delete V3 from my PC... ARGH
3) I like waffles

How can I fix 1 and 2?
 
Doom Chaos said:
(Thanks for the other problem)
More problems happened for me...

1) Injecting "Zelda Master Quest" from any source into any "Zelda Ocarina of Time" wad doesn't create the wad, it juste creates the 000blabla documents and the other things. But no wad.
2) I can't freaking delete V3 from my PC... ARGH
3) I like waffles

How can I fix 1 and 2?

1) Not sure
2) Ctrl+Alt+Delete->Processes->End Auto Inject
3) Liking waffles is a problem?
 
1) When I go look at the Injection List, it says they all work... And where can I get the WORKING ones?
2) Thanks ^^
3) Probably not

EDIT: I found my problem. I was using ":" in the injected wad name.
Well I don't think I have anything that doesn't work for me. Thanks ^^
 

Site & Scene News

Popular threads in this forum