Hack Change Identification and Acknowledgement message

[Ingunar]

Describe the current functionality: Changing the hack's offset or hash will not be acknowledged when replacing hack_hash.ini

To Reproduce:

1. Change any single hack's hash or offset in the hack_hash.ini file.
2. Replace the file on your SD card or USB with it.
3. Enter the Priiloader Menu.
4. Enter the "System Menu Hacks" section.
5. All of the hacks will still be enabled as before there was no change;
   The Priiloader will cache the enabled hacks from the NAND.

Version: 0.10.0

Requested change:

• The changed hack should be disabled.
• The hack_hash.ini change should be acknowledged on the first boot after the change.

Additional context: This problem is easily experienced by people who generate and change the [Fix NWC24iSetUniversalTime] hack.

[DacoTaco]

this sounds like a small change, but is most certainly not small. the questions/problems here are :

• stability. priiloader saves to NAND (and loads on boot) for stability reasons so it does not have a dependency with external devices
• what do we do with the saved hacks if a hack is changed and autoboot is enabled
• do we want to break the boot flow because a hack was changed
• how often are hacks changed outside of development

there is probably more that i can't think of now, but it should show this is not a small change

[Ingunar]

Maybe something like this:

1. Maybe an additional file could be added to NAND,
   (so Priiloader can do a basic compare/check of the hack_hash.ini on the SD/USB) Adding something like a hack version number check could maybe do the trick.
2. Disable the next first autoboot like when Priiloader gets updated
   (not sure how this is done currently, and is it because the full settings get deleted)
3. I would say yes, but not in the case when the hack_hash.ini is missing
4. With the addition of the "dynamic" hack [Fix NWC24iSetUniversalTime] I guess it has become more noticeable now.
   I guess we will see this problem reported more every time daylight savings starts and ends... #wehonestlyneeduniversalsolutionforthatone

[DacoTaco]

ye, that hack is... hacky :')

as for your idea of a hack version sounds bad and not necessary for something that should never change in production. i would rather say to add a hack's MD5 or SHA hash to the Hack's state file. but the problem is that it takes time to calculate and verify all hacks that are loaded, and on boot you do not want it seem like its doing nothing.

im personally also not fully convinced a changed hacks file should trigger a autoboot to be skipped. maybe im hesitant to change it, i don't know. maybe that could change if i can think of a fast but reliable way to check the state of the loaded hacks vs the saved ones on nand.

another problem : what if the hack_hash.ini is on a usb device that takes multiple seconds to respond? would boot have to wait for those devices to respond?

[Ingunar]

i would rather say to add a hack's MD5 or SHA

This was my first idea, but maybe that is just overcomplicating for this case

another problem : what if the hack_hash.ini is on a usb device that takes multiple seconds to respond? would boot have to wait for those devices to respond?

Yuuup :[

[Masamune3210]

imo, any time a critical part of the state changes, like the hacks, autoboot should probably be temp ignored just for the sake of making sure that everything is sane before proceeding. but that might just be me overthinking things