Bypassing registration in 3.19+

[ero-sennin]

Hi,

Is there a way to use 3.19.* firmwares without a Kobo account? The old method with manually inserting some arbitrary user data into KoboReader.sqlite does not work anymore. A "Critical Error" dialog appears on Nickel startup saying "Your eReader hasn't synchronized with the server yet. Any highlights, notes, or reading progress you've made on the device will be lost." After pressing the "Sign out" button the whole .kobo directory is deleted.

Seems like Nickel is doing some stricter checks on the registration data now. I tried to insert the real eth0 MAC address of my Kobo into the ___DeviceID column, also used proper UUIDs for UserID and UserKey, but it didn't work. Does anybody know how to generate user data to make 3.19+ firmwares happy?

[davidfor]

There is some discussion on this in one of the 3.19.x firmware discussion threads. From memory, there is a solution. Personally, I've never seen the point. Kobo do not validate the email address you use, so you don't need to use a real address to sign up.

[ero-sennin]

Thanks, found the discussion in the 3.19.5613 thread. Still no solution though.

Originally Posted by davidfor

Personally, I've never seen the point. Kobo do not validate the email address you use, so you don't need to use a real address to sign up.

Well, I'm just uncomfortable with having to ask Kobo's permission to use my own legally purchased device. What if Kobo goes bankrupt and shuts down their servers, or they just decide not to support my device anymore, or something like that.

[PeterT]

Just register. If you have to use a throwaway email address do so. I honestly don't see what the big deal is.

[davidfor]

Originally Posted by ero-sennin

Thanks, found the discussion in the 3.19.5613 thread. Still no solution though.

That's the first post and there is a lot more discussion in that thread about this, plus in other threads. In that thread there is at least one report of it work, but with no details. But, I have a vague memory that the workaround was to press the x in the top right corner of the dailog rather than pressing OK or whatever button is displayed. That closes the dialog without triggering the reset.

Well, I'm just uncomfortable with having to ask Kobo's permission to use my own legally purchased device. What if Kobo goes bankrupt and shuts down their servers, or they just decide not to support my device anymore, or something like that.

If that happens, you won't be worried about upgrading the firmware because there won't be any upgrades available.

But, as you really mean you won't be able to do a factory reset and upgrade to your stored copy of the firmware, that's easy to solve. Register with a fake email address and take a copy of the details. Then use these values when setting up the device.

[frostschutz]

The 3.19.x dislikes specific values in the fake user entry; I used to set all fields to empty string and that gives you the scary popup. It's still possible to fake registrations with proper values, there are some posts about it which I'm too lazy to find right now. Only problem with that method is that the reader crashes if you go into Settings -> Accounts while WLAN is active.

My reader is currently registered properly, it's safer that way - you never know what they decide to change in their next update.

In the future, if Kobo makes the registration checkings even stricter, the only viable method for faking it might be a patch of some kind.

[StillReading]

I had my Kobos fake-registered with previous firmware versions, all I can say is that the fake registration (empty values) still worked after updating to 3.19 (didn't test the latest version yet). I'm writing this because I was afraid I'd lose my fake registration when updating to 3.19 (there was a discussion about that here at the time the firmware was released).

To all those "I don't see the problem" people: I'm pretty sure the reader tranfers its (unique) serial number during registration. Combine that with the IP adress used for the registration (and stuff like Geolocation etc.), Kobo already gets pretty interesting information for every registration process. Assuming the serial number is also transferred when looking up new firmware versions and doing other "online stuff" on the reader (which is most probably true), along with the IP adress, and combining this data with the data which has been logged from the Kobo website, Kobo will be able to profile your reader usage in a pretty detailed way. I don't want to give Kobo access to that kind of data if I can prevent it. If you see this otherwise and have no problems with Kobo tracking you, good for you.

[HarryT]

Originally Posted by ero-sennin

Well, I'm just uncomfortable with having to ask Kobo's permission to use my own legally purchased device. What if Kobo goes bankrupt and shuts down their servers, or they just decide not to support my device anymore, or something like that.

What if they do? How will that leave you in any worse position than if you hadn't registered in the first place?

[frostschutz]

Originally Posted by StillReading

I'm pretty sure the reader tranfers its (unique) serial number during registration.

This is also transferred in the fake registration case. If you wish to prevent that you must never enable WiFi.

[JSWolf]

Amazon requires you to sign in in order to be able to create collections.

I don't see how registering a Kobo Reader with Kobo is an issue. It's a lot easier than the fake registration. Besides, what's wrong with giving Kobo this information? If you don't like registering, don't buy a Kobo or a Kindle. Buy a different brand where you never have to register.

[StillReading]

Originally Posted by frostschutz

This is also transferred in the fake registration case. If you wish to prevent that you must never enable WiFi.

Not true for the registration itself, because it's simply being skipped when entering fake values. Keeping WIFI disabled would be a way to never have the Kobo "phone home", yes. It's entirely possible and feasible to use a Kobo reader without ever having it go online.

JSWolf: well, Amazon is Amazon, and Kobo is Kobo. Just because Amazon is forcing users into their ecosystem doesn't mean that's a good thing. If you can't see the problem in manufacturers profiling their users via the internet then that's fine for you, other people see it differently.

[Ripplinger]

I register my Kobos with a real email address to a real Kobo account. However, that account has no information other than my email. I don't use it to purchase books at all, I don't even browse the Kobo store from the reader. I purchase my books elsewhere through my PC only and sideload all books. These sideloaded books never interact with Kobo's servers, even on the rare times I turn on wifi to get a firmware update.

Exactly what information is Kobo getting from my registered reader that they wouldn't have from just browsing the bookstore from my PC? So they have my IP... every site you ever visit at any time from your PC has your IP and can match it up to an area. Why would I care if they also might have the serial number of the reader? (and I'm not even sure they collect that info). Whenever you buy a product, the store has a record of the serial number, you need to supply it for warranties, service, etc.

