Python version of the API

In the previous articles How I reverse-engineered the API – Part 1 and Part 2 we saw how I proceeded to analyze and reverse engineer the Ask FM API so I could automate some tasks.

From there, I decided to implement a basic version of the API, with only a few functions I needed (a lot are missing, like liking an answer, following and unfollowing people, blocking people, etc.). After some time using this ugly code, some people asked me to share my work. I was reluctant to do so for multiple reasons :  First, I’m not sure about the law around reverse engineering, it’s always been a grey area to me. Also, I’m not sure the people who asked me for it would benefit from this code or these articles because they won’t understand anything and won’t know how to use it. And lastly, I didn’t want to share an easy “working as-is” executable, because it would allow script kiddies to spam on because of the absence of captchas when using this.

For these reasons (and for intellectual property matters), I voluntarily stripped off the API secret key from the Java code on the Github repository, otherwise might get angry at me for sharing such a thing. I might contact them and if they’re okay with it, I’ll add it back.

The code

Anyway, enough talk, here is the link to the github repository :

Hexalyse/pyAskFm – Basic python implementation of the API

Final word

As you can see, there are a lot of things that could be done to improve this code. If you’re interested in contributing, read the file on github, and feel free to send a Pull Request.

How I reverse-engineered the API – Part 2

In the second part, we’ll take a look at the requests we intercepted thanks to Fiddler, and see if 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
X-Api-Version: 0.8
X-Client-Type: android_3.8.1
Accept: application/json; charset=utf-8
X-Access-Token: .4WspnFnDpwQNevsbXIEExPDgJZDM
Accept-Encoding: identity
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)
Connection: Keep-Alive
Content-Length: 186

json {"did":"84a2b70bfae4ae65","guid":"84a2b70bfae4ae65","pass":"password123lol","rt":"4","ts":"1471967146","uid":"JohnDoe"}

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 API – Part 2”

How I reverse-engineered the API – Part 1

In this first post, we’ll see how I managed to reverse engineer the 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, 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 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 servers.

Continue reading “How I reverse-engineered the API – Part 1”