Hacking [POC] Removing Update Nag on EmuNAND

[d0k3]

Turning off the update nag should be as simple as scanning the title.db file and setting all of the active bits from 0x01 to 0x00

You might want to fix the bold text in your post. There also is second way of doing this (that's what my importfixer does) and that is simply setting the number of active entries at the beginning of the entries to zero.

Import.db before resetting all Active Flags at entry offset 0x04 to 0x00
[...]
Import.db After resetting all Active Flags at entry offset 0x04 to 0x00
[...]

Dammit, that tool's output looks good! I was looking for exactly that for some time. Can you post a link to extdata tool?

Import.db before resetting all Active Flags at entry offset 0x04 to 0x00If someone wanted to write a PC based emuNAND "Cleaner" to remove all of the Update Data:
I'd think you could:

• Scan the title directory for 00000000.ctx files
• Open up the 00000000.ctx file and grab the names of what it was going to do (.ctx files are unencrypted on the NAND)
• Delete the files it was planning on processing
• Delete the 00000000.ctx file
• Rinse-repeat until no more 00000000.ctx files
• Profit.

Of course it would easier to just re-create the emuNAND....


(If you leave the "junk" files behind, it won't try to download the update again.)

Is it always 00000000.ctx (meaning: can it also be 00000001.ctx, etc...)? Also, I have never seen such a .ctx file. If you have a sample, can you post it here?

Actually it would be easier to write your emunand to your sysnand and do a recovery mode reset to wipe the update then flash it back to emunand.

A recipe for disaster, as others said. SysNAND writes, especially full SysNAND writes, shouldn't be handled carelessly. Also, what @Datalogger said above.

 

[Datalogger]

Thanks d0k3, Good catch on the import.db name.
Fixed.

Tool:
https://github.com/Tiger21820/ctr_toolkit
Usage:
extdata_tool -m IMG -t import.db


Same format as:
http://3dbrew.org/wiki/Title_Database
BDRI & Title Entry Format

 

[Datalogger]

I didn't have any luck changing the Header offset 0x2C "Number of used Title Entries" to 0x00
It still wanted to process them.

It did not want to if I set the actual title entries "Active" data to 0x00

And I have never seen anything other than 00000000.ctx, as it can contain more than one entry to process.
That doesn't mean it wouldn't be better to process all *.ctx files

 

[d0k3]

I didn't have any luck changing the Header offset 0x2C "Number of used Title Entries" to 0x00
It still wanted to process them.

It did not want to if I set the actual title entries "Active" data to 0x00

And I have never seen anything other than 00000000.ctx, as it can contain more than one entry to process.
That doesn't mean it wouldn't be better to process all *.ctx files

Do you by any chance also have a sample .CTX file for me to have a look at? There shouldn't be any copyrighted data in there, so it should be completely okay to post here.

 

[Syphurith]

Do you by any chance also have a sample .CTX file for me to have a look at? There shouldn't be any copyrighted data in there, so it should be completely okay to post here.

I don't know what it was updating to for my 4.1.0-8J.
about the format: http://3dbrew.org/wiki/CTXT
After you've cleaned the .ctx, you would need to clean those update content. (.app,.tmd,.ctx,.cmd)
Yes if you parse .cmd you can also get what is present and remove contents that aren't.
To avoid the copyright i would give you those via conversation.

 

[d0k3]

Thanks d0k3, Good catch on the import.db name.
Fixed.

Tool:
https://github.com/Tiger21820/ctr_toolkit
Usage:
extdata_tool -m IMG -t import.db


Same format as:
http://3dbrew.org/wiki/Title_Database
BDRI & Title Entry Format

Okay, I actually have tested this tool before. The reason why I coded my own (this is in no way user-friendly, bug-free or finished at all, more like a proof of concept) is that extdata_tool doesn't catch everything there is in the DBs. Duh...

I don't know what it was updating to for my 4.1.0-8J.
about the format: http://3dbrew.org/wiki/CTXT
After you've cleaned the .ctx, you would need to clean those update content. (.app,.tmd,.ctx,.cmd)
Yes if you parse .cmd you can also get what is present and remove contents that aren't.
To avoid the copyright i would give you those via conversation.

Thanks for the data, @Syphurith . The .CTX contain the content id (= number of the TMD) and from the TMD it could be decided which APP to delete. With that information, it would be possible to create an effective 'EmuNAND Update Nag Cleaner'. Big downside of this: the import.db is not fully understood (just read what I wrote above, and my tool is not perfect either) and any modification could backfire.

For now I won't take up the project of doing that 'EmuNAND Update Nag Cleaner'. I've got more interesting stuff waiting in line and still too little time . If I'd be unlucky enough to catch the update nag on EmuNAND myself things might change. It would be 100 times better if we could just find a way into the recovery menu of the EmuNAND anyways. If the recovery menu is even part of the NAND memory, that is, otherwise it would be impossible.

 

[wurstpistole]

I also want to confirm that dumping import.db from nag-free sysnand, and injecting into emunand removes the nag.
A quick question, what is actually the reason for the nag? Is it that I put my device to sleep while in EmuNand with Wifi active? Should i just deactivate Wifi whenever i do not want to play online?

 

[Deleted-19228]

Now that sounds like a recipe for disaster

I can see it now:
"Well, I copied my 9.5.0-23U emuNAND to my 9.2.0-20U sysNAND to clean it, but now for some strange reason I can’t get rxTools to work anymore…"


(Better hope they have a HardMod ready for this one...)

That was implied...

I can't believe people would actually think to write to their sysnand without a hardmod anyway. I have personally done this any time I have screwed up and downloaded the update. Takes <5 minutes to read emunand, read sysnand, write emunand then re-read it and write it back to emunand partition, and write the sysnand back using diskwriter (with a hardmod obviously)

 

[TheShadowRunner]

A quick question, what is actually the reason for the nag? Is it that I put my device to sleep while in EmuNand with Wifi active? Should i just deactivate Wifi whenever i do not want to play online?

Precisely, yes.

 

[d0k3]

(PS: If you leave the "junk" files behind, it won't try to download the update again.)

And I have never seen anything other than 00000000.ctx, as it can contain more than one entry to process.

This got me thinking. The CTX files have a fixed size of 0x600 byte, which translates to 32kB because of the FAT file system (32kB cluster size). So, 32 of these files are 1MB, meaning the size requirements are still very manageable.

Now, what I want to say: Just generate one fake 00000000.ctx file, 0x600 byte (or 1536 byte for those of us that don't like hex), all zeroes. Now put a copy of this file in each and every title/[idhigh]/[idlow] folder. And, you should get an update proof NAND. The fake CTX file will never be read by the 3DS because the import.db does not say so (meaning the fake content is very acceptable). And the import.db will never get the update nag, because the update routines think there is already an update waiting in line because of the .CTX. This method may not be 100% proof because an update can also bring a completely new title with it, but loading that onto your 3DS would mean that the update routines would accept partial updates, which I'm almost sure they are not. The .ctx really is the only last part of the puzzle (the one that keeps the 3DS from accepting another update), because otherwise GW downgraded NANDs (which have all sorts of crap leftover, but no CTX files) wouldn't accept an update either. I'm also pretty sure manual updating would still work, but (and that's important) the update nag would be gone for good.

Now, I'm pretty sure that would work, but the bis problem here is: there is almost no way to test it, because we can't really control when we get another update nag. Or in other words, we can't deliberately get an update nag unsuccesfully and then say: see, blocking worked. At least none that I know of. Ideas and testers are welcome, though.

 

[Datalogger]

I've already tried something similar.

I took all of the .CTX files from an already downloaded, but not installed,Update NAND and injected them into a "virgin" NAND of the same version.
I then booted it and turned off PSVProxy's Update Blocker (That's a great program. Lets me access eShop but optionally block all Updates. Works a treat!)

After about two minutes in sleep mode, it started downloading all the updates then triggered the "Nag"

I didn't want to try zeroing out the .CTX files as it looks to be a checksum at the very end.

Also, not all 00000000.ctx files are 0x600 size.
Some are 0xa00

Update:
I can confirm it's not the title folder that keeps it from triggering.
I copied to entire "Ready to Update" title folder to a fresh made NAND and it still re-downloaded the updates.

Still testing,
More to come....

Update:
Narrowed it down to the Data folder
Now testing which one (sysdata or extdata)....

Update:
OK, it's sysdata.
Now testing which 00000000 file (00010034,00010022,0002008f or 0001002c)

Testing 00010034/00000000 ...
It's not 00010034

Testing 00010022/00000000 ...
It's not 00010022

Testing 0002008f/00000000 ...
It's not 0002008f

Testing 0001002c/00000000 ...

And the Winner is: 0001002c/00000000 !!!

Copied just that one file from a 9.5.0-23U "Ready to Update" NAND to a "Virgin" same version NAND and it's been >6 hours left wide open in sleep mode with no proxy protection and it has not updated.
Before it would have started taking the update in less than 3 minutes.

Now to learn more about what that file does....

Edit:
I also tested and you can still force a Manual Update with this set by going to the System Menu

 

[d0k3]

I've already tried something similar.

I took all of the .CTX files from an already downloaded, but not installed,Update NAND and injected them into a "virgin" NAND of the same version.
I then booted it and turned off PSVProxy's Update Blocker (That's a great program. Lets me access eShop but optionally block all Updates. Works a treat!)

After about two minutes in sleep mode, it started downloading all the updates then triggered the "Nag"

I didn't want to try zeroing out the .CTX files as it looks to be a checksum at the very end.

Also, not all 00000000.ctx files are 0x600 size.
Some are 0xa00

Update:
I can confirm it's not the title folder that keeps it from triggering.
I copied to entire "Ready to Update" title folder to a fresh made NAND and it still re-downloaded the updates.

Still testing,
More to come....

Update:
Narrowed it down to the Data folder
Now testing which one (sysdata or extdata)....

Update:
OK, it's sysdata.
Now testing which 00000000 file (00010034,00010022,0002008f or 0001002c)

Testing 00010034/00000000 ...
It's not 00010034

Testing 00010022/00000000 ...
It's not 00010022

Testing 0002008f/00000000 ...
It's not 0002008f

Testing 0001002c/00000000 ...

And the Winner is: 0001002c/00000000 !!!

Copied just that one file from a "Ready to Update" NAND to a "Virgin" NAND and it's been two hours and no update.

Now to learn more about what that file does....

Edit:
I also tested and you can still force a Manual Update with this set by going to the System Menu

It's always the last one you try . The file you found is the "NIM" savegame (unsure what NIM stands for, more info here). Savegames in general are based on IVFC hashtrees, which means a complicated file structure with multiple hashes that are used to verify each other. Isolating the true difference will not be easy, but still be possible. Can I have a look at both, "original" and "protected" version of the 0001002c/00000000 file?

 

[Datalogger]

It's always the last one you try . The file you found is the "NIM" savegame (unsure what NIM stands for, more info here). Savegames in general are based on IVFC hashtrees, which means a complicated file structure with multiple hashes that are used to verify each other. Isolating the true difference will not be easy, but still be possible. Can I have a look at both, "original" and "protected" version of the 0001002c/00000000 file?

Message sent

And a quick Binary Compare shows me less than .005% of the two files are different, about 115 bytes out of 2MB.
(One triggers the NAG, the other does not)

 

[d0k3]

Message sent

And a quick Binary Compare shows me less than .005% of the two files are different, about 115 bytes out of 2MB.
(One triggers the NAG, the other does not)

Okay, let's try to understand the differences, shall we? (if anyone wants to see the files, shoot us a message or write in thread)

Of the ~115 bytes of difference, almost all of it are hashes, belonging to the IVFC hashtree. Only a very small part (~16 byte?) is actual changed data. Interesting offsets are 0x00C050, 0x010B050 and (possibly) 0x10B30F. Now if you compare 0x00C050 in b4 with 0x010B050 in aftr, that data is identical. Savegames actually have two partitions, one of which is the backup partition. I assume b4 is without, aftr with the update nag. 0x00C050 then belongs to the active partition, 0x010B050 is the backup partition. The true interesting data starts at 0xC058 - this is all zeroes in b4, and contains one 32 bit value in aftr (not the only change, but a good starting point).

Now, you can't just take the data over, because all those pesky hashes have to be accounted for, too. We will find a way to handle this, though.

EDIT: What we need is a savegame editor - is there something like this?

 

[leonmagnus99]

@d0k3 heyo buddy ! i read your "

• Dump your import.db via Decrypt9
• Drag and drop the import.db on importfix.exe (attached)
• Inject your import.db via Decrypt9" to get rid of the update nag !

my question is this, so firstly i have the n3ds with gw card ,sysnand is 9.0 and emuNAND is 9.4 and i use the mset to access the emuNAND and i would like to use your method without messing up my emuNAND as you warned it can be messy XD , (i have the nag only in emuNAND as i was playing online in emuNAND few times and had left it in sleep mode .. that caused the update i guess?)

i dont want to lose my cias etc. i have tons of them installed so how do i go on using the decrypt9 thingie, i am sorry about the dump/injecting etc. those words i do not really know what you mean by them it confuses me into thinking that i need CFW for it, could you give me the steps in street language please !?
XD

 

[d0k3]

@d0k3 heyo buddy ! i read your "

• Dump your import.db via Decrypt9
• Drag and drop the import.db on importfix.exe (attached)
• Inject your import.db via Decrypt9" to get rid of the update nag !

my question is this, so firstly i have the n3ds with gw card ,sysnand is 9.0 and emuNAND is 9.4 and i use the mset to access the emuNAND and i would like to use your method without messing up my emuNAND as you warned it can be messy XD , (i have the nag only in emuNAND as i was playing online in emuNAND few times and had left it in sleep mode .. that caused the update i guess?)

i dont want to lose my cias etc. i have tons of them installed so how do i go on using the decrypt9 thingie, i am sorry about the dump/injecting etc. those words i do not really know what you mean by them it confuses me into thinking that i need CFW for it, could you give me the steps in street language please !?
XD

Just do a backup of your EmuNAND first, then you can try around all you like. To do that backup, you may use either EmuNAND tool or Decrypt9 "Dump Emunand" feature. I think the wording is pretty clear, and Decrypt9 will warn you of critical operations, so nothing bad will happen.

 

[Urbanshadow]

I have an n3ds with the update nag and no emunand backup without it. Can I modify it to remove the nag and update-proof my system ? if so, how?

 

[Datalogger]

Okay, let's try to understand the differences, shall we? (if anyone wants to see the files, shoot us a message or write in thread)

Of the ~115 bytes of difference, almost all of it are hashes, belonging to the IVFC hashtree. Only a very small part (~16 byte?) is actual changed data. Interesting offsets are 0x00C050, 0x010B050 and (possibly) 0x10B30F. Now if you compare 0x00C050 in b4 with 0x010B050 in aftr, that data is identical. Savegames actually have two partitions, one of which is the backup partition. I assume b4 is without, aftr with the update nag. 0x00C050 then belongs to the active partition, 0x010B050 is the backup partition. The true interesting data starts at 0xC058 - this is all zeroes in b4, and contains one 32 bit value in aftr (not the only change, but a good starting point).

Now, you can't just take the data over, because all those pesky hashes have to be accounted for, too. We will find a way to handle this, though.

EDIT: What we need is a savegame editor - is there something like this?

I'll do some byte-by-byte testing later today to see if it triggers a hashing error or not.

Kind of odd, those two sets at 0xc061 and 0x10b061 look like plain-text keys...

 

[leonmagnus99]

i tried the dump and inject method..

dumping worked and after puting the import db into importfix i got a import_emu somting like that, do i put it in the Root of my msd ?

i did that and tried injecting it into emuNAND but it failed, and i renamed it to import.db and tried again but it failed again ,

"searching for import.db.. tries to open import.db ,could not open import.db , failed"

 

[MelonGx]

Succeeded on N3DS emuNAND 9.5 + rxTools Dec.05.

1) Dump emuNAND with emuNANDTool.
2) Dump FAT16 XORPAD with Decrypt9.
3) Decrypt emuNAND.
4) Mount/Open decrypted emuNAND with OSFMount/WinImage/etc.
5) Export import.db and drag it to @d0k3 's importfix.exe.
6) Inject the modified import.db back.
7) Re-encrypt emuNAND.
8) Inject re-encrypted emuNAND with emuNANDTool.