How to write a non-intrusive hack

[test011]

This explains an idea to design hacks that don't interfere with stock firmware installation.
I am not saying it would work on every hack, but it would in many cases. If you write Kindle hacks, it’s worth a read.

Some basics. Kindle has following run level.

runlevel 2 : Booting (/etc/inittab defines this as default runlevel)
/etc/rc2.d/S50battcheck launches runlevel 5

runlevel 3 : Update done in this level.
/etc/rc3.d/S50updater launches runlevel 5

runlevel 4 : Recovery?
/etc/rc4.d/S99diag_reboot this reboots Kindle

runlevel 5 : Conventional
Runs usual Kindle framework

runlevel 6 : Kernel toggle?
/etc/rc6.d/S50kernel_toggle does something but not really sure what.


When user selects "UPDATE" in runlevel 5 menu Settings, Kindle goes down to runlevel 3 and do Update and then goes back to level 5 to execute Kindle framework.

Runlevel 3 and 5 are what we are interested in. If we can clear up hacks temporarily in runlevel3(rc3.d), stock firmware can be installed without a problem.

OK, now we have an idea how Kindle runs around, let’s think about this;

When a hack is installed, it usually insets a name tag in /etc/prettyversion.txt. This is one of the reasons that stock firmware rejects hacked kindle.

So, some hack doesn’t do anything to /etc/prettyversion.txt and remains invisible. That’s fine, but if you’d like to put something in it, this can be overcome by modifying /etc/prettyversion.txt in init script, not in install script. That means /etc/prettyversion.txt must be modified in init script at runlevel5 and restored to stock state when Kindle goes into runlevel3.

To sum up, a non-intrusive hack can be made with…

1) install and uninstall script must not modify /etc/prettyversion.txt directly. Put whatever necessary into init script. (adding and removing name tag along with whatever the hack needs to do)
2) when init script is started, add name tag string to /etc/prettyversion.txt. When init script is stopped, remove name tag string.
3) install script should create two sym-links, init script as /etc/rc5.d/S###### and as /etc/rc3.d/K######
4) uninstall script should remove the init script and sym-links created in 3)

The whole credit goes to kukyakya from my local forum. (I am just doing a quick and dirty translation and don't really understand what I am translating)

kukyakya has successfully released a font hack in this manner. I am using it. It's publicly available but the site is not in English, thus not sure I should link it.

Anyway let me remind you that kukyakya has a gmail account by the same name, if you have any thing to add.

I hope this is enough for gurus out there. What I most want to see is a screen saver hack done in this way.

[NiLuJe]

That's good to know, thanks!

I personnaly really like porkupan's idea of using a single init script + symlink, which checks for a trigger file in the user partition, and then only runs the actual hack from a script there if the trigger file is found.

Also, bind mounts. Niiiice.

[test011]

Great job NiLuJe!

Very similar idea is used in kukyakya's font hack. It'd been first released on last December. The first release had a file triggered script like porkupan's and fonts were in user partition like porkupan's, had an anti-brick scripts, and automatically using the respective original fonts if some fonts are missing from user partition font folder. Though fonts were copied, not mounted.

Anyway, it's a shame that it wasn't published here earlier.

I got the permission so, these are the links to his files. You might look at the repository for the source for runlevel3 implementation.

Note: It's not in English.

https://redmine.kukyakya.pe.kr/proje...iki/Customfont
https://redmine.kukyakya.pe.kr/proje...ont/repository
https://redmine.kukyakya.pe.kr/attac...omfont.r60.zip

Release60 is for 2.5 Kindle of course. This font hack has runlevel3 automatic disable switch which every Kindle hack should have.

[NiLuJe]

Nice, I'll take a look at that later!

EDIT:
There's some really nice ideas here, but it's still a bit too intrusive for my tastes, with the addition of two static binaries, even if it's just rsync & fatattr .

And even if it's nice to know how to do things to let official updates run, I actually like to let the choice to the user. (You want to run an update, just remove the trigger file and reboot, in the meantime, you'll have 'trapped' the OTA update file, and it's always nice to be able to take a look at them ^^⁾ (Edit: moot point, see my answer later ^^)

One thing I really really like is the reboot on usb plugout feature, that's really nice, I might try that. Too bad you have to launch another process in the background to achieve it. (Yes, I really want to avoid touching/adding/running new things in the system side of things ^^).

[test011]

Thank you for the comment.

About OTA thing, many of average users wouldn't really want to capture anything, they just don't like any inconvenience created by a hack. But it's good to have choice, in both way.

Maybe you could consider a file switch to on/off a smooth OTA update with your next hack version.

[NiLuJe]

Yeah, I just realised that I really just needed to copy any *.bin file found on /mnt/us/ somewhere on shutdown, and that'll be the end of that problem... -_-" Kinda freaked that it took me two days to think of that. Must. sleep. more.

So, yeah, thanks for the info!