BackDoorLock hack - prevents silent updates

[xtine]

Ok, I installed the Back Door Lock through KUAL, then uninstalled and reinstalled the Screensaver hack (with back door locked). I did find an update.log file under extensions/backdoorlock. Here's what it says (I locked it through KUAL every time I installed/uninstalled):


================================== 2013-03-02 17:43:03 ===============================
[KUAL] Lock state:
[ 2013-03-02 17:43:03 ]

BACK DOOR LOCKED

Update file(s):
- none -

Downloading now:
- none -
=================================== 2013-03-02 17:43:52 ===============================
[KUAL] Locked by user
=================================== 2013-03-02 17:46:41 ===============================
[KUAL] Locked by user
=================================== 2013-03-02 17:50:14 ===============================
[KUAL] Locked by user

[dsmid]

Thanks for the report, now it's clear Back Door Lock has zero effect on KPW

[xtine]

That's too bad

[twobob]

Originally Posted by dsmid

Thanks for the report, now it's clear Back Door Lock has zero effect on KPW

Oooookay...

So. I should go update the listing?

Can you provide me with an easy way to test the other devices?

[dsmid]

I have an idea how to stop pushed updates even on KPW and KT but I can't implement it because I don't have any KPW or KT device.

In case someone wants to give it a try:

1. First you need otaupd to release DBus service name com.lab126.ota. That's easy: search for com.lab126.ota in the binary and replace it by e.g. com.lab126.pta (rhymes with PITA).
2. Then code a replacement DBus service that registers name com.lab126.ota for itself. Most of the time it would just pass all calls to com.lab126.pta via DBus but when a suspicious request is detected (one that looks like pushed update), it would just log it instead.
   You can use any DBus stack for that, I prefer QtDBus as it worked OK on Kindle 3 last time I tried.

[dsmid]

Originally Posted by twobob

Oooookay...

So. I should go update the listing?

Yes, please.

Originally Posted by twobob

Can you provide me with an easy way to test the other devices?

Just install anything with Back Door Lock active. You should find a message "Immediate update (i.e. initiated by user), proceeding..." with some details in update.log after that.

[twobob]

UPDATED LISTING.

EDIT: On the KT...

Ghex... full binary. pictured over two pictures... I think I see the issue.. it's not in there..

[twobob]

The DX has no /usr/bin/otaupd I can find.

Hmm found something..

/usr/sbin/otaup ... it's a script. Doh.

[eureka]

Originally Posted by dsmid

I have an idea how to stop pushed updates even on KPW and KT but I can't implement it because I don't have any KPW or KT device.

In case someone wants to give it a try:

1. First you need otaupd to release DBus service name com.lab126.ota. That's easy: search for com.lab126.ota in the binary and replace it by e.g. com.lab126.pta (rhymes with PITA).
2. Then code a replacement DBus service that registers name com.lab126.ota for itself. Most of the time it would just pass all calls to com.lab126.pta via DBus but when a suspicious request is detected (one that looks like pushed update), it would just log it instead.
   You can use any DBus stack for that, I prefer QtDBus as it worked OK on Kindle 3 last time I tried.

Why to complicate? Simple sed for single text file will work just fine. There is no need to get original com.lab126.ota out of the way.

[dsmid]

Originally Posted by twobob

UPDATED LISTING.

EDIT: On the KT...

Ghex... full binary. pictured over two pictures... I think I see the issue.. it's not in there..

It's in /usr/lib/libotaup.so.

[dsmid]

Originally Posted by twobob

The DX has no /usr/bin/otaupd I can find.

Hmm found something..

/usr/sbin/otaup ... it's a script. Doh.

/usr/bin/otaupd is on 5.x firmwares only.
DX is more like K3, I bet the framework calls process_update there as well.

[dsmid]

Originally Posted by eureka

Why to complicate? Simple sed for single text file will work just fine. There is no need to get original com.lab126.ota out of the way.

Thanks for reminding me, this seems to much easier. I will use your solution in the next release of this hack.

[knc1]

Originally Posted by liyajiang

My day version of the Kindle paperwhite, hand feel is ineffective, the screen with found input chaos, pressing a key other key follow random input, from yesterday, the screen long time no reaction, today morning session suddenly have a reaction, I try to stay in the system restore, need to make sure the language position, because can't input information and can't go ahead, you see is the mainboard failure or screen failure

Answered in detail, it the other thread which has this post.
https://www.mobileread.com/forums/sho...81&postcount=3

[dsmid]

Version 7

• Should work on KT and KPW now (thanks to eureka for the hint)

A reboot is required on Kindle Touch and Kindle Paperwhite after locking/unlocking the back door with KUAL and the silent update detection does not work on these devices, the hack uses a different method to stop silent updates.

[eureka]

Originally Posted by dsmid

A reboot is required on Kindle Touch and Kindle Paperwhite after locking/unlocking the back door with KUAL

Ugh, no. You can just add restart todo command after mntroot ro in lock.sh/unlock.sh scripts. It will be enough for KT/PW to notice the change.