Hacking [POC] Removing Update Nag on EmuNAND

[Datalogger]

Well, you helped a lot!


Good to hear! The problem with this method, right now, as I understand it, is that you first have to get the update nag to get an 'updatesave' that is properly setup to block future updates. You didn't manually edit it, correct? There's also no tool in existence that can actually properly this file. Duh... Another question: when the update nag is blocked, it won't download any of the update files to your SysNAND, EmuNAND, correct?

As of now, yes you would need to take the update then copy the one file to a "Clean" NAND to keep it from updating.

This is more a "Proof of Concept" than a viable solution in itself.
What I was looking for was a clear solution to being able to stop the update and not leave any "Garbage" files behind.
It all came down to this one file 688KB file.

And yes, changing this one file keeps the NAND from downloading any update files, but it still allows you to use the 'System Information" to perform a manual update if you want to force an update.

 

[d0k3]

As of now, yes you would need to take the update then copy the one file to a "Clean" NAND to keep it from updating.

This is more a "Proof of Concept" than a viable solution in itself.
What I was looking for was a clear solution to being able to stop the update and not leave any "Garbage" files behind.
It all came down to this one file 688KB file.

And yes, changing this one file keeps the NAND from downloading any update files, but it still allows you to use the 'System Information" to perform a manual update if you want to force an update.

Alright, I've researched this some more, and it turns out trying to manually edit these files is almost hopeless. Duh :/. There's just too little known about this yet. One thing that I am still interested in, though - did you try manually editing these files?
What happens if you manually edit the file? The relevant offsets are 0x0000C058 (8 bytes, all zero in b4) and 0x0000C060 (1 byte, it's possible this only needs to be incremented). Everything else, as I said, is hashes and control data. Now, I think this could be limited even farther - for example it could be enough to edit just one byte in the 0x0000C058 offset, or to just increment 0x0000C058. No idea. It is very much possible there will be problems after teh edit, though.

 

[Datalogger]

Alright, I've researched this some more, and it turns out trying to manually edit these files is almost hopeless. Duh :/. There's just too little known about this yet. One thing that I am still interested in, though - did you try manually editing these files?
What happens if you manually edit the file? The relevant offsets are 0x0000C058 (8 bytes, all zero in b4) and 0x0000C060 (1 byte, it's possible this only needs to be incremented). Everything else, as I said, is hashes and control data. Now, I think this could be limited even farther - for example it could be enough to edit just one byte in the 0x0000C058 offset, or to just increment 0x0000C058. No idea. It is very much possible there will be problems after teh edit, though.

I will spend some time on this over the weekend.
I was able to make many changes to the /0001002c/00000000 file and it never "crashed" the 3DS, and I have narrowed it down a little but it needs more testing before I file a report.

It's very time-consuming to test as I have to re-encrypt and re-write the entire emuNAND every time I want to test something with it.

I was thinking of maybe looking into some other way to inject it, like have a folder on the SDCard named "Inject_Me" then I could put in the filepath and file I wanted to inject for testing.
In this case it would be "/Inject_Me/data/[ID1]/sysdata/0001002c/00000000"

More of a custom testing tool, not for public release.
...just thinking about it, haven't looked into the details of how to do it just yet....

 

[d0k3]

I will spend some time on this over the weekend.
I was able to make many changes to the /0001002c/00000000 file and it never "crashed" the 3DS, and I have narrowed it down a little but it needs more testing before I file a report.

It's very time-consuming to test as I have to re-encrypt and re-write the entire emuNAND every time I want to test something with it.

I was thinking of maybe looking into some other way to inject it, like have a folder on the SDCard named "Inject_Me" then I could put in the filepath and file I wanted to inject for testing.
In this case it would be "/Inject_Me/data/[ID1]/sysdata/0001002c/00000000"

More of a custom testing tool, not for public release.
...just thinking about it, haven't looked into the details of how to do it just yet....

I'll add an experimental injection / dumping function for that file into Decrypt9. It would be experimental in the way that we don't know yet if it can be useful. No problem, you just could have asked .

 

[d0k3]

... and done! @Datalogger, check my Decrypt9 on Github. You'll need to compile yourself. Proper release coming up!

 

[Datalogger]

... and done! @Datalogger, check my Decrypt9 on Github. You'll need to compile yourself. Proper release coming up!

Already checked out, compiled and ready to test.

Thanks for adding in the Testing Tool!
That will save a lot of wear and tear on my SD cards

 

[Datalogger]

@d0k3
Do you know why I would be unable to use the Extractor/Injector on my N3DS? (worked OK on my O3DS)
It's failing at the end of the Fragmentation Check, marked below "//<-- Fails right here"

When reading 0001002c,before it fails it has the first 0x40000 bytes of the file correct so it found the right file.

    // check for fragmentation
   if (found && (*size > cluster_size)) {
        if (fat_size / fat_count > 0x100000) // prevent buffer overflow
            return 1; // fishy FAT table size - should never happen
        DecryptNandToMem(buffer, p_offset + fat_start, fat_size / fat_count, partition);
        for (u32 i = 0; i < (*size - 1) / cluster_size; i++) {    
           if (*(((u16*) buffer) + fat_pos + i) != fat_pos + i + 1) //<-- Fails right here  
                return 1;                                         
        } // no need to check the files last FAT table entry
    }
    return (found) ? 0 : 1;

 

[d0k3]

@d0k3
Do you know why I would be unable to use the Extractor/Injector on my N3DS? (worked OK on my O3DS)
It's failing at the end of the Fragmentation Check, marked below "//<-- Fails right here"

When reading 0001002c,before it fails it has the first 0x40000 bytes of the file correct so it found the right file.

    // check for fragmentation
   if (found && (*size > cluster_size)) {
        if (fat_size / fat_count > 0x100000) // prevent buffer overflow
            return 1; // fishy FAT table size - should never happen
        DecryptNandToMem(buffer, p_offset + fat_start, fat_size / fat_count, partition);
        for (u32 i = 0; i < (*size - 1) / cluster_size; i++) {   
           if (*(((u16*) buffer) + fat_pos + i) != fat_pos + i + 1) //<-- Fails right here 
                return 1;                                        
        } // no need to check the files last FAT table entry
    }
    return (found) ? 0 : 1;

Could you defragment your CTRNand on PC and infect it back? I know you've got a NANDmod, so this shouldn't be a problem. My FAT routines don't handle fragmentation yet, and normally there should no fragmentation on a SysNAND not modified by rxTools / GW (not 100% sure). I'll think about handing fragmentation later.

 

[Datalogger]

Thanks for the suggestion, I tried that but No-Go.
sysNAND or emuNAND on the N3DS fail to copy it 100% of the time.
O3DS works 100% of the time, but I don't want to use it for this since it doesn't (yet) have a HardMod.

Seems odd that all of the other files never fragment, just this one.
The ticket.db is over 35MB and never has any problem, wonder why so much with this little 2MB file?

Either way, I'll keep monitoring/testing the manual way with the N3DS.
So far it's been over a week "unprotected" and no sign of it even trying to download the updates.

I'm going to have my O3DS HardMod'ed so I can use it for this since it doesn't have any issues fragmenting the file.
(Right now only my N3DS has a mod.)

 

[d0k3]

Thanks for the suggestion, I tried that but No-Go.
sysNAND or emuNAND on the N3DS fail to copy it 100% of the time.
O3DS works 100% of the time, but I don't want to use it for this since it doesn't (yet) have a HardMod.

Seems odd that all of the other files never fragment, just this one.
The ticket.db is over 35MB and never has any problem, wonder why so much with this little 2MB file?

Either way, I'll keep monitoring/testing the manual way with the N3DS.
So far it's been over a week "unprotected" and no sign of it even trying to download the updates.

I'm going to have my O3DS HardMod'ed so I can use it for this since it doesn't have any issues fragmenting the file.
(Right now only my N3DS has a mod.)

Well, if it is not fragmented and you get that, that error needs to be fixed. If it is fixed size (which I strongly assume it is), it is almost impossible that it fragments after you defragmented it. On my N3DS, there was never any trouble dumping that file. Could you try another defragmentation tool and/or make sure there really is no fragmentation? If the problems persist we can try something to find out the cause.

EDIT: Maybe it helps if we compare sizes? On my N3DS, the file is exactly 2MB (0x200000 byte).

 

[Syphurith]

A temporary and automatic theorm for blocking the system update checking is proposed.
Manipulation of Code.bin is involved, and 3dstool and customized tools are written for the deed.
Since the URLs for checking the updates are also inside the code.bin of nim module, this could be patched.
In major 3 steps would be taken.
1.Get .app/.cxi, from decrypted NAND, or from a decrypted CIA. Then unpack it with 3dstool.
2.Modify the decompressed code.bin for whatever needed.
3.Compress it, create exefs header and pack all those back into .app/.cxi, conversion to CIA is possible.
The CIA is touched, and enviorment with signature checks patched needed for installation.
This could also be used for further translation or whatever deed that would touch the code.bin.

Tools that ever used.
1.3dstool, author dnadsw. Latest version could be found in the github repo, "release".
2.CompressCode. Use this to compress the uncompressed one, old file would overwritten. With help info.
3.FixExefsHeader. Used for generating the exefs header for 3dstool, with compressed version of code.bin. With Help info.
CompressCode and FixExefsHeader are GPL licensed and republishing with source is appreciated. Modification is always allowed.
EDIT: Forgot to mention the blz.* files belong to its own author. So GPL may not suite that easy..

#Unpack the already decrypted .cxi "00000000.cxi". "exefs.O" would be there
3dstool -xvtf cxi 00000000.cxi --header ncch --exefs exefs.O --romfs romfs --exh exh --logo logo --plain plain
#Unpack exefs to "exefs" folder. code.bin would be decompressed ("u").
3dstool -xvtfu exefs exefs.O --exefs-dir exefs
#Now modify the code.bin.
#Compress code.bin. Decompressed one is now overwritten.
compresscode exefs\code.bin
#Generate new exefs header as "exefs.hdr".
FixExefsHdr exefs.hdr exefs
#Pack the exefs back to "exefs.N".
3dstool -cvtf exefs exefs.N --exefs-dir exefs --header exefs.hdr
#Pack the .cxi back to "00000000.modified" with 3dstool.
3dstool -cvtf cxi 00000000.modified --header ncch --exefs exefs.N --romfs romfs --exh exh --logo logo --plain plain

The detailed steps above could be used, noticing the lines beginning with #.

 

[Karuta]

Is there a way to remove the update nag without a pre-nag backup of my EmuNAND?

 

[Cataklysm]

Came to this thread due to having the exact problem listed: Emunand nagging to update.

However, being the total simpleton I am, I can't exactly differentiate which folder is which in terms of emunand vs sysnand, so backing up / following instructions proves quite difficult! That, and I can't exactly get a pre-nag backup of emunand either. Does the inject method work? People haven't been really reporting back, haha

 

[Urbanshadow]

Came to this thread due to having the exact problem listed: Emunand nagging to update.

However, being the total simpleton I am, I can't exactly differentiate which folder is which in terms of emunand vs sysnand, so backing up / following instructions proves quite difficult! That, and I can't exactly get a pre-nag backup of emunand either. Does the inject method work? People haven't been really reporting back, haha

I usually do it by size. If you installed some titles in emunand but you are a sysnand purist like me and it's clean, the emunand folder (whatever ID) should be greater in size, as installed titles get stored there. Make then a text file on SD root telling which ID is which nand and there you have it.

 

[Cataklysm]

I usually do it by size. If you installed some titles in emunand but you are a sysnand purist like me and it's clean, the emunand folder (whatever ID) should be greater in size, as installed titles get stored there. Make then a text file on SD root telling which ID is which nand and there you have it.

Considering the content I've got installed on the Emunand, this makes a lot more sense.

Thanks for that. From there, I guess I...do the importdb dump > replace > inject? I'm still reading overall.

 

[Urbanshadow]

Considering the content I've got installed on the Emunand, this makes a lot more sense.

Thanks for that. From there, I guess I...do the importdb dump > replace > inject? I'm still reading overall.

That's how I did it, once. It didn't work for me on n3ds, maybe I should try again.

 

[Deleted User]

Using Decrypt9 to dump import.db from my sysNAND and import_emu.db from my emuNAND, then injecting the sysNAND import.db into emuNAND worked for me. No more update nag after a few days (~3). I am now updating to 9.5 so that I can use multipatcher to block it.

 

[calebsw]

Is there a way to remove the update nag without a pre-nag backup of my EmuNAND?

check this post

 

[Selver]

Could you defragment your CTRNand on PC and infect it back? I know you've got a NANDmod, so this shouldn't be a problem. My FAT routines don't handle fragmentation yet, and normally there should no fragmentation on a SysNAND not modified by rxTools / GW (not 100% sure). I'll think about handing fragmentation later.

Hi d0k3,

Wondering about something you said, if it's proven or just typical? For example, don't CTRAging (and other factory test titles) have a testing function that forces fragmented files?
( I think it creates tiny (e.g., 0 or 1 byte) files until full, then deletes every other file, then allocates a file having more than 32k data.... )

Thus, I wonder if fragmentation might not be prevented by OFW, but rather it's just a stroke of luck?

Else, can you help me understand how we know that all file allocation using OFW is ensured to be contiguous? Does the OFW do some type of defrag before writing?

Thanks!

[edit -- changed "ensured" to "prevented" above]

 

[d0k3]

Hi d0k3,

Wondering about something you said, if it's proven or just typical? For example, don't CTRAging (and other factory test titles) have a testing function that forces fragmented files?
( I think it creates tiny (e.g., 0 or 1 byte) files until full, then deletes every other file, then allocates a file having more than 32k data.... )

Thus, I wonder if fragmentation might not be prevented by OFW, but rather it's just a stroke of luck?

Else, can you help me understand how we know that all file allocation using OFW is ensured to be contiguous? Does the OFW do some type of defrag before writing?

Thanks!

[edit -- changed "ensured" to "prevented" above]

I personally think defragmentation is prevented by OFW simply by having enough room, and by most critical files staying the same size when replaced, to be honest