Direct Links to Kobo Firmware - Page 4

thp1017 · 10-19-2012, 08:48 PM

Quote:

Originally Posted by davidfor

Your looking at code that is executed a long time after the problem that is being discussed occurs.

Hmm, pretty sure it is the right place. On startup (or disconnect, etc.), init calls rcS, which is in /etc/init.d. As part of that, there is a check to see if KoboRoot.tgz and upgrade folder exist in .kobo

If so, it untars KoboRoot.tgz, and calls upgrade-wifi.sh. In that script, at the start, it does the MD5 check - which, if it fails, causes the upgrade process to abort immediately. If its fine (or the md5 file doesn't exist), the firmware is applied in generic-upgrade.sh (using dd, etc., that george.talusan mentioned as a way to fix the Glos that were bricked). So it'd be easy to add a few lines in to check the version.

Quote:

Originally Posted by davidfor

Of course, there already is code that checks if the right firmware is being loaded. It is the code in the desktop app or WiFi download or maybe on the download server that makes sure the right firmware file is downloaded. Personally, I am happy with this mechanism. And I am happy that if I want to bypass this and take the risk I can try something else. But, that is my decision.

On the face of it, I totally agree

Kobo shouldn't have to go out of its way to prevent stupid user errors, especially "unauthorized", stuff we've been warned against doing, etc... but this really seems like an easy fix, something that should take a few minutes to add in. And if someone screwed up the logic server side, somewhere, it'd be an extra easy check.

davidfor · 10-20-2012, 02:47 AM

Quote:

Originally Posted by thp1017

Hmm, pretty sure it is the right place. On startup (or disconnect, etc.), init calls rcS, which is in /etc/init.d. As part of that, there is a check to see if KoboRoot.tgz and upgrade folder exist in .kobo

If so, it untars KoboRoot.tgz, and calls upgrade-wifi.sh. In that script, at the start, it does the MD5 check - which, if it fails, causes the upgrade process to abort immediately. If its fine (or the md5 file doesn't exist), the firmware is applied in generic-upgrade.sh (using dd, etc., that george.talusan mentioned as a way to fix the Glos that were bricked). So it'd be easy to add a few lines in to check the version.

OK, I should have reread the code and not relied on memory.

And your probably right. The code is fairly generic and there probably is a way to add some sort of test.

They would still have a problem with older devices. The code we are looking at is not the version of the code that actually loads the new firmware. When firmware is being loaded, it is by whatever version of the code that is already on the device. If they fix this now, then it will be OK for the next upgrade. But, a factory reset takes the device back to an older firmware that didn't have that check. This shouldn't stop them adding the test.

After writing this, I have the feeling I am missing something that makes it harder than it looks from here.

murg · 10-20-2012, 03:38 AM

Quote:

Originally Posted by davidfor

They would still have a problem with older devices. The code we are looking at is not the version of the code that actually loads the new firmware. When firmware is being loaded, it is by whatever version of the code that is already on the device.

I'm not sure about this. The problem with the Australian devices was that the embedded factory installed firmware, that was not normally replaceable by new firmware, had some problem with installing the new versions.

My clear impression is that the firmware update management software doesn't get replaced easily. In fact, if 2.0.4 does what we think it does, they had to issue a two-stage special update to revise the firmware update management software.

I do agree with you that the older devices won't have these protections, even if they are to be added to the new devices.

But, when you get right down to it, there is no excuse not to add what protections you can, when you can. Using 'but some devices won't be protected' to not do anything is just poor management.

Given Kobo's track record with software releases, assuming that the Desktop won't screw up something is a mistake. There may be a small risk of this, but it is a valid risk, and the cost of breaking a significant number of devices can get large. Not to mention the reputational damage.

davidfor · 10-20-2012, 04:11 AM

Quote:

Originally Posted by murg

I'm not sure about this. The problem with the Australian devices was that the embedded factory installed firmware, that was not normally replaceable by new firmware, had some problem with installing the new versions.

My clear impression is that the firmware update management software doesn't get replaced easily. In fact, if 2.0.4 does what we think it does, they had to issue a two-stage special update to revise the firmware update management software.

From what Kobo developers have said, it was the update mechanism that is at fault. So, it was the 1.9.11 version of the code we are talking about. They have also mentioned space issues, so it might be that the 1.9.11 version didn't remove some files and there wasn't enough space to unpack the firmware properly. My guess is that the 2.0.4 does the cleanup or has the cleanup code in the firmware installation, so that the later firmware can be installed properly.

Of course, I might be wrong as this is put together from several comments from the developers plus a little looking at shell scripts in the firmware updates.

SeigneurAo · 10-20-2012, 07:30 AM

Quote:

Originally Posted by murg

there is no excuse not to add what protections you can, when you can.

Apart from the time it takes to do it, even if you guys seem to think it is a matter of a few days at worse (based on what grounds, I really don't know).

davidfor · 10-20-2012, 08:05 AM

Quote:

Originally Posted by SeigneurAo

Apart from the time it takes to do it, even if you guys seem to think it is a matter of a few days at worse (based on what grounds, I really don't know).

You are right, we don't know for sure how long it would take. But, we are looking at the code that does the upgrade once the new firmware has been copied to the device. Based on that and my experience, "days" seems to long. But, as I stated, I feel I am missing something.

SeigneurAo · 10-20-2012, 08:12 AM

Quote:

Originally Posted by davidfor

You are right, we don't know for sure how long it would take. But, we are looking at the code that does the upgrade once the new firmware has been copied to the device. Based on that and my experience, "days" seems to long. But, as I stated, I feel I am missing something.

In terms of coding, it certainly is a small thing, but such a critical feature would need extensive testing, and if I understand correctly you're in beta testers group so you know perfectly well this can take more than first thought.
Also, as it has been stated elsewhere, wouldn't we wish developers to use their time and skills on something else than failproofing software against erratic, and discouraged user behaviour such as sideloaded firmwares ?

davidfor · 10-20-2012, 08:55 AM

Quote:

Originally Posted by SeigneurAo

In terms of coding, it certainly is a small thing, but such a critical feature would need extensive testing, and if I understand correctly you're in beta testers group so you know perfectly well this can take more than first thought.
Also, as it has been stated elsewhere, wouldn't we wish developers to use their time and skills on something else than failproofing software against erratic, and discouraged user behaviour such as sideloaded firmwares ?

Don't worry, I understand that completely. I've spent far much time fixing the problems caused by the "one more thing" that someone insisted on to take any change lightly. From looking at the code, this seems a simple change but you're right, the testing could be a nightmare.

It might not be obvious from what I said, but this has mainly been an intellectual exercise for me. I basically agree with the Kobo developers attitude on it and I don't expect then to do anything now. Plus there are other things I want them to do first. And they know what they are

But, I hope they add this to their list and consider it when they have time. Or when they plan the Glo II and the Micro. Or maybe the SuperGlo and the Glo Mini.

thp1017 · 10-20-2012, 09:32 AM

Quote:

Originally Posted by davidfor

It might not be obvious from what I said, but this has mainly been an intellectual exercise for me. I basically agree with the Kobo developers attitude on it and I don't expect then to do anything now.

Haha, yeah, this is why I started digging around - I kept thinking this should be fairly easy, and wanted to see if I could figure out what it would take to add some minimal protections in. And I'm sure it'd take more than it looks at first glance to add something in - test if the file is there, stuff to account for older devices where the config script isn't there., etc. It *seems* like it shouldn't take more than a few days to implement and test, but who knows

As you say, hopefully this is something they'll add to their list of 'things to do' and come back to at some point in the near future - while I'm sure there are those of us out there that could still brick things if we wanted, it would be nice to have.

murg · 10-20-2012, 09:47 AM

While a feature like this may only take a day for the coding, the effort around that day will consume person-weeks.

The firmware update protection feature itself operates at a time when the device is engaged in a single thread, that of recognising that the firmware update files exist and had made the decision to update the firmware. At this point, the device should be very single task oriented.

The firmware update protection feature itself is fairly simple. Look for a specific file, read the file, use the contents to make the determination of whether or not to proceed with the update. You can even use the filename of the md5 hashes as the check, in that the firmware will look for the md5 file that is named for the device type, and if it cannot be found, goes through the normal hash-not-match functionality.

The tricky bit is deleting the update if it is not the correct one for the device.

Testing is actually fairly simple. Due to the single-taskedness of what is happening on the device at the time the firmware update is happening, the device can pretty much ignore everything else that is happening on the device, just like it does not when the update is being processed.

As that covers the technical side, the consumer electronics side is much simpler. As Kobo has decided to give its customers access the the user-accessable drive, prudent design demands that they make it next to impossile for anything that a user does to that side of the device cause the device harm. On the Touch, this was ultimately handled with the paperclip factory reset. On the Glo, this seems to require a PC and some specialised knowledge.

The device is already checking the md5 hashes to ensure that a good copy of the firmware is available. It is but a short leap to ensure that the correct copy of the firmware is the one being presented.

I am not advocating that Kobo should be able to handle anything that gets thrown at it. If you try to deliberately mess up the device, you get what you deserve. But normal everyday interfacing with PCs and users should be covered.

davidfor · 10-20-2012, 09:48 AM

Quote:

Originally Posted by thp1017

As you say, hopefully this is something they'll add to their list of 'things to do' and come back to at some point in the near future - while I'm sure there are those of us out there that could still brick things if we wanted, it would be nice to have.

That sounds like a challenge that I am sure someone will accept

frankieGom · 10-20-2012, 05:24 PM

Quote:

Originally Posted by murg

On the Touch, this was ultimately handled with the paperclip factory reset. On the Glo, this seems to require a PC and some specialised knowledge.

The issue at hand is not about a missing paper clip reset on the Glo (see http://kobo.intelliresponse.com/inde...3812&question=), but rather that installing the Touch FW will brick the Glo, rendering the reset, any reset, non functional. And I'm sure that, likewise, installing the Glo FW on a Touch woulb brick it all the same.

I'm with davidfor (and Kobo) on this one and prefer Kobe use their scarce resources to some other uses than making sure the hackers populating these forums (of which I am one example) cannot brick their devices.

I'm good enough knowing that there is an inherent risk in sideloading FW on Kobo devices, or any other devices for that matter. As a matter of fact I have already had cold sweats "upgrading" Nokia mobiles, Blackberries, Android smartphones or WiFi routers (openWrt or dd-wrt anyone?) outside the recommended, supported path!

And blaming the manufacturer that leaves the door wide open to hacking, as Kobo does, would never cross my mind as the harder it is to hack the device the more risky it gets...

murg · 10-20-2012, 06:55 PM

Quote:

Originally Posted by frankieGom

I'm with davidfor (and Kobo) on this one and prefer Kobe use their scarce resources to some other uses than making sure the hackers populating these forums (of which I am one example) cannot brick their devices.

Maybe I haven't been clear.

I don't care about hackers breaking their devices. By definition, this activity is the deliberate manipulation of the firmware. If you break that seal that says 'breaking seal will void warranty', then you are on your own.

The theoretical scenario in this case is that someone, who wanted to simply read an ebook that was on their SD card without having the device reboot every time it came out of sleep, did an activity that is well know to have worked in the past (as recently as 2 weeks ago) and discovered that Kobo had pulled the rug out from under them.

Kobo is producing consumer electronics devices. And have allowed users access to a drive on that device. That drive contains files that the device needs to operate. As such, the device should be able to properly handle any activity that happens on that drive.

Face it, normal none technical people are moving things on and off their Kobo's. What happens if they accidentally delete all of the files? What happens if their computer has a problem and corrupts the drive?

Putting a check in to ensure that the update firmware is for the correct device is a basic check. Especially if there is any possibility that the wrong firmware can be loaded, and this possibility clearly exists (do you really completely trust Kobo not to make mistakes in the Desktop app?).

Over the past year, Kobo users have been trained that they can manually load firmware updates. We were warned that after 2.1.4 future firmware may be targetted to specific devices and may be 'incompatible' with the non-targetted devices in the future. There is a fairly large difference between 'incompatible' and 'will render useless'. 2.1.5 came out without any announcement, and specifically without an announcement that the firmware was targetted to specific devices and that it would break the Glo.

Consider two facts, the first of which is that 'incompatible' is not a very strong word or warning. In fact, I found that the 2.0.0a official release was incompatible with my Australian Touch. The second fact is that 2.1.5 is an emergency bug fix release and the clear assumption was that it was just 2.1.4 with the major bug fixed, not that it was the first of these future releases. In fact, while one can make the argument that while it was technically a future release and covered by the warning, in my mind I was expecting the next feature release (now 2.1.6? 2.2.0?) to be the one that we had to be careful of.

In fact, 2.1.5 was not really a 'release' in that Kobo did not update the release notes, and the 2.1.4 release notes are displayed on the device when you update to the 2.1.5 firmware. Nor was 2.1.5 announced here on MR, which seems to be the place for Kobo to announce new releases.

The final point is that the paperclip reset seems to have moved from a factory reset to a basic reset in the Glo. It should have remained the factory reset, so that no matter what happens to the device, you can always get it back to a working state without having to delve into Linux command lines. It wasn't so very long ago that Kobo's own official release (2.0.0a, the last release in fact) caused many people to have to resort to the paperclip factory reset because the firmware failed to properly update and bricked the devices.

azbdsf · 10-20-2012, 08:36 PM

2.1.4 is shared for Touch and Glo ?

I want to go back to 2.1.4 with my Glo... too much trouble with 2.1.5.
Is it safe to use 2.1.4 downloaded from here ?
Must I make a reset factory to go back to 2.1.2 before install 2.1.4 ?
Or back from 2.1.5 to 2.1.4 can be done dirrectly ?

PS: Sorry for bad english level...

murg · 10-20-2012, 08:40 PM

Quote:

Originally Posted by azbdsf

2.1.4 is shared for Touch and Glo ?

I want to go back to 2.1.4 with my Glo... too much trouble with 2.1.5.
Is it safe to use 2.1.4 downloaded from here ?
Must I make a reset factory to go back to 2.1.2 before install 2.1.4 ?
Or back from 2.1.5 to 2.1.4 can be done dirrectly ?

PS: Sorry for bad english level...

I think it is shared, but actually, I don't know for sure.

With the thread to announce 2.1.4, MDK said that future releases may be targetted to different devices, but didn't say that about 2.1.4.

The problem with the Glos breaking only seemed to have happened since 2.1.5 came out.

I seem to remember people manually loading 2.1.4 on their Glo's without issues.

In any case, it is probably always safer, when going back to a previous version of the firmware, to do a factory reset.

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
SD card firmware (1.4) image links for AU/NZ	sabredog	Kobo Reader	42	03-27-2015 03:11 AM
Kobo Writing Life now open (New direct self-pub program)	MMHaven	Writers' Corner	12	08-08-2012 10:25 AM
Firmware Links	Montebello	Andere Lesegeräte	0	12-20-2009 03:58 PM
Updating firmware without direct Internet connection	KillerRabbit	iRex	1	01-08-2007 11:08 AM

10-20-2012, 09:47 AM	#55
murg No Comment Posts: 3,238 Karma: 23878043 Join Date: Jan 2012 Location: Australia Device: Kobo: Not just an eReader, it's an adventure!	While a feature like this may only take a day for the coding, the effort around that day will consume person-weeks. The firmware update protection feature itself operates at a time when the device is engaged in a single thread, that of recognising that the firmware update files exist and had made the decision to update the firmware. At this point, the device should be very single task oriented. The firmware update protection feature itself is fairly simple. Look for a specific file, read the file, use the contents to make the determination of whether or not to proceed with the update. You can even use the filename of the md5 hashes as the check, in that the firmware will look for the md5 file that is named for the device type, and if it cannot be found, goes through the normal hash-not-match functionality. The tricky bit is deleting the update if it is not the correct one for the device. Testing is actually fairly simple. Due to the single-taskedness of what is happening on the device at the time the firmware update is happening, the device can pretty much ignore everything else that is happening on the device, just like it does not when the update is being processed. As that covers the technical side, the consumer electronics side is much simpler. As Kobo has decided to give its customers access the the user-accessable drive, prudent design demands that they make it next to impossile for anything that a user does to that side of the device cause the device harm. On the Touch, this was ultimately handled with the paperclip factory reset. On the Glo, this seems to require a PC and some specialised knowledge. The device is already checking the md5 hashes to ensure that a good copy of the firmware is available. It is but a short leap to ensure that the correct copy of the firmware is the one being presented. I am not advocating that Kobo should be able to handle anything that gets thrown at it. If you try to deliberately mess up the device, you get what you deserve. But normal everyday interfacing with PCs and users should be covered.

10-20-2012, 08:36 PM	#59
azbdsf Aka Redfish Posts: 56 Karma: 12506 Join Date: Dec 2011 Device: Kobo touch	2.1.4 is shared for Touch and Glo ? I want to go back to 2.1.4 with my Glo... too much trouble with 2.1.5. Is it safe to use 2.1.4 downloaded from here ? Must I make a reset factory to go back to 2.1.2 before install 2.1.4 ? Or back from 2.1.5 to 2.1.4 can be done dirrectly ? PS: Sorry for bad english level...

Advert

Advert