I've sent you a PM with a de-gzipped traffic analysis of the android app, every entry contains a token, so I don't think they're user-unique, and they can be downloaded from any browser that supports 302 redirects
To avoid double-posting i'll just update this post.
I've managed to setup a apache2 reverse proxy to transform HTTP requests into HTTPS
Then I've entered kobo's FQDNs into my own DNS server to point them to my web server
And I've captured everything I could using wireshark
I've realized this badly-made graph to symbolize how the sync process works in general.
The process goes from top to bottom, and the requests should be in that order.
The automatic sync, that happens when the device connects to wifi, only happens if the sync queue isn't empty, and consists of downloading the sync queue, downloading covers&metadata and finally uploading events.
I'm slightly concerned about the events, even if it's just "First time/Last time/Amount of times you've done it", sometimes I just don't like people peeking into what I've done, but whatever.
The only URL that is critical for automatic sync is the storeapi one, as it passes the sync queue, the download targets (could logically be alterred) and the metadata.
So, if a sync patch needs to be made, only this URL needs modifications, so that's one patch in libnickel, one modification in Kobo eReader.conf and the server itself.
I'd probably also go for a services patch to be able to switch between home screens and the odd other internal setting, an api patch for manual update distribution and anything else involves emulating the store api, so that's probably one for later.
This is becoming REAL guise.
EDIT2: Sync queue data here, stripped as well as I could
https://pastebin.com/Dh1p5Cit