深入扒一扒安卓中的ADB命令

Posted 2023-04-05

参考技术A

做过安卓开发的朋友或多或少都遇到过让人厌恶的类似于“could not read ok from ADB Server”的错误。产生这个错误的原因可能多种多样，每次遇到问题的时候，可能大部分人都和我一样，去google一下这个问题别人是如何解决的。假设一下子找到解决了，就放过，下次在遇到的时候同样的再去google一下就好了。但是，这样不是正确的治学态度，为此孔祥子决定去扒一扒！

如下，是我在发现android studio连接不上手机的时候，尝试去启动一个adb server，但是失败了。

<pre>

根据问题提示，5037端口被占用了。下面就来看看到底是哪一个端口被占用。

<pre>

C:\\Users\\zxy>netstat -ano | findstr "5037"
TCP 127.0.0.1:5037 0.0.0.0:0 LISTENING 7912
TCP 127.0.0.1:5037 127.0.0.1:50025 ESTABLISHED 7912
TCP 127.0.0.1:5037 127.0.0.1:56501 ESTABLISHED 7912
TCP 127.0.0.1:50025 127.0.0.1:5037 ESTABLISHED 7120
TCP 127.0.0.1:56501 127.0.0.1:5037 ESTABLISHED 1264
</pre>

果然，5037被进程id为7912的进程占用了。顺藤摸瓜，看看到底什么进程捣的鬼，
<pre>
C:\\Users\\zxy>tasklist | findstr "7912"
romaster_daemon.exe 7912 Console 1 3,024 K
</pre>

看到了吗，是这个进程romaster_daemon.exe ，好了，到此为止找出来是哪一个程序了，下面打开任务管理器，kill掉就可以了。

Android adb（Android Debug Bridge） 是一个通用命令行工具，其允许您与模拟器实例或连接的 Android 设备进行通信。它可为各种设备操作提供便利，如安装和调试应用，并提供对 Unix shell（可用来在模拟器或连接的设备上运行各种命令）的访问。

该工具作为一个客户端-服务器程序，包括三个组件：
客户端（adb client） ，该组件发送命令。客户端在开发计算机上运行。可以通过发出 adb 命令从命令行终端调用客户端。

这里说的客户端，其实包含很广泛。例如我们在命令行窗口运行一个adb命令，其实就是一个adb客户端。还有，我们在android studio中通过点击运行或者调试按钮，app就安装到手机里面了，这个也可以看做是adb客户端。对应的后台进程名称 根据运行的程序的不同而不同。

后台程序 ，该组件在设备上运行命令。后台程序在每个模拟器或设备实例上作为后台进程运行。
也就说，开发者测试手机或者模拟器上运行的后台进程，负责接收命令，并运行命令。这个名字对应应该是adbd

具体如下

服务端 ，该组件管理客户端和后台程序之间的通信。服务器在开发计算机上作为后台进程运行。
您可以在 android_sdk/platform-tools/ 中找到 adb 工具
这个是在开发者自己的电脑上，运行的旨在管理adb客户端和手机端的后台程序通信的一个管理程序。

具体流程如下

启动一个 adb 客户端时，此客户端首先检查是否有已运行的 adb 服务器进程。如果没有，它将启动服务器进程。当服务器启动时，它与本地 TCP 端口 5037 绑定，并侦听从 adb 客户端发送的命令—所有 adb 客户端均使用端口 5037 与 adb 服务器通信。

然后，服务器设置与所有运行的模拟器/设备实例的连接。它通过扫描 5555 到 5585 之间（模拟器/设备使用的范围）的奇数号端口查找模拟器/设备实例。服务器一旦发现 adb 后台程序，它将设置与该端口的连接。请注意，每个模拟器/设备实例将获取一对按顺序排列的端口 ， 这些端口包括用于控制台连接的偶数号端口和用于 adb 连接的奇数号端口。例如：

模拟器 1，控制台：5554
模拟器 1，adb：5555
模拟器 2，控制台：5556
模拟器 2，adb：5557
以此类推...

如上所示，在端口 5555 与 adb 连接的模拟器实例与侦听端口 5554 的控制台的实例相同。

注意 ，这里所说的端口都是开发者电脑上的端口。

我的理解，偶数端口用来实际的数据传输。奇数端口用来发送控制命令和连接用的，例如调试。（如果不正确请指出）

当服务器已设置与所有模拟器实例的连接后，您可以使用 adb 命令访问这些实例。由于服务器管理与模拟器/设备实例的连接，并处理来自多个 adb 客户端的命令，因此，您可以从任意客户端（或从某个脚本）控制任意模拟器/设备实例。

解读一下
注意：上图中的标识为黄色的区域的进程为后台守护进程。
Adb Server运行在开发者电脑上，任何adb client都要等待这个运行起来之后才能做后续的工作。电脑上的android studio或者eclipse等一些adb client和它交互。一旦adb client的命令被发送到手机中，并且被手机中的adbd接收之后，才能和手机交互。

然后在看一张更详细的图

这个图，详细的解释了我运行adb命令中的详细细节。

关于adb的详细命令可以参考： http://adbshell.com/commands 这个网站详。

看了之后，对于前面的5037被占用，导致无法连接手机的原因，我想，我们应该有了更深层次的理解。同时对于其他情况的不能连接手机，我们下次就会有了自己的思考了。

