Talk:SD Filesystem - Revision history

Elisherer: /* Save files */

2011-12-19T05:30:06Z

Save files

← Older revision		Revision as of 08:30, 19 December 2011
Line 19:		Line 19:
	Wouldn't this imply that the whole save file is modified for each save? When I diff two 00000001.sav from different (subsequent) writes, they only differ at certain portions (the first 0x10 bytes, certain blocks of subsequent 0x20 bytes and certain one-byte changes). [[User:FireFly\|FireFly]] 17:18, 18 December 2011 (CET)		Wouldn't this imply that the whole save file is modified for each save? When I diff two 00000001.sav from different (subsequent) writes, they only differ at certain portions (the first 0x10 bytes, certain blocks of subsequent 0x20 bytes and certain one-byte changes). [[User:FireFly\|FireFly]] 17:18, 18 December 2011 (CET)
	::IIRC when I first xored two different 00000001.sav files, the output was garbage therefore I assumed that meant they change the CTR for each save write. But when I did the same for a GBA VC save recently, I got zeros and garbage where the changed data is. So I'm not really sure what's with the CTR. --[[User:Yellows8\|Yellows8]] 18:56, 18 December 2011 (CET)		::IIRC when I first xored two different 00000001.sav files, the output was garbage therefore I assumed that meant they change the CTR for each save write. But when I did the same for a GBA VC save recently, I got zeros and garbage where the changed data is. So I'm not really sure what's with the CTR. --[[User:Yellows8\|Yellows8]] 18:56, 18 December 2011 (CET)
	:::From my experience, each saving takes a 0x1000 block and saves is somewhere else...when you xor 2 files it doesn't mean anything because the data maybe xored with ~~the~~ encrypted ~~0xFFs~~ so no clear text. For data to be discovered the first file needs to have an encrypted data at some offset and 2nd file will have encrypted 0xff at the same offset. this is rather rare for the 3ds to delete its backups... --[[User:Elisherer\|Elisherer]] 07:28, 19 December 2011 (CET)		:::From my experience, each saving takes a 0x1000 block and saves is somewhere else...when you xor 2 files it doesn't mean anything because the data maybe xored with other encrypted data so no clear text. For data to be discovered the first file needs to have an encrypted data at some offset and 2nd file will have encrypted 0xff at the same offset. this is rather rare for the 3ds to delete its backups... --[[User:Elisherer\|Elisherer]] 07:28, 19 December 2011 (CET)

Elisherer: /* Save files */

2011-12-19T05:28:46Z

Save files

← Older revision		Revision as of 08:28, 19 December 2011
Line 19:		Line 19:
	Wouldn't this imply that the whole save file is modified for each save? When I diff two 00000001.sav from different (subsequent) writes, they only differ at certain portions (the first 0x10 bytes, certain blocks of subsequent 0x20 bytes and certain one-byte changes). [[User:FireFly\|FireFly]] 17:18, 18 December 2011 (CET)		Wouldn't this imply that the whole save file is modified for each save? When I diff two 00000001.sav from different (subsequent) writes, they only differ at certain portions (the first 0x10 bytes, certain blocks of subsequent 0x20 bytes and certain one-byte changes). [[User:FireFly\|FireFly]] 17:18, 18 December 2011 (CET)
	::IIRC when I first xored two different 00000001.sav files, the output was garbage therefore I assumed that meant they change the CTR for each save write. But when I did the same for a GBA VC save recently, I got zeros and garbage where the changed data is. So I'm not really sure what's with the CTR. --[[User:Yellows8\|Yellows8]] 18:56, 18 December 2011 (CET)		::IIRC when I first xored two different 00000001.sav files, the output was garbage therefore I assumed that meant they change the CTR for each save write. But when I did the same for a GBA VC save recently, I got zeros and garbage where the changed data is. So I'm not really sure what's with the CTR. --[[User:Yellows8\|Yellows8]] 18:56, 18 December 2011 (CET)
			:::From my experience, each saving takes a 0x1000 block and saves is somewhere else...when you xor 2 files it doesn't mean anything because the data maybe xored with the encrypted 0xFFs so no clear text. For data to be discovered the first file needs to have an encrypted data at some offset and 2nd file will have encrypted 0xff at the same offset. this is rather rare for the 3ds to delete its backups... --[[User:Elisherer\|Elisherer]] 07:28, 19 December 2011 (CET)

Yellows8: /* Save files */

2011-12-18T16:56:39Z

Save files

