Giovanni Rocca

Giovanni Rocca

Application developer and web designer

SmashGAG is our little new app – project.


Hello guys! How are you doing!?


A couple of month have passed now since the end of my adventure with PokéMesh. During these time a lot of things happened in my life, beginning from the birth of my daughter Noelle followed by my new job position in an awesome team for a great company.

In the free time, mainly at the weekend, me and a good old friend started working towards this new project.

Idea

SmashGAG came from an old Facebook page I had in which I’ve shared a couple of Facebook fake conversations using real and fake characters. I searched for a tool to quickly create these kind of memes with ease for a couple of hours and I finally ended up creating my own little app to build them.

Our main goal (that I think we reached) was to use what I’ve learn with PokèMesh and PokémonGO and take it to a new project (no matter which one or the kind). For example, a rest service that uses so and so, the same communication protocol, the security and many other little things.

The source code of my old app to create these Facebook fake conversations got deleted many months ago since it was a dead project, but I took the idea from it to build what we decide to call, SmashGAG.

About the project

SmashGAG is a new app, very similar to 9gags or other meme and fun applications/websites that will let you create facebook, twitter and google search gags. In addition to other kind of similar services (that let you build these kind of meme) the works is done server side and provided through a rest api service. Images are built in the server and use the real Facebook, Twitter and Google css style to reproduce a perfect screenshot. Within the app you can customize lot of thing such as like, comments, reactions and many more things. The app got a local database that will let you create your characters and use it anytime on your gags. You can customize character name, avatar, nickname after the @ for twitter and even choose if you want the little blue V for twitter verified accounts. Hashtags on the status are processed as well and marked with the blue color. You can use the app to prank on your friend or just build gags to share with your friends on your pages.

Additional

Inside the App, you can register for free to remove the watermark on the gags. By registering, you will have a custom profile with a custom nickname and avatar. We are actually work to bring in a follow/likes system that will let you follow other users and rate their gags. Obviously this will take a bit longer since it’s our “weekend project”, but we are happy of the actual result.

Technical notes

The backend is written in node with express and mongoose which manages the rest service and the data. The request and response envelopes are encrypted client side and deciphered by the server using a magic table. This can be cracked with ease… but will also let us catch any abuser with ease (just like PokémonGO). The first client, of course, it’s for Android. Probably we will move to bring live a web an iOS app later.

You can try the app by becoming a beta tester on the Google Play Store using the following link:

https://play.google.com/apps/testing/com.smashgag?authuser=1

You can also join our discord to discuss the project:

https://discord.gg/CwXbxw2

Social references of the project:

Facebook: https://www.facebook.com/smashgag/
Twitter: https://twitter.com/SmashGag
Instagram: https://www.instagram.com/smashgag/

The app will remain in beta stage until the explore and profile sections will let you see and rate gags built by other users.

Let me know for any improvements or problems!

 

Reverse Engineering: LiveScore.com api encryption

Hello everyone!

Everything stated and reported on this post is for study and demonstration purpose.
There is no violation or usage of copyrighted code nor abuse of service. The code snippet that can be found on the post are reversed and made opensource under GPL license.

Platform: LiveScore.com
Api communication: JSON
Security measure: body encrypted


Request from the original client:

URL http://api.livescore.com/~~/app/07/home/soccer/1.0/
Status Complete
Response Code 200 OK
Protocol HTTP/1.1
SSL
Method GET
Kept Alive No
Content-Type text/plain
Client Address /192.168.1.133
Remote Address api.livescore.com/54.246.163.117


Headers:

GET /~~/app/07/home/soccer/1.0/ HTTP/1.1
user-agent LiveScore_Android_App/new_version
Host api.livescore.com
Connection Keep-Alive
Accept-Encoding gzip


What is superclear is that our response is encrypted, as you can notice by making a simple get request opening: http://api.livescore.com/~~/app/07/home/soccer/1.0/

By digging and debugging the code of the Android App (I’m really familiar with JAVA) I was able to reverse engineering the request structure and the decryption method to obtained styled JSON.

The reversed decryption method, that can be found here, takes 2 parameters, the byte array of the body response and an int32 that is a key obtained by the body. The key is obtained from another little function that takes the bytes from 16 to 35 of the response body (first 15 bytes are discarded and used elsewhere since it’s the query expiration) and from 35 to the end is the encrypted JSON.


Here is a little example on how to use the code, that can be ease ported as well to other languages:

byte[] body = response.body().bytes(); // The bytes of the body response
byte[] key = Arrays.copyOfRange(body, 16, 35);
body = Arrays.copyOfRange(body, 35, body.length);
String json = decrypt(body, key);


Big lacks:

  • SSL
  • Encryption/Decryption methods as well as magic bytes are too easy to spot.

Improvements/Fixes:

  • Encryption/Decryption take times and resources. It’s not needed at all except to hide sensitive informations.
  • Implement hashes on headers/request envelopes.
  • Track users for preventing api abuse

 

 

PokéMesh – Inizio e fine di un’avventura

In questo primo articolo del mio sito/curriculum voglio raccontare la mia bellissima esperienza ed avventura con PokéMesh andando a toccare punti ed idee personali e punti tecnici che potrebbero richiedere un livello base di logica di programmazione ed informatica.

Partiamo dal principio, come nasce PokéMesh.

PokéMesh nasce poche settimane dopo la pubblicazione della popolare app Pokémon GO (meta luglio 2016), sviluppata da Niantic con diversi partener, tra i quali Google, che forniva i server, ed ovviamente Nintendo.

Vista la grande popolarità del gioco decisi di proporre l’idea di sviluppare un’applicazione Android a 3 ragazzi, Alvise – Vincenzo – Domenico, con cui ho avuto il piacere di poter lavorare e con cui spero di poter portare a termine altri grandi progetti. Volevo inizialmente realizzare qualcosa di utile e semplice, e fu cosi che iniziammo a realizzare una mappa che era in grado di mostrare i Pokémon nelle vicinanze.

Non ricordo esattamente a chi venne il nome “PokéMesh”, probabilmente a Domenico ma fu chiaramente azzeccato – Poké (Pokémon) Mesh (Rete). Ma iniziamo a scendere un po più nello specifico su come e cosa era necessario fare per poterla realizzare.

Come tutte le applicazioni e i giochi online, anche Pokémon GO ha un client, l’app, e i server, con il quale avviene un costante scambio di dati. Il passaggio dei dati avviene attraverso le api che comunicano usando dei messaggi in Protobuf (molto simile al JSON). Questi messaggi, contengono poi una serie di dati che vengono riprodotti sul gioco. Per scendere ancora di più nel semplice, il gioco richiede dei dati ai server con dei messaggi, il server li verifica e risponde con i dati richiesti.

Nel nostro caso dovevamo ottenere i Pokémon da mostrare sulla mappa ai loro server, in modo da fornire un servizio “reale” e funzionante. Per fare ciò, si è reso necessario sfruttare alcune tecniche di hacking, ad iniziare dal MITM (man in the middle), una tecnica che consente di poter intercettare lo scambio di dati, che come ormai tutte le app è protetto da SSL, tra il client e i server, riuscendo a leggerne e modificarne il contenuto.

Inizialmente rilasciammo l’app sul PlayStore e sul sito web http://www.pokemesh.com. Il successo dell’app fu quasi immediato, anche grazie alla cura che abbiamo dato all’aspetto grafico dell’app e alle sue funzionalità, seppur ancora molto povere. Con grande stupore, dopo alcuni giorni, l’app scalò la classifica globale del Google Play Store, superando inizialmente Amazon, Spotify, Instagram e altre app di rilievo approdando seconda in classifica (il primo posto era ovviamente di Pokémon GO). La gioia durò poche ore, poichè fummo rimossi dallo store per violazione delle policies di Google. Il danno fu minimo. L’app era già cosi popolare che bastò inserire un sistema di aggiornamenti in-app e continuare la distribuzione sul sito. Penso che nessuno all’interno del nostro gruppo abbia mai visto numeri cosi alti in termini di utenza cosi come penso che sarà veramente difficile trovare un’altro progetto che dia tali soddisfazioni (sempre in termine di numeri).

