Hacking Wii U Hacking & Homebrew Discussion

ShadowOne333 · Jul 23, 2016

AboodXD said:
Just one question, ok?

Who leaked the kernel exploit?
Who was the fist person to notice the leak and how/where did they find it?
Was the leak just an excuse to release the exploit?

I have been asking those questions since day 1...

Keep up, dude.
The 5.5.1 Kernel exploit was leaked by a beta tester.
The user made a thread and basically some sort of deadline for the leak.

Eventually, the leak package was uploaded and confirmed by the devs.
After that they said they would be much more careful with the testers. Basically no one from here hahaha

oumoumad · Jul 23, 2016

AboodXD said:
Just one question, ok?

Who leaked the kernel exploit?
Who was the fist person to notice the leak and how/where did they find it?
Was the leak just an excuse to release the exploit?

I have been asking those questions since day 1...

It was going to be released in matter of days anyway, just one of the pre-release testers leaked it. All of that only means that there won't be anymore pre-release testing and they'll be more careful with whom they share the exploit.

retroben · Jul 24, 2016

Has anyone tried running a dumped/extracted Wii U DK64 copy in PJ64 to see what would happen?
Does it still run at 60fps without any lag if it runs at all?
I am desperately looking for details in case it proves useful to the original DK64 version to achieve at least the same issue result of challenging timers instead of ungodly ones caused by the lagfix code I stumbled on.
With the GS code's positive results,it makes everything including oranges and camera shots lagless while breaking the counter timer speeds,making all minigames impossible except the minecart TNT one becoming easy cake.

VinsCool · Jul 24, 2016

retroben said:
Has anyone tried running a dumped/extracted Wii U DK64 copy in PJ64 to see what would happen?
Does it still run at 60fps without any lag if it runs at all?
I am desperately looking for details in case it proves useful to the original DK64 version to achieve at least the same issue result of challenging timers instead of ungodly ones caused by the lagfix code I stumbled on.
With the GS code's positive results,it makes everything including oranges and camera shots lagless while breaking the counter timer speeds,making all minigames impossible except the minecart TNT one becoming easy cake.

The rom is 1:1 identical to the clean (U) [!] Dump. So are all n64 games I've dumped so far.

retroben · Jul 24, 2016

Thanks for the info.
What is the container made out of I wonder? The customizations it runs on,or inbuilt emulation mods.
It hurts not knowing just how it got running at a full 60fps with perfect physics and the rest of the conditions for stable lagless.
Perhaps there could be rdram patching happening at runtime of it on Wii U.

EclipseSin · Jul 24, 2016

retroben said:
Thanks for the info.
What is the container made out of I wonder? The customizations it runs on,or inbuilt emulation mods.
It hurts not knowing just how it got running at a full 60fps with perfect physics and the rest of the conditions for stable lagless.
Perhaps there could be rdram patching happening at runtime of it on Wii U.

Well, since I spent the 3 seconds to open the config file, I guess I'll show it to you. As for the VC having it's own patches as well, I guess it's possible since there are different revisions of them.

Code:

;DonkeyKong E
[RomOption]
;BackupType 0 Auto 1 SRAM 2 Flash 3 EEPROM
BackupType = 3
;BackupSize  2048 16K 4K 512
BackupSize = 2048
Rumble = 1
RetraceByVsync = 0
UseTimer = 1
AIUseTimer = 0
;TicksPerFrame = 788000
RSPMultiCore = 1
;PlayerNum = 4
PDFURL = "http://m1.nintendo.net/docvc/NUS/USA/NDOE/NDOE_E.pdf"

;0x8076a0b1 state

;0x8076a0A8 old stage
;0x8076a0AC old stage door num

;0x807444E4 next stage
;0x807444E8 next stage door num

;0x807ed560 Jet little game HighScore
[Cmp]
W32OverlayCheck = 0

[Sound]
Resample = 31900

[Input]
StickModify = 3

[Idle]
Count = 2
Address0 = 0x80000A04
Inst0 = 0x1462FFFF
Type0 = 1
Address1 = 0x806008FC
Inst1 = 0x0306082B
Type1 = 1

[Render]
CopyDepthBuffer = 1
FirstFrameAt = 1000


[Cheat]
;Banana Little
Cheat0 = 1
Cheat0_Addr = 0x807FC95A
Cheat0_Value = 0x004a004a
Cheat0_Bytes = 4
Cheat1 = 1
Cheat1_Addr = 0x807FC95E
Cheat1_Value = 0x004a004a
Cheat1_Bytes = 4

