Proguard是否足以通过渗透测试? [英] Is proguard enough to pass penetration testing?

查看:123
本文介绍了Proguard是否足以通过渗透测试?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

对于我们的android移动应用程序,我们必须选择一种混淆工具,以便我们的应用程序可以通过渗透测试用例. Proguard是否足以满足要求,还是我们应该使用Dexguard?

解决方案

混淆不足以通过渗透测试

适当的渗透测试将同时分析应用程序的静态和运行时行为,因此仅通过混淆就不会涵盖运行时行为

但是还要专门考虑将要进行的静态分析远不能保证安全

我将为您提供一个实际的简单示例,因为您建议的两种工具之间的差异已经在另一个答案中报告了

假设您有一个原始的,由以下内容提供的MainActivity:

protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);

    //...

    // lines for adding the shortcut in the home screen
    appPreferences = PreferenceManager.getDefaultSharedPreferences(this);
    isAppInstalled = appPreferences.getBoolean("isAppInstalled", false);

    if(isAppInstalled == false)
        addShortcut();

其中:

private void addShortcut() {
    //Adding shortcut

    // ...

    addIntent.setAction("com.android.launcher.action.INSTALL_SHORTCUT");
    // ...

    SharedPreferences.Editor editor = appPreferences.edit();
    editor.putBoolean("isAppInstalled", true);
    editor.commit();
}

这些是ProGuard混淆并通过在线Java反编译器

获取的coounterparts.

结论:

1)如您所见-尽管有一些混淆,但您仍处于攻击者可以轻松修改代码流的位置[例如,将if (!this.f2293p)转换为if (this.f2293p)]并容易理解,尽管经过了混淆,但修改应用程序中的值必须执行的操作.在这种情况下,这是一个简单的愚蠢的"isAppInstalled"首选项,但当然它可能更敏感,例如:

public boolean appIsPurchased(){
    return settings.getBoolean(keyPurchase,false);
}

存储未加密的共享首选项的PS(尤其是如果包含敏感数据的情况)是非常不好的做法,这只是出于演示目的的快速示例.在具有root用户权限的设备中,检索此文件等于浏览到系统文件夹并搜索xml文件

2)而且,一般而言,这种纯粹的混淆不会隐藏任何硬编码的内容.我们已经看到了:

editor.putBoolean("isAppInstalled", true);

转化为:

this.f2293p = this.f2292o.getBoolean("isAppInstalled", false);

另一个简单的示例可以是:

if (barcode.equals("123456")) {
    return "Hat";
}
if (barcode.equals("234567")) {
    return "Jumper";
}
if (barcode.equals("345678")) {
    return "Pants";
}
return "Troubles detecting the new item";

迷惑后出现:

return str.equals("123456") ? "Hat" : str.equals("234567") ? "Jumper" : str.equals("345678") ? "Pants" : "Troubles detecting the new item";

对于那些目的是破坏您纯粹被混淆的应用程序的人来说,这样的字符串是厚颜无耻的提示.例如,您的端点字符串将对任何人都可用

因此,您需要DexGuard之类的工具或其他能够产生比简单混淆更复杂的东西的商业解决方案

这是ProGuard +第三方安全工具的最终结果的一个示例[我没有DexGuard,我使用的另一种安全保护是通过拖放原始未受保护的apk来自动应用保护的.]

这是新的onCreate()方法:

protected void onCreate(Bundle bundle) {
    //...
    this.f1859o = PreferenceManager.getDefaultSharedPreferences(this);
    this.f1860p = this.f1859o.getBoolean(k09kcah9u6scvhh4ab059fbmtq.itg7jcg3c4din73t0cib8n7eau("~"), false);
    if (!this.f1860p) {
        m3099j();
    }
}

这是第二个示例,其中的硬编码字符串已被黑客视图完全隐藏:

public String m3101a(String str) {
    PrintStream printStream = System.out;
    StringBuilder stringBuilder = new StringBuilder();
    stringBuilder.append(k09kcah9u6scvhh4ab059fbmtq.itg7jcg3c4din73t0cib8n7eau("}}"));
    stringBuilder.append(str);
    String stringBuilder2 = stringBuilder.toString();
    return str.equals(k09kcah9u6scvhh4ab059fbmtq.itg7jcg3c4din73t0cib8n7eau("}|")) ? k09kcah9u6scvhh4ab059fbmtq.itg7jcg3c4din73t0cib8n7eau("}s") : str.equals(k09kcah9u6scvhh4ab059fbmtq.itg7jcg3c4din73t0cib8n7eau("}r")) ? k09kcah9u6scvhh4ab059fbmtq.itg7jcg3c4din73t0cib8n7eau("~{") : str.equals(k09kcah9u6scvhh4ab059fbmtq.itg7jcg3c4din73t0cib8n7eau("~z")) ? k09kcah9u6scvhh4ab059fbmtq.itg7jcg3c4din73t0cib8n7eau("~y") : k09kcah9u6scvhh4ab059fbmtq.itg7jcg3c4din73t0cib8n7eau("~x");
}

这是您通过渗透测试所需的防护等级

最后,作为一项附加的安全措施,这种专业工具也可能能够检测到受保护的不可读"代码中的修改,并且如果检测到对受保护版本的篡改操作,则可以停止执行该应用.而且,与简单的[但很漂亮] ProGuard不同,它可以对模拟器,植根设备和其他潜在危险场景进行检测

