Will the typos ever end?
Some checks failed
update server / update (push) Has been cancelled

This commit is contained in:
Lillian Skinner 2025-01-04 01:56:07 -05:00
parent 3dace111ca
commit 61b5ac7e91
No known key found for this signature in database

View File

@ -14,7 +14,7 @@ preview: /preview.png
<p>
Nintendo DSi NANDs are just a FAT12 filesystem, and for the most part are very similar to any other type of data storage - the difference seems to be that files and fragments are stored at <code>0x200</code> instead of <code>0x1000</code>. This is not in multiples, so you won't see it as <code>0x400</code>, <code>0x600</code>, and so on.
<br><br>
MangaOn's file begins at <code>0x699200</code> in the image, and the filesize is stored at <code>0x210</code> in the header in little endian format - so <code>F8C000</code> in this case. From where comic.bin starts (notated with a <code>BVSC</code> header), there are headers for sections of the <code>.bin</code> (<code>11 00 08 00</code>), always occurring exactly on a multiple of <code>0x10</code>, and always preceded by at least 4 <code>FF FF FF FF</code> bytes. Using this, I was able to find where they stopped occuring, and work my way down the image to find where they resumed again. By knowing that fragments can only occur on <code>0x200</code>, I was able to find exactly where it stopped and started again. This occured one more time, and from there, it was a straight shot to the end of the file, which I found by using the length of the file I was missing, and luckily the rest of the build was stored in one clear shot from that point.
MangaON's file begins at <code>0x699200</code> in the image, and the filesize is stored at <code>0x210</code> in the header in little endian format - so <code>F8C000</code> in this case. From where comic.bin starts (notated with a <code>BVSC</code> header), there are headers for sections of the <code>.bin</code> (<code>11 00 08 00</code>), always occurring exactly on a multiple of <code>0x10</code>, and always preceded by at least 4 <code>FF FF FF FF</code> bytes. Using this, I was able to find where they stopped occuring, and work my way down the image to find where they resumed again. By knowing that fragments can only occur on <code>0x200</code>, I was able to find exactly where it stopped and started again. This occured one more time, and from there, it was a straight shot to the end of the file, which I found by using the length of the file I was missing, and luckily the rest of the build was stored in one clear shot from that point.
<br><br>
The locations from where the build was pieced back together are as follows:
<div class="code-div"><TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>