Possible new downgrade method

[katadelos]

I was poking around recovery-util a while back and might have discovered a novel method of downgrading the firmware version used by a (jailbroken) device. recovery-util mounts the rootfs early in the boot process and when a update is found and processed by this program, the build number seems to be checked against the build number in the file /etc/version.txt.

This file looks something like this:

System Software Version: 060-juno_1402_malbec_bellatrix-380729
Tue Feb  1 08:37:30 UTC 2022
com.lab126.eink.malbec.os

As previously established by NiLuJe and others, the important parts here are the first and last parts of the first line - 380729 is the major component of the version number and 060 is the minor component. In this case, the build number corresponds to that of 5.14.2 on PW5 (3807290060).

It appears to be possible to trick the updater in recovery-util into applying an unmodified update binary by changing the build number used in the file above to the build number of the update before the update you wish to install (the build numbers can be found as part of the filename of the source tarballs found here).

Note that I've only tested this a couple of times and on devices where you can actually access the serial port; you may or may not run the risk of bricking your device if you attempt to downgrade using this method.

[aguy]

Mmmhhh, this thread is interesting...

[joh77]

Nice find katadelos!

But this might be useful only for jailbroken devices?

[riothamus]

Originally Posted by katadelos

Note that I've only tested this a couple of times and on devices where you can actually access the serial port; you may or may not run the risk of bricking your device if you attempt to downgrade using this method.

Does this mean you need the serial port to perform this downgrade or that you might need the serial port if you accidently brick the device?

[j.p.s]

Originally Posted by joh77

But this might be useful only for jailbroken devices?

/etc/version.txt can only be accessed after jailbreak.

Originally Posted by riothamus

Does this mean you need the serial port to perform this downgrade or that you might need the serial port if you accidently brick the device?

Serial port allows you to recover from bricking.

[darkassassinua]

Paperwhite 5 SE with 5.14.3 - changed value to 3807290060 - got "UPDATE ERROR: 12"
also "380729","3783100001" doesnt work too.
but "378310" is worked.
downgraded from 5.14.3 to 5.14.2

1)Mount filesystem as writable "mntroot rw"
2)Open /etc/version.txt - replace 383089(if you on 5.14.3) to 378310
3)copy update file from 5.14.2 to mnt/us
4)Reboot

After reboot ur Kindle "updated" to 5.14 2

[joh77]

Originally Posted by j.p.s

/etc/version.txt can only be accessed after jailbreak.

So there is no chance for me

[dedeca]

sorry i'm noob.
How do I do step 1: 1)Mount filesystem as writable "mntroot rw" ?


I used the KOreader text editor but I can't modify the version.txt file

[dedeca]

1)Mount filesystem as writable "mntroot rw"

sorry, but how do i do that?

[j.p.s]

Originally Posted by dedeca

1)Mount filesystem as writable "mntroot rw"

sorry, but how do i do that?

How much linux or other unix experience do you have?

Do you know how to use the editor vi or nano?

The instructions are there every time you ssh to the kindle:

ssh root@pw3
#################################################
#  N O T I C E  *  N O T I C E  *  N O T I C E  # 
#################################################
Rootfs is mounted read-only. Invoke mntroot rw to
switch back to a writable rootfs.
#################################################
[root@kindle root]#

If that is not enough, you might not be ready yet to try this.

And, of course, it needs to be set back to ro when you are finished.

[fonix232]

Okay, I'm excited about this, but for a completely different reason...

I believe by modifying the build values here, one could essentially block firmware updates completely (at least until Amazon catches up with the version number supplied), essentially making sure that your jailbreak doesn't get wiped out because Amazon forced an update even though you turned off auto updates.

[dedeca]

Originally Posted by j.p.s

If that is not enough, you might not be ready yet to try this.

I did a forum search on SSH on Kindle and found that I know absolutely nothing about it. If I tried, I would probably lock my device. Anyway, I'll keep researching, who knows, one day...

[NiLuJe]

Wiping (at least) some of the more database-y stuff from /var/local might be a good idea before attempting a significant (or maybe even a not so significant one) downgrade, because nothing in the process is intended to support database downgrades .

IIRC, back in the olden days, at worst it just broke stuff at runtime, but there is a non-zero chance it could break the boot, which would be bad .

[j.p.s]

Originally Posted by dedeca

I did a forum search on SSH on Kindle and found that I know absolutely nothing about it. If I tried, I would probably lock my device. Anyway, I'll keep researching, who knows, one day...

Presumably, someday, there will be step by step easy instructions, maybe even a KUAL extension. The latter might be tricky, because not all model, build number, and firmware version combinations would be compatible. But eventually, this should be among the simplest and easiest significant hacks.

[j.p.s]

Originally Posted by fonix232

Okay, I'm excited about this, but for a completely different reason...

I believe by modifying the build values here, one could essentially block firmware updates completely (at least until Amazon catches up with the version number supplied), essentially making sure that your jailbreak doesn't get wiped out because Amazon forced an update even though you turned off auto updates.

Good idea. I hope someone looks into this. It might be a bit more complicated than just putting in a large number.

Originally Posted by NiLuJe

Wiping (at least) some of the more database-y stuff from /var/local might be a good idea before attempting a significant (or maybe even a not so significant one) downgrade, because nothing in the process is intended to support database downgrades .

IIRC, back in the olden days, at worst it just broke stuff at runtime, but there is a non-zero chance it could break the boot, which would be bad .

Good point. It would be good to know which dbs can be simply deleted