← Older revision		Revision as of 19:56, 18 December 2011
Line 18:		Line 18:
	* The data dir contains 00000001.sav, this is the title's encrypted savegame. Although these saves look similar to FLASH savegames, these savegames use proper unique CTR for each AES block in the file, and the CTR properly changes for each savegame write.		* The data dir contains 00000001.sav, this is the title's encrypted savegame. Although these saves look similar to FLASH savegames, these savegames use proper unique CTR for each AES block in the file, and the CTR properly changes for each savegame write.
	Wouldn't this imply that the whole save file is modified for each save? When I diff two 00000001.sav from different (subsequent) writes, they only differ at certain portions (the first 0x10 bytes, certain blocks of subsequent 0x20 bytes and certain one-byte changes). [[User:FireFly\|FireFly]] 17:18, 18 December 2011 (CET)		Wouldn't this imply that the whole save file is modified for each save? When I diff two 00000001.sav from different (subsequent) writes, they only differ at certain portions (the first 0x10 bytes, certain blocks of subsequent 0x20 bytes and certain one-byte changes). [[User:FireFly\|FireFly]] 17:18, 18 December 2011 (CET)
			::IIRC when I first xored two different 00000001.sav files, the output was garbage therefore I assumed that meant they change the CTR for each save write. But when I did the same for a GBA VC save recently, I got zeros and garbage where the changed data is. So I'm not really sure what's with the CTR. --[[User:Yellows8\|Yellows8]] 18:56, 18 December 2011 (CET)

FireFly at 16:18, 18 December 2011

2011-12-18T15:18:51Z

← Older revision		Revision as of 18:18, 18 December 2011
Line 13:		Line 13:

	This probably won't matter to most people but if you interrupt the transfer of a eShop title before it completes downloading you're left with an extra 00000001.ctx file in the directory of the 0000000x.app and other files associated with it. The .app file is created filled with 0xFFFF padding ( at full size ) and chunks are sequentially over-written with the correct encrypted data as the title downloads onto the SD card. However if the download is interrupted before it finishes, the title can still be loaded/selected/launched, and it will appear in the 3DS home menu ( logo, sound, model, etc. ). It doesn't mind that most of the file is corrupt/junk. When opening or launching it of course you'll just get a generic error and forced to return to Home menu screen. If you erased or padded far enough into the header - or ended the download early enough - then the title/logo won't even appear in the home menu, but the tile *will still show there, but without the logo/model when selected. ( if you place your cursor over it, nothing appears where the game title should normally be. It will not be launchable.) [[User:Jl12\|Jl12]]		This probably won't matter to most people but if you interrupt the transfer of a eShop title before it completes downloading you're left with an extra 00000001.ctx file in the directory of the 0000000x.app and other files associated with it. The .app file is created filled with 0xFFFF padding ( at full size ) and chunks are sequentially over-written with the correct encrypted data as the title downloads onto the SD card. However if the download is interrupted before it finishes, the title can still be loaded/selected/launched, and it will appear in the 3DS home menu ( logo, sound, model, etc. ). It doesn't mind that most of the file is corrupt/junk. When opening or launching it of course you'll just get a generic error and forced to return to Home menu screen. If you erased or padded far enough into the header - or ended the download early enough - then the title/logo won't even appear in the home menu, but the tile *will still show there, but without the logo/model when selected. ( if you place your cursor over it, nothing appears where the game title should normally be. It will not be launchable.) [[User:Jl12\|Jl12]]

			== Save files ==
			The article mentions
			* The data dir contains 00000001.sav, this is the title's encrypted savegame. Although these saves look similar to FLASH savegames, these savegames use proper unique CTR for each AES block in the file, and the CTR properly changes for each savegame write.
			Wouldn't this imply that the whole save file is modified for each save? When I diff two 00000001.sav from different (subsequent) writes, they only differ at certain portions (the first 0x10 bytes, certain blocks of subsequent 0x20 bytes and certain one-byte changes). [[User:FireFly\|FireFly]] 17:18, 18 December 2011 (CET)

Jl12 at 19:37, 12 June 2011

2011-06-12T17:37:43Z

← Older revision		Revision as of 21:37, 12 June 2011
Line 12:		Line 12:


	This probably won't matter to most people but if you interrupt the transfer of a eShop title before it completes downloading you're left with an extra 00000001.ctx file in the directory of the 0000000x.app and other files associated with it. The .app file is created filled with 0xFFFF padding ( at full size ) and chunks are sequentially over-written with the correct encrypted data as the title downloads onto the SD card. However if the download is interrupted before it finishes, the title can still be loaded/selected/launched, and it will appear in the 3DS home menu ( logo, sound, model, etc. ). It doesn't mind that most of the file is corrupt/junk. When opening or launching it of course you'll just get a generic error and forced to return to Home menu screen. If you erased or padded far enough into the header - or ended the download early enough - then the title/logo won't even appear in the home menu, but the tile *will still show there, but without the logo/model when selected. ( if you place your cursor over it, nothing appears where the game title should normally be. It ~~also~~ will not be launchable.)		This probably won't matter to most people but if you interrupt the transfer of a eShop title before it completes downloading you're left with an extra 00000001.ctx file in the directory of the 0000000x.app and other files associated with it. The .app file is created filled with 0xFFFF padding ( at full size ) and chunks are sequentially over-written with the correct encrypted data as the title downloads onto the SD card. However if the download is interrupted before it finishes, the title can still be loaded/selected/launched, and it will appear in the 3DS home menu ( logo, sound, model, etc. ). It doesn't mind that most of the file is corrupt/junk. When opening or launching it of course you'll just get a generic error and forced to return to Home menu screen. If you erased or padded far enough into the header - or ended the download early enough - then the title/logo won't even appear in the home menu, but the tile *will still show there, but without the logo/model when selected. ( if you place your cursor over it, nothing appears where the game title should normally be. It will not be launchable.) [[User:Jl12\|Jl12]]
	[[User:Jl12\|Jl12]]

