MobileRead Forums - View Single Post

miyoyo · 03-26-2017, 01:14 PM

I also did my little investigation, and here's what I found:

There are only four HTTPS domains (excluding logins and oauths) in libnickel.so, these being:
- api.kobobooks.com - As far as I can tell, it's just for system upgrades
- storeapi.kobo.com - HTTPS Enforced, Pretty self-explainatory, user data, subscriptions, etc, but no dice on books. It does have a nice API tho.
- services.kobobooks.com - This one is interesting, it fails on HTTP but if the request is done in HTTPS by something like WGET, we get values from the sqlite database. Maybe OTA settings?
- partner.kobobooks.com - Not used, as far as I can tell.
The current order of website calls is: api.kobobooks.com, then mobile.kobobooks.com (Still can't get this one as HTTP, the request is HTTPS even when every trace of HTTPS is wiped from libnickel.so), then storeapi.kobo.com and finally services.kobobooks.com
StoreAPI and Services make use of the nx-kobo-userkey header, it's a UUIDv4, and is not linked to the hardware, maybe linked to the initial login?
They also need a special Authorization header. I couldn't get one from the eReader, but I pulled one from a capture of the android app and it seems to work.
The CA certificates are written at the end of nickel, and, except if you can forge one of the exact same size as another one, you won't go far. They are in the .der format

Also, I think another thing to look at should be the Desktop/Mobile apps, it's way easier to capture traffic from that.

Fun fact: their server also isn't W3C compliant, as it can return 404 when the only problem is that the request type isn't valid.

03-26-2017, 01:14 PM	#59
miyoyo Member Posts: 24 Karma: 13368 Join Date: Dec 2012 Device: Kobo Glo HD	I also did my little investigation, and here's what I found: There are only four HTTPS domains (excluding logins and oauths) in libnickel.so, these being: api.kobobooks.com - As far as I can tell, it's just for system upgrades storeapi.kobo.com - HTTPS Enforced, Pretty self-explainatory, user data, subscriptions, etc, but no dice on books. It does have a nice API tho. services.kobobooks.com - This one is interesting, it fails on HTTP but if the request is done in HTTPS by something like WGET, we get values from the sqlite database. Maybe OTA settings? partner.kobobooks.com - Not used, as far as I can tell. The current order of website calls is: api.kobobooks.com, then mobile.kobobooks.com (Still can't get this one as HTTP, the request is HTTPS even when every trace of HTTPS is wiped from libnickel.so), then storeapi.kobo.com and finally services.kobobooks.com StoreAPI and Services make use of the nx-kobo-userkey header, it's a UUIDv4, and is not linked to the hardware, maybe linked to the initial login? They also need a special Authorization header. I couldn't get one from the eReader, but I pulled one from a capture of the android app and it seems to work. The CA certificates are written at the end of nickel, and, except if you can forge one of the exact same size as another one, you won't go far. They are in the .der format Also, I think another thing to look at should be the Desktop/Mobile apps, it's way easier to capture traffic from that. Fun fact: their server also isn't W3C compliant, as it can return 404 when the only problem is that the request type isn't valid. Last edited by miyoyo; 03-26-2017 at 01:20 PM.