search

zhehaowang / sneaky

Feed and strategy for cross-venue Sneakers trading (Du, StockX).
GNU Lesser General Public License v3.0
10 stars 3 forks source link

feed: du #13

Closed zhehaowang closed 5 years ago

zhehaowang commented 5 years ago

reference: https://github.com/levislin2016/du-app-api

Hurdle 1: log in. Without a web interface, it seems the best we can do is to MitM ourselves: manual proxy to laptop, install a cert on phone, capture traffic and decrypt https headers on laptop. There are commercial apps out there providing an integrated solution: Fiddler and Charles Proxy both do this. With the latter we were able to see what exactly phone sent to authenticate itself, although replicating that didn't seem to work yet: 'pwd' based log in appeared no longer present in Du v4.1.1. We could either try a few more combinations with our iOS Du v4.1.1, or switch to an Android Du v3.5.5 and try pwd log in on that.

zhehaowang commented 5 years ago

Overcame hurdle 1: logging in. Du 4.2.1. Tried Android Du 3.5.5 as well but no luck due to no obvious way to trust Charles certificate.

Solution: Charles SSL proxy + copy as curl request, replay until we find the minimal required fields and url patterns: what stays the same and what changes. Then reproduce that in python. To verify the curl param is indeed reproduced, try sending both to a local echoing server and compare.

zhehaowang commented 5 years ago

Overcame hurdle 2: getting details.

getList url worked just fine with a nonsensical md5 sign value. getDetails url did not: always 403'ed. My suspicion's that sign actually needs to match the request. In login request's case, sign seems sensitive to post parameters (e.g. timestamp of the request, and also including params' sequence!) but not http headers. In getDetail's case, sign is sensitive to get url and positions of each param. Presumably sign is a transformation (e.g. md5) of some substitution of the get url string / post params, but that transformation itself is hard to guess.

The work here worked out just fine: https://github.com/luo1994/du-app-sign/tree/master/du (the execjs version). It seems getDetails requires no actual login, but rather sign to match the url itself, which the repo in question was able to produce with some extracted js. This would be a pretty weird defense mechanism in that client has all the information to construct a valid request without needing to send over any identifying information of itself.

Seems to be working fine so far. Closing feed part of this work.