Jl12: incomplete downloads from eshop

2011-06-12T17:36:06Z

incomplete downloads from eshop

← Older revision		Revision as of 21:36, 12 June 2011
Line 9:		Line 9:

	* It makes an encrypted connection to the update servers initially. [[User:Jl12\|Jl12]]		* It makes an encrypted connection to the update servers initially. [[User:Jl12\|Jl12]]



			This probably won't matter to most people but if you interrupt the transfer of a eShop title before it completes downloading you're left with an extra 00000001.ctx file in the directory of the 0000000x.app and other files associated with it. The .app file is created filled with 0xFFFF padding ( at full size ) and chunks are sequentially over-written with the correct encrypted data as the title downloads onto the SD card. However if the download is interrupted before it finishes, the title can still be loaded/selected/launched, and it will appear in the 3DS home menu ( logo, sound, model, etc. ). It doesn't mind that most of the file is corrupt/junk. When opening or launching it of course you'll just get a generic error and forced to return to Home menu screen. If you erased or padded far enough into the header - or ended the download early enough - then the title/logo won't even appear in the home menu, but the tile *will still show there, but without the logo/model when selected. ( if you place your cursor over it, nothing appears where the game title should normally be. It also will not be launchable.)
			[[User:Jl12\|Jl12]]

Jl12 at 05:28, 5 June 2011

2011-06-05T03:28:10Z

← Older revision		Revision as of 07:28, 5 June 2011
Line 3:		Line 3:
	::oh, my bad--[[User:T3a\|T3a]] 04:37, 9 April 2011 (CEST)		::oh, my bad--[[User:T3a\|T3a]] 04:37, 9 April 2011 (CEST)


	~~Suggestion: Start a title database with some sort of organization. Added SSFIV3D USA, MiiMaker USA.~~

	~~( '''HTTP_X_GAMEID: 00002400''' is also put in the http headers when N3DS tests wifi connectivity. It may be an identifier for the OS rather than the camera. )~~

	~~--[[User:Jl12\|Jl12]] 13:59, 15 April 2011 (CEST)~~

	Extra data downloaded from internet are able to download from PC.		Extra data downloaded from internet are able to download from PC.
	So we do MITM attack when download the data,we may find the server.		So we do MITM attack when download the data,we may find the server.
	data downloaded from PC are not encrypted not to use with other 3DS.[[User talk:Matyapiro31\|Matyapiro]]		data downloaded from PC are not encrypted not to use with other 3DS.[[User talk:Matyapiro31\|Matyapiro]]

			* It makes an encrypted connection to the update servers initially. [[User:Jl12\|Jl12]]

Matyapiro31 at 03:12, 5 June 2011

2011-06-05T01:12:30Z

← Older revision		Revision as of 05:12, 5 June 2011
Line 9:		Line 9:

	--[[User:Jl12\|Jl12]] 13:59, 15 April 2011 (CEST)		--[[User:Jl12\|Jl12]] 13:59, 15 April 2011 (CEST)

			Extra data downloaded from internet are able to download from PC.
			So we do MITM attack when download the data,we may find the server.
			data downloaded from PC are not encrypted not to use with other 3DS.[[User talk:Matyapiro31\|Matyapiro]]

Jl12 at 11:59, 15 April 2011

2011-04-15T09:59:57Z

← Older revision		Revision as of 13:59, 15 April 2011
Line 5:		Line 5:

	Suggestion: Start a title database with some sort of organization. Added SSFIV3D USA, MiiMaker USA.		Suggestion: Start a title database with some sort of organization. Added SSFIV3D USA, MiiMaker USA.

			( '''HTTP_X_GAMEID: 00002400''' is also put in the http headers when N3DS tests wifi connectivity. It may be an identifier for the OS rather than the camera. )

			--[[User:Jl12\|Jl12]] 13:59, 15 April 2011 (CEST)

Jl12 at 11:55, 15 April 2011

2011-04-15T09:55:27Z

← Older revision		Revision as of 13:55, 15 April 2011
Line 2:		Line 2:
	:They're not offsets, they're filenames. [[User:Bushing\|Bushing]] 23:39, 8 April 2011 (CEST)		:They're not offsets, they're filenames. [[User:Bushing\|Bushing]] 23:39, 8 April 2011 (CEST)
	::oh, my bad--[[User:T3a\|T3a]] 04:37, 9 April 2011 (CEST)		::oh, my bad--[[User:T3a\|T3a]] 04:37, 9 April 2011 (CEST)


			Suggestion: Start a title database with some sort of organization. Added SSFIV3D USA, MiiMaker USA.

← Older revision		Revision as of 08:30, 19 December 2011
Line 19:		Line 19:
	Wouldn't this imply that the whole save file is modified for each save? When I diff two 00000001.sav from different (subsequent) writes, they only differ at certain portions (the first 0x10 bytes, certain blocks of subsequent 0x20 bytes and certain one-byte changes). [[User:FireFly\|FireFly]] 17:18, 18 December 2011 (CET)		Wouldn't this imply that the whole save file is modified for each save? When I diff two 00000001.sav from different (subsequent) writes, they only differ at certain portions (the first 0x10 bytes, certain blocks of subsequent 0x20 bytes and certain one-byte changes). [[User:FireFly\|FireFly]] 17:18, 18 December 2011 (CET)
	::IIRC when I first xored two different 00000001.sav files, the output was garbage therefore I assumed that meant they change the CTR for each save write. But when I did the same for a GBA VC save recently, I got zeros and garbage where the changed data is. So I'm not really sure what's with the CTR. --[[User:Yellows8\|Yellows8]] 18:56, 18 December 2011 (CET)		::IIRC when I first xored two different 00000001.sav files, the output was garbage therefore I assumed that meant they change the CTR for each save write. But when I did the same for a GBA VC save recently, I got zeros and garbage where the changed data is. So I'm not really sure what's with the CTR. --[[User:Yellows8\|Yellows8]] 18:56, 18 December 2011 (CET)
	:::From my experience, each saving takes a 0x1000 block and saves is somewhere else...when you xor 2 files it doesn't mean anything because the data maybe xored with ~~the~~ encrypted ~~0xFFs~~ so no clear text. For data to be discovered the first file needs to have an encrypted data at some offset and 2nd file will have encrypted 0xff at the same offset. this is rather rare for the 3ds to delete its backups... --[[User:Elisherer\|Elisherer]] 07:28, 19 December 2011 (CET)		:::From my experience, each saving takes a 0x1000 block and saves is somewhere else...when you xor 2 files it doesn't mean anything because the data maybe xored with other encrypted data so no clear text. For data to be discovered the first file needs to have an encrypted data at some offset and 2nd file will have encrypted 0xff at the same offset. this is rather rare for the 3ds to delete its backups... --[[User:Elisherer\|Elisherer]] 07:28, 19 December 2011 (CET)

← Older revision		Revision as of 08:28, 19 December 2011
Line 19:		Line 19:
	Wouldn't this imply that the whole save file is modified for each save? When I diff two 00000001.sav from different (subsequent) writes, they only differ at certain portions (the first 0x10 bytes, certain blocks of subsequent 0x20 bytes and certain one-byte changes). [[User:FireFly\|FireFly]] 17:18, 18 December 2011 (CET)		Wouldn't this imply that the whole save file is modified for each save? When I diff two 00000001.sav from different (subsequent) writes, they only differ at certain portions (the first 0x10 bytes, certain blocks of subsequent 0x20 bytes and certain one-byte changes). [[User:FireFly\|FireFly]] 17:18, 18 December 2011 (CET)
	::IIRC when I first xored two different 00000001.sav files, the output was garbage therefore I assumed that meant they change the CTR for each save write. But when I did the same for a GBA VC save recently, I got zeros and garbage where the changed data is. So I'm not really sure what's with the CTR. --[[User:Yellows8\|Yellows8]] 18:56, 18 December 2011 (CET)		::IIRC when I first xored two different 00000001.sav files, the output was garbage therefore I assumed that meant they change the CTR for each save write. But when I did the same for a GBA VC save recently, I got zeros and garbage where the changed data is. So I'm not really sure what's with the CTR. --[[User:Yellows8\|Yellows8]] 18:56, 18 December 2011 (CET)
			:::From my experience, each saving takes a 0x1000 block and saves is somewhere else...when you xor 2 files it doesn't mean anything because the data maybe xored with the encrypted 0xFFs so no clear text. For data to be discovered the first file needs to have an encrypted data at some offset and 2nd file will have encrypted 0xff at the same offset. this is rather rare for the 3ds to delete its backups... --[[User:Elisherer\|Elisherer]] 07:28, 19 December 2011 (CET)