In the second part, we’ll take a look at the requests we intercepted thanks to Fiddler, and see if Aks.fm implemented some sort of security (tokens, checksums, etc)
Understanding the request headers and parameters
Here is the request we’ll analyze :
POST /authorize HTTP/1.1
Accept: application/json; charset=utf-8
Authorization: HMAC a9f98b69f649e0c96240cc6e36980da96f308cea
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
User-Agent: Dalvik/2.1.0 (Linux; U; Android 6.0.1; GT-N7100 Build/MOB30R)
As we can see , there are lots of interesting headers here. I’ll not make you wait and explain directly what I deducted from my tests :
Continue reading “How I reverse-engineered the Ask.fm API – Part 2”
In this first post, we’ll see how I managed to reverse engineer the Ask.fm API. In a subsequent post, I might give the (ugly) code I came up with, which implements some of the API features I needed for various bots and scripts.
If you don’t already know Ask.fm, it’s a social network where people can create profiles and can send each other questions… and answer it, obviously.
Unfortunately, their website has nasty limitations (Google reCAPTCHA) that prevented me to do what I wanted. But I noticed their application never ask for any captchas. So I guessed it was using a backend API, and if I can use it, I can code bots more easily to automate various tasks (like sending “Group Questions”, a widespread practice amongst ask.fm users). I searched if their API was documented and if they offered developers access to it : they didn’t. I searched the web for people who would have implemented it in any language, and found nothing.
So it was my job to reverse engineer and implement (a basic version of) their API in Python. I will retrace my journey, step by step, of how I finally got to the point of intercepting API calls made from the Android app, to the ask.fm servers.
Continue reading “How I reverse-engineered the Ask.fm API – Part 1”