请注意如何通过这些步骤强化代码.没有人能100%安全地被黑客入侵.您的工作只会使工作变得尽可能困难,仅此而已

For our android mobile app , we have to choose an obfuscation tool so that our app will pass penetration test cases. Is Proguard enough for the same or we should use Dexguard?

解决方案

Obfuscation is NOT enough to pass a penetration test

A proper penetration test will analyze both static and runtime behavior of your app, so the runtime behavior will not be covered at all only through obfuscation

But also considering exclusively the static analysis that you will undergo you are far from being secure

I'll make you a practical easy example because the differences between the two tools you suggested are already reported in another answer

Say that you have an original unobfuscated MainActivity given by:

protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);

    //...

    // lines for adding the shortcut in the home screen
    appPreferences = PreferenceManager.getDefaultSharedPreferences(this);
    isAppInstalled = appPreferences.getBoolean("isAppInstalled", false);

    if(isAppInstalled == false)
        addShortcut();

where:

private void addShortcut() {
    //Adding shortcut

    // ...

    addIntent.setAction("com.android.launcher.action.INSTALL_SHORTCUT");
    // ...

    SharedPreferences.Editor editor = appPreferences.edit();
    editor.putBoolean("isAppInstalled", true);
    editor.commit();
}

These are the coounterparts obfuscated by ProGuard and taken through an online Java decompiler

Conclusions:

1) as you can see - despite the proguard obfuscation - you are in a position where an attacker can easily modify the code flow [e.g. turning if (!this.f2293p) into if (this.f2293p)] and easily understand what you have to do to modify a value in your app, despite obfuscation. In this case it was a simple stupid "isAppInstalled" preference but of course it could have been something more sensitive like:

public boolean appIsPurchased(){
    return settings.getBoolean(keyPurchase,false);
}

PS storing unencrypted Shared Preferences [especially if containing sensitive data] is a very bad practice, this is just a quick example for demonstrational purposes. In rooted devices retrieving this file is just equal to browse to a system folder and search for an xml file

2) moreover in general this pure obfuscation will not hide anything which is hardcoded. We already saw that:

editor.putBoolean("isAppInstalled", true);

was transformed in:

this.f2293p = this.f2292o.getBoolean("isAppInstalled", false);

Another simple example can be:

if (barcode.equals("123456")) {
    return "Hat";
}
if (barcode.equals("234567")) {
    return "Jumper";
}
if (barcode.equals("345678")) {
    return "Pants";
}
return "Troubles detecting the new item";

becoming after obfuscation:

return str.equals("123456") ? "Hat" : str.equals("234567") ? "Jumper" : str.equals("345678") ? "Pants" : "Troubles detecting the new item";

Such strings are cheeky hints for people whose purpose is breaking your purely obfuscated app. For example your endpoints strings would be available to anyone

So you need a tool like DexGuard or other commercial solutions able to produce something more complex than simple obfuscation

This is an example of the final result from ProGuard + third-party security tool [I do not have DexGuard, I use another one where protection is automatically applied through a drag'n'drop of the original unprotected apk]

This is the new onCreate() method:

protected void onCreate(Bundle bundle) {
    //...
    this.f1859o = PreferenceManager.getDefaultSharedPreferences(this);
    this.f1860p = this.f1859o.getBoolean(k09kcah9u6scvhh4ab059fbmtq.itg7jcg3c4din73t0cib8n7eau("~"), false);
    if (!this.f1860p) {
        m3099j();
    }
}

while this is the second example with hardcoded strings that have been totally hidden from the hacker view:

public String m3101a(String str) {
    PrintStream printStream = System.out;
    StringBuilder stringBuilder = new StringBuilder();
    stringBuilder.append(k09kcah9u6scvhh4ab059fbmtq.itg7jcg3c4din73t0cib8n7eau("}}"));
    stringBuilder.append(str);
    String stringBuilder2 = stringBuilder.toString();
    return str.equals(k09kcah9u6scvhh4ab059fbmtq.itg7jcg3c4din73t0cib8n7eau("}|")) ? k09kcah9u6scvhh4ab059fbmtq.itg7jcg3c4din73t0cib8n7eau("}s") : str.equals(k09kcah9u6scvhh4ab059fbmtq.itg7jcg3c4din73t0cib8n7eau("}r")) ? k09kcah9u6scvhh4ab059fbmtq.itg7jcg3c4din73t0cib8n7eau("~{") : str.equals(k09kcah9u6scvhh4ab059fbmtq.itg7jcg3c4din73t0cib8n7eau("~z")) ? k09kcah9u6scvhh4ab059fbmtq.itg7jcg3c4din73t0cib8n7eau("~y") : k09kcah9u6scvhh4ab059fbmtq.itg7jcg3c4din73t0cib8n7eau("~x");
}

This is the degree of protection you need to pass the penetration test

Finally - as an additional safety measure - this kind of professional tools may also able to detect modifications in the protected "unreadable" code and stop the app execution if a tampering action on the protected version is detected. And also, unlike the simple [but beautiful] ProGuard, implement the detection for emulators, rooted devices and other potentially dangerous scenarios

Please note how the code was hardened through these steps. No one is 100% safe from being hacked. Your job is only making it as difficult as possible, that's it

这篇关于Proguard是否足以通过渗透测试?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