An architect’s day out with Reverse Code Engineering

Technically speaking; RCE, Malware analysis and architecting are orthogonal processes.

However over a period of time, I somehow started to see a lot of areas of Malware analysis where an Architect can contribute significantly towards improving the reverse engineering process. After all, reverse engineering is the process of reversing what an architect does. Isn’t it?

Let me take few scenarios. First one is a compelling case-study of Mobile Malware analysis and application of architects’ design principle investigation.


In this scenario, let’s talk about Mobile reverse engineering process. In the recent times, malware targeting mobile platform have gained significant media glare for the sensitivity associated with it. As it is the case with desktop threats, Mobile security researchers also have lots of frameworks/tools/scripts to process the bulk samples and similar variants of the same family.

Along with these existing tools and their metrics, what would also be a significant addition is the design principles employed in the mobile “app” under investigation.

Let’s consider adding a classification metric to the traditional classification with classification data extracted by analyzing the design patterns used in these mobile “apps”. For example a specific variant of the mobile malware family is designed with

  • 1st time through” Invitational design pattern &

  • Springboard” as its primary navigation pattern &

  • Expanding list” as its secondary navigation pattern &

  • Multi-step” pattern for data entry

Now, it can be easily observed on a huge data set that all the variants of this family has the same design patterns applied to them!


We all know that malware coded in Java is not new and there are millions (if not billion) of malware found in the wild which are written in Java and the number keeps growing. Security researchers have common automation utilities and frameworks to identify the similarities among the variants of same malware family, understanding relationships between different code constructs, decompiling the samples, etc.,

Along with the similarity metrics and identified binary patterns among these samples, there can be one more useful data point which would be common in most of the variants. And to see that metric, we need to put on our architect’s glasses and see through it.

Let us start with one of the several architectural viewpoints which can be used to create such metrics.

How about tracking these variants based on the relationship of their components (classes)! This needs processing a considerable set of malware samples and create a table of data and plot them based on the “is-a”, “has-a” and “uses-a” relationship and see how useful that would be.

Example: Sample A has three components where Component-1 “is-a” Applet and it “has-a” instance of Component-2 which “uses-a” instance of Component-3 which “is-a” serializable implementation.

Since, the exact names of these components are generally polymorphic; it may not be worth to plot these data using the names instead by numbered Components. The components number can be maintained with reference of other code metrics such as Cyclomatic complexity, member counts, etc.,

Hope, I have written this post in a manner such that the concept is made clear. Feel free to comment/share your views on this!

Happy reading!


Tags: ,

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: