This is yet another reminder that good JS minification tools exist that can absolutely change object properties into short minimal strings instead of descriptive names. It's called the Closure Compiler in advanced mode. You do have to have quite a bit of discipline in writing the JS to have that though. Some languages like ClojureScript actually do this by default, so it doesn't take much effort.<p>Also it helps if you don't have to use objects (with keys) to transfer data. What I mean is that there's little reason to use<p><pre><code> {
"alias": "b6WJEDTp",
"member_nickname": "faRw33",
"created_at": "4d",
"is_auth": "Y",
"board_id": 114961,
<snip>
</code></pre>
when you instead can use a simple array<p><pre><code> [
"b6WJEDTp",
"faRw33",
"4d",
"Y",
114961,
<snip>
</code></pre>
if you have some post-processing to transform array indices into object keys.<p>Both of these approaches also cut down on the amount of data transferred over the wire, so it saves data and helps speed up the site for users too.
Nice article! I always wonder what the legal aspects of publishing a reverse engineering article for a private API are? Does the company that the API belongs to have rights to an obligatory take down request?
I've gone through this same exercise in the past in order to mass-delete a large number of comments on different threads. I was afraid that Blind may one day suffer a data leak. I attempted to reroll the crypto in Ruby, but ultimately failed and went the JS route, same as the author. I also had to roll my own sesion-token refresh logic. Finally I was wondering if any kind of data mining could be done with the tool, but I never took it that far. Thanks for the writeup!
So, they used asymmetric encryption for the request so that a MITM can't read that, but they used symmetric encryption for the response. Though it requires a MITM to fully analyse the code, it allows a MITM to decrypt any response. Cited possible reason (in the conclusion) is performance.<p>I think you don't have to resort to symmetric encryption here, even keeping performance in mind. What you do is generate a new asymmetric keypair on the client for every session, then send the public key over to the server. Then the server encrypts every response with that public key, allowing only the client to decrypt it.<p>Doing that, one can only read a session's network traffic, both ways, if they can read values of variables on the client -- but if one can do that, you can read everything anyway. ;)<p>EDIT: forgot to talk about performance -- you just use a so-called "envelope", where the sending party first encrypts the data symmetrically with a randomly generated key, then encrypts that random key with the asymmetric crypto. The pair (symmetrically encrypted data and the asymmetrically encrypted key) is sent to the receiver, which can use its private key to decrypt the symmetric key, with which it decrypts the data.
the sad state of web developers.<p>from the silly comments of "infinite scrolling" being definitive proof of a solid rest api behind and that php is or is not capable of either (the writing is too ambiguous). to the roundabout amateur obfuscation (the author calls encryption) that is entirely akin to the JavaScript that disabled right click to "copyright" the page's content in the 90s.<p>sigh