扒一扒基于词法分析和语法分析的SQL注入攻击检测

周末了，又到了一星期中的美好时刻，因为期待，因为渲染在时光中的慵散。本周，Black Hat大会，应该是安全界中的大事件。

这不，经过一番紧锣密鼓的搜罗，发现了一篇关于Black Hat上关于国人的新闻“Black Hat｜长亭科技：防SQL注入利器－－SQLChop”。

技术背景

咦，SQL注入，老生常谈了，不禁有些许唏嘘。先来看看，报道中对SQLChop的介绍：

调整思路后，长亭科技将目光放在了传统的编译原理方法上。在BlackHat2012会议中提出的libinjection首先考虑到了词法分析， 但是其结果仍存在较大的改进空间。经过技术人员不懈的努力，在多方调研和尝试后确立了在词法分析的基础上再作了语法分析的思路。

研究解决了包括输入数据的编码多样性，词法分析需要考虑语句拼接以及语法分析要覆盖SQL庞大的语法集在内的各种技术难题，最后研发出了无规则的基于词法分析和语法分析的SQL注入攻击检测与防御引擎——SQLChop。SQLChop在检测准确率和召回率两方面相比传统的WAF都有了质的飞越，真正使SQL注入防御技术上了一个新的台阶。

我想说的是，国内应该已经有几家安全厂商早已使用了基于词法语法分析的SQL防注入引擎。这样做的好处就是，再也不用写那些千变万化的规则了，而且漏报的情况很少，相对的，如何处理误报，才是要好好斟酌的事。

说白了，用词法语法分析SQL注入，是一种大而全的比较投机的方法，精确度和传统的规则匹配，还是有一定差距的。但是他可以检测出未知的sql注入。至于所谓的技术难题，我也来说道说道。

词法语法分析SQL注入的一些环节

首先，需要一个HTTP协议解析引擎，将url，post，cookie等相关的参数进行解析，还原成用户输入的数据。如：

www.baidu.com/index.asp?id=123&name=admin

对于id，name所代表的含义我们并不关心，我只要解析后用户所输入的数据，如123，admin。

然后，我需要对这些数据进行拼接。

Select * from table where id = XXX

XXX就是所谓的用户输入的数据。Select * from table where id =，设置成固定模板即可，它存在的价值，只是为了语法分析器能够进行分析而已。至于id后面的参数是否需要添加引号等细节问题，就不一一说明了。

当然，每个参数都需要拼接成一条完整的SQL语句。如上述的url中含有两个参数，id和name，那么我们就需要拼接成两条sql语句，分别进行检测了。

现在我们就有了完整的sql语句了。接下来，我们就要进行词法语法分析了，用啥工具好呢，首先想到的当然是flex&bison了。

但是，难道要我们自己去实现一套sql语句的语法分析，Oh，No，别忘了，我们有更趁手的武器，那就是开源的mysql啊！

Mysql使用了yacc作为语法分析，具体的实现，看mysql server的代码就可以了。Mysql的关键字token在sql/lex.h中也有定义。

有了词法分析，我们就可以统计token的数量，尤其是我们认为的恶意的token。然后通过词法分析中得到的token的数量，作为判断是否是sql注入的凭证之一。

有了语法分析，我们再也不用关心各种变形了，编码的多样性对语法分析器来说，已经无关紧要。因为我们使用的是原生的语法分析器，无论如何变形，只要语法分析器可以通过，那么他就是一条有效的sql语句。

有人会问，你现在只是针对mysql的语法啊，其他的数据库，如MSsql，oracle等并不能愉快的工作。当然，你不能完全的借鉴mysql server的代码吧，至少需要你自己去做一些完善吧，把mysql不兼容的token加入其中，添加一些其他数据库的语法规则，这应该也属于一个关键点吧。至于如何去完善，可以看看各种的SQL语法手册，慢慢去公关。

如果我们拼接的sql语句，在词法分析中发现了7个关键字(Token)，并且通过了语法分析，那么我们可以姑且可以粗略地认为这是一条有效的攻击数据。对于SQL注入的评定标准，那就是仁者见仁智者见智。对于如何去判断，哪些是真正的攻击，如何去除误报，还是一个长期优化的过程。

至此，一个完整的通过词法语法检测SQL注入的流程，已经跃然纸上。当然，如果要做成一个合格的产品，还有好多路要走。

后言

SQLChop采用的技术就是词法语法分析那一套，但是具体的实现方案，并不清楚，以上只是个人对于基于词法语法分析SQL注入的一些看法。

基于词法语法分析SQL注入检测，并不是什么新的技术，如何能做好，做到各种数据库都可以完美兼容，如何做到最大限度的减少误报，这个才是真正的技术难题。

同时，发现了SQLChop的Demo已经可以在github下载(https://github.com/chaitin/sqlchop)，但是，检测引擎只提供了so动态链接库。

展望

词法语法分析的确是个好东西，既然用到了SQL注入了，那么下一届大会上，是不是就要有基于词法语法的XSS注入攻击检测与防御引擎了啊，这个在技术上，也是完全可以的啊~

同时，希望有更多的安全工具可以开源，独乐乐不如众乐乐~

参考资料

Google专利搜索：sql注入 语法

中国的各大安全厂商都蹦出来了，而且写的都很详细，内容也都大同小异