blinkVideoDownloader.py broke 9/17/2019 - Invalid account id

[squigdawg]

I believe it started 9/17/2019, running blinkVideoDownloader.py gives this error:

## Processing page - 1 ##
Traceback (most recent call last):
  File "blinkVideoDownloader.py", line 48, in <module>
    videoListJson = res.json()["media"]
KeyError: 'media'

The response from https://rest-prod.immedia-semi.com/api/v1/accounts/<my real 6 digit account ID redacted>/media/changed?since=2019-04-19T23:11:20+0000&page=1 was {u'message': u'Invalid account id', u'code': 400}

Apologies for being lazy and not wanting to setup mitmproxy, install the security certificate to a tablet, and reverse engineer what changed. Maybe somebody else has already figured it out? If not I'll try to sort out what changed next weekend.

[maoshouse]

This will be my weekend project as well.

[maoshouse]

to follow up, I just submitted a get request to this endpoint with my account id and it worked.

[squigdawg]

Thank you for following up! I thought it strange nobody else is complaining :-) I wonder what changed on my setup then. I have 2 sync modules and the login returns 2 apparently valid network/accountIDs. I tried them both to the /media/changed URL above and I get the "invalid account" response. I did customize the script about a year ago to poll that URL every minute. Perhaps Blink implemented some kind of blocking on my account. The Android app still works OK. I'll look more this weekend. Thanks for confirming the problem is not affecting everybody.

[maoshouse]

I think this is inherently a problem of us trying to take advantage of endpoints of what is really a private API (by virtue of obscurity). So I'd imagine your regular 1 minute call rate is easily identified as atypical. I'm not sure if the Blink Android App uses the same api. Perhaps it doesn't and thus isn't affected by "invalid account" error you're getting when trying to usev1/accounts endpoints of the script.

Which brings me to another point. Many of the requests documented by MattTW in his readme throw HTTP 426s, for "upgrade required". So clearly our requests are being handled but it's unclear as to what "upgrade" if any is required or available.

Since these APIs aren't meant for public consumption, we can't even be sure if these status codes are accurate.

I've read about capturing network packets using tools, and have attempted using Charles to discover what http requests the Blink iPhone app is making. Didn't have much luck, but I'll give it another whack this weekend.

[squigdawg]

So here's what I found. It seems there was a protocol change for the login command so this old URL: 'https://rest.prod.immedia-semi.com/login' became: 'https://rest.prod.immedia-semi.com/api/v2/login'

And there is a new field (I think it's new) called "Account" and "id" with a new 6 digit number that is different than the "networks" 6 digit numbers. I suspect that many people's accountID still matches their networkID so they are not seeing problems. But through some combination of having multiple networks on one account (and maybe having deleted and re-setup a sync module) the account and network ID numbers can become different.

Anyway, I made a small change and pull request to fix the script https://github.com/MattTW/BlinkMonitorProtocol/pull/36

Also, to any future unfortunate soles trying to get mitmproxy or similar apps to work, I ended up using an Android 5.x tablet because Android 6.x and newer cause apps not to trust user certificates by default. Supposedly you can decompile, modify and recompile the APK to change that, but apktool seems to have a bug which causes errors recompiling APKs with '$' characters in the resource file. So the blink app was having none of that.

Hopefully this will be useful to somebody else.

[squigdawg]

Thanks for the merge MattTW

[maoshouse]

Nice! I don’t have access to an android tablet and was unsuccessful in attempting to install trust certificates to achieve what you did on iOS.

Do you have the time to get and publish the updated api endpoints?