Preventing Wi-Fi firmware updating

[Nick_1964]

Originally Posted by tshering

There must have happened something more than that. According to your earlier description, calibre refused to interact with the device on account of the firmware version. This shows that at that point, calibre had access to the database, and that therefore we can know that windows was able to find a driver (the generic mass storage driver). The usb problem appeared only later.
I did a short test. I modified the data on the device in a way that it identifies itself as eReader-99.10. As expected, windows does connect to the ereader.

But, did calibre recognises it to??... I only know that in between the reader does rebooted twice... I can try to repeat it, but I don't know the steps exactly anymore.. what I do noticed 5 seconds ago, my weather and Boat/plane radar system ( works on sended transponders on boats or planes ) doesn't work also.
All connected to a D-Link 7 ports USB hub.
So I put the input of the hub to another usb port on the computer.. all that stupid things are asking for drivers already installed but when you put them on another port,you have to re-install it again.. Then put it back again to the old one and there are my weather station and flight data again.
On my desk are 2 USB cables.. one connected to the D-Link, but second one is connected to the rear of the computer directly.
I know I did powered of and on the reader when used option one,because calibre say it could not read it's database.. some guy on the internet has written,when this happens restart your reader again without power supply cable attached... maybe I have switched then the cables and connected my reader on the D-Link that already was in error but I didn't was aware of until now.... that could do a lot of explaining... still not why it tries to download the firmware while it already was patched with version two..but it can explain the USB hussle.
I really don't know it anymore... option 2 works, calibre can read the database,what happened in between.. we would never know, I don't think I can reproduce it anymore... patch number two still stays the most good one..because with one it was at that moment attached to a working USB port like you say my dear Sherlock, but can't be read by calibre.

[tshering]

Originally Posted by Nick_1964

But, did calibre recognises it to??...

I am not a calibre user and did not try. But I expect calibre to recognise it. Sorry for the late reply.

[Nick_1964]

With all crosses red, tried patch 1 again, this time no strange things but calibre says it doesn't understand the database on my reader, not even when I changed the driver into future versions, so back to number two again and calibre recognised it, I didn't tried to sync on number one,because of number one somehow failed I am on the wrong firmware,did sync on the second patch again, this time sync went okay, no update received.

[doctorbook]

This patch works very well on firmware 3.1.1.

# Firmware 3.1.1 (761b066420)

<Patch>
patch_name = `prevent firmware update`
patch_enable = `yes`
# alternative 1
#change `5.0.0` , `99.10` , `999.9` or similar
#replace_string = 01105C10, `3.1.1`, `99.10`
# alternative 2
replace_string = 01106BB0, `https://api.kobobooks.com/1.0/UpgradeCheck/%1/%2/%3/%4/%5`, `https://api.kobobooks.com/1.0/UpgradeCheck/%1/%2/%3/9.9/N`
# alternative 3
#replace_string = 01106BB0, `https://api.kobobooks.com/1.0/UpgradeCheck/%1/%2/%3/%4/%5`, `https://api.kobobooks.com/1.0/UpgradeCheck/%1/%2/k/99.9/N`
</Patch>

Its creator has done an excellent job. Congratulations!
My question is: is it possible to create a version that works on firmware 3.2.0 or 3.3.0?
Thanks

I apologize for my bad English (google translator)

[tshering]

Originally Posted by doctorbook

My question is: is it possible to create a version that works on firmware 3.2.0 or 3.3.0?

You just need to replace 01106BB0 of the 3.1.1 version by the position of the string https://api.kobobooks.com/1.0/UpgradeCheck/%1/%2/%3/%4/%5 in libnickel.so.1.0.0. (The first byte of the file has the position 0). You cannot do any harm, since the patch executable will refuse to do the job if you set a wrong position value.

[DNSB]

Originally Posted by doctorbook

This patch works very well on firmware 3.1.1.

Its creator has done an excellent job. Congratulations!
My question is: is it possible to create a version that works on firmware 3.2.0 or 3.3.0?
Thanks

I apologize for my bad English (google translator)

For 3.3.0, you can try:

<Patch>
patch_name = `prevent firmware update`
patch_enable = `yes`
# alternative 1
#change `5.0.0` , `99.10` , `999.9` or similar
#replace_string = C3E87C, `3.1.1`, `5.9.9`
# alternative 2
replace_string = C48280, `https://api.kobobooks.com/1.0/UpgradeCheck/%1/%2/%3/%4/%5`, `https://api.kobobooks.com/1.0/UpgradeCheck/%1/%2/%3/9.9/N`
# alternative 3
#replace_string = C48280, `https://api.kobobooks.com/1.0/UpgradeCheck/%1/%2/%3/%4/%5`, `https://api.kobobooks.com/1.0/UpgradeCheck/%1/%2/k/99.9/N`
</Patch>

For 3.3.1 you can try:

<Patch>
patch_name = `prevent firmware update`
patch_enable = `yes`
# alternative 1
#change `5.0.0` , `99.10` , `999.9` or similar
#replace_string = C41874, `3.1.1`, `5.9.9`
# alternative 2
replace_string = C4B2A0, `https://api.kobobooks.com/1.0/UpgradeCheck/%1/%2/%3/%4/%5`, `https://api.kobobooks.com/1.0/UpgradeCheck/%1/%2/%3/9.9/N`
# alternative 3
#replace_string = C4B2A0, `https://api.kobobooks.com/1.0/UpgradeCheck/%1/%2/%3/%4/%5`, `https://api.kobobooks.com/1.0/UpgradeCheck/%1/%2/k/99.9/N`
</Patch>

Regards,
David

[doctorbook]

Thank you. You guys are great! I try now to apply the patch for 3.3.0.

Originally Posted by tshering

