一、实验目的

1、增强对程序机器级表示、汇编语言、调试器和逆向工程等理解；

2、提高分析问题解决问题的能力。

二、实验内容

通过程序反汇编和逆向工程拆除所给的目标代码文件中的二进制炸弹。一个“Binary Bombs”（二进制炸弹）是一个Linux可执行C程序，包含phase1~phase6共6个阶段，即6个炸弹。炸弹运行各阶段要求输入一个字符串，若输入符合程序预期，该阶段炸弹被“拆除”，否则“爆炸” 。

本实验要求拆除至少3个炸弹，多则不限。

三、实验工具和环境

软件工具：gdb调试器和objdump；

实验语言：C语言，AT&T汇编语言

实验环境： linux

四、拆炸弹过程分析

阶段1：字符串比较

实验比较输入的字符串和预先设定的字符串是否相同。必有预先设定的字符串，看代码，推测预先设定的字符串在0x402440中。


查看0x402440中的内容，并测试是否正确。


第一个炸弹拆除。
阶段2：循环

由函数read_six_numbers可知，输入6个数。

由一下代码可知x1=0，x2=1.


找到循环的位置，分析知，后面的数字为它前两个数字之和。

即6个数分别为0，1，1，2，3，5.


测试结果


第二个炸弹拆除。
阶段3：条件/分支：含switch语句

由开始代码知(%rsp)+0x8中存放x1，(%rsp)+0xc中存放x2.

x/2s 0x402260f可知，输入的是两个整数。


由这部分可知，输入的数的个数要大于1，否则爆炸。


比较x1和7，若x1大于7，则爆炸，即x1<7.


假设x1=0。把x1送入%eax，并跳转到0x4024b0+(%rax*8)，即到0x00400fab中。




把0xc7送入%eax中，并开始计算，得%eax中的值为-60.


将%eax的值和5进行比较，若大于5，则爆炸。

将%eax的值和x2进行比较，若相等，则返回。即x2=-60.


测试结果


第三个炸弹拆除。

个人觉得Binary Ninja很优秀的二进制分析工具，这里简单来总结一下其Python API的使用方法（Ubuntu系统）：

首先Binary Ninja在Ubuntu上基本上是绿色软件，不需要安装，在这里有介绍：https://docs.binary.ninja/getting-started.html。

在其安装目录下找到Script目录，在终端中运行：

python3 install_api.py

（因为我同时在用Python3和Python2.7），运行之后，就可以在Python工程里直接调用其相应API了。不过这里吐槽一下其官网文档，不是应该给大家详细介绍这些么，一上来介绍了很多wrtie plugin的东西，虽然也很重要，可哪有调用其API方便呢。

下面的代码展示了如何Print一个可执行文件中的所有文件名，很简单粗暴有木有：

from binaryninja import *
import time

bv = BinaryViewType.get_view_of_file('util.o')
bv.update_analysis()
time.sleep(5)
for func in bv.functions:
    print(func.symbol.name)

其他更复杂的Python API功能可以参考其API Document：https://api.binary.ninja/

就简单总结这么多。

（这篇博客整理的时候也参考了一些文章，例如这篇：http://arm.ninja/2016/03/08/intro-to-binary-ninja-api/ ）

Part 1.           需求分析：为什么要使用二进制库？
答案在于两个方面：
1)         隐藏源代码的需要。
放眼现在市面上各个中间件软件提供商，所提供的产品绝大多数都是以二进制库的形式发布的。流行的比如Linux下的Qt图形库，Windows下微软的DirectX图形接口、.NET基类，以及嵌入式平台上的MiniGUI等等。在Linux下静态库和动态库文件的扩展名通常为.lib和.so(Shared Object)，而Windows下动态库也称作动态链接库，扩展名为.dll(Dynamic Link Library)。
2)         模块化、层次化设计的需要。
一旦某个软件模块设计完成，可以将其打包成一个独立的库文件。这样系统其他部分就可以按照其提供的接口进行调用，而无须考虑代码层次的兼容性。其次，库文件是已经编译好的二进制文件，被调用的库只需要静态或动态地链接到主调代码中即可，而无需再次编译库的源代码，大大提高了编译的速度和效率。
下面在Linux环境中使用流行的gcc编译器来演示这两种库的建立和使用。
 
Part 2.           案例1：C与动态共享库
假设有一个简单的任务（经典的helloworld例子）
有一个sayHello的方法在sayhello.c中定义：
//file: sayhello.c
#include<stdio.h>
 
void sayHello()
{
        printf("hello!/n");
}
头文件sayhello.h声明函数sayHello()的形式：
//file: sayhello.h
void sayHello();
现在我们希望发布这个sayHello函数的实现，但是不希望别人知道源代码。于是我们可以将sayHello()函数打包成二进制库的形式发布，同时提供一个头文件声明其调用格式。
主程序hello.c调用sayHello()，如下：
//file: hello.c
#include"hello.h"
int main()
{
        sayHello();
        return 0;
}
生成动态库的过程如下：
[sonic@Rex dynamic-lib-gcc]$ gcc -c -fpic sayhello.c
这样就生成了一个sayhello.o的目标文件。
参数-c: 编译或汇编源文件,但是不作连接.编译器输出对应于源文件的目标文件.
参数-fpic: Generate position-independent code (PIC) suitable for use in a shared library, if supported for the target machine.
[sonic@Rex dynamic-lib-gcc]$ gcc -shared sayhello.o -o libHello.so
共享库libHello.so就生成好了。
现在假设第三方客户需要使用我们提供的共享库，只需要提供libHello.so和hello.h就行了。（hello.h包含于主程序hello.c中）
[sonic@Rex dynamic-lib-gcc]$ gcc hello.c sayhello.so -o hello
把主程序文件和打包好的共享库文件一起编译，最后得到的文件是
[sonic@Rex dynamic-lib-gcc]$ ls
hello  hello.c  libHello.so  sayhello.h
但是这样还不能运行：
[sonic@Rex dynamic-lib-gcc]$ ./hello 
./hello: error while loading shared libraries: libHello.so: cannot open shared object file: No such file or directory
这是因为编译hello时用到了共享库，而运行的时候系统只在几个固定的目录进行查找：
/lib、/usr/lib，其余的在配置文件/etc/ld.so.conf中指定。
这里有两种选择，一是把libHello.so拷入系统指定的目录，一是自己建一个专门放置共享库的目录。
比如/lib/local/shared-lib就是一个不错的选择。
修改/etc/ld.so.conf，将目录加入其中。
把libHello.so复制到/lib/local/shared-lib，然后以root账户运行/sbin/ldconfig更新系统缓存。
Ok，现在运行：
[sonic@Rex dynamic-lib-gcc]$ ./hello 
hello!
Bingo！试验成功！
用ldd检查一下编译完成的hello可执行文件：
[sonic@Rex dynamic-lib-gcc]$ /usr/bin/ldd[1] hello
        libHello.so=> /usr/local/shared-lib/libHello.so (0x00a26000)
        libc.so.6 => /lib/tls/libc.so.6 (0x001d0000)
        /lib/ld-linux.so.2 (0x001b7000)
可以发现红色标记的那一行是我们提供的共享库。
 
Part 3.           案例2：C++与库
这是一个稍微复杂一点的例子。
比如我们要发布一个类，提供这样的头文件声明：
//file: SaySomething.h
class SaySomething
{
public:
        void sayhello();
        void sayhi();
};
成员函数的定义由两个文件承担：
//file: SayHello.cpp
#include "SaySomething.h"
#include <iostream>
using namespace std;
void SaySomething::sayhello()
{
        cout<<"hello"<<endl;
}
 
//file: SayHi.cpp
#include "SaySomething.h"
#include <iostream>
using namespace std;
void SaySomething::sayhi()
{
        cout<<"hi"<<endl;
}
基于同样的理由，内部成员函数的具体实现是不能公开的，头文件是公开对外发布的唯一途径。
 
