[Discussion] Should we add anti-cheat and anti-frida rules?

[CalebFenton]

@apkunpacker has proposed adding rules for detecting anti-cheat systems and anti-frida techniques. I'm generally in favor of supporting this in apkid since it falls in line with the general purpose of apkid as "peid for android" or a tool that can give you intelligence about what an android artifact (apk, dex, so) does.

The three main personas I see using apkid are:

1. malware analysts
2. data scientists
3. compliance / auditors

I could see personas 2 and 3 getting value from anti-cheat and anti-frida rules.

One downside of adding these rules is increased scanning cost. However, if the rules are fairly sane the cost shouldn't be too onerous. If people complain, we could add flags to disable certain rule types / tags.

There are some open questions we can figure out during review:

• Should yara folder structure be reorganized?
• What new tags should be added?

What does everyone else think? @enovella @strazzere

[CalebFenton]

For context, there's already a PR: https://github.com/rednaga/APKiD/pull/299 And at least one issue: https://github.com/rednaga/APKiD/issues/297

[apkunpacker]

For context, there's already a PR: #299 And at least one issue: #297

and for Anti-Cheat and anti frida samples , first i gone for koodous to confirm if samples exist in good quantity or not and yeah many samples exist AntiCheat - https://koodous.com/rules/Pm3xWdoa4BGRoZ5e AntiFrida - https://koodous.com/rules/z3RqYd89Qk1VrL80

[strazzere]

Perhaps we should add a switch for choosing which tags the user wants to utilize?

This way we can add more, have a "default" level of tags included in a base search, then the ability for folks to further tune based on their wants and needs. This actually lines up with PEiD in terms of fast/slow heuristics.

[enovella]

Hi all,

I really like the idea of "default" level tags. In fact, I've been adding my own rules in APKiD for several years in a personal folder to avoid delaying default scans.

Regarding:

1. Anti-cheats - Are we adding a new anticheat.yara or still using the tag protector?
2. Anti-Frida - This is always difficult to fingerprint. Actually, in @apkunpacker's rule, any app repackaged with the Frida Gadget will match and not necessarily this app does protections against Frida hooking.

[atlantis0]

Hi,

Curious to see how the Anti-Frida rule be implemented. As suggested by @enovella, the above rule is susceptible to false positives. Can samples with frida-gadget be rejected ?

[strazzere]

I feel that we should strive for non-string-based-only rules for these complex type of things. Strings only will always lead to false positive based issues.

The general idea is that the strings can help point out an overarching umbrella of things, if people want that. Eg. GADGET. Sure something is mentioning gadget, this could be good, bad, your own doing, etc. If we can fingerprint is this the /actual/ frida gadget vs checking for a gadget? That is where the powerful detection is.

[apkunpacker]

I feel that we should strive for non-string-based-only rules for these complex type of things. Strings only will always lead to false positive based issues.

The general idea is that the strings can help point out an overarching umbrella of things, if people want that. Eg. GADGET. Sure something is mentioning gadget, this could be good, bad, your own doing, etc. If we can fingerprint is this the /actual/ frida gadget vs checking for a gadget? That is where the powerful detection is.

i guess we can check for dex compiler along with rule so if dexlib2 is there , it most likely that dex is tampered to insert gadget . But still 2 issue -

1. some app genuinely built with dexlib2
2. inserted gadget with lief doesn't fit the rule

[apkunpacker]

I feel that we should strive for non-string-based-only rules for these complex type of things. Strings only will always lead to false positive based issues.

The general idea is that the strings can help point out an overarching umbrella of things, if people want that. Eg. GADGET. Sure something is mentioning gadget, this could be good, bad, your own doing, etc. If we can fingerprint is this the /actual/ frida gadget vs checking for a gadget? That is where the powerful detection is.

@strazzere @atlantis0 @CalebFenton @enovella how about this rule https://koodous.com/rules/20R5aGARB7OZXLjy

rule anti-frida : protector
{
        meta:
          description = "Anti Frida Checks"
          author = "ApkUnpacker"
          date = "2022/04/27"          

        strings:
          $include1  = "linjector"          
          $include2  = "libfrida"
          $include3  = "gum-js-loop"
          $include4  = "frida-agent"
          $include5  = "frida-server"
          $include6  = "frida-helper"
          $include7  = "GADGET"
          $include8  = "re.frida.server"
          $include9  = "frida-agent-32.so"
          $include10 = "frida-agent-64.so"
          $include11 = "frida_agent_main"
          $exclude1  = "FRIDA_SCTP_CONNECTION_STATE_CREATED"
          $exclude2  = "FridaGadgetLocation"
          $exclude3  = "FRIDA_GADGET_SCRIPT_CHANGE_BEHAVIOR_IGNORE"
          $exclude4  = "re.frida.Error.Transport"
          $exclude5  = "FridaGadgetScriptInteraction"
          $exclude6  = "FRIDA_SCRIPT_RUNTIME_QJS"
          $exclude7  = "FRIDA_SCRIPT_RUNTIME_V8"

        condition:
           is_apk and 2 of ($include*) and not any of ($exclude*)
}

[strazzere]

Can you give an example of what an application is actually doing to detect frida?

Is it literally just looking for all the strings you have included in the include section?

If I was to make a rule like this, I would take a subset of these APKs you have identified and looked to see if they are all using a plugin / snippet / etc and reverse that. Then maybe we can identify "this technique is used in admob v2.3 by everyone" and can then be fingerprinted.

That way you now are detecting a set of techniques, used by a group/library -- rather than a random list of frida like things that may or may not be utilized for detecting anything.

[apkunpacker]

Can you give an example of what an application is actually doing to detect frida?

Is it literally just looking for all the strings you have included in the include section?

If I was to make a rule like this, I would take a subset of these APKs you have identified and looked to see if they are all using a plugin / snippet / etc and reverse that. Then maybe we can identify "this technique is used in admob v2.3 by everyone" and can then be fingerprinted.

That way you now are detecting a set of techniques, used by a group/library -- rather than a random list of frida like things that may or may not be utilized for detecting anything.

as you said we need rule which can differentiate between actual frida detection and gadget so with above gadget is excluded . most probably match is hit to find use of repo https://github.com/darvincisec/DetectFrida specifically those few lines from https://github.com/darvincisec/DetectFrida/blob/master/app/src/main/c/native-lib.c#L26 but not limited to that repo only , it should match with other app also which have those strings and as far as i tested target app with those strings are crashed if used with frida . if planning for for more robust rule then we can pick up from dexguard native rule also which have sure that app is looking frida in maps and from Promon Shield rule also as all of promon shield apk have frida detection inbuilt

[yoshimo]

I think apkid should clearly mark frida detection attempts in its analysis.

[enovella]

The previous rule is very error-prone and it could give us lots of false positives. Check @strazzere's comment above and start profiling a bunch of apps with Frida detection. Find similarities and uniqueness in these apps and write stronger rules not only based on strings.