Cheat2 = 1
Cheat2_Addr = 0x807FC9B8
Cheat2_Value = 0x004a004a
Cheat2_Bytes = 4
Cheat3 = 1
Cheat3_Addr = 0x807FC9BC
Cheat3_Value = 0x004a004a
Cheat3_Bytes = 4

Cheat4 = 1
Cheat4_Addr = 0x807FCC4B
Cheat4_Value = 8
Cheat4_Bytes = 1

Cheat5 = 1
Cheat5_Addr = 0x807FCA74
Cheat5_Value = 0x004a004a
Cheat5_Bytes = 4
Cheat6 = 1
Cheat6_Addr = 0x807FCA78
Cheat6_Value = 0x004a004a
Cheat6_Bytes = 4

Cheat7 = 1
Cheat7_Addr = 0x807FCA16
Cheat7_Value = 0x004a004a
Cheat7_Bytes = 4
Cheat8 = 1
Cheat8_Addr = 0x807FCA1A
Cheat8_Value = 0x004a004a
Cheat8_Bytes = 4

Cheat9 = 1
Cheat9_Addr = 0x807FCAD2
Cheat9_Value = 0x004a004a
Cheat9_Bytes = 4
Cheat10 = 1
Cheat10_Addr = 0x807FCAD6
Cheat10_Value = 0x004a004a
Cheat10_Bytes = 4

As you can see, they patch games from the configuration file. Some games even have vertex patches in their config files. Probably some kind of math correction for the VC or something, not sure. Don't care that much.

Bug_Checker_ · Jul 24, 2016

NWPlayer123 said:
Nintendo Land was the first game we/I ever modding, it's what I developed sarcextract/sarcpack v1 with, but I haven't had much motivation with making better tools, slowly working on some BFRES stuff and then I'll probably move onto a GUI for SARCTools

@NWPlayer123, if I might ask you a question with a bit of context: while looking at a post by @jebediah in this thread

https://gbatemp.net/threads/【tutori...-a-quick-dirty-way.415344/page-2#post-6100655

jebediah said:
@Masterwin Well done

I'm trying to get the DLC characters in the party (replacing original ones), but I have *MASSIVE* difficulties getting the voices to work, the main reason being the community seems to have no working SARC packer available which would allow us to pack DLC voices inside original character's voice archives. SARC packers used for the 3DS don't work because they use little endian byte order mark instead of the big endian mark used by the Wii U, and the one created by NWPlayer123 included in SARCTools doesn't achieve packing in a way that the Wii U recognises. A simple extract and repack without editing the files shows the resulting SARC is not the same (different file size, different hex values in the header, and different 00 spaces at recurring locations within the archive). NWPlayer123's SARC extractor works like a charm though, but we need a working packer as of today.

I gave a go at the sarc.py script made by ObsidianX as part of the 3dstools utilities, as it claims it can create SARC archives using a big endian option. However, either I can't make it work (which is very well possible) or the big endian option isn't working, as NWPlater123's SARCExtract tells me the resulting archive was written in little endian indeed.

Last option if we can't pack: hex editing the sarc directly, where the _param.bin and rest of the .bfwav file and content appear as clear as when extracted. I desperately made a fool of myself messing around with this, but to no avail. You have the right to laugh now

So the only thing I managed to do was to extract an original character's menu voice archive (the sound they make at selecting screen, which lies in a separate archive in content/audio/driver_menu), replace the .bfwav sound file with that of a DLC character, rename it as the original character's file, repack using NWPlayer123's SARCPack, and then using a hex editor to replace its header with the one found in the original character archive (from first byte to the "FWAV" mark where the sound file's data begins). This way was the only way to get the selection screen voice to work.

However, the same doesn't work with the race voice archives found in content/audio/driver, and it would be virtually impossible to match the 70+ .bfwav file names from DLC to original characters anyway, as their number and names vary so much from character to character (especially Tanuki Mario's which are completely different from the rest).

Anybody getting aboard this boat, share your ideas!

I recalled what you earlier had said:

