rvtr/rmc_website
1
Fork 0
mirror of https://github.com/rvtr/rmc_website.git synced 2025-06-18 10:25:30 -04:00
Code Issues Actions Packages Projects Releases Wiki Activity

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

Browse Source
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
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
dsidev/release/dev-nands_update.html
View File

@ -14,7 +14,7 @@ preview: /preview.png
<p> <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. 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> <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> <br><br>
The locations from where the build was pieced back together are as follows: 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> <div class="code-div"><TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0><TR><TD><PRE>