I guess encryption and decryption are already possible and work fine.
There are other issues though. They're not exactly the original games. Parts of the iso are slightly modified for running in the virtual console
There are other issues though. They're not exactly the original games. Parts of the iso are slightly modified for running in the virtual console
Well thats what I said
Also why I said we would need Ocarina Cheatcode support before the WIi VC Channel to make DKCR and NSMBWii to support it.I will take a look into the apploader in the iso. I still believe that the current tools can only use the isos itself created by converting NFS files to ISO.
If someone has the EGGS Header figured out then make it public here and not in the Discord
Didn't you see there's already a tool for converting back and forthWell thats what I said
I will take a look into the apploader in the iso. I still believe that the current tools can only use the isos itself created by converting NFS files to ISO.
If someone has the EGGS Header figured out then make it public here and not in the Discord
https://gbatemp.net/threads/semi-working-nfs2iso2nfs-convert-nfs-to-iso-and-back.455812
As I said I believe that tool can only use ISOs which were created from itself.
So as other ISOs reload the Wii U I believe that the Tool does not work.
Edit: He says in that topic that the 8 bytes are still unknown BUT I tested it and the Wii U does not care about those 8 bytes. So those 8 bytes are not the reason why custom ISOs dont work.
Last edited by Tock46,
You need to install a Nintendont forwarder on your vWii first somehow (e.g. with Wuphax), then you can load Nintendont directly from the Wii U menu using HBL2HBC and navigate using a GameCube or other HID controller (no Wiimote required).
As for Wii games, only a few games from the eShop can be played with the GamePad at the moment.
D
Deleted User
Guest
Yes I said I highly doubt that its JUST encrpytion at play. meaning more than just encryption has been done to the .nfs files. so yah no duh they are encrpyted
Last edited by ,
D
Deleted User
Guest
I might as well do some experimentation, maybe we can find out the encrpytion key. (it could be possible that the encryption key is already out there.) But with the current stage of wiiu hacking nobody is going to get it done...
D
Deleted User
Guest
true, but again its the EGGS header. As stated before nobody understands that header. no understanding of header, no wii injections. I also completely forgot that program also exists. And It cannot convert a wii iso to a .nfs. It can only convert the .nfs to a .iso and back. And not only that, but this means it would be pointless trying to change the controller as most games that are for the wiiu vc wii games support one controller type. (so for example doesn't accept numchuck inputs for the wii game itself so for example new super mario bros doesn't support classic controller. So even if we flipped that setting on for wiiugamepad emulation it would do nothing.)
Last edited by ,
It can convert any Wii iso. It just encrypts and splits it into smaller parts.
Last edited by piratesephiroth,
D
Deleted User
Guest
I don't think they do, because of the differences in the apploader and tik, as @Foen said.
But they are encrypted and decrypted fine.
After the research I did it I have the feeling that the NFS2ISO tool works and does not create broken NFS files. Even the EGGS Header should be 100% correct.
What I believe is the problem is that in the code folder are rvlt.tik and rvlt.tmd. those are the "same" as the ticket.bin and tmd.bin from the root of the Wii ISO EXCEPT that rvlt.tik has a different byte at 0xE that the ticket.bin from the ISO.
Of the 4 games I looked into one was 0x26 vs 0x39, one was 0x47 vs 0x58, one was 0xC8 vs 0xD7 and the last one was 0x92 vs 0x8D.
Edit: Yep changed the byte to the same as in the iso and the Wii U reloaded like always. So this has to be it
What I believe is the problem is that in the code folder are rvlt.tik and rvlt.tmd. those are the "same" as the ticket.bin and tmd.bin from the root of the Wii ISO EXCEPT that rvlt.tik has a different byte at 0xE that the ticket.bin from the ISO.
Of the 4 games I looked into one was 0x26 vs 0x39, one was 0x47 vs 0x58, one was 0xC8 vs 0xD7 and the last one was 0x92 vs 0x8D.
Edit: Yep changed the byte to the same as in the iso and the Wii U reloaded like always. So this has to be it
Last edited by Tock46,
After the research I did it I have the feeling that the NFS2ISO tool works and does not create broken NFS files. Even the EGGS Header should be 100% correct.
What I believe is the problem is that in the code folder are rvlt.tik and rvlt.tmd. those are the "same" as the ticket.bin and tmd.bin from the root of the Wii ISO EXCEPT that rvlt.tik has a different byte at 0xE that the ticket.bin from the ISO.
Of the 4 games I looked into one was 0x26 vs 0x39, one was 0x47 vs 0x58, one was 0xC8 vs 0xD7 and the last one was 0x92 vs 0x8D.
Edit: Yep changed the byte to the same as in the iso and the Wii U reloaded like always. So this has to be it
Hm. So it's basically xor'ed with 0x1F.
So, if I may ask the obvious question, what's stopping someone from decrypting a Wii VC dump, extracting the fw.img, and cobbling together a cIOS based on its contents?
