How is it part of a package while in memory? The save data (while not all together or not necessarily even easy to edit) it must be there in memory and able to be changed before a savegame happens.
We're not talking about modifying savegames at all in this case. For example lets say i make a new game and call myself infinity, the infinity will be there in memory until the game is saved, no? that is modifiable without the game knowing isn't it... So if the 'name field' had an overflow then it might be possible to change infinity (or some other value) to something that will crash or cause code execution when the game has saved and relaunches - i think thats a lot simpler than it would actually work in practice. It's kinda a weird position if we really can modify game memory (some of it at least) and the possibility of skipping all their encryption all together. A savegame exploit doesnt sound as useful now but it could end up useful to have multiple routes into userland.
To people in the know with actual data, what data IS in memory? Could we have at least a map of whats accessible, game executables must be yes? That is pretty interesting. Also please share thx.
I've been thinking today of other alternative things maybe people overlooked while thinking about savegames and the lack of files under user control. One thing came to mind ages ago but i assumed it just wasn't useful for the platform, but the .m3u file format had a code execution bug that affected tons of apps with a simple long junk string at a certain point. m3u is one of the few files we can actually access (note: PSP FW 6.10 removed the ability for the system to make the m3u files, which suggests it has some importance or they are being just safe). The Nintendo Sound app has been updated, don't know if it's related or not.
Another thing while on sound is .mp3 files, the other type of file we can actually modify at will... there's been idv1/2 bugs in the past, not only that but mp3s let you load image files (nintendo hates standard image files at least under your control!). If an MP3 is loaded with an image in it, png, jpeg, tiff? and there is a potential exploit there assuming the sound player even displays the mp3 files. Let's remember the one file still left under our control to modify ended up with the original exploit, the system settings. So little things like these you never know if they are worth looking into prehaps.
And now the current entry on the Wii-U is the browser, which is the other avenue always worth thinking about (although the 3DS one is deliberately crippled in with no java and flash). Not a coder myself but all these new people turning up and actually being constructive on here is quite refreshing and i hope more progress comes from here. But people please share info anonymously if you have to, because you never know who might turn up and be a help. Right now wiiubrew is totally empty and useless... 3dbrew was actually useful for example and still is getting more and more so.
Nintendo didn't get suddenly good at security this time around they just did the obvious and tried to fix every known type of method used last gen from even being attempted. They rely loads on their own filetypes they made themselves, it's prime for exploitation really it's just people would rather go for known/obvious existing bugs and port them.
Sorry long post i'm getting interested in scene again it looks like. My last post was worded badly. The data that would make up the savegame is in memory and accessible. Not the savegame itself unless the game was coded to actually keep a 1:1 save in memory for some reason. Look on mario kart 8 and see why don't you?
Then change something during the game and save it.
We're not talking about modifying savegames at all in this case. For example lets say i make a new game and call myself infinity, the infinity will be there in memory until the game is saved, no? that is modifiable without the game knowing isn't it... So if the 'name field' had an overflow then it might be possible to change infinity (or some other value) to something that will crash or cause code execution when the game has saved and relaunches - i think thats a lot simpler than it would actually work in practice. It's kinda a weird position if we really can modify game memory (some of it at least) and the possibility of skipping all their encryption all together. A savegame exploit doesnt sound as useful now but it could end up useful to have multiple routes into userland.
To people in the know with actual data, what data IS in memory? Could we have at least a map of whats accessible, game executables must be yes? That is pretty interesting. Also please share thx.
I've been thinking today of other alternative things maybe people overlooked while thinking about savegames and the lack of files under user control. One thing came to mind ages ago but i assumed it just wasn't useful for the platform, but the .m3u file format had a code execution bug that affected tons of apps with a simple long junk string at a certain point. m3u is one of the few files we can actually access (note: PSP FW 6.10 removed the ability for the system to make the m3u files, which suggests it has some importance or they are being just safe). The Nintendo Sound app has been updated, don't know if it's related or not.
Another thing while on sound is .mp3 files, the other type of file we can actually modify at will... there's been idv1/2 bugs in the past, not only that but mp3s let you load image files (nintendo hates standard image files at least under your control!). If an MP3 is loaded with an image in it, png, jpeg, tiff? and there is a potential exploit there assuming the sound player even displays the mp3 files. Let's remember the one file still left under our control to modify ended up with the original exploit, the system settings. So little things like these you never know if they are worth looking into prehaps.
And now the current entry on the Wii-U is the browser, which is the other avenue always worth thinking about (although the 3DS one is deliberately crippled in with no java and flash). Not a coder myself but all these new people turning up and actually being constructive on here is quite refreshing and i hope more progress comes from here. But people please share info anonymously if you have to, because you never know who might turn up and be a help. Right now wiiubrew is totally empty and useless... 3dbrew was actually useful for example and still is getting more and more so.
Nintendo didn't get suddenly good at security this time around they just did the obvious and tried to fix every known type of method used last gen from even being attempted. They rely loads on their own filetypes they made themselves, it's prime for exploitation really it's just people would rather go for known/obvious existing bugs and port them.
Sorry long post i'm getting interested in scene again it looks like. My last post was worded badly. The data that would make up the savegame is in memory and accessible. Not the savegame itself unless the game was coded to actually keep a 1:1 save in memory for some reason. Look on mario kart 8 and see why don't you?
Then change something during the game and save it.
