Powering Quark-Engine with Yara.

[VivekChoudhary128]

Continuing the issue #313 here.
I've been looking into the idea of powering Quark with Yara, and after doing some RnD here and there my first thought was, "Since Quark does more than just string matching, how are we planning to do the logical flow using Yara? "

Here were the couple of ideas that I had -

1) Yara file as a string variable file: in this case we read .yar file as a normal file, extracting the string and passing them to the already written Quark logic, something like below -

rule Malware : SENDSMS
{
        meta:
        description = "Send Location via SMS"

        strings:
                $permission_1 = "android.permission.SEND_SMS"
                $permission_2 = "android.permission.ACCESS_COARSE_LOCATION",
                $permission_3 = "android.permission.ACCESS_FINE_LOCATION"
                $api_class_1 = "Landroid/telephony/TelephonyManager",
                $api_method_1 = "getCellLocation"
                $api_discriptor_1 = "()Landroid/telephony/CellLocation;"
                ...
                ..
                // etc vars
        ],

        condition:
                true
}

PROS -

1. This can be implemented easily since everything will be same in a .yar file like in .json file.
2. This make sure that the format of yara rule that the user will provide is exactly what our application needs.
3. Easy intergration with other apps. Since, users will know the exact format of yara file that Quark requires, they can easily port this functionality to their code flow with minimal possibilities of error.

CONS -

1. Since yara file will be just act like a data holder. We may not be able to use much of yara functionality, like string matching using of other modules (if needed).

2) Keeping the format of Quark Rules and Yara rules similar: In this case we just do the permission check logic (Step 1 of Quark flow) in Yara compiling and and send the rest of the strings variables which define the native classes to already written Quark Logic (something like first point).

import "androguard"

rule Malware : SENDSMS
{
        meta:
        description = "Send Location via SMS"

        strings:
                $api_class_1 = "Landroid/telephony/TelephonyManager",
                $api_method_1 = "getCellLocation"
                $api_discriptor_1 = "()Landroid/telephony/CellLocation;"
                ...
                ..
                // etc vars
        ],

        condition:
                androguard.permission(/android.permission.SEND_SMS/)
                and androguard.permission(/android.permission.ACCESS_COARSE_LOCATION/)
                and androguard.permission(/android.permission.ACCESS_FINE_LOCATION/)
}

PROS and CONS are quite similar to first idea.

3) Writing the whole logic of Quark in Yara Rules: Doing everything, from matching permissions to finding the functions and their order of calling in Yara rules.
4) Porting the whole logic of Quark-Engine as a Yara module: Prividing Quark as an Yara module, re-writing the whole logic in C by using using Yara APIs to integrate the logic.

PROS -

1. Usability will be more dynamic by the users, since the logic will be accessible in a modular way.
2. Will actually use Yara features.

more RnD needed on rest of pros..

CONS -

1. Requires to port the logical codebase to C (since yara module are written in C).
2. Effort and time are more required.
3. Managing a whole different codebase.

what are your thoughts on this? @18z @haeter525 @pulorsok

[haeter525]

Hi @PaulNicolasHunter.
According to your thought, you would like to implement the analysis logic of Quark by using YARA.
However, since the GSoC idea in #313 is redesigning Quark rules, I don't see the need to do this.

Could you give us more details on why it helps us achieve that idea?
Thanks.

[VivekChoudhary128]

@haeter525, What my understanding is that, a same rule written in yara and in json has two different meanings in terms of usability.

We know that we use a json file by reading it with python, parsing it with json module and selecting the keys and finally passing them to our python logic.
However, a yara file is quite different in terms of usability, unlike json, we compile it and use it to match strings, either by passing it in yara command line tool or by using python-yara.

so my question is that how are we planning to utilize the string maching way of yara and incorporate that in Quark ?

[haeter525]

@PaulNicolasHunter. Thanks for the explanation. I understand. Implementing the whole analysis logic is one of our options here.
For a better discussion, could you list the pros and cons of those four ideas? And which one do you suggest the most?

[VivekChoudhary128]

@haeter525 I believe that if we go with the first 2 options, then we may not be even able to utilize power of Yara, because if we are thinking to use yara just like a file which just stores string variables like json, then I don't think it's much of a use, furthermore it'd be hard to just read those strings from the yara file.
That is my understanding on how are currently planning to use yara for Quark correct me if I'm wrong.

Coming to, 4th point requires a quite lot of effort but I think that should be a way if we are aiming to increase usability of Quark from yara standpoint.
please, let me know what you think.

[haeter525]

Hi @PaulNicolasHunter . Here are quick questions.

1. Since you suggest the last option the most, could you provide an example for it? Also,
2. What is the effort the last option needs? Why does it increase the usability of Quark? Please describe your idea as specific as possible. In this way, we can understand it better.

Besides, I suggest you organize the pros and cons into a list to make the concepts clear and easy to read.

[VivekChoudhary128]

Since you suggest the last option the most, could you provide an example for it

@haeter525 Currently I haven't prepared any sort of POC for the 4th idea, moreover, I'm trying to think out loud and understand what the current plan of action of the team on increasing the usablilty of Quark using Yara. I sound like I'm pressing on 4th because imho I feel that this is the way using which we'll be able to utilize Yara's functionality more, though it seem far less feasible to do so. Furthermore, It's also unclear to me if the team already has any prior thoughts on how to go through this GSOC idea.

What is the effort the last option needs? Why does it increase the usability of Quark? Please describe your idea as specific as possible.

I haven't calculated the exact metrics of the effort required, because before doing that I wanted to just wanted to know about current scenerio that you have in mind.

also, I have added pros and cons from the top of my head in my first comment.

[pulorsok]

Hi @PaulNicolasHunter,
I suggest you describe how the idea benefits Quark, which is the first thing we would like to know about your idea.
And I also suggest you describe how you plan to implement it specifically, which can help us understand your idea quickly.

The benefit of your idea and your implementation plan is very important in the GSoC proposal.

[VivekChoudhary128]

@pulorsok actually, currently I'm aiming to get advice from you guys on how we should proceed to use Yara with Quark. I ended up sounding like pressing on 4th idea because I felt that way we may use Yara's functionality more, though I didn't dig deeper on how much feasible it might be.

I've added pros and cons of each idea on the top.