NWPlayer123 said:
Just remembered to post this, I figured out what the 3rd word (0x08-0x0C) is in Yaz0 compressed Wii U files. Apparently it tells the Wii U the padding size of the SARC inside. Most of the Nintendo Land ones pad to 0x2000, so you need to change that third word to 0x2000 as well. That said, this version lets you do exactly that. I added an optional third argument to specify the padding size (in decimal), or it defaults to 0x100. I've triple checked everything (with testing from Cafiine) and this should be all you need to do basic repacking of archives. As I discovered, drag and drop doesn't work with SARCPack (but does with yaz0enc) still.
SARCPack Source Code
SARCPack 32-BIT EXE
Yaz0enc with source
HxD Hex Editor (my recommended hex editor for Windows)

If you wanted to do that, then just update. You'd need a CFW for when they inevitably patch our stuff.

Anyway,on your github, you do not have the history to all the revisions listed to SARCPack.py
https://github.com/NWPlayer123/WiiUTools/tree/master/SARCTools

versions
SARCPack-0.1.py
SARCPack-0.2.py
SARCPack-0.2.1.py

the dropbox link for SARCPack-0.2.1.py and the github are nearly identical but slightly different.

the dropbox version has this extra added line:
padding = int(padding)

Code:

class SimpleArchive(object):
    def pack(self, folder, padding):
        padding = int(padding)
        '''Generate string list for finding and writing'''

my question(s):
what version is the dropbox SARCPack.py?
And what version is the github SARCPack.py?

retroben · Jul 24, 2016

Tried the A04 and 6008FC addresses as GS codes accordingly on Mupen AE,and it seemed like it tamed the bone displacement a bit,though it still happens,but it no longer freaks out in front of Cranky's Lab at the intro map,yet to have seen Creepy Castle's heights where it also likes to go crazy.

If DK64 could boot on Cemu,someone could attempt to essentially get the rdram at any given moment and mention where.
This last step could very well lead to several benefits in emulating it,especially if Cemu emulates it well enough to prevent bad rdram values for a clean dump of only that 800000 sized section.
Or if there's hacking tools for direct system level access,someone could dump the rdram that way on their hacked Wii U!
And those settings also seem to be important to attempt replicating in the emulator side.
Where could the 60fps part be though?

retroben · Jul 25, 2016

It seems displacement is luck based,turns out those two codes are at the same values already according to PJ64's memory viewer and several of my code attempts were in vain despite erradicating lag.
From a stream showing the lagfix code on an actual console,it has the time counter staying at the correct pace,now I know for sure the minigame timer emulates badly.
From what I can gather,the Wii U VC's emulator is what mods the game to run at 60fps and is a proper equivalent to a stronger version of a real N64 to deal with the lagging.

Bug_Checker_ · Jul 25, 2016

retroben said:
It seems displacement is luck based,turns out those two codes are at the same values already according to PJ64's memory viewer and several of my code attempts were in vain despite erradicating lag.
From a stream showing the lagfix code on an actual console,it has the time counter staying at the correct pace,now I know for sure the minigame timer emulates badly.
From what I can gather,the Wii U VC's emulator is what mods the game to run at 60fps and is a proper equivalent to a stronger version of a real N64 to deal with the lagging.

Have you tried removing the comment indicator from:
;TicksPerFrame=788000
If that did not work then double it
If that did not work then double it again.
If you are going in the wrong direction then start with original number and halve it, ect.

AboodXD · Jul 25, 2016

Bug_Checker_ said:
@NWPlayer123, if I might ask you a question with a bit of context: while looking at a post by @jebediah in this thread

https://gbatemp.net/threads/【tutorial】how-to-play-mario-kart-8-dlc-tracks-in-loadiine-in-a-quick-dirty-way.415344/page-2#post-6100655

I recalled what you earlier had said:

Anyway,on your github, you do not have the history to all the revisions listed to SARCPack.py
https://github.com/NWPlayer123/WiiUTools/tree/master/SARCTools

versions
SARCPack-0.1.py
SARCPack-0.2.py
SARCPack-0.2.1.py

the dropbox link for SARCPack-0.2.1.py and the github are nearly identical but slightly different.

the dropbox version has this extra added line:
padding = int(padding)

Code:

class SimpleArchive(object): def pack(self, folder, padding): padding = int(padding) '''Generate string list for finding and writing'''

my question(s):
what version is the dropbox SARCPack.py?
And what version is the github SARCPack.py?

I don't feel like reading the whole source code thing so I could know what "padding" is used for, but I can tell you one thing for sure, one of the versions will definitely throw an error.

Only 2 possibilities.

