In my previous article, I left a lingering question regarding the decryption methodology inside wasm. Today, let's dive deep into the world of reverse engineering again and uncover the mysteries that lie beneath the code.
Now, some of you might wonder why this post is titled pure guesswork. Well, that's because I tackled this 'reversing' challenge without actually doing any acutally reversing.
Thinking Forward
If there exists a decryption algorithm, there must be a corresponding encryption mechanism. In this case, the exported function h in the webassembly is the encryption method I want.
Similar to its decryption counterpart, it requires two parameters: encrypted data and a trackId.
1 2 3
function f_h(a:{ a:byte, b:byte }, b:int, c:long_ptr, d:int, e:int) { var m:int; ...
Let's explore how this encryption works.
Guessing the encryption
First, we need a script to test how different parameters influence the encryption outcome:
from Crypto.Cipher import AES from Crypto.Util.Padding import pad from wasmer import engine,Store, Module, Instance,Memory,Uint8Array,Int32Array import io,sys,pathlib import re,base64
for i inrange(0x20): data = b'A'*0x10+b"CCCCCCCC"+b"DDDDDDDD" # track_id = b'E'*0x8+b'F'*0x8+b'G'*0x7 # max 24 track_id = b'\x41' * i # track_id = b'E'*0x8 print(hex(i),encrypt(data,track_id))
From the results, we can observe that after track_id reaches a length of 0x18 bytes, the outcome remains the same. This implies that the length of track_id beyond 0x18 doesn't impact the results.
0x18 is an intriguing value, precisely 192 bits. This instantly reminded me of aes-192 encryption. In fact, if you search "192 bit encryption" on Google, the first result typically points towards AES.
But how can we ascertain that this is indeed AES encryption? While we could manually verify it, we also need to identify the encryption mode and its IV (Initialization Vector).
I began by trying out CBC mode, primarily because it's commonly employed. Also, due to the nature of CBC mode (as detailed on Wikipedia), it's straightforward to verify it by using the initial 16 bytes as the IV.
uhhhhhh, wtf, it indeed was the CBC mode (Coooooooool). Now, the task was to identify the IV.
Finding Parameters
Since the encryption function doesn't explicitly demand an IV, there are two possibilities. The IV could either be generated based on trackId (since the data would eventually be encrypted) or it could be randomly generated and then appended to the returned value.
The latter can be quickly ruled out, given the length of the return value doesn't seem to have room for an appended IV. This points to the former - the IV might be derived from the trackId. But how?
To solve this, I started with the simplest assumption: that the first 16 bytes of the trackId were being used as the IV.
LOOOOOOOL, it is same as the key. wtf is your encryption bro.
But then another challenge arose. The xm_encryptor can also process a trackId with a length less than 24 bytes. Knowing that AES-192 cannot work with a key length other than 24 bytes, I assert that the algorithm must somehow pad the trackId with some additional characters.
Our task now was to identify the padding characters and its padding method. Since the encryption needed to support variable trackId lengths and since the padding was done based on our provided trackId, the most straightforward solution would be to pad with some constant characters.
There are also two types of simplest padding methods, one is to pad behind the trackId, and the other is to pad in front.
So at this time, there is one simple but effective method - Bruteforce. One byte by one byte. We only need to run 256*24=6144 iterations. Not even hitting 10k.
But the second approach, padding before the trackId, worked.
1 2 3 4 5
[aynakeya @ ThinkStation]:~/workspace/ximalaya 23:16:55 $ python test_wasm_3.py found [b'1'] ... found filled up: b'123456781234567812345678'
Verify Parameter with Memdump
To validate the padding method is accuracy, another technique I can employ is the memory dump. While debugging would work too, I'm just too lazy to debugging WebAssembly.
To achieve this, I added a few lines to the encrypt function:
1 2 3 4
result_data = bytearray(memory_i.buffer)[result_pointer:result_pointer+result_length].decode() a = bytearray(memory_i.buffer)[0:track_id_offset*3] off = a.find(key) print(a[off-0x20:off+0x20])
By examining the output, we can clearly identify the padding:
The presence of sequences like 123456781AAAAAAAAAAAAAAA in the dumped data suggests that our assumption regarding the padding is indeed accurate.
Put it together
With all the pieces of the puzzle now in place, it's clear that the wasm encryption follows these steps:
Decode the input with Base64.
Use AES-192-CBC encryption. The key is derived from trackId. If trackId has fewer than 24 bytes, it's prepended with 123456781234567812345678 to reach the required length. And the IV is the first 16 byte of the key.
Encode the result using Base64.
Walking Backwards
Having understood the correct encryption method, I took a moment to ponder whether there might be a more straightforward reverse engineering approach.
I wasn't keen on trawling through WebAssembly. Just then, one user from some git issue mentions that the older version of the Ximalaya client used a DLL to implement the encryption, and more importantly, the encryption mechanism was identical.
Hey, I don't need to deal with the stupid WebAssembly anymore. I could now dive straight into dissecting the algorithm using the my good old assembly code. Well, at least that's what I initially thought.
The Golang DLL
I did take some time dived into reverse engineering - mainly because the dll was crafted using Golang . While the world of assembly offers its intricate dance of registers and memory locations, it became exponentially challenging with Go's binaries, thanks to its distinctive calling convention.
For those unfamiliar, a calling convention defines the runtime call stack's operation, dictating how functions receive parameters from their callers and return their results. Typically, languages like C or C++ adhere to conventions that is fairly easy to use and understand. Enter Golang - a language that not only dances but also brings its own dance floor. Unlike its peers, Go uses a unique, stack-based calling convention, throwing a wrench into the familiar rhythm of traditional reverse engineering tools.
What does this mean for reverse engineers? Pure Pain.
Standard tools like IDA Pro, Ghidra, or Radare2 can get pretty confused by Go's conventions. Recognizing function boundaries, arguments, and return values becomes an uphill battle. Local variables and function arguments are frequently intermixed, and because Go binaries are statically compiled, there's a whole lot of code to sift through.
But every dark cloud has a silver lining.
Instead of wrangling with Go's intricacies head-on, an alternative approach dawned upon me: why not write a similar AES decryption function in Go, compile it with debugging symbols, and then use that as a basis for comparison with the target binary? By doing this, I'd have a "known" reference, a roadmap of sorts, to guide my analysis of the original DLL.
The process was fairly straightforward. I wrote an AES decryption method in Go, ensuring it closely mirrored the suspected functionality of the target DLL. Upon compiling this with debugging symbols, I was armed with a binary rich in annotations that helped demystify the corresponding sections of the DLL.
func main() { a, b := DecryptByAes("asdfsadfsadf") fmt.Println(a, b) }
Using my custom-compiled Go binary as a reference, I could now align and correlate patterns, function calls, and data structures more effectively with the DLL. This comparative approach illuminated the obscured parts of the DLL, allowing me to make headway much faster than if I had been grappling with the unfamiliar Go assembly on its own.
Here's the key padding:
Debugging
Another approach is to create a C program that calls the binary. This way, I can engage in debugging to uncover the inner workings of the fill_key function and understand its behavior more effectively.
printf("load awesome.dll success\n"); // Get a pointer to the decrypt() function DecryptFunction decrypt_func = (DecryptFunction) GetProcAddress(hLib, "Decrypt"); if (decrypt_func == NULL) { printf("Error getting Decrypt function address\n"); return1; }
// Test call char value[0x50] = "QQ==\x00"; // Just for demonstration char key[0x50] = "abcd\x00"; // Just for demonstration printf("ready to execute\n"); char* result = decrypt_func(value, 4, key, 4); printf("ok\n");
printf("Result: %s\n", result);
FreeLibrary(hLib); return0; }
After all, the results of the proper reverse engineering were very consistent with my guesswork solution.
Some Thoughts
Sometimes, when confronted with a perplexing problem, it's beneficial to shift gears. Using an informed approach to make educated guesses can be far more productive than blindly grappling in the dark. Instead of hitting the wall repeatedly, stepping back and reassessing can often open doors to solutions previously unseen.
The age-old wisdom of "Don't put all your eggs in one basket" rings true here. Diversifying your strategies can save you from potential pitfalls and lead you to your eureka moment faster than you might think.
All in all, the joy of conquering a formidable challenge is incomparable. Those fleeting moments of doubt now serve as milestones marking how far I've journeyed, filling me with a profound sense of achievement.
deffind_ext(data): exts = ["m4a","mp3","flac","wav"] value = magic.from_buffer(data).lower() for ext in exts: if ext in value: return ext raise Exception(f"unexpected format {value}")
