Add a configuration option "Full w/ hashfile" to
the "verification" option menu, to enable hashfile
generation when doing full verification of a backup.
When enabled, during full backup verification we save the
chunk's SHA256 digest in a hashfile next to the output file
we're currently verifying.
The performance impact is negligible between "Full verify"
and "Full verify w/ hashfile", because we already
compute the SHA256 of the chunks when verifying.
We save the SHA256 per chunks (4 MB) because due to
SE limitations, we can't compute the SHA256 of the
whole partition (or rawnand).
On the other hand a pure software implementation
is way too slow to be bearable, even asm-optimized:
between 15 and 90 seconds per 4 MB chunk for
crc32/sha1/sha256, depending on the optimizations
and the actual algorithm.
The output hash file format is as follows:
# chunksize: <CHUNKSIZE_IN_BYTES>
sha256_of_chunk_1
sha256_of_chunk_2
...
sha256_of_chunk_N
Some Sandisk U1 sd cards do not behave nicely if they power cycle too fast. A min 100ms wait, is enough to mitigate that.
Fortunately, because of how the code paths are structured, this was never hit.
- Use always aligned buffers to up the speed for DMA usage. For verification, backup and restore.
- Rework verification a little bit and make default Sparse mode.
Sparse mode protects from fake sd cards, bad sectors and frequent I/O corruption. Aka, ~100% of cases.
- Allow no hekate_ipl.ini and create it at 1st hekate boot
- Show Payloads/More configs options when no boot entry in main .ini
- Fix black screen on empty ini/payload folders
- Fix some stack corruption with freeing ini lists (wip)
Currently bpmp loses access to the relevant registers when secmon or exosphere is launched.
This change provides support for all firmwares and properly sanitizes the display.