先以动态库形式编译：
[sonic@Rex dynamic-lib-g++]$ g++ -c -fpic SayHello.cpp SayHi.cpp
生成了两个目标文件：SayHello.o和SayHi.o。 
参数-c和-fpic与上例含义一致。
[sonic@Rex dynamic-lib-g++]$g++ -shared SayHello.o SayHi.o -o libSay.so
库文件libSay.so已经生成。
使用：
//file: Main.cpp
#include "SaySomething.h"
 
int main()
{
 SaySomething* sayHello=new SaySomething();
 sayHello->sayhello();
 sayHello->sayhi();
 return 0;
}
编译：
[sonic@Rex dynamic-lib-g++]$ g++ Main.cpp libSay.so -o hello2
同样，将libSay.so放入之前建立的共享库目录/lib/local/shared-lib，运行：
[sonic@Rex dynamic-lib-g++]$ ./hello2 
hello
hi
用ldd查看hello2:
[sonic@Rex dynamic-lib-g++]$ /usr/bin/ldd hello2 
        libSay.so => /usr/local/shared-lib/libSay.so (0x0032b000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00a39000)
        libm.so.6 => /lib/tls/libm.so.6 (0x00301000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x0090f000)
        libc.so.6 => /lib/tls/libc.so.6 (0x001d0000)
        /lib/ld-linux.so.2 (0x001b7000)
结论是一致的。
 
还有一种方案是采用静态库的形式发布，当然，效果是一样的，达到了隐藏代码的目的。
[sonic@Rex static-lib-g++]$ g++ -c SayHello.cpp SayHi.cpp
这里没有使用-fpic选项，得到了两个同前缀的.o目标文件。
[sonic@Rex static-lib-g++]$ ar -r libSay.a SayHello.o SayHi.o
使用ar工具打包成.a文件（archive），编译：
[sonic@Rex static-lib-g++]$ g++ Main.cpp libSay.a -o hello3
这次直接运行即可：
[sonic@Rex static-lib-g++]$ ./hello3 
hello
hi
使用ldd查看的结果中也没有libSay的项了：
[sonic@Rex static-lib-g++]$ /usr/bin/ldd hello3 
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00a39000)
        libm.so.6 => /lib/tls/libm.so.6 (0x00301000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x0090f000)
        libc.so.6 => /lib/tls/libc.so.6 (0x001d0000)
        /lib/ld-linux.so.2 (0x001b7000)
 
Part 4.           比较与分析
现在比较一下静态链接和动态链接。
静态链接下的各中间文件的最终可执行文件：
[sonic@Rex static-lib-g++]$ ll
-rw-------  1 sonic sonic     153 Oct  3 13:50 Main.cpp
-rw-------  1 sonic sonic     133 Oct  3 13:50 SayHello.cpp
-rw-rw-r--  1 sonic sonic    2648 Oct  3 21:43 SayHello.o
-rw-------  1 sonic sonic     128 Oct  3 13:50 SayHi.cpp
-rw-rw-r--  1 sonic sonic    2636 Oct  3 21:43 SayHi.o
-rw-------  1 sonic sonic      71 Oct  3 13:50 SaySomething.h
-rwxrwxr-x  1 sonic sonic    8230 Oct  3 21:47 hello3
-rw-rw-r--  1 sonic sonic    5592 Oct  3 21:45 libSay.a
 
