Talk:Savegames - Revision history

Wwylele: /* File system */

2016-08-19T09:52:56Z

File system

← Older revision		Revision as of 13:52, 19 August 2016
Line 122:		Line 122:

	Data of one file in SAVE partition / filestore seems sometimes fragmented into several blocks, and BlockMap probably describes how to link and build them. Is this already known? And I think what is stored in BlockMap forms linked lists, and an entry is {uint32 previous_block; uint32 next_block; }. (Note that I was looking into CECD system savegame, which is the only savegame I looked, and which contains a relative complicated folder structure, where files and folders can be added and deleted frequently) --[[User:Wwylele\|Wwylele]] ([[User talk:Wwylele\|talk]]) 15:01, 18 August 2016 (CEST)		Data of one file in SAVE partition / filestore seems sometimes fragmented into several blocks, and BlockMap probably describes how to link and build them. Is this already known? And I think what is stored in BlockMap forms linked lists, and an entry is {uint32 previous_block; uint32 next_block; }. (Note that I was looking into CECD system savegame, which is the only savegame I looked, and which contains a relative complicated folder structure, where files and folders can be added and deleted frequently) --[[User:Wwylele\|Wwylele]] ([[User talk:Wwylele\|talk]]) 15:01, 18 August 2016 (CEST)

			Also the SAVE partition looks very similar to [[Extdata#Filesystem\|extdata VSXE partition]], especially the folder and file entries. --[[User:Wwylele\|Wwylele]] ([[User talk:Wwylele\|talk]]) 13:52, 19 August 2016 (CEST)

Wwylele at 13:07, 18 August 2016

2016-08-18T11:07:20Z

← Older revision		Revision as of 15:07, 18 August 2016
Line 121:		Line 121:
	== File system ==		== File system ==

	Data of one file in SAVE partition / filestore seems sometimes fragmented into several blocks, and BlockMap probably describes how to link and build them. Is this already known? And I think what is stored in BlockMap forms linked lists, and an entry is {uint32 previous_block; uint32 next_block; } [[User:Wwylele\|Wwylele]] ([[User talk:Wwylele\|talk]]) 15:01, 18 August 2016 (CEST)		Data of one file in SAVE partition / filestore seems sometimes fragmented into several blocks, and BlockMap probably describes how to link and build them. Is this already known? And I think what is stored in BlockMap forms linked lists, and an entry is {uint32 previous_block; uint32 next_block; }. (Note that I was looking into CECD system savegame, which is the only savegame I looked, and which contains a relative complicated folder structure, where files and folders can be added and deleted frequently) --[[User:Wwylele\|Wwylele]] ([[User talk:Wwylele\|talk]]) 15:01, 18 August 2016 (CEST)

Wwylele at 13:02, 18 August 2016

2016-08-18T11:02:42Z

← Older revision		Revision as of 15:02, 18 August 2016
Line 118:		Line 118:

	Are those two u32 cardIDs mentiond in keyY generation for the first version of savegamy encryption just ROM chip type ID repeated twice, like 45FA009045FA0090 or ROMID/EEPROMID combination? --[[User:Duke srg\|Duke srg]] 10:43, 23 February 2015 (CET)		Are those two u32 cardIDs mentiond in keyY generation for the first version of savegamy encryption just ROM chip type ID repeated twice, like 45FA009045FA0090 or ROMID/EEPROMID combination? --[[User:Duke srg\|Duke srg]] 10:43, 23 February 2015 (CET)

			== File system ==

			Data of one file in SAVE partition / filestore seems sometimes fragmented into several blocks, and BlockMap probably describes how to link and build them. Is this already known? And I think what is stored in BlockMap forms linked lists, and an entry is {uint32 previous_block; uint32 next_block; } [[User:Wwylele\|Wwylele]] ([[User talk:Wwylele\|talk]]) 15:01, 18 August 2016 (CEST)

Duke srg: /* Savegame keyY CardId */ new section

2015-02-23T08:43:36Z

Savegame keyY CardId: new section

← Older revision		Revision as of 11:43, 23 February 2015
Line 114:		Line 114:
	:Is it more clear with my last edit? The RomFS [https://github.com/3dshax/ctr/blob/master/ctrtool/ivfc.c IVFC] is basically identical to savegames, except savegames have the additional filesystem level.(Didn't realize that when I figured out the savegame hashes though) And it's not actually possible to generate the MAC yet with the AES engine, since the keyY for gamecard savegames is currently unknown. --[[User:Yellows8\|Yellows8]] 16:57, 3 September 2012 (CEST)		:Is it more clear with my last edit? The RomFS [https://github.com/3dshax/ctr/blob/master/ctrtool/ivfc.c IVFC] is basically identical to savegames, except savegames have the additional filesystem level.(Didn't realize that when I figured out the savegame hashes though) And it's not actually possible to generate the MAC yet with the AES engine, since the keyY for gamecard savegames is currently unknown. --[[User:Yellows8\|Yellows8]] 16:57, 3 September 2012 (CEST)
	::That's really interesting. I wonder what is the general idea here...Do savegames use the romFS structure.. --[[User:Elisherer\|Elisherer]] 00:00, 4 September 2012 (CEST)		::That's really interesting. I wonder what is the general idea here...Do savegames use the romFS structure.. --[[User:Elisherer\|Elisherer]] 00:00, 4 September 2012 (CEST)

			== Savegame keyY CardId ==

			Are those two u32 cardIDs mentiond in keyY generation for the first version of savegamy encryption just ROM chip type ID repeated twice, like 45FA009045FA0090 or ROMID/EEPROMID combination? --[[User:Duke srg\|Duke srg]] 10:43, 23 February 2015 (CET)

Elisherer at 22:00, 3 September 2012

2012-09-03T20:00:07Z

← Older revision		Revision as of 00:00, 4 September 2012
Line 113:		Line 113:
	@Yellows8, That's awesome! Can you explain a bit more about the buffer padding (maybe give an example) I want to add the foundings to 3dsexplorer and complete the saving algorithm (without the MAC signing ofcourse) --[[User:Elisherer\|Elisherer]] 07:12, 3 September 2012 (CEST)		@Yellows8, That's awesome! Can you explain a bit more about the buffer padding (maybe give an example) I want to add the foundings to 3dsexplorer and complete the saving algorithm (without the MAC signing ofcourse) --[[User:Elisherer\|Elisherer]] 07:12, 3 September 2012 (CEST)
	:Is it more clear with my last edit? The RomFS [https://github.com/3dshax/ctr/blob/master/ctrtool/ivfc.c IVFC] is basically identical to savegames, except savegames have the additional filesystem level.(Didn't realize that when I figured out the savegame hashes though) And it's not actually possible to generate the MAC yet with the AES engine, since the keyY for gamecard savegames is currently unknown. --[[User:Yellows8\|Yellows8]] 16:57, 3 September 2012 (CEST)		:Is it more clear with my last edit? The RomFS [https://github.com/3dshax/ctr/blob/master/ctrtool/ivfc.c IVFC] is basically identical to savegames, except savegames have the additional filesystem level.(Didn't realize that when I figured out the savegame hashes though) And it's not actually possible to generate the MAC yet with the AES engine, since the keyY for gamecard savegames is currently unknown. --[[User:Yellows8\|Yellows8]] 16:57, 3 September 2012 (CEST)
			::That's really interesting. I wonder what is the general idea here...Do savegames use the romFS structure.. --[[User:Elisherer\|Elisherer]] 00:00, 4 September 2012 (CEST)

Yellows8 at 14:57, 3 September 2012

2012-09-03T12:57:51Z

← Older revision		Revision as of 16:57, 3 September 2012
Line 112:		Line 112:

	@Yellows8, That's awesome! Can you explain a bit more about the buffer padding (maybe give an example) I want to add the foundings to 3dsexplorer and complete the saving algorithm (without the MAC signing ofcourse) --[[User:Elisherer\|Elisherer]] 07:12, 3 September 2012 (CEST)		@Yellows8, That's awesome! Can you explain a bit more about the buffer padding (maybe give an example) I want to add the foundings to 3dsexplorer and complete the saving algorithm (without the MAC signing ofcourse) --[[User:Elisherer\|Elisherer]] 07:12, 3 September 2012 (CEST)
			:Is it more clear with my last edit? The RomFS [https://github.com/3dshax/ctr/blob/master/ctrtool/ivfc.c IVFC] is basically identical to savegames, except savegames have the additional filesystem level.(Didn't realize that when I figured out the savegame hashes though) And it's not actually possible to generate the MAC yet with the AES engine, since the keyY for gamecard savegames is currently unknown. --[[User:Yellows8\|Yellows8]] 16:57, 3 September 2012 (CEST)

Elisherer at 05:12, 3 September 2012

2012-09-03T03:12:22Z

← Older revision		Revision as of 07:12, 3 September 2012
Line 108:		Line 108:
	@Yellows8, I think the old encryption is just [http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Electronic_codebook_.28ECB.29 AES-ECB] which is the same as AES-CTR whose counter isn't progressing... --[[User:Elisherer\|Elisherer]] 15:07, 25 March 2012 (CEST)		@Yellows8, I think the old encryption is just [http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Electronic_codebook_.28ECB.29 AES-ECB] which is the same as AES-CTR whose counter isn't progressing... --[[User:Elisherer\|Elisherer]] 15:07, 25 March 2012 (CEST)
	:It is not AES-ECB. If it were,(and Nintendo has never used AES-ECB directly) you would see the same encrypted 16-byte block for every all-zero 16-byte block. The CTR does increase, it just gets reset every X bytes. An encryption method only counts as direct AES-ECB only if the encrypted data is used as the AES input block, and the output block is used as the strait decrypted block. --[[User:Yellows8\|Yellows8]] 18:31, 25 March 2012 (CEST)		:It is not AES-ECB. If it were,(and Nintendo has never used AES-ECB directly) you would see the same encrypted 16-byte block for every all-zero 16-byte block. The CTR does increase, it just gets reset every X bytes. An encryption method only counts as direct AES-ECB only if the encrypted data is used as the AES input block, and the output block is used as the strait decrypted block. --[[User:Yellows8\|Yellows8]] 18:31, 25 March 2012 (CEST)

			== Hashes ==

			@Yellows8, That's awesome! Can you explain a bit more about the buffer padding (maybe give an example) I want to add the foundings to 3dsexplorer and complete the saving algorithm (without the MAC signing ofcourse) --[[User:Elisherer\|Elisherer]] 07:12, 3 September 2012 (CEST)

Yellows8: /* Encryption method */

2012-03-25T14:31:25Z

Encryption method

← Older revision		Revision as of 18:31, 25 March 2012
Line 107:		Line 107:

	@Yellows8, I think the old encryption is just [http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Electronic_codebook_.28ECB.29 AES-ECB] which is the same as AES-CTR whose counter isn't progressing... --[[User:Elisherer\|Elisherer]] 15:07, 25 March 2012 (CEST)		@Yellows8, I think the old encryption is just [http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Electronic_codebook_.28ECB.29 AES-ECB] which is the same as AES-CTR whose counter isn't progressing... --[[User:Elisherer\|Elisherer]] 15:07, 25 March 2012 (CEST)
			:It is not AES-ECB. If it were,(and Nintendo has never used AES-ECB directly) you would see the same encrypted 16-byte block for every all-zero 16-byte block. The CTR does increase, it just gets reset every X bytes. An encryption method only counts as direct AES-ECB only if the encrypted data is used as the AES input block, and the output block is used as the strait decrypted block. --[[User:Yellows8\|Yellows8]] 18:31, 25 March 2012 (CEST)

Elisherer at 13:07, 25 March 2012

2012-03-25T11:07:25Z

← Older revision		Revision as of 15:07, 25 March 2012
Line 103:		Line 103:

	I think this game is also using the new save encryption.--Matyapiro31 09:47, 19 February 2012 (CET)		I think this game is also using the new save encryption.--Matyapiro31 09:47, 19 February 2012 (CET)

			== Encryption method ==

			@Yellows8, I think the old encryption is just [http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Electronic_codebook_.28ECB.29 AES-ECB] which is the same as AES-CTR whose counter isn't progressing... --[[User:Elisherer\|Elisherer]] 15:07, 25 March 2012 (CEST)

Matyapiro31: add info on new save encryption game

2012-02-19T07:47:09Z

add info on new save encryption game

← Older revision		Revision as of 10:47, 19 February 2012
Line 99:		Line 99:
	Magic isn't always 0x080D6CE0, sometimes it is 0x080D6C80 or something in the like...		Magic isn't always 0x080D6CE0, sometimes it is 0x080D6C80 or something in the like...
	Unrelatedly, I wonder what kind of data unused blocks are mapped to (zeros or FF). Because those Rayman3D saves say that data goes up to 0xF000 (the end of the dewearleveled image), however there are usually no more than 4 blocks in use. --[[User:Luigi2us\|Luigi2us]] 00:05, 1 February 2012 (CET)		Unrelatedly, I wonder what kind of data unused blocks are mapped to (zeros or FF). Because those Rayman3D saves say that data goes up to 0xF000 (the end of the dewearleveled image), however there are usually no more than 4 blocks in use. --[[User:Luigi2us\|Luigi2us]] 00:05, 1 February 2012 (CET)

			[http://dl.dropbox.com/u/37418652/3DS/MH3G.sav\|MH3G save file]

			I think this game is also using the new save encryption.--Matyapiro31 09:47, 19 February 2012 (CET)

← Older revision		Revision as of 00:00, 4 September 2012
Line 113:		Line 113:
	@Yellows8, That's awesome! Can you explain a bit more about the buffer padding (maybe give an example) I want to add the foundings to 3dsexplorer and complete the saving algorithm (without the MAC signing ofcourse) --[[User:Elisherer\|Elisherer]] 07:12, 3 September 2012 (CEST)		@Yellows8, That's awesome! Can you explain a bit more about the buffer padding (maybe give an example) I want to add the foundings to 3dsexplorer and complete the saving algorithm (without the MAC signing ofcourse) --[[User:Elisherer\|Elisherer]] 07:12, 3 September 2012 (CEST)
	:Is it more clear with my last edit? The RomFS [https://github.com/3dshax/ctr/blob/master/ctrtool/ivfc.c IVFC] is basically identical to savegames, except savegames have the additional filesystem level.(Didn't realize that when I figured out the savegame hashes though) And it's not actually possible to generate the MAC yet with the AES engine, since the keyY for gamecard savegames is currently unknown. --[[User:Yellows8\|Yellows8]] 16:57, 3 September 2012 (CEST)		:Is it more clear with my last edit? The RomFS [https://github.com/3dshax/ctr/blob/master/ctrtool/ivfc.c IVFC] is basically identical to savegames, except savegames have the additional filesystem level.(Didn't realize that when I figured out the savegame hashes though) And it's not actually possible to generate the MAC yet with the AES engine, since the keyY for gamecard savegames is currently unknown. --[[User:Yellows8\|Yellows8]] 16:57, 3 September 2012 (CEST)
			::That's really interesting. I wonder what is the general idea here...Do savegames use the romFS structure.. --[[User:Elisherer\|Elisherer]] 00:00, 4 September 2012 (CEST)