MobileRead Forums

MobileRead Forums (https://www.mobileread.com/forums/index.php)
-   Kindle Developer's Corner (https://www.mobileread.com/forums/forumdisplay.php?f=150)
-   -   BackDoorLock hack - prevents silent updates (https://www.mobileread.com/forums/showthread.php?t=205666)

dsmid 02-13-2013 05:06 AM

BackDoorLock hack - prevents silent updates
 
3 Attachment(s)
This simple hack has only one purpose: stop Amazon from updating your Kindle silently without your explicit consent.
It is intended for users who believe in "My device - my rules" principle.

It doesn't stop Kindle from downloading the update file but once it is downloaded, any silent installation attempt
fails instantly in an early stage without depleting the battery and intercepting the GUI.
The update file is preserved after such failed attempt and thus it is not downloaded again and again.
Full updates are recognized during the attempt and a countermeasure is deployed
(dummy update file update__this-file-prevents-installing-on-reboot.bin is created to confuse the boot-time updater)

Manual update triggered by user is still possible (i.e. selecting "Update Your Kindle" in the menu).

When an update attempt is detected and subfolder /documents/backdoorlock exists in your Kindle,
you will find a new document named "Silent update attempt detected" containing the details on your home screen.

You shouldn't ever need to disable/uninstall this hack as it doesn't stop you from installing anything manually.
The only exception is when an incremental update needs to patch the file /etc/updater.conf - such update would fail
with an error. Only then you would need to uninstall the hack or deactivate it with KUAL.
You would also need to reinstall/reactivate the hack after installing a full update (the huge one).

It was tested on Kindle 3 and Kindle 4 but should work on any Kindle, PW2 included.
Silent update detection does not work on Kindle Touch and Kindle Paperwhite as the hack uses a different method
to stop silent updates on these devices.

You can install the hack as a classic update bundle or a KUAL extension. Please do not install both.


Installing using update bundle

Make sure you have already jailbroken your Kindle.

Extract backdoorlock_*version*.zip and choose an appropriate update_backdoorlock_*_install.bin file for your Kindle model:

- If you have Kindle Keyboard 3G, choose update_backdoorlock_*version*_k3g_install.bin [serial number starts with B006]
or update_backdoorlock_*version*_k3gb_install.bin [serial number starts with B00A]

- If you have Kindle Keyboard WiFi, choose update_backdoorlock_*version*_k3w_install.bin

- For all other models choose update_backdoorlock_*version*_install.bin

Then copy the chosen update_*.bin file to root of your Kindle storage, safely eject your Kindle
and on Kindle go to *[HOME] -> [MENU] > Settings -> [MENU] > Update Your Kindle*.

Use the same steps to uninstall the hack, just use an appropriate update_backdoorlock_*_uninstall.bin file instead.


Installing using KUAL (Kindle Unified Application Launcher)

Make sure you have KUAL installed properly.

Extract backdoorlock_kual_*version*.zip and copy the contents (the backdoorlock folder) to folder /extensions on your Kindle.
Safely eject your Kindle and find five new menu items in KUAL.

If you want to fully uninstall the extension, remember to unlock the back door before deleting the extension folder.

If you want to read the lock state report as a document, create a subfolder /documents/backdoorlock in your Kindle.
Then the report will be created in this folder everytime you select the "Lock state" menu item.
On the other hand, if you don't like the onscreen reports and prefer to read the document only, create an empty file named noeips
in folder /extensions/backdoorlock/ .

Spoiler:

Here is how it works:

It replaces the line
Code:

_UPDATE_WAIT="/usr/sbin/updatewait"
in /etc/updater.conf with this one:
Code:

_UPDATE_WAIT="$(if [ -x /mnt/us/backdoorlock/updatewait ]; then echo /mnt/us/backdoorlock/updatewait; else echo /usr/sbin/updatewait; fi)"
Wrapper script /mnt/us/backdoorlock/updatewait passes any calls to /usr/sbin/updatewait but only if called with parameter -i (immediate/interactive) - that's how "Update Your Kindle" calls it.
OTOH silent updates call updatewait without any parameters and such attempts are intercepted and logged to /mnt/us/backdoorlock/update.log or /mnt/us/extensions/backdoorlock/update.log .

On KT and KPW lines
Code:

legacy.GET.FWUO=com.lab126.ota
legacy.GET.FWUP=com.lab126.ota

are commented out in file /etc/todo/handler_registry.conf

knc1 02-13-2013 08:33 AM

Quote:

Originally Posted by dsmid (Post 2422069)
This simple hack has only one purpose: stop Amazon from updating your Kindle silently without your explicit consent.
It is intended for users who believe in "My device - my rules" principle.

It doesn't stop Kindle from downloading the update file but once it is downloaded, any silent installation attempt fails instantly in an early stage without depleting the battery and intercepting the GUI.
The update file is preserved after such failed attempt and thus it is not downloaded again and again.

Manual update triggered by user is still possible (i.e. selecting "Update Your Kindle" in the menu).

It was tested on Kindle 4 but should work on any Kindle.

Spoiler:

Here is how it works:

It replaces the line
Code:

_UPDATE_WAIT="/usr/sbin/updatewait"
in /etc/updater.conf with this one:
Code:

_UPDATE_WAIT="$(if [ -x /mnt/us/backdoorlock/updatewait ]; then echo /mnt/us/backdoorlock/updatewait; else echo /usr/sbin/updatewait; fi)"
Wrapper script /mnt/us/backdoorlock/updatewait passes any calls to /usr/sbin/updatewait but only if called with parameter -i (immediate/interactive) - that's how "Update Your Kindle" calls it.
OTOH silent updates call updatewait without any parameters and such attempts are intercepted and logged to /mnt/us/backdoorlock/update.log .

Does this also prevent the updater in the initramfs from running when the update file is present during a full reboot (cold start)?

If unknown, please test for that and report back.

twobob 02-13-2013 09:14 AM

I love you. but some source would be nice.

Tidy. thanks

dsmid 02-13-2013 09:36 AM

Quote:

Originally Posted by knc1 (Post 2422230)
Does this also prevent the updater in the initramfs from running when the update file is present during a full reboot (cold start)?

If unknown, please test for that and report back.

Well, when I left an update from Amazon in the user store (Update_1615370055_1813030025.bin) and rebooted, it didn't do anything.
On the other hand, doing the same thing with a hack (update_loc_cz_4.1r62_k4_install.bin) gave me "Update error 3" on boot.
I suppose that the initramfs beast is looking for update files with a lowercase prefix of update_ or is silently ignoring Amazon signed packages that are not full updates.
I don't know how would a full update package behave on reboot though (there are no such updates for my Kindle models). It may get installed.

The problem is that deleting/damaging the update file would trigger redownloading and I'm trying to avoid that.
Maybe an init script purging any update files in user store scheduled to launch when Kindle is shutting down would solve the problem.

eureka 02-13-2013 09:58 AM

Quote:

Originally Posted by dsmid (Post 2422319)
The problem is that deleting/damaging the update file would trigger redownloading and I'm trying to avoid that.
Maybe an init script purging any update files in user store scheduled to launch when Kindle is shutting down would solve the problem.

Look here for detailed description of OTA updating process for KT/PW and method of disrupting it with minimal, precisely targeted changes so that no update would be never downloaded at all. Maybe you'll find something similar in K4.

dsmid 02-13-2013 10:30 AM

Thanks for the hint eureka, unfortunately Kindle 3 & 4 doesn't have /etc/todo/handler_registry.conf nor otaupd daemon.

On Kindle 3 & 4, Transfer Manager Daemon (tmd) handles the downloading part, reports back to framework via DBus when the download is complete and then the framework creates file /tmp/.framework_update (containing path to the downloaded update file) and, on the occasion of entering sleep mode, launches process_update which in turn launches updatewait which in turn launches process_update -i after some preconditions are met (battery level sufficient etc.).

"Update Your Kindle" launches updatewait -i which in turn launches process_update -i.

twobob 02-13-2013 10:37 AM

Quote:

Originally Posted by dsmid (Post 2422385)
Thanks for the hint eureka, unfortunately Kindle 3 & 4 doesn't have /etc/todo/handler_registry.conf nor otaupd daemon.

On Kindle 3 & 4, Transfer Manager Daemon (tmd) handles the downloading part, reports back to framework via DBus when the download is complete and then the framework creates file /tmp/.framework_update (containing path to the downloaded update file) and launches updatewait .

Wow. Good info. Thanks :)

dsmid 02-13-2013 11:28 AM

Maybe I've got a solution.
I've extracted all strings from KPW 5.3.3 recovery_util (initramfs binary responsible for handling updates) and found this:

Code:

update*.bin
ERROR:Refusing to update: %d update files were found. Expected to find only one.

What about creating yet another dummy update file when a full update package is detected ?

BTW, these two strings sitting next to each other look quite interesting:

Code:

turing126
PASSWORD:

It strongly reminds me The Answer to the Ultimate Question of Life, the Universe, and Everything (42) ;)

