-
Notifications
You must be signed in to change notification settings - Fork 0
Broken with Koudai48 v6 -- need to crack new API #11
Comments
Also, plive.48.cn straight up refuses to connect outside Mainland China, it seems. With Alibaba Cloud or China Telecom's DNS servers, plive.48.cn resolves to 115.231.96.215 (AS4134 CHINANET-BACKBONE), where port 80 is closed (not ideal, but fair enough) and port 443 open. With 1.1.1.1 or 8.8.8.8, plive.48.cn resolves to 47.244.116.101 (AS45102 Alibaba (US) Technology Co., Ltd. -- appears to be a Hong Kong node), where both port 80 and port 443 are closed. |
Side remark: v6 of the stupid app still doesn't support iOS's password autofill. Wonder which awful cross-platform framework they're using for this. |
Okay, the host is Edit: I might want to try Frida though. It's been on my things to try list for quite a few years, but I never got around to it. |
Glad u still here. |
Lovely. Except even if there are further encryptions, the key has to be embedded in the app, so it's still technically possible to crack (and makes "need to crack new API" an even more apt description), just harder. However, if that's the case, it would probably be even less feasible on iOS. Android apps, though, are known to be easier to decompile, so with this preliminary info, I'd say the task falls squarely on the shoulders of Android developers. |
FYI. |
Thanks for the note. @王子杰 Not a single more cent from me then.
|
https://github.com/xsaiting/pocket48-grab |
xsaiting's website seems to work but his backend proxy code is not open source (not at the moment), so it doesn't help. I did notice something else earlier today, so a fix here will be released as soon as I get around to it. Interestingly enough, my periodic monitoring script (feeding https://github.com/SNH48Live/snh48g-livestreams-analysis) did not lead to an IP block. Then again I don't spam the API, only once every ten minutes. |
By the way, I did give it a shot myself today, but unfortunately all my phones are unjailbreakable (even my two old 6 Pluses are on 12.2, and the latest jailbreakable version is 12.1.2), meaning I can't decrypt the app bundle. So cracking it myself is out of the picture for the foreseeable future (unless someone shares a decrypted bundle with me). |
A brief status update: I started working on the 6.0.0 update about two hours ago, hoping to get a working version (sans possible refinements) in about an hour. Boy was I wrong. I did get std mode to work, but now it has the much dreaded N+1 problem. Way to go. Oh, and if you compare properties returned in the list request to properties returned in a single resource request, the sheer discrepancy will leave you speechless. There must be an API design genius behind this work. Perf mode will never be the same again. There's no more subtitle, so you don't know who's in a 星梦Mini Live VOD without checking the thumbnail, and you can't even tell birthday stages from regular ones, let alone whose. Thanks for screwing with automators. What's more, they can't even do pagination any more. You heard it right. With a proper database it's actually very hard to screw up pagination, but they somehow managed it. Compare these two subsequent pages: $ curl -sS -H 'Content-Type: application/json' 'https://pocketapi.48.cn/live/api/v1/live/getOpenLiveList' --data "{'groupId': 10, 'record': true, 'next': 324479006174679040}" | jq -r '.content.liveList[].liveId'
324479006145318913
324479006145318914
324479006149513216
324479006149513217
324479006149513218
324479006128541696
324479006145318912
324479006128541697
324479006128541698
324479006132736000
324479006132736001
324479006170484738
324479006132736002
324479006136930304
324479006086598657 x
324479006136930306
324479006086598658 x
324479006090792960 x
324479006124347394
324479006090792961 $ curl -sS -H 'Content-Type: application/json' 'https://pocketapi.48.cn/live/api/v1/live/getOpenLiveList' --data "{'groupId': 10, 'record': true, 'next': 324479006090792961}" | jq -r '.content.liveList[].liveId'
324479006086598657 x
324479006086598658 x
324479006090792960 x
324479006069821440
324479006069821441
324479006069821442
324479006069821443
324479006074015744
324479006074015745
324479006032072705
324479006074015746
324479006032072706
324479006036267008
324479006036267009
324479006036267010
324479006040461312
324479006040461313
324479006011101186
324479006015295488
324479006040461314 I marked the duplicate IDs with crosses. Bravo. To sum it up:
|
(If one look closely at the IDs in #11 (comment), it's not too hard to realize what went wrong in their schema.) |
9981227 should at least be usable. Some refinements (mainly in the perf mode department, but as I mentioned above it won't be the same again) are on the way. |
Seems broken as of today, which coincides with the stupid v6 update of the app (and which totally bricks v5 -- who the fuck practice that kind of brain dead brutal upgrade?)
In fact, the error isn't so much that the body is empty; the status code is actually 404, so my error handling code is apparently ineffective.
I'm acknowledging the issue but don't have time to investigate at the moment.
The text was updated successfully, but these errors were encountered: