View Single Post
Old 03-18-2012, 03:42 AM   #13
eureka
but forgot what it's like
eureka ought to be getting tired of karma fortunes by now.eureka ought to be getting tired of karma fortunes by now.eureka ought to be getting tired of karma fortunes by now.eureka ought to be getting tired of karma fortunes by now.eureka ought to be getting tired of karma fortunes by now.eureka ought to be getting tired of karma fortunes by now.eureka ought to be getting tired of karma fortunes by now.eureka ought to be getting tired of karma fortunes by now.eureka ought to be getting tired of karma fortunes by now.eureka ought to be getting tired of karma fortunes by now.eureka ought to be getting tired of karma fortunes by now.
 
Posts: 710
Karma: 2290994
Join Date: Dec 2011
Location: north (by northwest)
Device: Kindle Touch
EDIT: provided recipe has been included by dsmid into his unified, easy installable BackDoorLock hack.

(using of overlay root filesystem is no fun with silent sudden OTA updating, so I've researched OTA updating subsystem for proper disabling)

Here is how OTA updating works on Kindle Touch (checked on 5.0.4):
  1. todo process pulls service info from Amazon server. URL for getting info is built with the help of supporting libraries, through which some parameters are taken from SQLite database at /var/local/appreg.db. There is software revision in service info URL's query string and in separate HTTP request header. Value for query string is taken from table properties from row with handlerId = 'urlbuilder.gparams' and name = 'software_rev'. Value for header is taken from table properties from row with handlerId = 'urlbuilder.headers' and name = 'X-ADP-SW'.
  2. server checks client KT software version (from HTTP request query string and/or header) and, if needed, adds to service info message about available OTA update
  3. if service info contains message about available OTA update, todo sends it to lipc service, which is defined by appropriate values in service message (values GET, FWUO). todo is looking for these values in it's internal handler registry (which is built and cached in RAM at todo startup from content of /etc/todo/handler_registry.conf). For legacy.GET.FWUO com.lab126.ota service is defined, so todo sends message to com.lab126.ota by setting lipc property handleToDoItem
  4. service com.lab126.ota is provided by otaupd process, so this daemon handles downloading and checking validness of downloaded update bundle
  5. after downloading and checking for validness of downloaded update bundle, otaupd invokes ota-update upstart script with path to bundle as parameter
  6. on successful/failed OTA update install otaupd reports back to todo, which is sending status back to Amazon (no new information is sent to Amazon here except of fact of success/fail)
So:
  • make backup of /etc/todo/handler_registry.conf !
  • look for strings with com.lab126.ota in /etc/todo/handler_registry.conf
  • comment them (with # character)
  • then restart todo process with command restart todo in SSH session.
I think, it will be sufficient for disabling OTA updates. (And it looks like when handler is unknown to todo, it sends FAILED status to Amazon, which isn't different from unsuccessful OTA update install.)

Note that with commented handlers, todo will not send message to com.lab126.ota service, so ota-update upstart script will not be invoked. But manual updates should still work (with unmodified ota-update).

UPD This solution isn't more reliable than editing of ota-update upstart script, because it's the same in general and closes only the current "official channel" for pushing OTA update. I didn't checked whether Amazon could use other existing "channels" (i.e. service messages) for invoking otaupd daemon to initiate OTA updating procedure.

Last edited by eureka; 05-15-2013 at 07:12 AM. Reason: point to BackDoorLock hack
eureka is offline   Reply With Quote