Download JKSM, backup save file, download legit Moon, play until you can save, restore the old save file.
Download JKSM, backup save file, download legit Moon, play until you can save, restore the old save file.
Did you copy the correct offsets?
With FBI, or you can use something like TikSweeper
I'm confused, are people claiming the movable.sed they get once formatting is COMPLETELY identical to the original?
"Most of the System Format is done with FS:InitializeCtrFileSystem. This command updates the high u64 of the keyY stored in movable.sed."
"The movable.sed keyY high u64 is updated on the source 3DS during a System Transfer, and when doing a system format with System Settings."
"When you first enter the System Format menu, it will check if a NNID is linked. If there's a linked-NNID, it will then display: "Are you ready to connect to the Internet to check whether data can be formatted"? Continuing will only result in connecting to wifi for checking in with Nintendo's servers, which may fail if the console is banned. Once that's done it will continue with the usual system-format messages; proceeding will result in the NNID cookie, potentially still present on NAND backups or multiboot scenarios, being invalidated until the next sign-in (at which point even old sessions will be valid again)."
Am I missing something, or shouldn't that not be the case? If you system format, shouldn't there be at least some difference?
"Most of the System Format is done with FS:InitializeCtrFileSystem. This command updates the high u64 of the keyY stored in movable.sed."
"The movable.sed keyY high u64 is updated on the source 3DS during a System Transfer, and when doing a system format with System Settings."
"When you first enter the System Format menu, it will check if a NNID is linked. If there's a linked-NNID, it will then display: "Are you ready to connect to the Internet to check whether data can be formatted"? Continuing will only result in connecting to wifi for checking in with Nintendo's servers, which may fail if the console is banned. Once that's done it will continue with the usual system-format messages; proceeding will result in the NNID cookie, potentially still present on NAND backups or multiboot scenarios, being invalidated until the next sign-in (at which point even old sessions will be valid again)."
Am I missing something, or shouldn't that not be the case? If you system format, shouldn't there be at least some difference?
i think so. ignore the first 8 and the last 40? then copy over the entire original LFCS.
looking at my backup of my original LFCS it has the same amount of bytes as the new one so i'm fairly sure i did it right... they are definitely completely different.
There definitely should be a difference (which I think I sort of confirmed by replacing the bytes in the moveable.sed and it forcing the DS to act formatted) but for some reason there isn't. I can only speak for myself but I did a full system format, as well as using TinyFormat and compared the dumps off all 3, which were the same. I then compared the dumps of every sysNAND backup I've made since installing A9LH (9.2-11.2) and every single one of them had identical files as well.
Weird. My o3ds had LFS and SED different but the n3ds has the same localfriendcodeseed as both movable.sed files, the one from before arm9 install and after.
So apperantly I could unban my o3ds but not the n3ds. They did system transfer.
So now we can ask if there is a difference between the way the RAM processes work in CTRNAND regarding the moveable.sed and a system format/transfer in O3DS vs. N3DS. Perhaps there is something else we didn't know about the reasoning behind the "not so much more efficient" updated RAM.
from what I understand, it will only generate a new value when you do system transfer as youre using the old value to the destination 3ds. once you do system transfer you have to reformat right? then thats when it generates a new one since the old is going to be transferred.
so maybe thats what the twitter guy does. transfer extract copy repeat.
just speculation
D
Deleted User
Guest
So the current thought is that At the time of transfer, the 3ds each has an id each. Id 1 is moved to 3ds#2. Id 2 is destroyed, and a New ID3 is made on 3ds#1?
Am I following that train of thought correctly?
Am I following that train of thought correctly?
Wait is the lfc edit with different move sed is permanent or everything goes to hell when rebooting the 3ds or something?
I would say the same except if he were doing that everyone would have unique LFS, but at least three got identical files.
WOW THANKS GUYS! i was injecting my original LFCS instead of my new one i made... i'm a huge dunce.
BUT IT WORKED! i'm back online! thank you so much to everyone who helped me with this and the super bros who figured it out in the first place. you guys are truly excellent.
and i guess now we wait and see if nintendo bans us for doing this haha!
good luck to everyone who had the same movable and LFCS. i really hope we can sort you guys out sooner than later.
BUT IT WORKED! i'm back online! thank you so much to everyone who helped me with this and the super bros who figured it out in the first place. you guys are truly excellent.
and i guess now we wait and see if nintendo bans us for doing this haha!
good luck to everyone who had the same movable and LFCS. i really hope we can sort you guys out sooner than later.
BTW people should realize (if they don't already) if you do get banned again from using a donor LFS, it's essentially that, you've just banned another console when you thought one was bad enough. Please be cautious.
Similar threads