I guess I'm one of those who just don't see the problem.

[ero-sennin]

OK, figured out how to patch libnickel.so.1.0.0 to disable the Critical Error popup. This way it would accept any non-empty registration data, like in older firmwares.

Spoiler:

The string "Critical Error" is referenced from these two functions:

008A85D0: _ZN18Nickel3Application20finishInitializationEv ; Nickel3Application::finishInitialization()

008FC95C: _ZN19PlugWorkflowManager16onDoneProcessingEv    ; PlugWorkflowManager::onDoneProcessing()

Both functions contain a similar piece of code:

<...>
008FCA3E                 BL              sub_643568 ; load and validate user data
008FCA42                 CBNZ            R0, no_error
008FCA44                 LDR             R1, =(_ZN19PlugWorkflowManager16staticMetaObjectE_ptr - 0xE29760)
008FCA46                 ADDS            R6, R7, #4
008FCA48                 LDR             R2, =(aCriticalError - 0x8FCA58)
008FCA4A                 MOV.W           LR, #0xFFFFFFFF
008FCA4E                 MOV             R3, R0  ; int
008FCA50                 MOV             R0, R6  ; this
008FCA52                 LDR             R1, [R5,R1] ; _ZN19PlugWorkflowManager16staticMetaObjectE_ptr ; char *
008FCA54                 ADD             R2, PC  ; "Critical Error"
008FCA56                 STR.W           LR, [SP,#0x14+var_14]
008FCA5A                 BLX.W           _ZNK11QMetaObject2trEPKcS1_i ; QMetaObject::tr(char const*,char const*,int)
008FCA5E                 MOV             R0, R6
008FCA60                 MOVS            R1, #1
008FCA62                 BLX.W           j__ZN19AccountSignOutMixin17showSignOutDialogE7QStringb ; AccountSignOutMixin::showSignOutDialog(QString,bool)
008FCA66                 LDR             R0, [R7,#0xC+var_8]
008FCA68                 LDR             R3, [R0]
008FCA6A                 CBNZ            R3, loc_8FCA80
008FCA6C                 MOVS            R1, #2
008FCA6E                 MOVS            R2, #4
008FCA70                 BLX.W           _ZN10QArrayData10deallocateEPS_jj ; QArrayData::deallocate(QArrayData*,uint,uint)
008FCA74
008FCA74 no_error        ; continue normally
<...>

This code calls a function at 0x643568 that loads and validates the user data. If that function returns 0, the Critical Error dialog is shown. Otherwise, no dialog appears and everything is fine. So we can just modify that function to always return a non-zero value.

The end part of the load-and-validate-user-data function at 0x643568, where the result is returned, looks like this:

006435A6                 ADDS            R0, R5, #1  ; return 0 if R5 == -1
006435A8                 ADD.W           R7, R7, #0x3C
006435AC                 IT NE
006435AE                 MOVNE           R0, #1      ; otherwize return 1
006435B0                 MOV             SP, R7
006435B2                 POP             {R4-R7,PC}  ; return from function

Changing the first line to

006435A6                 ADDS            R0, R5, #2  ; return 1 if R5 == -1

will make the function always return 1. Done!

Here is the patch for libnickel.so.1.0.0 from the 3.19.5761 firmware:

<Patch>
patch_name = `Accept any registration data, disable the Critical Error dialog`
patch_enable = `yes`
replace_bytes = 6435A6, 68, A8
</Patch>

The only problem is that the patch would have to be manually updated for future firmwares. Perhaps we could find out how to generate valid registration data that would work with unpatched firmwares?

[peyton]

Thanks, i'll test that for my Mini

[peyton]

My mistake.. Your patch works great. I disabled all patches except yours and i could put sqlite bypass all right. Great Thanks !