On a somewhat related note, one convoluted way to update to 5.3.0 for devs would be to boot to diags, flash the rootfs & kernel from the unpacked update, and manually reapply the jailbreak/usbnet on main. The entry point is plugged, but AFAICT, if we manage to put the stuff back in, most of the simple things should still work. If you mess up, you potentially only get one shot, though, ;D.

5.3.0 still runs /var/local/system/fixup and/or /var/local/system/onetimefixup (if they were found). And /var/local isn't overwrited by update.

... but that still leaves the question of how to write a file to /var/local... (Essentially, that's what the data.(tar.gz|stgz) files did, but that hole is closed now.

Seems like Amazon has now officially declared war on us.

As foreseeable as that was, it's still a pity that companies keep employing the same idiotic and short-sighted strategy of trying to lock their customers in, instead of providing an open (or at least "openable") environment which allows for open development.

I'll keep my PW shutdown and in Airplane mode until we find some way to crack open the 5.3.0 firmware. (I'll still manually download it and look through it).

... but that still leaves the question of how to write a file to /var/local... (Essentially, that's what the data.(tar.gz|stgz) files did, but that hole is closed now.

The support for the requirement that those files be signed was in the original Kpw firmware. I just didn't think to mention it.

In answer to that question:
It would (will?) require a 5.2.0.a hack to put our code into that location in a way which makes it still usable after the update to 5.3.
Prior to doing the update to 5.3.0.
It would also be necessary to confirm that user additions to that part of the directory tree don't get scrubbed by the handling of the md5sum file manifest.

The support for the requirement that those files be signed was in the original Kpw firmware. I just didn't think to mention it.

In answer to that question:
It would (will?) require a 5.2.0.a hack to put our code into that location in a way which makes it still usable after the update to 5.3.
Prior to doing the update to 5.3.0.

Yes, but this will only help for people who actually still run 5.2.0, and are aware of the situation. It won't help folks who got their PW shipped with 5.3.0, or who already went through the auto-update without being aware that it's also an auto-lockdown. We need to find a proper solution for "vanilla" 5.3.0. I guess that it's time to get our hands dirty and try to find another exploit.

Quote:

It would also be necessary to confirm that user additions to that part of the directory tree don't get scrubbed by the handling of the md5sum file manifest.

That's highly improbable. First, /var/local/ is a different partition, and second, it only contains user data. Wouldn't make sense to expect any particular state there.

That's highly improbable. First, /var/local/ is a different partition, and second, it only contains user data. Wouldn't make sense to expect any particular state there.

Highly improbably or not, it should still be checked.
I do not believe that if: "it makes sense" or not is in the Amazon design qualifications.

And since the system firmware does check for specific things in that part of the tree the system does expect certain specific states there.
Perhaps not exclusively, but still that is one or more particular states.