https://www.3dbrew.org/w/index.php?title=Talk:Flash_Filesystem&feed=atom&action=historyTalk:Flash Filesystem - Revision history2024-03-29T00:49:24ZRevision history for this page on the wikiMediaWiki 1.35.8https://www.3dbrew.org/w/index.php?title=Talk:Flash_Filesystem&diff=17020&oldid=prevSmea: and at spelling apparently2016-04-17T21:07:00Z<p>and at spelling apparently</p>
<table class="diff diff-contentalign-left diff-editfont-monospace" data-mw="interface">
<col class="diff-marker" />
<col class="diff-content" />
<col class="diff-marker" />
<col class="diff-content" />
<tr class="diff-title" lang="en">
<td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">← Older revision</td>
<td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">Revision as of 21:07, 17 April 2016</td>
</tr><tr><td colspan="2" class="diff-lineno" id="mw-diff-left-l60" >Line 60:</td>
<td colspan="2" class="diff-lineno">Line 60:</td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>== Note: ==</div></td><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>== Note: ==</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"></td><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"></td></tr>
<tr><td class='diff-marker'>−</td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div>There is currently a third TWL partition <del class="diffchange diffchange-inline">who's </del>location in NAND is currently unknown. Said partition is TWLS, or TWL Sound. By default, this partition is empty, however, if you record a sound with the DSi Sound app, the partition is populated, similar to TWLP. --[[User:MassExplosion213|MassExplosion213]] 23:03, 17 April 2016 (CEST)</div></td><td class='diff-marker'>+</td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div>There is currently a third TWL partition <ins class="diffchange diffchange-inline">whose </ins>location in NAND is currently unknown. Said partition is TWLS, or TWL Sound. By default, this partition is empty, however, if you record a sound with the DSi Sound app, the partition is populated, similar to TWLP. --[[User:MassExplosion213|MassExplosion213]] 23:03, 17 April 2016 (CEST)</div></td></tr>
</table>Smeahttps://www.3dbrew.org/w/index.php?title=Talk:Flash_Filesystem&diff=17019&oldid=prevMassExplosion213: Because I'm awful at hitting buttons2016-04-17T21:04:15Z<p>Because I'm awful at hitting buttons</p>
<table class="diff diff-contentalign-left diff-editfont-monospace" data-mw="interface">
<col class="diff-marker" />
<col class="diff-content" />
<col class="diff-marker" />
<col class="diff-content" />
<tr class="diff-title" lang="en">
<td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">← Older revision</td>
<td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">Revision as of 21:04, 17 April 2016</td>
</tr><tr><td colspan="2" class="diff-lineno" id="mw-diff-left-l60" >Line 60:</td>
<td colspan="2" class="diff-lineno">Line 60:</td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>== Note: ==</div></td><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>== Note: ==</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"></td><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"></td></tr>
<tr><td class='diff-marker'>−</td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div>There is currently a third TWL partition who's location in NAND is currently unknown. Said partition is TWLS, or TWL Sound. By default, this partition is empty, however, if you record a sound with the DSi Sound app, the partition is populated, similar to TWLP. --[[User:MassExplosion213<del class="diffchange diffchange-inline">:</del>MassExplosion213]] 23:03, 17 April 2016 (CEST)</div></td><td class='diff-marker'>+</td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div>There is currently a third TWL partition who's location in NAND is currently unknown. Said partition is TWLS, or TWL Sound. By default, this partition is empty, however, if you record a sound with the DSi Sound app, the partition is populated, similar to TWLP. --[[User:MassExplosion213<ins class="diffchange diffchange-inline">|</ins>MassExplosion213]] 23:03, 17 April 2016 (CEST)</div></td></tr>
<!-- diff cache key 3dbrew:diff::1.12:old-17018:rev-17019 -->
</table>MassExplosion213https://www.3dbrew.org/w/index.php?title=Talk:Flash_Filesystem&diff=17018&oldid=prevMassExplosion213 at 21:03, 17 April 20162016-04-17T21:03:33Z<p></p>
<table class="diff diff-contentalign-left diff-editfont-monospace" data-mw="interface">
<col class="diff-marker" />
<col class="diff-content" />
<col class="diff-marker" />
<col class="diff-content" />
<tr class="diff-title" lang="en">
<td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">← Older revision</td>
<td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">Revision as of 21:03, 17 April 2016</td>
</tr><tr><td colspan="2" class="diff-lineno" id="mw-diff-left-l57" >Line 57:</td>
<td colspan="2" class="diff-lineno">Line 57:</td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>::::::Aren't you talking about a movable.sed file or there are others not mentioned explicitly?--[[User:Duke srg|Duke srg]] 14:01, 11 April 2014 (CEST)</div></td><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>::::::Aren't you talking about a movable.sed file or there are others not mentioned explicitly?--[[User:Duke srg|Duke srg]] 14:01, 11 April 2014 (CEST)</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>:::::::No, I mean this: [[Title_Database]]. --[[User:Yellows8|Yellows8]] 18:23, 11 April 2014 (CEST)</div></td><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>:::::::No, I mean this: [[Title_Database]]. --[[User:Yellows8|Yellows8]] 18:23, 11 April 2014 (CEST)</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins style="font-weight: bold; text-decoration: none;"></ins></div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins style="font-weight: bold; text-decoration: none;">== Note: ==</ins></div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins style="font-weight: bold; text-decoration: none;"></ins></div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins style="font-weight: bold; text-decoration: none;">There is currently a third TWL partition who's location in NAND is currently unknown. Said partition is TWLS, or TWL Sound. By default, this partition is empty, however, if you record a sound with the DSi Sound app, the partition is populated, similar to TWLP. --[[User:MassExplosion213:MassExplosion213]] 23:03, 17 April 2016 (CEST)</ins></div></td></tr>
</table>MassExplosion213https://www.3dbrew.org/w/index.php?title=Talk:Flash_Filesystem&diff=8915&oldid=prevYellows8: /* Possible firmware downgrade vulnerability */2014-04-11T16:23:58Z<p><span dir="auto"><span class="autocomment">Possible firmware downgrade vulnerability</span></span></p>
<table class="diff diff-contentalign-left diff-editfont-monospace" data-mw="interface">
<col class="diff-marker" />
<col class="diff-content" />
<col class="diff-marker" />
<col class="diff-content" />
<tr class="diff-title" lang="en">
<td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">← Older revision</td>
<td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">Revision as of 16:23, 11 April 2014</td>
</tr><tr><td colspan="2" class="diff-lineno" id="mw-diff-left-l56" >Line 56:</td>
<td colspan="2" class="diff-lineno">Line 56:</td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>:::::Yeah, at least one of those console-unique AESMACs would be rendered invalid with method you're describing. --[[User:Yellows8|Yellows8]] 06:21, 11 April 2014 (CEST)</div></td><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>:::::Yeah, at least one of those console-unique AESMACs would be rendered invalid with method you're describing. --[[User:Yellows8|Yellows8]] 06:21, 11 April 2014 (CEST)</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>::::::Aren't you talking about a movable.sed file or there are others not mentioned explicitly?--[[User:Duke srg|Duke srg]] 14:01, 11 April 2014 (CEST)</div></td><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>::::::Aren't you talking about a movable.sed file or there are others not mentioned explicitly?--[[User:Duke srg|Duke srg]] 14:01, 11 April 2014 (CEST)</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins style="font-weight: bold; text-decoration: none;">:::::::No, I mean this: [[Title_Database]]. --[[User:Yellows8|Yellows8]] 18:23, 11 April 2014 (CEST)</ins></div></td></tr>
</table>Yellows8https://www.3dbrew.org/w/index.php?title=Talk:Flash_Filesystem&diff=8914&oldid=prevDuke srg at 12:01, 11 April 20142014-04-11T12:01:52Z<p></p>
<table class="diff diff-contentalign-left diff-editfont-monospace" data-mw="interface">
<col class="diff-marker" />
<col class="diff-content" />
<col class="diff-marker" />
<col class="diff-content" />
<tr class="diff-title" lang="en">
<td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">← Older revision</td>
<td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">Revision as of 12:01, 11 April 2014</td>
</tr><tr><td colspan="2" class="diff-lineno" id="mw-diff-left-l55" >Line 55:</td>
<td colspan="2" class="diff-lineno">Line 55:</td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>::::Ok, just to clarify, during system update AESMAC init file IS updated with the new console-unique data. So after transferring firmware changes from one system to another without complete decypher, during next boot at least AESMAC file on CTR NAND partition contents will have wrong data and REG_AESMAC being initialized with that will fail the following boot process. Smart enough.--[[User:Duke srg|Duke srg]] 05:59, 11 April 2014 (CEST)</div></td><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>::::Ok, just to clarify, during system update AESMAC init file IS updated with the new console-unique data. So after transferring firmware changes from one system to another without complete decypher, during next boot at least AESMAC file on CTR NAND partition contents will have wrong data and REG_AESMAC being initialized with that will fail the following boot process. Smart enough.--[[User:Duke srg|Duke srg]] 05:59, 11 April 2014 (CEST)</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>:::::Yeah, at least one of those console-unique AESMACs would be rendered invalid with method you're describing. --[[User:Yellows8|Yellows8]] 06:21, 11 April 2014 (CEST)</div></td><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>:::::Yeah, at least one of those console-unique AESMACs would be rendered invalid with method you're describing. --[[User:Yellows8|Yellows8]] 06:21, 11 April 2014 (CEST)</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins style="font-weight: bold; text-decoration: none;">::::::Aren't you talking about a movable.sed file or there are others not mentioned explicitly?--[[User:Duke srg|Duke srg]] 14:01, 11 April 2014 (CEST)</ins></div></td></tr>
<!-- diff cache key 3dbrew:diff::1.12:old-8913:rev-8914 -->
</table>Duke srghttps://www.3dbrew.org/w/index.php?title=Talk:Flash_Filesystem&diff=8913&oldid=prevYellows8: /* Possible firmware downgrade vulnerability */2014-04-11T04:21:54Z<p><span dir="auto"><span class="autocomment">Possible firmware downgrade vulnerability</span></span></p>
<table class="diff diff-contentalign-left diff-editfont-monospace" data-mw="interface">
<col class="diff-marker" />
<col class="diff-content" />
<col class="diff-marker" />
<col class="diff-content" />
<tr class="diff-title" lang="en">
<td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">← Older revision</td>
<td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">Revision as of 04:21, 11 April 2014</td>
</tr><tr><td colspan="2" class="diff-lineno" id="mw-diff-left-l54" >Line 54:</td>
<td colspan="2" class="diff-lineno">Line 54:</td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>:::The CTRNAND files /w console-unique AESMACs I'm referring to get updated when sys-updates get installed, if those don't get updated properly(invalid AESMACs for example) you would have a system which would fail to boot when it tries to launch titles from CTRNAND-FS. There's no way to properly update those files without proper NAND xorpads/etc. --[[User:Yellows8|Yellows8]] 22:11, 10 April 2014 (CEST)</div></td><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>:::The CTRNAND files /w console-unique AESMACs I'm referring to get updated when sys-updates get installed, if those don't get updated properly(invalid AESMACs for example) you would have a system which would fail to boot when it tries to launch titles from CTRNAND-FS. There's no way to properly update those files without proper NAND xorpads/etc. --[[User:Yellows8|Yellows8]] 22:11, 10 April 2014 (CEST)</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>::::Ok, just to clarify, during system update AESMAC init file IS updated with the new console-unique data. So after transferring firmware changes from one system to another without complete decypher, during next boot at least AESMAC file on CTR NAND partition contents will have wrong data and REG_AESMAC being initialized with that will fail the following boot process. Smart enough.--[[User:Duke srg|Duke srg]] 05:59, 11 April 2014 (CEST)</div></td><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>::::Ok, just to clarify, during system update AESMAC init file IS updated with the new console-unique data. So after transferring firmware changes from one system to another without complete decypher, during next boot at least AESMAC file on CTR NAND partition contents will have wrong data and REG_AESMAC being initialized with that will fail the following boot process. Smart enough.--[[User:Duke srg|Duke srg]] 05:59, 11 April 2014 (CEST)</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins style="font-weight: bold; text-decoration: none;">:::::Yeah, at least one of those console-unique AESMACs would be rendered invalid with method you're describing. --[[User:Yellows8|Yellows8]] 06:21, 11 April 2014 (CEST)</ins></div></td></tr>
</table>Yellows8https://www.3dbrew.org/w/index.php?title=Talk:Flash_Filesystem&diff=8909&oldid=prevDuke srg: typo2014-04-11T04:00:59Z<p>typo</p>
<table class="diff diff-contentalign-left diff-editfont-monospace" data-mw="interface">
<col class="diff-marker" />
<col class="diff-content" />
<col class="diff-marker" />
<col class="diff-content" />
<tr class="diff-title" lang="en">
<td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">← Older revision</td>
<td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">Revision as of 04:00, 11 April 2014</td>
</tr><tr><td colspan="2" class="diff-lineno" id="mw-diff-left-l53" >Line 53:</td>
<td colspan="2" class="diff-lineno">Line 53:</td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>::I'm not about converting a NAND image from system to another directly. Can we alculate for a various firmware byte-to-byte XOR-difference, which result the same xorpads for each system to annihilate. And for the same CTRNAND files untouched with a firmware update this difference will be zero. So applying this difference for another console CTRNAND will update a firmware without the need of the actual console-unique xorpad--[[User:Duke srg|Duke srg]] 21:48, 10 April 2014 (CEST)</div></td><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>::I'm not about converting a NAND image from system to another directly. Can we alculate for a various firmware byte-to-byte XOR-difference, which result the same xorpads for each system to annihilate. And for the same CTRNAND files untouched with a firmware update this difference will be zero. So applying this difference for another console CTRNAND will update a firmware without the need of the actual console-unique xorpad--[[User:Duke srg|Duke srg]] 21:48, 10 April 2014 (CEST)</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>:::The CTRNAND files /w console-unique AESMACs I'm referring to get updated when sys-updates get installed, if those don't get updated properly(invalid AESMACs for example) you would have a system which would fail to boot when it tries to launch titles from CTRNAND-FS. There's no way to properly update those files without proper NAND xorpads/etc. --[[User:Yellows8|Yellows8]] 22:11, 10 April 2014 (CEST)</div></td><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>:::The CTRNAND files /w console-unique AESMACs I'm referring to get updated when sys-updates get installed, if those don't get updated properly(invalid AESMACs for example) you would have a system which would fail to boot when it tries to launch titles from CTRNAND-FS. There's no way to properly update those files without proper NAND xorpads/etc. --[[User:Yellows8|Yellows8]] 22:11, 10 April 2014 (CEST)</div></td></tr>
<tr><td class='diff-marker'>−</td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div>::::Ok, just to clarify, during system update AESMAC init file IS updated with the new console-unique data. So after transferring firmware <del class="diffchange diffchange-inline">canges </del>from one system to another without complete decypher, during next boot at least AESMAC file on CTR NAND partition contents will have wrong data and REG_AESMAC being initialized with that will fail the following boot process. Smart enough.--[[User:Duke srg|Duke srg]] 05:59, 11 April 2014 (CEST)</div></td><td class='diff-marker'>+</td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div>::::Ok, just to clarify, during system update AESMAC init file IS updated with the new console-unique data. So after transferring firmware <ins class="diffchange diffchange-inline">changes </ins>from one system to another without complete decypher, during next boot at least AESMAC file on CTR NAND partition contents will have wrong data and REG_AESMAC being initialized with that will fail the following boot process. Smart enough.--[[User:Duke srg|Duke srg]] 05:59, 11 April 2014 (CEST)</div></td></tr>
</table>Duke srghttps://www.3dbrew.org/w/index.php?title=Talk:Flash_Filesystem&diff=8908&oldid=prevDuke srg at 03:59, 11 April 20142014-04-11T03:59:42Z<p></p>
<table class="diff diff-contentalign-left diff-editfont-monospace" data-mw="interface">
<col class="diff-marker" />
<col class="diff-content" />
<col class="diff-marker" />
<col class="diff-content" />
<tr class="diff-title" lang="en">
<td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">← Older revision</td>
<td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">Revision as of 03:59, 11 April 2014</td>
</tr><tr><td colspan="2" class="diff-lineno" id="mw-diff-left-l53" >Line 53:</td>
<td colspan="2" class="diff-lineno">Line 53:</td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>::I'm not about converting a NAND image from system to another directly. Can we alculate for a various firmware byte-to-byte XOR-difference, which result the same xorpads for each system to annihilate. And for the same CTRNAND files untouched with a firmware update this difference will be zero. So applying this difference for another console CTRNAND will update a firmware without the need of the actual console-unique xorpad--[[User:Duke srg|Duke srg]] 21:48, 10 April 2014 (CEST)</div></td><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>::I'm not about converting a NAND image from system to another directly. Can we alculate for a various firmware byte-to-byte XOR-difference, which result the same xorpads for each system to annihilate. And for the same CTRNAND files untouched with a firmware update this difference will be zero. So applying this difference for another console CTRNAND will update a firmware without the need of the actual console-unique xorpad--[[User:Duke srg|Duke srg]] 21:48, 10 April 2014 (CEST)</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>:::The CTRNAND files /w console-unique AESMACs I'm referring to get updated when sys-updates get installed, if those don't get updated properly(invalid AESMACs for example) you would have a system which would fail to boot when it tries to launch titles from CTRNAND-FS. There's no way to properly update those files without proper NAND xorpads/etc. --[[User:Yellows8|Yellows8]] 22:11, 10 April 2014 (CEST)</div></td><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>:::The CTRNAND files /w console-unique AESMACs I'm referring to get updated when sys-updates get installed, if those don't get updated properly(invalid AESMACs for example) you would have a system which would fail to boot when it tries to launch titles from CTRNAND-FS. There's no way to properly update those files without proper NAND xorpads/etc. --[[User:Yellows8|Yellows8]] 22:11, 10 April 2014 (CEST)</div></td></tr>
<tr><td class='diff-marker'>−</td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div>::::Ok, just to clarify, during system update AESMAC init file IS updated with the new console-unique data. So after transferring firmware canges from one system to another without complete decypher, during next boot at least AESMAC file on CTR NAND partition contents will have wrong data and REG_AESMAC being initialized with that will fail the following boot process. Smart enough.</div></td><td class='diff-marker'>+</td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div>::::Ok, just to clarify, during system update AESMAC init file IS updated with the new console-unique data. So after transferring firmware canges from one system to another without complete decypher, during next boot at least AESMAC file on CTR NAND partition contents will have wrong data and REG_AESMAC being initialized with that will fail the following boot process. Smart enough.<ins class="diffchange diffchange-inline">--[[User:Duke srg|Duke srg]] 05:59, 11 April 2014 (CEST)</ins></div></td></tr>
</table>Duke srghttps://www.3dbrew.org/w/index.php?title=Talk:Flash_Filesystem&diff=8907&oldid=prevDuke srg: /* Possible firmware downgrade vulnerability */2014-04-11T03:57:24Z<p><span dir="auto"><span class="autocomment">Possible firmware downgrade vulnerability</span></span></p>
<table class="diff diff-contentalign-left diff-editfont-monospace" data-mw="interface">
<col class="diff-marker" />
<col class="diff-content" />
<col class="diff-marker" />
<col class="diff-content" />
<tr class="diff-title" lang="en">
<td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">← Older revision</td>
<td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">Revision as of 03:57, 11 April 2014</td>
</tr><tr><td colspan="2" class="diff-lineno" id="mw-diff-left-l53" >Line 53:</td>
<td colspan="2" class="diff-lineno">Line 53:</td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>::I'm not about converting a NAND image from system to another directly. Can we alculate for a various firmware byte-to-byte XOR-difference, which result the same xorpads for each system to annihilate. And for the same CTRNAND files untouched with a firmware update this difference will be zero. So applying this difference for another console CTRNAND will update a firmware without the need of the actual console-unique xorpad--[[User:Duke srg|Duke srg]] 21:48, 10 April 2014 (CEST)</div></td><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>::I'm not about converting a NAND image from system to another directly. Can we alculate for a various firmware byte-to-byte XOR-difference, which result the same xorpads for each system to annihilate. And for the same CTRNAND files untouched with a firmware update this difference will be zero. So applying this difference for another console CTRNAND will update a firmware without the need of the actual console-unique xorpad--[[User:Duke srg|Duke srg]] 21:48, 10 April 2014 (CEST)</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>:::The CTRNAND files /w console-unique AESMACs I'm referring to get updated when sys-updates get installed, if those don't get updated properly(invalid AESMACs for example) you would have a system which would fail to boot when it tries to launch titles from CTRNAND-FS. There's no way to properly update those files without proper NAND xorpads/etc. --[[User:Yellows8|Yellows8]] 22:11, 10 April 2014 (CEST)</div></td><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>:::The CTRNAND files /w console-unique AESMACs I'm referring to get updated when sys-updates get installed, if those don't get updated properly(invalid AESMACs for example) you would have a system which would fail to boot when it tries to launch titles from CTRNAND-FS. There's no way to properly update those files without proper NAND xorpads/etc. --[[User:Yellows8|Yellows8]] 22:11, 10 April 2014 (CEST)</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins style="font-weight: bold; text-decoration: none;">::::Ok, just to clarify, during system update AESMAC init file IS updated with the new console-unique data. So after transferring firmware canges from one system to another without complete decypher, during next boot at least AESMAC file on CTR NAND partition contents will have wrong data and REG_AESMAC being initialized with that will fail the following boot process. Smart enough.</ins></div></td></tr>
</table>Duke srghttps://www.3dbrew.org/w/index.php?title=Talk:Flash_Filesystem&diff=8905&oldid=prevYellows8: /* Possible firmware downgrade vulnerability */2014-04-10T20:11:35Z<p><span dir="auto"><span class="autocomment">Possible firmware downgrade vulnerability</span></span></p>
<table class="diff diff-contentalign-left diff-editfont-monospace" data-mw="interface">
<col class="diff-marker" />
<col class="diff-content" />
<col class="diff-marker" />
<col class="diff-content" />
<tr class="diff-title" lang="en">
<td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">← Older revision</td>
<td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">Revision as of 20:11, 10 April 2014</td>
</tr><tr><td colspan="2" class="diff-lineno" id="mw-diff-left-l52" >Line 52:</td>
<td colspan="2" class="diff-lineno">Line 52:</td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>:There's no way to convert a NAND image from one 3DS for use on another 3DS, without generating the NAND xorpad(s) for both systems(requires ARM9 code exec on both). Another reason why ARM9 exec is needed here is because there's certain files stored in CTRNAND containing console-unique AESMACs. Since that keyslot is initialized by bootrom those AESMACs can only be calculated on the same 3DS which you're calculating these CTRNAND AESMACs for. --[[User:Yellows8|Yellows8]] 18:02, 10 April 2014 (CEST)</div></td><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>:There's no way to convert a NAND image from one 3DS for use on another 3DS, without generating the NAND xorpad(s) for both systems(requires ARM9 code exec on both). Another reason why ARM9 exec is needed here is because there's certain files stored in CTRNAND containing console-unique AESMACs. Since that keyslot is initialized by bootrom those AESMACs can only be calculated on the same 3DS which you're calculating these CTRNAND AESMACs for. --[[User:Yellows8|Yellows8]] 18:02, 10 April 2014 (CEST)</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>::I'm not about converting a NAND image from system to another directly. Can we alculate for a various firmware byte-to-byte XOR-difference, which result the same xorpads for each system to annihilate. And for the same CTRNAND files untouched with a firmware update this difference will be zero. So applying this difference for another console CTRNAND will update a firmware without the need of the actual console-unique xorpad--[[User:Duke srg|Duke srg]] 21:48, 10 April 2014 (CEST)</div></td><td class='diff-marker'> </td><td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><div>::I'm not about converting a NAND image from system to another directly. Can we alculate for a various firmware byte-to-byte XOR-difference, which result the same xorpads for each system to annihilate. And for the same CTRNAND files untouched with a firmware update this difference will be zero. So applying this difference for another console CTRNAND will update a firmware without the need of the actual console-unique xorpad--[[User:Duke srg|Duke srg]] 21:48, 10 April 2014 (CEST)</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins style="font-weight: bold; text-decoration: none;">:::The CTRNAND files /w console-unique AESMACs I'm referring to get updated when sys-updates get installed, if those don't get updated properly(invalid AESMACs for example) you would have a system which would fail to boot when it tries to launch titles from CTRNAND-FS. There's no way to properly update those files without proper NAND xorpads/etc. --[[User:Yellows8|Yellows8]] 22:11, 10 April 2014 (CEST)</ins></div></td></tr>
</table>Yellows8