1.10款优秀的Android逆向工程工具
2.Android Adb 源码分析(一)
3.Android NDK Tombstone/Crash 分析
4.Android代码静态检查（lint、Checkstyle、ktlint、Detekt）
5.Android 7.0 popupWindow update()的坑
6.AndroidStudio运行Flutter时卡在Running ‘gradle assembleDebug...‘问题解决[2023-12-13更新]

10款优秀的Android逆向工程工具

       在探索Android逆向工程的世界里，众多工具为开发者和安全专家提供了强大的支持。这里有款值得一提的xampp源码安装工具，它们各具特色，帮助我们深入理解APK文件和Dalvik虚拟机的工作原理：

       1SMALI/BAKSMALI：作为Dalvik虚拟机的得力助手，它能反编译和回编译classes.dex，语法类似于Jasmin/dedexer，且支持注解和调试信息等。

       ANDBUG：基于jdwp协议的Andbug，作为安卓安全神器，无需源代码即可进行调试，其Python封装和脚本断点机制使其极具灵活性。

       ANDROGUARD：专为Android逆向工程设计，提供恶意软件分析功能，使用DAD反编译器，支持DEX、ODEX和APK等文件处理。

       APKTOOL：Google官方提供的APK编译工具，可反编译与重构APK，便于资源修改和调试。

       AFE：用于安全漏洞检测和恶意软件创建的AFE项目，包含AFE和AFEServer两部分，支持自动化操作和命令行界面。

       Dedexer：开源的dex文件反编译工具，方便查看Java源代码结构。

       ANDROID OPENDEBUG：通过Cydia Substrate进行设备监控，Linux源码开源协议但仅限测试设备。

       Dare：提供apk反编译为JavaClass文件的功能，适用于Linux和Mac OS X。

       FINO：Android动态分析工具，适用于动态分析场景。

       Enjarify：Google出品的Enjarify，将Dalvik字节码转为Java字节码，兼容性与效率出色。

       尽管现在java层更多使用ak和apktool等工具，而对于底层分析，IDA和Winhex则是不二之选。对于Android逆向工程需求，可以根据具体任务选择合适的工具。

Android Adb 源码分析(一)

       面对Android项目的调试困境，我们的团队在项目临近量产阶段，将userdebug版本切换为了user版本，并对selinux权限进行了调整。然而，这一转变却带来了大量的bug，日志文件在/data/logs/目录下，因为权限问题无法正常pull出来，导致问题定位变得异常困难。面对这一挑战，我们尝试了两种解决方案。

       首先，我们尝试修改data目录的权限，使之成为system用户，以期绕过权限限制，网站收集视频源码然而数据目录下的logs文件仍保留了root权限，因此获取日志依然需要root权限，这并未解决问题。随后，我们找到了一个相对安全的解决办法——通过adb命令的后门机制，将获取root权限的命令修改为adb aaa.bbb.ccc.root。这一做法在一定程度上增加了后门的隐蔽性，避免了被窃取，同时对日常开发的影响也降至最低。

       在解决这一问题的过程中，我们对Android ADB的相关知识有了更深入的理解。ADB是Android系统中用于调试的工具，它主要由三部分构成：adb client、adb service和adb daemon。其中，adb client运行于主机端，提供了命令接口；adb service作为一个后台进程，位于主机端；adb daemon则是运行于设备端（实际机器或模拟器）的守护进程。这三个组件共同构成了ADB工具的完整框架，且它们的代码主要来源于system/core/adb目录，用户可以在此目录下找到adb及adbd的源代码。

       为了实现解决方案二，我们对adb的代码进行了修改，并通过Android SDK进行编译。具体步骤包括在Windows环境下编译生成adb.exe，以及在设备端编译adbd服务。需要注意的是，在进行编译前，溯源码燕窝真伪需要先建立Android的编译环境。经过对ADB各部分关系及源代码结构的梳理，我们对ADB有了更深入的理解。

       在后续的开发过程中，我们将继续深入研究ADB代码，尤其是关于如何实现root权限的功能。如果大家觉得我们的分享有价值，欢迎关注我们的微信公众号“嵌入式Linux”，一起探索更多关于Android调试的技巧与知识。

