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 0x200 instead of 0x1000. This is not in multiples, so you won't see it as 0x400, 0x600, and so on.
-MangaOn's file begins at 0x699200 in the image, and the filesize is stored at 0x210 in the header in little endian format - so F8C000 in this case. From where comic.bin starts (notated with a BVSC header), there are headers for sections of the .bin (11 00 08 00), always occurring exactly on a multiple of 0x10, and always preceded by at least 4 FF FF FF FF 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 0x200, 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 0x699200 in the image, and the filesize is stored at 0x210 in the header in little endian format - so F8C000 in this case. From where comic.bin starts (notated with a BVSC header), there are headers for sections of the .bin (11 00 08 00), always occurring exactly on a multiple of 0x10, and always preceded by at least 4 FF FF FF FF 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 0x200, 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.
The locations from where the build was pieced back together are as follows: