It's possible to export raw saves with savedatafiler then find and edit values in a hex editor, like cheat codes. However, some games have checksum bytes within the save file that need to be correct or that save file gets read as corrupted by the game. A while ago I tried exporting two Lord of Magna saves (for this game, each save has three .sav files in the 8-digit ID folder) and searching for the money values. I changed that value in one of the files, then when I imported the whole save the edited file was corrupted and the game deleted it (the other two files were still there). I'm not sure what checksum methods are used in different games, so I'm posting some notes. It looks like each game uses its own checksums and possibly encryption in the exported saves, so if anyone has edited saves successfully it helps to share what kind of checksum is used and where it is. There are also several games with save editor programs, so reading about how those work could also help. I read about one case here: https://gbatemp.net/threads/ocarina-of-time-3d-save-editing-progress.380927/ This is for The Legend of Zelda: Ocarina of Time 3D, which uses the last two bytes of the save with a CRC-16 checksum. It computes a CRC-16 checksum with those bytes set to zero (this is important, deleting them instead of setting to 0 gives a different checksum value). Then, it checks if those two bytes are equal to that checksum. This particular save is stored as Little Endian, which means every four bytes are reversed, so when you edit the checksum bytes (or any value in the save), you reverse the four-byte groups so it will read correctly. Lord of Magna appeared to be doing something similar, though I couldn't find the checksum method to use even when testing with several variations of byte flips. Maybe I made a silly error in my brute force code somewhere, since that looked simple to find if the method was the same (compare two saves, list changed byte groups that could be the checksum, set groups of bytes to 0 and see if the checksum matches the bytes or possibly the flipped zeroed byte groups. That's assuming a lot about the checksum method, though.). I think it helps to clarify another assumption, which is that only the saves in the 8-digit ID folder matter. When I export with savedatafiler, there's a datetime folder with the 8-digit ID folder with the saves, and also two .dat files and a .log file with the ID folder. The .dat files appear to be used for injecting the save back into the particular game ROM it was exported from. I don't think they matter for the save file since I could use the same save (files inside the 8-digit ID folder) on two different cartridges by exporting from the cartridge, replacing just those files, then importing. The exported save files for different saves appear to have their own formats. I tried looking at some saves from another game, Conception II, and the saves are very dissimilar (just a header in common) and sometimes even different sizes, so I guess that there's some kind of encryption or compression being used with them. I think that makes sense for Conception II since it's a port of a Vita game, and Vita saves are heavily encrypted. Maybe the encryption got carried over in the 3DS port. I tried another game, Etrian Odyssey Untold: The Millennium Girl, which has a raw save with no checksum or encryption, as I learned after the following test. I save in the Inn with 100 gold and export that, buy 2 potions (60 gold now) and export that, then compare the two saves in a hex editor. I find the address easily, so I back up a save and change the address around the gold from 00 3C 00 00 00 to 14 28 3C 00 00 (this makes it easy to tell if the value is flipped). I copy this edited file over the one in one of the exported saves, then import that back into the game. The save loads properly and shows 15400 gold, which is 3C28 in hex, so that means it's Little Endian here too and also I'd better go back and change that save because the 14 might have ruined something else. 999,999,999 base 10 = 3B9AC9FF base 16 is plenty, so I changed the 4-byte group with the gold byte to FF C9 9A 3B (flipped bytes for Little Endian format) and reimported the save, which showed 999,999,999 gold as desired. Pretty neat. If there was a checksum, the save would have said some corruption message instead of loading. So it looks like the individual games have their own exported save formats, including possible checksums and encryption/compression.