I copied it all to notepad++ and then used this regex to replace with blank --How do you select and copy the hex values from HashTool without the offsets on the left?
Code:
@.......:
I copied it all to notepad++ and then used this regex to replace with blank --How do you select and copy the hex values from HashTool without the offsets on the left?
@.......:
Any idea if it allows drag and drop?
hope this would help someone understand
No, you need to convert the heximal values to decimal values
Any idea if it allows drag and drop?
It's supposed to be incredibly user-friendly. I can't say for certain, but probably.
If you want to talk with the developer, maybe PM Gericom about it. He might be able to squeeze in support for easy Virtual Console extraction and injection. Don't take my word for it, though. I'm not him.
Sorry for all the PM's Gericom. I love you.
romfs generation #19That's a nice idea indeed. I had not come up with that, but it should be rather simple to implement.
I might have a look at the romfs format, to make unpacking and packing possible. (with correct hashes ofc)
https://github.com/3DSGuy/Project_CTR/issues/19applestash said:I'm opening this to explain the issue, and so anyone checking the repo will know when it's sorted (when this is closed)
romfs_gen.c functions do not return correct values
u32 GetFileUTableIndex(romfs_buildctx *ctx, fs_file *file)
u32 GetDirUTableIndex(romfs_buildctx *ctx, fs_dir *dir)
Details:
The romfs filesystem format was mostly RE'd by neimod, with the exception of parts of the romfs header and file/dir "weird_offsets". When a file or directory is "entered" in the romfs by Nintendo's makerom, their entry offset is also recorded in the romfs header. The "weirdoffset" in file/dir entries is actually the value in the romfs header where it's offset is supposed to go. You can trace weird offsets until you reach a file/dir entry with 0xfffffffff for it's weird offset, that entry is the first one to use that offset slot in the romfs header. How Nintendo's makerom "decides" which offset slot in the romfs header to use for each entry is unknown, but it isn't random. The functions listed above "decide" incorrectly which offset slot for a given entry.
[CCI ERROR] 'CardDevice: NorFlash' can only be used with save-data sizes: 128K & 512K
[RESULT] Failed to build CCI
Apparently some people are able to decrypt the 7.x games.
http://www.neogaf.com/forum/showpost.php?p=130232372&postcount=9124
Apparently some people are able to decrypt the 7.x games.
http://www.neogaf.com/forum/showpost.php?p=130232372&postcount=9124
Well looking at that HCS forum Team Fail did upload all the raw music files and the folder of it. So I would assume they actually did it.They coulda easily just used the sound player and the audio jack.
But it isn't publically possible yet though. Hopefully it will in the future.
For those you looking to rebuild the romfs using the source above is a good place to start that along with the information in this thread should be enough to repack the romfs. As for romfs generation I think I am starting to see a pattern with the weird offsets and I will probably look into romfs generation when I am finished coding my tool.romfs generation #19
https://github.com/3DSGuy/Project_CTR/issues/19
If any one of you manages to figure it out please be sure to submit a Pull Request.
snip
Good news for you then as my tool already does this.How about the ability to repack roms with zero keys with the same settings as the original cci? This means, without the use of rsf files