twobob 02-13-2013 11:34 AM

Spoiler:
LOL. What do you get if you multiply six by nine?


in base 13
tee hee hee...


And "Yes". probably creating a phantom update would work. I have on occasion stupidly dropped 2 .bins in the root. Needless to say they fail. both of them.

Nice mental machinations!

dsmid 02-14-2013 02:48 AM

Here are some confirmed facts:
  • initramfs updater looks only for lowercase update file names - "update*.bin"
  • OTOH rootfs updater is case insensitive when it comes to update file names (that's why full updates begin with lowercase 'u' while incremental updates begin with uppercase 'U')
  • initramfs updater silently fails if there are two or more "update*.bin" files and leaves the files as they are
  • rootfs updater (the framework part to be more precise) deletes all but one the first one in ASCII order and then happily installs the leftover
  • rootfs updater ignores zero-length "update files", doesn't even delete them
I'll utilize these facts in version 2 of this hack.

knc1 02-14-2013 07:38 AM

Quote:

Originally Posted by dsmid (Post 2423145)
Here are some confirmed facts:
  • initramfs updater looks only for lowercase update file names - "update*.bin"
  • OTOH rootfs updater is case insensitive when it comes to update file names (that's why full updates begin with lowercase 'u' while incremental updates begin with uppercase 'U')
  • initramfs updater silently fails if there are two or more "update*.bin" files and deletes all but the first one in ASCII order
  • rootfs updater (the framework part to be more precise) deletes all but the last one in ASCII order and then happily installs the leftover
I'll utilize these facts in version 2 of this hack.

Super!
Sounds much more complete.
Are you going to give this on/off updater thing KUAL buttons?

Although I haven't written it up anywhere specifically, I did post the complete sequence for adding one new button to the KUAL 'Helpers' menu:

Start here, first post:
https://www.mobileread.com/forums/sho...d.php?t=205610
That is one of the existing buttons.

Then in post #3 :
https://www.mobileread.com/forums/sho...98&postcount=3
The changes needed in words, and an attachment of the files in #1 after the changes.

At that point, I started by adding the "helper2" code to the kBBB repo -
http://hg.minimodding.com/repos/sys/...97cdb3/helper2
Which tracks all the changes from the post #3 attachment to the working DateTime button.

To summarize - just a few small edits to the control files + a new script to perform the function you want to add.

dsmid 02-14-2013 08:19 AM

Quote:

Originally Posted by knc1 (Post 2423375)
Are you going to give this on/off updater thing KUAL buttons?

Yes, why not. I always forget there are newer ways how to install things to Kindle than just creating an update bundle.
Sounds like I'm becoming an old school hacker :o

dsmid 02-14-2013 01:07 PM

Version 2:
Full updates are recognized during the attempt and a countermeasure is deployed (dummy update file update__this-file-prevents-installing-on-reboot.bin is created to confuse the boot-time updater)

You can install the hack as a KUAL extension now.

twobob 02-14-2013 02:08 PM

Quote:

Originally Posted by dsmid (Post 2423715)
Version 2:
Full updates are recognized during the attempt and a countermeasure is deployed (dummy update file update__this-file-prevents-installing-on-reboot.bin is created to confuse the boot-time updater)

You can install the hack as a KUAL extension now.

https://www.mobileread.com/forums/sho...7&postcount=25

Topness! much obliged. Once the Touch and PW tests are in I will ditch the ? after the support numbers :)

Excellentness. That should be word

(-_-) 02-14-2013 03:13 PM

Thanks for making this.

Unfortunately I was unable to install via the 'update_backdoorlock_2_install.bin' on a
K3 3G.

"update your kindle" is grayed out. Restart results in an error. (Update error: 3)


All times are GMT -4. The time now is 05:05 PM.

Powered by: vBulletin
Copyright ©2000 - 3.8.5, Jelsoft Enterprises Ltd.
MobileRead.com is a privately owned, operated and funded community.