You just need to replace 01106BB0 of the 3.1.1 version by the position of the string https://api.kobobooks.com/1.0/UpgradeCheck/%1/%2/%3/%4/%5 in libnickel.so.1.0.0. (The first byte of the file has the position 0). You cannot do any harm, since the patch executable will refuse to do the job if you set a wrong position value.

I did not understand. Could you explain in a simpler way?
OK I need to replace string 01106BB0 of the 3.1.1 version but...
How do I find the number of the string to the file libnickel?

[doctorbook]

I tried the patch for version 3.3.0 but it seems that does not work.
kpg.exe does not create the file koboroot.tgz

<Patch>
patch_name = `prevent firmware update`
patch_enable = `yes`
# alternative 1
#change `5.0.0` , `99.10` , `999.9` or similar
#replace_string = C3E87C, `3.1.1`, `5.9.9`
# alternative 2
replace_string = C48280, `https://api.kobobooks.com/1.0/UpgradeCheck/%1/%2/%3/%4/%5`, `https://api.kobobooks.com/1.0/UpgradeCheck/%1/%2/%3/9.9/N`
# alternative 3
#replace_string = C48280, `https://api.kobobooks.com/1.0/UpgradeCheck/%1/%2/%3/%4/%5`, `https://api.kobobooks.com/1.0/UpgradeCheck/%1/%2/k/99.9/N`
</Patch>

[tshering]

Originally Posted by doctorbook

I tried the patch for version 3.3.0 but it seems that does not work.

At the moment, I cannot find https://api.kobobooks.com in FW 3.3.0 and 3.3.1, but since DNSB evidently sees them, this might just be me.

Edit: DNSB has of course the correct address. The encoding however has changed. Each char is now two bytes. For our purpose, every second byte has to have a value of 0; e.g. h\x00t\x00t\x00p\x00s\x00:\x00/\x00/\x00a\x00p\x00i\x00 instead of https://api. I am in a hurry and cannot write the code myself now. Edit 2: Looking at it again, I think it would be more appropriate to interpret the pattern as \x00h instead of h\x00 and so on, and decrease the offset by one.

Another thought: Couldn't we try to prevent the updating by redirecting the url in the host file, rather than patching the library?

[Nick_1964]

Originally Posted by tshering

At the moment, I cannot find https://api.kobobooks.com in FW 3.3.0 and 3.3.1, but since DNSB evidently sees them, this might just be me.

Edit: DNSB has of course the correct address. The encoding however has changed. Each char is now two bytes. For our purpose, every second byte has to have a value of 0; e.g. h\x00t\x00t\x00p\x00s\x00:\x00/\x00/\x00a\x00p\x00i\x00 instead of https://api. I am in a hurry and cannot write the code myself now.

Another thought: Couldn't we try to prevent the updating by redirecting the url in the host file, rather than patching the library?

After patching the 5 of the keyboard is replaced by an N, i can't type in my password with wifi, the 5 is in it but its gone...

[GeoffR]

Originally Posted by tshering

Edit: DNSB has of course the correct address. The encoding however has changed. Each char is now two bytes. For our purpose, every second byte has to have a value of 0; e.g. h\x00t\x00t\x00p\x00s\x00:\x00/\x00/\x00a\x00p\x00i\x00 instead of https://api. I am in a hurry and cannot write the code myself now.

These are C++ QString objects, they have length, character width, and some other fields preceding the string of 16-bit characters. if you modify them you need to either keep the length of the string unchanged, or else update the length field. and add a 16-bit null terminator \x00\x00.

[PeterT]

Originally Posted by Nick_1964

After patching the 5 of the keyboard is replaced by an N, i can't type in my password with wifi, the 5 is in it but its gone...

LOL... I'm sure I had mentioned that back in a post when I was trying the WiFi patch at one point....


Sure did See https://www.mobileread.com/forums/sho...1&postcount=72

Dumb suggestion though. Change the replace string from ending in 9/N to 9/5

[DNSB]

Originally Posted by doctorbook

I tried the patch for version 3.3.0 but it seems that does not work.
kpg.exe does not create the file koboroot.tgz

My apologies for not testing the patch properly. The address is correct but the string now has a different format and the replace_string function does not work with it. I suspect a unicode replace would work however the string starts with some extra information and terminates with a \x00\x00 pair. This would make keeping the string length the same rather important.

A quick look at the 3.3.1 libnickel file suggests the 39 at C4B294 is the string length (0x39 or 57 decimal), the 10 at C4B29C is the character width (0x10 or 16) and the 114 bytes from C4B2A0 to C4B311 are the 57 characters in the string while the 2 \x00 characters at C4B312 are the terminating null character.

The easiest way to make the change might be just to do a replace byte on the %4 string.

Something like:
3.3.1
replace_bytes = C4B308, 25 00 34 00, 39 00 39 00

3.3.0
replace_bytes = C482E8, 25 00 34 00, 39 00 39 00

Which keeps the length of the string the same but changes %4 to 99 which should make the wireless update dysfunctional. And we can hope no other chunk of code references that substring.


Regards,
David

[GeoffR]

Originally Posted by PeterT

LOL... I'm sure I had mentioned that back in a post when I was trying the WiFi patch at one point....


Sure did See https://www.mobileread.com/forums/sho...1&postcount=72

Dumb suggestion though. Change the replace string from ending in 9/N to 9/5

This is probably due to a compiler optimisation: If there are two objects with common members such as strings "abc" and "bc", and both are known to be constants, then the compiler can save some space by overlapping them in memory.

[PeterT]

Originally Posted by GeoffR

This is probably due to a compiler optimisation: If there are two objects with common members such as strings "abc" and "bc", and both are known to be constants, then the compiler can save some space by overlapping them in memory.

Exactly. Scares me as to what OTHER optimizations we might be mucking with!