Ma andiamo avanti… Giunti a settembre, Niantic, inizia ad adottare serie contromisure per impedire ad applicazioni (erano veramente tante) non ufficiali, tra cui la nostra, di poter ricevere dati dai propri server.

N.B: Ogni singola app ed ogni singolo utente che richiedeva dati ai loro server, per loro, era un costo, e non indifferente.

La prima seria contromisura fu l’introduzione della Signature, meglio conosciuta come la Unknown6, una “firma” lasciata nel messaggio per richiedere i dati, che veniva verificata dal server e qualora qualcosa non combaciasse, non veniva ritornato alcun dato. Da questo momento in poi si è passati al livello successivo. Servivano tecniche di hacking molto più avanzate ed un livello teorico abbastanza solido per poter riuscire a “crakkare” la loro sicurezza. Fu cosi che nacque una solida community di sviluppatori provenienti da tutto il mondo, Russia, India, Cina, Romania, Brasile, Canada, Belgio ecc ecc ecc. La prima battaglia durò 4 giorni, dove più di 40 sviluppatori all’interno di una chat, condividevano idee e metodi, lavorando insieme per riuscire a riprodurre la signature che era cryptata ed inserita nella richiesta. Si è quindi ricorso al Reverse Engineering per ricostruire l’algoritmo con cui la signature veniva cryptata.

Inutile dire che nel corso dei mesi, gli aggiornamenti alla loro sicurezza sono stati molto accaniti e frequenti. Possiamo dire che non esiste al mondo nessun sistema che non possa essere crakkato, lo puoi rendere difficile ai limiti dell’impossibile tanto da renderlo estenuante poi per chi lo deve crakkare. Se dovessi parlare dei sistemi di sicurezza adottati negli ultimi aggiornamenti a cui ho lavorato, con un linguaggio terra terra, mi troverei un pò in difficoltà.

All’interno della signature erano stati inseriti diversi hash che venivano anch’essi validati dai server. L’algoritmo per generare gli hash era scritto all’interno della libreria nativa, successivamente offuscata con strong.code. Il primo hash ed il secondo hash erano dei long di 128 byte generati utilizzando un salt di 4 byte ottenuto dalla timestamp, inclusa anch’essa nella richiesta, e i byte della posizione dell’utente (latitudine, longitudine ed altitudine). Gli altri 5 hash erano ottenuti dai byte di ogni singola richiesta inclusa nel pacchetto richieste.

Ho smesso di lavorare al progetto da quando è diventato un gioco da ragazzi, per loro, mandarci KO, ed un impresa che richiedeva altre 2/3 settimane di lavoro per riuscire a ritornare operativi. Successivamente ci è stato anche recapitato un C&D che ha definitivamente chiuso ogni ipotesi di aggiornamento futuro.

Ancora più importante del lato economico, questo progetto penso abbia aperto delle porte a tutto il team. Personalmente, oltre ad aver decuplicato le mie competenze, che sperò di poter centuplicare con altri mille progetti nuovi, mi ha insegnato che lavorare in gruppo e unire più cervelli è la chiave per realizzare qualsiasi tipo di lavoro. In 3 sviluppatori ed 1 grafico abbiamo realizzato un’app che teneva una media di 80.000 persone connesse durante le 24/h, 4 milioni o più di richieste al minuto, oltre 8 server in batteria per gestire il traffico che proveniva sia dall’app che dal sito web. Sono emersi molto anche i nostri limiti durante dei tentativi di realizzare delle espansioni del progetto ma sono sicuro che da esse abbiamo imparato moltissimo. Abbiamo utilizzato oltre 4 linguaggi di programmazione per l’intero progetto, che ci ha portato ad imparare le basi del GOlang e ad espandere PHP java e bash scripting per l’automazione.

Vorrei infine concludere questo articolo sottolineando che tutto ciò che abbiamo fatto era nel pieno della legalità, sebbene può sembrare strano che ottenere dati da un server di proprietà altrui sia legale. Diventa illegale quando per ottenere i dati viene utilizzato del codice di proprietà altrui. Il codice da noi utilizzato era pienamente reversato e pubblicato sulla mia repository.