After 4 years of pure R&D and feedback from our early-adopters, we consider it's now time to go under the spotlights.
This article will give you a quick tour of our technology. Other technical articles will follow in the next few weeks to highlight some of REVEN (server) and REVEN-Axion (client front-end dedicated to reverse-engineers) features.
In a few lines:
REVEN currently helps for:
- advanced reverse engineering
- obfuscated/protected malwares
- application crash
- bug threat level qualification
- writing Proof-Of-Concepts (and even cooler things)
- advanced debug
- multi-thread & multi-process applications
- networked applications
- interactions between kernel and user lands, drivers development
Because we have killer features like:
- forward and backward analysis
- collaborative by design
- native and high-performance symbolic execution
- full view of a system when analyzing a binary/process: user land, kernel and hardware
Furthermore, we will release features for automatic detection of some 'nano-level' bugs during 2015, early adopters may contact us for using beta-version. We call 'nano-level' bugs those who are very close to the CPU/MMU (memory-related bugs like buffer overflow/underflow, double free, use after free, memory leaks, uninitialized data read, shared memory used outside semaphores/barriers, threads deadlocks, integers/floats/vectors overflow/errors, etc.)
How does REVEN work? (symbolic cpu, high-level algorithms, extendable API)
So far, we focused on building a general reverse-engineering product, and our early customers already use it for things like malware advanced reverse or complex software debugging (multi-processes with lot of application/kernel interactions).
In this article I will only write of dynamic analysis, even though REVEN can do its static counterpart and lot more.
REVEN analysis, in dynamic mode, starts from a virtual machine's state. That's to say, you run the environment you want to analyze in a standard VM, and you tag its state it at some point : you can tell REVEN what will trigger the tag, like a special hardware event (choose a keystroke or particular network event, etc.) or a static position in a binary you want to analyze. At the moment of the tag, we dump the VM's state but we keep it running and start recording a scenario in real time. This scenario comprises every event that occurs outside the CPU/RAM duo: human interactions (keyboard/mouse, plug usb device, etc.), hardware events or external events (communication with a remote server, hard drive, etc.).
Once the scenario you wanted to record is over (another configurable trigger), you can analyze it.
The initial processing
Depending on the duration of the scenario, it may take a few hours. For example, the analysis of loading a simple PDF by Acrobat Reader takes about two hours with the current version (October 2014) on a common desktop computer. We know how to greatly reduce this duration, we'll work on this later as it is not a priority for our customers for now.
During this processing, REVEN works on its own, you can go to sleep, or work on something else as REVEN system is still accessible and usable. Once the process ends, you can use it or save the REVEN state for a quick load later.
The human actions : use the force!
Ok, now we have a fully processed trace. That means that REVEN can display a lot of things, or answer a lot of our questions. We have two ways to interact with REVEN:
- use the SDK (Python API and soon the C++ API)
- use the dedicated GUI front-end : REVEN-Axion
REVEN is a server. Python scripts or REVEN-Axion front-end are clients. They may run in the same computer as REVEN, or in a distant one. You can even run several clients (i.e. many scripts & many Axion) at the same time, accessing the same REVEN server. By the way, REVEN is collaborative by design, you can have many humans/scripts working on the same project at the same time. I’ll blog about benefits of team collaboration during reverse process an other time.
So, we've recorded a full system trace at hardware level, it has been pre-processed, now we can access the full machine state for every instruction that was executed during the scenario.
Basic features :
- We can go back to any moment of the trace in a few milliseconds, browse registers, memory values, each system’s bit from that specific point in time is available, at physical level (not limited by software permissions).
- we can see whom, how and when a memory accessed occurred, for read, write or execute. Because we work at physical level, our Data History handles access from any virtual memory address that points to a physical memory, even from different processes or ring level.
- we can see and explore hardware events (page-faults, irq, pci mapped memories access, mmio, etc.) and the associated code (interrupts/exceptions handlers)
Using the above features, we built some higher level facilities, like :
- tracking dynamic strings (ascii, utf-8 & utf-16 ones)
- see used symbols and system calls
- full-featured data tainter (backward/forward, seamless ring3-ring0, etc.)
- OS semantic (symbols, track function’s arguments including structures, callstack, …)
- static visualization of code at every step of the trace, included code modifications that occurred in the run (interactive graphs of binaries (including drivers), functions, basic blocks, etc...)
- ... and a lot more :)
We will see some features in future articles. Customization and extend-ability
Those REVEN features are accessible by the REVEN-Axion client and through the Python API.
Furthermore, REVEN-Axion can be itself extended thanks to a built-in python+Qt interpreter that allows us (and you) to quickly build custom widgets or interact with the client.
We'll explain in later articles some of the example scripts / plugins available with REVEN by default (how to quickly detect and dump waves in a waved packed malware, how to use your REVEN as a backend debugger for gdb compatible front-end like IDA-pro and do forward/backward debugging from IDA, how to create a REVEN-Axion widget that shows you processes information in a few python lines, etc.)
Differences with existing products (The best one is the one that best fits YOUR needs)
Many other products are really great and we use tools like gdb, IDA-pro, Ollydbg, windbg or valgrind daily. We see REVEN/REVEN-Axion as a complement to those tools.
- REVEN and REVEN-Axion are products, from a real company. You can ask us for support, formation, expertise, tailored widgets or dedicated R&D around our products.
- client/server & collaborative: by design
- you can debug without a debugger
- forward / backward, instant access to every single instruction in the trace
- see the whole running system, including interactions with all other processes (i.e. discover unknown relations between your target application and non-related processes/modules, dive into IRQ/PageFault code, drivers, syscall etc)
- deterministic, non time dependent (bored of processes/network time-out when using breakpoints, or of buffers that are allocated elsewhere each time you run your usual debugger?)
- non intrusive: no 0xcc for breakpoint, neither debug registers use, no syscall hooks, no runtime instrumentation, no process alteration (which is the case with traditional debuggers). But note that the scenario is recorded in a VM for now (no guest tools/additions required by REVEN though).
- by design, not affected by anti-debugging tricks
- the scenario is only recorded once, you can do all the analysis in a different environment (in an isolated network for malware analysis, i.e. you can record the trace at your customer’s office and analyze it in yours, etc.)
- REVEN is based on a symbolic CPU. In the field of reverse-engineering and bug finding, having a symbolic engine gives us very powerful extra features compared to a numeric emulator whose purpose is to be fast. Symbolic execution is, well, slower, but can do a lot of things you cannot find elsewhere. We'll speak about some of them in futures articles.
How to get your own copy of REVEN?
By contacting our sales team directly: sales at tetrane.com / +33 339 250 045
Don't hesitate to request for a demo. As REVEN uses quite new concepts (many of our early-adopters were first lost without their good old habits) an interactive demo with Tetrane engineers is the best thing to start.
We offer the possibility to try REVEN on our own server (see it as SaaS), so rent REVEN for a limited amount of time.
Once you are convinced, you can order a ready-to-use REVEN appliance. We may sell the software alone in the future, but this distribution method is not privileged for now (we focus on the product features, user experience and integration with other hacker tools, not yet on seamless install process in unknown environment).
What we’ve learned:
- The dynamic mode of REVEN seems to be pretty cool, with instant access to every bit of data used during the trace
- You can do faster and deeper binaries analysis by using REVEN
- To extend its built-in features, REVEN provides Python API
- This article is not as innovative as REVEN is. Contact us to try the product ;)