动态链接下的各中间文件的最终可执行文件：
[sonic@Rex dynamic-lib-g++]$ ll
-rw-------  1 sonic sonic  153 Oct  3 13:57 Main.cpp
-rw-------  1 sonic sonic  133 Oct  3 13:57 SayHello.cpp
-rw-rw-r--  1 sonic sonic 3008 Oct  3 21:32 SayHello.o
-rw-------  1 sonic sonic  128 Oct  3 13:57 SayHi.cpp
-rw-rw-r--  1 sonic sonic 3000 Oct  3 21:32 SayHi.o
-rw-------  1 sonic sonic   71 Oct  3 13:57 SaySomething.h
-rwxrwxr-x  1 sonic sonic 5669 Oct  3 21:37 hello2
-rwxrwxr-x  1 sonic sonic 7941 Oct  3 21:34 libSay.so
 
 
中间文件
库文件
最终可执行文件
静态链接
2648+2636
5592
8230
动态链接
3008+3000
7941
5569
比较对应的文件发现，中间目标文件动态链接比静态略大，库文件动态链接明显大于静态，原因可能跟动态链接较静态链接更为复杂的机制有关。
最终可执行文件静态链接明显大于动态链接，原因很明显，动态链接顾名思义就是用到的时候才进行加载，因此主程序本身并不包含库。而静态链接就是把库在编译的时候就加载到可执行文件中，因此在运行时也不像同态链接那样需要库的支持。
 
这样一来，C/C++中头文件和库文件的关系就非常清楚了。
如下表所示。
 
头文件
静态库
动态库
内容
只提供函数、类以及全局变量、宏的申明，而不提供具体的实现（即源代码）
函数、类的具体实现的二进制目标代码
函数、类的具体实现的二进制目标代码
调用方式
头文件被预处理器(cpp)以直接插入代码的方式被包含进主调源代码中（include）
由链接器(ld)在编译期（静态）链接到主调二进制代码中
由链接器(ld)在运行期（动态）链接到主调二进制代码中
使用
源代码中#include，gcc参数-include headerfile
gcc参数-l library_name
放入系统定义的共享库搜索目录中
 
一点疑问
动态链接产生的.so文件在和主程序文件一起编译的时候不能使用-static选项。如果强制使用的话，虽说可以通过链接，但是执行的时候会发生这样的错误：
[sonic@Rex dynamic-lib-g++]$ g++ -static Main.cpp libSay.so 
[sonic@Rex dynamic-lib-g++]$ ./a.out 
-bash: ./a.out: /usr/lib/libc.so.1: bad ELF interpreter: No such file or directory
而静态链接产生的.a文件时可以和主程序文件一起用-static编译的。
[sonic@Rex static-lib-g++]$ g++  -static Main.cpp libHello.a
[sonic@Rex static-lib-g++]$ ./a.out
hello
hi

[1]如果安装过Intel的arm-linux交叉工具链，默认的ldd可能会定位到arm-linux目录下，所以为避免不必要的错误加上了绝对路径

AXMLPrinter2.jar apk分析APK文件，取得APK文件中的 包名、版本号及图标，很强大的工具，再一次感受到了批处理的牛逼。可以将android安卓编译过的二进制XML文件(binary xml file)反编译明文输出保存。是apk反编译修改的必备工具之一。例如需要查看apk安装包的权限、名称等，可以用AXMLPrinter2对androidmanifest.xml反编译进行明文查看。反编译速度非常快,好用
好用，可以顺利捣鼓出.XML文件
刚开始不知道怎么用,后面查一了下,用CMD AXMLPrinter2,会用了,谢谢.
不用打开的是使用cmd执行命令使用这个jar包的。
用AXMLPrinter2.jar反编译xxx.xml文件
解压xxx.apk,选择main.xml(也可选择其它xml文件，不过xml文件都是乱码)，复制到AXMLPrinter2.jar所在目录，通过cmd
进入到AXMLPrinter2.jar所在目录，使用如下命令，得到的main.txt就是反编译后的文件，现在可以看懂了。
java -jar AXMLPrinter2.jar main.xml > main.txt
“AXMLPrinter2.jar”为可执行文件，需要安装jave运行库(JRE)才能运行。
“AXMLPrinter2源码.zip”为“AXMLPrinter2.jar”的源码，可以自行修改编译。
使用示例：
java -jar AXMLPrinter2.jar AndroidManifest.xml > AndroidManifest.txt