If the github ver was the one to throw an error, it would be that "padding" must be an integer, so he added the line "padding = int(padding)" in the dropbox ver.
If the dropbox ver was the one to throw an error, it would be that "padding" being as an integer is invalid, so he removed the line "padding = int(padding)" from/in the github ver.

I think that 1 is more possible than 2. I'm an experienced python programmer and I know that adding a thing like "padding = int(padding)" while knowing that it would cause an error is just dumb, and I know NWPlayer123 isn't dumb, that's why I think that 1 is more possible than 2.

retroben · Jul 26, 2016

Bug_Checker_ said:
Have you tried removing the comment indicator from:
;TicksPerFrame=788000
If that did not work then double it
If that did not work then double it again.
If you are going in the wrong direction then start with original number and halve it, ect.

I'm not doing so on Wii U,but the original N64 in emulation on PJ64,as I am trying to solve the riddle of how it runs the game at 60fps lagless without game breaking issues via the kindness of anyone that can upload/PM me DK64's RDRAM section when preferably standing idle at DK Isles,from Wii U via hacked or (if it works yet) Cemu via Cheat Engine.

I wonder if I can find the default ticks per frame address within rdram and manipulate it to my will?
So even if any of the config settings affect rdram values,I may be able to utilize that to get 60fps and lagless to work on N64 emulators.
The farthest I have gotten is uber smooth 60fps with unplayabe half strength physics,and broken transitions causing running softlocks.

VinsCool · Jul 26, 2016

retroben said:
I'm not doing so on Wii U,but the original N64 in emulation on PJ64,as I am trying to solve the riddle of how it runs the game at 60fps lagless without game breaking issues via the kindness of anyone that can upload/PM me DK64's RDRAM section when preferably standing idle at DK Isles,from Wii U via hacked or (if it works yet) Cemu via Cheat Engine.

I wonder if I can find the default ticks per frame address within rdram and manipulate it to my will?
So even if any of the config settings affect rdram values,I may be able to utilize that to get 60fps and lagless to work on N64 emulators.
The farthest I have gotten is uber smooth 60fps with unplayabe half strength physics,and broken transitions causing running softlocks.
I will edit in a GameShark address after I find it again.

So if I understand correctly, you would need a ram dump with the game running on WiiU

If so, I can get you a RAM dump of it, if you want.

retroben · Jul 26, 2016

Thanks!

Edit:Seem to have found it.
The double pace one would go perfect with a code that slows down gameplay by half to sync it back up as long as it doesn't rebreak physics or drop the frames.

Sixty Frames
8060F3A3 0007
Still subject to orange bomb/fairy camera lag and if "lag fix" code 8000EFD2 000D is used,most devices can't even hit full speed unfortunately,so no clean test results.
And this code 80629332 0044 works around transitions on 60fps by skipping them.

VinsCool · Jul 26, 2016

retroben said:
Thanks!
I am having complications in finding the exact code that kept a non-stop 60fps throughout the entire game with said broken issues,either it being broken or double pace with correct physics.
The double pace one would go perfect with a code that slows down gameplay by half to sync it back up as long as it doesn't rebreak physics or drop the frames.

I see.

I'll dump my WiiU RAM with the game running tonight. I'll make sure to be standing idle at the DK isles, and PM you the file once it is done

Billy Acuña · Jul 26, 2016

Anything new with IOSU exploit or still a myth?

OctopusRift · Jul 26, 2016

Billy Acuña said:
Anything new with IOSU or still a myth?

IOSU isnt a myth, it's on your wii u right now!

Billy Acuña · Jul 26, 2016

OctopusRift said:
IOSU isnt a myth, it's on your wii u right now!

Edit to IOSU exploit*

CosmoCortney · Jul 26, 2016

it's neither a myth. just nothing new about its progress

Billy Acuña · Jul 26, 2016

CosmoCortney said:
it's neither a myth. just nothing new about its progress

Something that I learned from the 3DS scene is never trust on private work.

Hacking Wii U Hacking & Homebrew Discussion

QVID PRO QVO

Well-Known Member

Member

Persona Secretiva Felineus

Member

Ignorant Wizard

Well-Known Member

Member

Member

Well-Known Member

I hack NSMB games, and other shiz.

Member

Persona Secretiva Felineus

Member

Persona Secretiva Felineus

Well-Known Member

GBATemp's Local Octopus, Open 9am-2am. "Not Yet"

Well-Known Member

i snack raw pasta and chew lollipops

Well-Known Member

Similar threads

Popular threads in this forum