Shattered gem. Architecture of Ruby applications and their reverse-engineering

In times gone by, plenty of advertising articles were written about Ruby. In-depth information about its concept and internal structure can be found in a book called Ruby under a microscope. But the purpose of this article is very practical: analyze the reversal of applications written in this exotic language.

Problem statement

Imagine that you have some application that reads and validates a binary file. You have to figure out its validation algorithm. The initial automatic analysis of the application (performed using Detect It Easy) doesn’t bring any meaningful results: the application seems to be compiled from C++ in Microsoft Visual Studio 2015. However, its dynamic libraries include an interesting file x64-msvcr100-ruby200.dll, and the executable module features numerous references to it. The file positions itself as a Ruby interpreter written by its creator Yukihiro Matsumoto and even contains a link to the respective website.

In addition, the program includes some two and a half thousand *.rb files; a closer examination shows that they represent unprotected Ruby scripts in text format. As you may have guessed, there is a catch: none of these files contain calls to the target file, which means that you have to load the program to the x64dbg debugger and search for a call to this file in the dynamics of the interpreted code.

Examining the program

Let’s follow the standard procedure (you might be familiar with it from my previous articles). Set a breakpoint on the function that reads the file kernel32.dll.ReadFile. Of course, when the program loads, there are thousands of similar calls to all sorts of configuration files and libraries contained in the package; so, to make this task easier, let’s monitor the file reading process using the Process Monitor (ProcMon) program. Thanks to this tool, you can notice that, unlike all other files, the target file is read in blocks 0x10000 bytes in size. Therefore, to filter out all unwanted reading operations, you can set Size==0x10000 as a breakpoint condition.

Start the program and wait until it reaches the desired point. Now let’s analyze the call stack of the generated ReadFile.

The top five calls represent the native file reading harness and are of no interest. But below you can clearly see two nested interpreter calls that could be familiar to you from the analysis of virtual machines of other scripting languages. To avoid repeating what I have stated many times in earlier articles, I will try to be brief. Even the most hardcore scripting language interpreters (e.g. Python) never analyze text semantics during the execution. To optimize the interpreter performance when a module (class, object, method, etc.) is loaded, the text is compiled into native or threaded byte code; this process is called JIT (just-in-time) compilation or dynamic compilation.

And Ruby, despite its self-proclaimed extravagance, performs exactly the same operation (more information on JIT compilation for different Ruby implementations can be found on the website patshaughnessy.net). Now let’s get back to the virtual machine under investigation. If you examine nested stack calls in the above screenshot, you’ll identify the main instruction fetch cycle for the threaded code (marked with arrows). In IDA, the code of this procedure (sub_18001B6E0; the exported function is rb_vm_get_insns_address_table) looks as follows.

As you can see, the opcode is 8 bytes in size; the virtual machine contains 83 assembler commands; and the above-mentioned function contains implementations of each of these commands. It turns out that the interpreter library even contains a disassembler for the compiled bytecode (the exported rb_iseq_disasm_insn and rb_iseq_disasm functions). Analysis of these functions makes it possible to find a command mnemonic table located at 180200500:

A closer examination makes it possible to identify the bytecode interpreter type: YARV.

Generating an error

So, you’ve identified the interpreter and found the byte code from where the target file is read. What’s next? It would be boring to reverse the file operation by analyzing the compiled byte code, even with a built-in disassembler. The best way is to find the text source of the Ruby script (although it cannot be ruled out that the interpreter operates with artificially compiled byte code). But for now, let’s put such extreme options aside. Instead, let’s try to determine the name of the method that initiates file reading.

The first way to do this quickly and without painstaking code analysis that comes to mind is rather primitive: generate an error in the hope that the interpreter prints the call and return stack in the error report. A brief examination of the interpreter loop code shows the following: when an invalid opcode (>83) appears, the interpreter generates an error and even prints the stack when such an occurs.

Let’s simulate such a situation. As soon as you reach the breakpoint set on reading the 0x10000 block, you disable this breakpoint and set breakpoints on the next threaded code instruction fetching (on the second last screenshot, it’s the highlighted address 18001B722) and on the printf function (that prints the debugged stack). When the program reaches the next instruction, change it to an invalid one (e.g. 84) and see what printf prints. And this approach works: in addition to obscure debugging information about blocks and frames at the time when the error occurs, it outputs the closest class and method.

However, this information seems to be useless: most probably, reading occurs when eval from the HTMLExportDialog class is called, and, as bad luck would have it, this class isn’t available in plain code.

Searching for alternatives

Let’s try to approach the issue from a different angle and analyze the call stack shown in the screenshot at the beginning of the article once again. The thread under investigation ‘stems’ from the function call from ntdll, and it’s clear that the examined thread was started by some other thread. Going through the adjacent threads, you can find a similar candidate: this thread is quietly waiting for the end of the rb_eval_string_protect("PM::RubyBridge.run") function call.

At first glance, this discovery is also useless: as you might have guessed, neither PM nor RubyBridge are available in plain code. However, now you have a working hypothesis (and this hypothesis is partially supported by the application code analysis in IDA): the application communicates with the Ruby interpreter by calling rb_eval_string_protect.

Therefore, let’s remove all previous breakpoints and set a new breakpoint at the entry point of this function. After restarting the program, you’ll immediately notice plenty of interesting things: multiple calls in the PM.evx(URI.decode( %{./ruby/script/<ModuleName>.rbx} )) format where ModuleName refers to obviously encrypted files with the *.rbx extension, including RubyBridge, HTMLExportDialog, and many others. And most importantly, you’ve finally found the PM.evx implementation code that decrypts such files.

In other words, to protect their creation from evil hackers, the cunning developers have encrypted both the code and modules it decrypts using an asymmetric RSA algorithm, thus, making it impossible to change anything inside the script without a secret key. Fortunately, you don’t have to do this. To solve the task, all you have to do is find the validation algorithm for a given file, and this algorithm is hidden in one of the RSA encrypted scripts.

Furthermore, the major and most difficult part of the task has already been completed: you know the encryption algorithm for protected scripts, and the rest is paperwork. You can extract the public encryption key from the code and write a module decryption procedure; or you can set a breakpoint on decryption of the native RSA implementation library and dump the decrypted code… But as usual, let’s choose the line of least resistance.

In the previous screenshot, you can see that evx is implemented via eval; so, let’s set a breakpoint on the function x64-msvcr100-ruby200.dll.rb_f_eval – and at its entry point, you get the decrypted code of the modules on a silver platter. A few simple manipulations – and you find the ultimate goal: file validation algorithm.

Conclusions

It’s unlikely that you encounter such a strangely implemented and cunningly protected application in real life. As said above, scripting languages ​​are intended not for commercial packages: normally, they quietly do their job on closed servers. Still, the above-described experience would be useful should you decide to master virtual machines and interpreters or even design your own ones.

Good luck!