Clash of Clans – SuperCell new encryption reverse engineering

In this paper I’m going to speak about what I’ve did to reverse engineer the new encryption, using Clash of Clans as base (The logic used to break CoC could be replicated as well on Boom Beach and HayDay that are already shipped with the new encryption).

I’ll skip whatever that’s already known (the previous encryption), as it can be read and understood here: https://github.com/clugh/cocdp/wiki/Protocol (SuperCell shares the same protocol on all the games) and I’m going to focus on what really changes on this new encryption and how the crack has been done and figured out.

The goal, of course, was to break the encryption. Meanings, beeing able to decrypt and encrypt both server and client side to understand and reproduce payloads. You can find the patcher and the proxy server on github.

Tools used:

IDA
GDB
Gef
Unicorn emulator
Brain

Languages:

Python for the patcher
Node JS for the proxy server
ARM (ARM / Thumb) Assembly to reverse and understand the logic

What’s changed in details and why:

The old encryption was cracked by patching the public server key, that’s hardcoded in the libg and that’s used to feed blake2b update, to build the nonce, and crypto_box beforenm to build the shared key used later to encrypt/decrypt the payload.

First static analysis shown clearly that both the methods (blake2b update and cryptobox / cryptobox_open) was hard modified. Most of the edits done was only on purpose to obfuscate the whole encryption/decryption logic (the code is playing and moving the stackpointer up and down between close instructions). What really mettered can be found on top of what now are 2 big subroutines wrapping most of the encryption/decryption logic. The 2 subroutines involved are now generiting a new key during runtime (the function that build the key is reversed as well, and its mostly obfuscated with control flow flattening) but still feeded with the hardcoded public key as evidenced during debugging.

Hardcoded CoC key:

655a7dc351818e035c2990fb5f27e345064fbe1ea69bfd65f2ea7319943cd000

Key built int runtime:

7eb15f65bdd576619abbd0b0650c45db1020f5ec969fcf48a828424f1bc8d809

Following, this new key built in runtime is used to actually generate the nonce and to build the shared key with cryptobox_beforenm.

What follow, was dumping that new key, still static, and use it to reproduce and encrypt valid requests but of course that wasn’t enough to decrypt what the client send, why?

To build the login message, the official client, build the shared key from the private key generated during encryption logic and that pair with the key generated in runtime. What we know server side is the public key, that’s sent during login and that we can’t use to build the shared key.

So TLDR, patching the hardcoded key as we were used to, will just result in nothing done.

The actual logic

Starting from saying that I’m aware of another very easy method, that has been used by other guys and kept private and that i never ever tought to check since the amount of attention made to keep the things hard, my logic will patch 2 bytes. These 2 offsets has been found by digging in the memory at the entrance of the 2 involed sodium encryption and decryption subs (crypto_box and crypto_box_open). The library is loadint into R11 a struct holding our keys (public and private + the public server key) In more simple words, what the patch is doing, is replacing what’s used to build the shared key and instead of using the private key (that we don’t like because we don’t have on our server side) is using the hardcoded server key, that’s the pointer in memory just after the private one. This way, the shared key would be static and used always for any server proxy encryption and decryption.

Note please, if you read how the proxy server has been modded to made it work, you have noticed that is now using a “magic key” as shared key. This magic key was originally built in runtime while i was playing and messing with some values over there. Its basically the result of a beforenm with the 32 bytes key (the 0x72 one) that we were used to patch and the new server public key that’s build in runtime, that we already know.
This explain why my patcher is still patching the hardcoded public server key with the 0x72 one (that is now mandatory to let the client generate the magic key as well)

The question that will problably jump on the mind is why I’m still patching the hardcoded key. Simple. The 0x72 was patched inside the client during my works and the first magic key that was built was using it. I see no reason to skip patching 32 bytes that will make life harder to baby leechers. Let’s see that magic key as a little signature from me.

The runtime key generation

Some screenshots while working

More to come…

I personally hate private servers. My intent was not to damage in any way the company but instead, I want to challenge whose behind the security of the protocol to do his best and get out with an update soon that will challenge me as well.

I said that the function generating the key in runtime its reversed, and it is, mostly thanks to an old PokèMesh friend. Would still be interesting seeing where those involved values come from, but at the moment, this is not necessary at all.

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.