Android NDK Tombstone/Crash 分析

       程序员在调试Bug的过程中，访问非法内存是最让人头疼的问题。调试程序Bug通常有三种方法：那么如何调试引发Crash的NDK程序呢？

       幸运的是，Google早已预见到我们编写的NDK代码可能存在缺陷。当NDK程序发生Crash时，会在/data/tombstones/路径下生成记录Crash信息的文件tombstone_xx。同时，Google在NDK包中也提供了一系列调试工具，如addr2line、objdump、ndk-stack。

       在介绍Tombstone之前，我们先补充一下Linux信号机制的相关知识。信号机制是Linux进程间通信的一种重要方式，用于正常的进程间通信和同步，以及监控系统异常及中断。当应用程序运行异常时，Linux内核会产生错误信号并通知当前进程。当前进程在接收到该错误信号后，种树赚钱App源码可以有三种不同的处理方式。

       当Linux应用程序在执行时发生严重错误，一般会导致程序crash。Linux专门提供了一类crash信号，程序接收到此类信号时，缺省操作是将crash的现场信息记录到core文件，然后终止进程。

       什么是Tombstone？Android Native程序本质上就是一个Linux程序，当它在执行时发生严重错误，也会导致程序crash，然后产生一个记录crash的现场信息的文件，在Android系统中就是tombstone文件。

       Tombstone文件位于路径/data/tombstones/下，它记录了死亡进程的基本信息、死亡的地址以及死亡时的现场信息。

       分析出现Crash的原因和代码位置最重要的就是分析这个tombstone文件。tombstone文件主要由以下几部分组成：Build fingerprint、Crashed process and PIDs、Terminated signal and fault address、CPU registers、Call stack、Stack content of each call。

       Crashed process and PIDs信息表示Crash掉进程的基本信息，包括进程号、线程号等。Terminated signal and fault address信息表示程序因为什么信号导致了Crash以及出现错误的地址。Call Stack信息记录了程序在Crash前的函数调用关系以及当前正在执行函数的信息。

       在分析tombstone文件时，我们主要关注Crashed process and PIDs、Terminated signal and fault address和Call stack部分。

       addr2line是NDK中用来获得指定动态链接库文件或者可执行文件中指定地址对应的源代码信息的工具。ndk-stack能自动分析tombstone文件，将崩溃时的调用内存地址和C++代码一行一行对应起来。

       总结来说，Android NDK程序的系统调试并不复杂，只要掌握了正确的方法，了解Tombstone文件中关键信息的含义，学会使用addr2line和ndk_stack这两个超级方便的工具，就可以快速定位到导致NDK程序Crash的Bug。但具体的Bug还需要进一步根据业务逻辑来分析代码。

Android代码静态检查（lint、Checkstyle、ktlint、Detekt）

       在Android项目开发中，静态代码检查工具如lint、Checkstyle、ktlint和Detekt扮演着关键角色。它们通过在编译阶段自动检测代码缺陷，节省时间和资源，提升软件质量与可靠性，节省了开发和测试成本。Android项目主要使用Kotlin和Java，因此这些工具都需兼容这两种语言。

       Lint是Android Studio内置的工具，它能检测+种潜在问题，覆盖Manifest、XML、Java、Kotlin等文件类型，通过LOMBOK-AST、PSI和UAST分析器进行深度分析。在build.gradle中添加相应配置后，执行lint命令，可在build/reports/lint/lint.html中查看详细结果。

       CheckStyle专用于Java代码的编码规范检查，是Gradle的内置插件，它对比源码与编码约定，以HTML或XML格式显示结果。尽管自带+规则，但不支持自定义规则。在build.gradle中配置后，preBuild阶段会执行CheckStyle检查。

       对于Kotlin的代码检查，Detekt和ktlint是两个选择。Detekt支持规则定制，输出HTML格式，阅读体验较好，而ktlint规则不可定制。两者可通过命令行结合Git钩子进行代码提交前的检查。

       尽管团队和项目的代码规范各异，但静态代码检查工具在确保代码质量、发现性能问题和隐藏bug方面必不可少。对于高质量项目，使用这些工具是提升开发效率和软件质量的重要手段。

