【问题标题】:Crashlytics: Is it possible to obfuscate native libraries and yet obtain symbolicated crash reports?Crashlytics:是否可以混淆原生库并获得符号化的崩溃报告?
【发布时间】:2021-09-28 22:52:17
【问题描述】:

我有一个用 kotlin 编写的带有 C++ 本机库 (.so) 的 android 应用程序。使用 crashlytics,我们能够混淆 kotlin 方法并获得符号化的崩溃报告,本机库是否可以使用相同的方法?目前,我必须选择使用 -fvisibility=hidden 构建 C++ 库并混淆我的函数名称(如果我运行 nm -gDC <.so library packaged with the apk> 则不可见),或者让我的函数名称在.so 文件并获取符号化的崩溃报告。我是否可以在我的应用程序中打包一个经过混淆的 .so 文件,然后获得本地库中崩溃的符号化崩溃报告?

This answer 似乎暗示我无法拥有一切。

【问题讨论】:

    标签: android c++ obfuscation crashlytics symbolicatecrash


    【解决方案1】:

    您不能将所有内容都保存在一个文件中,因此请使用两个:构建您的 APK,但维护两个单独的 .so 版本:一个完全符号化,您保留,另一个通过条带传递( 1) 命令,删除所有符号,与 APK 一起打包。这会删除符号,但不会更改地址。

    当您收到墓碑/崩溃报告时,它最初只会包含您库中的地址 - 因为在您的 APK 中运行时,它不会有任何符号。但是,您可以轻松解析地址,并且您可以构建一个小脚本通过 addr2line 传递墓碑并获得更有意义的见解。

    【讨论】:

    • 你知道这在实践中有效吗?确定剥离库和未剥离库中的地址相同吗?
    • 肯定是的,因为我们已经多次使用相同的技巧;否则不会建议的。这在 macOS 和 Windows 中也很常见,其中符号位于单独的文件中(分别为 .dSym 和 .pdb)。文件大小会有所不同,但符号表位于与可执行 (rx) 部分不同的部分中,因此该部分将是相同的。试试看:-)
    • 我认为这里的问题是不同的(请注意,我没有在我的问题中提到 strip),因为它是关于 -fvisibility=hidden:这是混淆不属于接口(基本上,除了 jni 接口之外的所有内容),它们不会被 strip 步骤隐藏。现在,如果一个构建两个版本的库还有待尝试,一个分发构建的-fvisibility=hidden 并剥离,一个符号化构建没有-fvisibility=hidden 并且不剥离:addr2line 将在带有来自分发的墓碑的符号化库上工作图书馆?
    • 该条删除所有内部符号,句号。任何未明确导出的内容都会被删除。但是,地址不会以任何方式改变。这就是为什么它可以在不考虑可见性标志的情况下工作。 addr2line 将通过获取二进制中的地址(实际上是偏移量,因为由于 ASLR 二进制可重定位)来工作,并解析最接近它的符号 + 一些偏移量。由于这两个库具有相同的文本段,因此它可以工作。这是各地非常普遍的做法。但是请注意,面对熟练的逆向工程师,仅仅删除符号并不是什么大问题。
    • 我不认为你是正确的。查看最终剥离的库,如果您首先编译 -fvisibility=hidden,会对 .so 文件中可见的函数名称数量产生重大影响。因此,所有内部符号都被删除是不正确的。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-02-12
    • 2011-09-09
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-05-08
    相关资源
    最近更新 更多