Android 7.0 popupWindow update()的坑

       åœ¨Android 7.0手机上发现popupWindow 位置不对，后来经过排查，发现Android 7.0源码上update()有bug,会把位置固定成顶部。 解决方案：在Android 7.0手机上不使用update()方法。

        if (Build.VERSION.SDK_INT != Build.VERSION_CODES.N) { //Android 7.0手机调用PopupWindow update 会导致位置错乱

        popupWindow.update();

        }

        这个bug只出现在Android 7.0上。

AndroidStudio运行Flutter时卡在Running ‘gradle assembleDebug...‘问题解决[--更新]

       在学习Flutter框架和Dart语言过程中，遇到项目运行时卡在"Running Gradle task 'assembleDebug'..."的问题。查阅资料得知，此现象通常因网络限制，特别是缺少外网环境所致。针对此问题，我总结了以下解决步骤，希望对遇到同样困扰的开发者有所帮助。

       首先，确保已按照相关博客设置Flutter和Dart的环境，并开启AndroidStudio虚拟移动设备，尝试运行官方示例代码。

       若卡在"Running Gradle task 'assembleDebug'..."，则需调整本地Gradle配置以引入国内镜像源，以提升构建速度并解决网络问题。

       步骤如下：

       1. 打开项目A的Gradle Scripts/gradle-wrapper.properties，记录当前Gradle版本号。

       2. 接着，打开项目B的android/gradle/wrapper/gradle-wrapper.properties文件，替换distributionUrl为腾讯镜像源链接，确保链接中的版本号与项目A记录的版本号一致。

       3. 修改项目B的android/build.gradle文件，在buildscript和allprojects块中添加指定的maven源代码，确保其位于google()和mavenCentral()之前。

       4. 执行gradlew指令，依次输入相关命令。如果遇到执行失败的情况，需进一步排查错误。

       针对可能出现的错误，如"BUG! exception in phase 'semantic analysis'"，这通常与JDK版本不兼容有关。解决方法是根据官方提供的兼容版本卸载并重新安装JDK，推荐参考相关博客进行操作。

       完成上述步骤后，再次执行构建操作，预计构建速度将明显提升，运行项目时卡顿问题也将得到解决。

       通过调整本地Gradle配置引入国内镜像源，以及解决JDK版本不兼容的问题，有效解决了AndroidStudio运行Flutter时卡在"Running Gradle task 'assembleDebug'..."的现象，优化了开发体验。

安卓被曝严重BUG是怎么回事_安卓被曝严重BUG相关介绍

       相信最近很多的小伙伴可能都已经听说了我们的安卓最近出大事了，这个很严重的BUG给我们的生活隐私带来了极大的威胁，而我们很多的小伙伴对这个可能都还不太了解，接下来咖绿茵小编给大家介绍一下。

安卓被曝严重BUG是怎么回事

       据以色列安全公司Checkmarx曝光，安卓系统存在一个CVE--漏洞，该漏洞允许流氓APP远程获取摄像头、麦克风和GPS位置数据的输入。这一行为十分敏感，所以安卓开源项目特别设置了一组权限，要求任何APP都必须先向用户请求，获得批准才能调用。

       该安全公司表示，首次发现漏洞时，研究团队确保它们可以重现轻松利用它们的过程。确认后，Checkmarx研究小组将发现的结果负责地通知谷歌。 他们直接与谷歌合作，通知了我们的研究团队，并确认了除了Pixel系列手机外也可能出现这一漏洞。谷歌告知我们的研究团队，其影响要大得多，并扩展到了更广泛的Android生态系统中，三星等其他供应商也承认这些缺陷也影响了他们的Camera应用，并开始采取缓解措施。

       目前三星和谷歌都已经发布补丁来修复以上提到的漏洞，谷歌还表示已经向其他合作伙伴发布了一个补丁。但是，Checkmarx创建了一个攻击场景，利用“存储访问”权限的漏洞，不仅可以调用存储在手机中的照片和视频数据，还获得了随时调用摄像头的权限。由于存储访问相对来说没那么敏感，大多数用户在授权方面并不在意，这就给了黑客可乘之机。

       Checkmarx安全团队表示，这种漏洞主要利用谷歌相机APP，同时三星的相机应用也存在相同状况，因此这2大厂商最有可能受影响。他们称，这一漏洞会威胁“数以亿计”的用户。