elf反编译

Ⅰ 如何反编译linux里的elf文件

objmp -S a.out > a.S

Ⅱ 求一款能够编辑linux系统的.so文件的工具。百度毫无信息啊

用二进制编辑器
linux用VI也可以吧
1。 vim -b your_file (-b 是二进制模式, 一定要，否则文件大小会变)
2。 然后“:%!xxd”就可以转换为16进制，注意要编辑左边的hex, 改写右边的文本没用！和Ultraedit严重不同
3。 编辑好了再“:%!xxd -r”转换回文本模式":wq"存盘退出。

Ⅲ so格式文件是什么文件

SO文件格式即ELF文件格式，它是Linux下可执行文件，共享库文件和目标文件的统一格式。

根据看待ELF文件的不同方式，ELF文件可以分为链接视图和装载视图。链接视图是链接器从链接的角度看待静态的ELF文件。

从链接视图看ELF文件，ELF文件由多个section组成，不同的section拥有不同的名称，权限。而装载视图是操作系统从加载ELF文件到内存的角度看待动态的ELF文件。

从装载视图看ELF文件，ELF文件由多个segment，每一个segment都拥有不同的权限，名称。实际上，一个segment是对多个具有相同权限的section的集合。

(3)elf反编译扩展阅读：

由于android操作系统的底层基于Linux系统，所以SO文件可以运行在Android平台上。Android系统也同样开放了C/C++接口供开发者开发Native程序。

由于基于虚拟机的编程语言JAVA更容易被人反编译，因此越来越多的应用将其中的核心代码以C/C++为编程语言，并且以SO文件的形式供上层JAVA代码调用，以保证安全性。

而ELF头表记录了ELF文件的基本信息，包括魔数，目标文件类型（可执行文件，共享库文件或者目标文件），文件的目标体系结构，程序入口地址（共享库文件为此值为0），然后是section表大小和数目，程序头表的大小和数目，分别对应的是链接视图和装载视图。

Ⅳ iOS 的 framework 和 ipa 文件可以反编译出源码吗

ipa 文件其实是一个压缩包，里面包括了可执行文件，资源文件等信息。
反编译的话也可以，只是你要有足够强的功底，就可以。这个至少汇编得会吧，然后可以根据反编译出来的汇编写出原来的OC程序。现在我没有发现有什么工具可以直接反编译出ELF文件的。
框架(framework)是一个基本概念上的结构，用于去解决或者处理复杂的问题。这个广泛的定义使用的十分流行，尤其在软件概念。框架也能用于机械结构。

Ⅳ 反编译exe文件就是把exe还原为汇编

首先了解一下概念，exe程序只是WIN下PE格式的可执行文件的一种,而所谓的计算机执行的代码只是一串二进制数,跟数据没区别，当CS,EIP指向哪，哪里就是程序，而汇编语言之所以叫最底层的语言，是因为， 汇编的每一个语法，都应对了一串二进制的指令，这也就是反汇编的原理，所以NO1.一、反编译exe程序 就是 把 exe 还原为汇编语言吗？,这句话，不能叫还原，应该叫解释，“解释”的东西，没还原的那么逼真，比如，在汇编源程序中所有的标号和注释，进行编译后，变成二进制可执行文件后，在反汇编，标号就变成数字了，而注释更是没了..... 二、除了 还原为 汇编语言，还能 反编译为 其他高级语言吗？不能，高级语言的语法是建立在大量的计算机二进制代码之上的，比如你C语言随便调用一个子函数，到了二进制中，他是先压栈，参数（编译后参数从右往左压，每个语言还不一样），然后就是call 子函数，子函数运行后，他还要清理堆栈，所以你一个句简单的高级语言，其实蕴含了大量的代码，而高级语言编译后的程序，就脱离了他的开发环境，楼上说的会引起你误会，Java的中间码，可以用他自带的反编译工具，因为Java不是编译器，而是解释器，所以他不编译，只是解释他的中间码NO2.所有的exe都可以反汇编,但是你要注意，不只exe这种pe格式，linux下可执行文件是elf，所以你在反汇编的时候，要注意可执行文件的文件的头，而早期的DOS只是纯二进制代码，没有头文件，这个很重要，你要反汇编什么格式，就要选择相应的工具NO3.exe反汇编，当然是OD,不过，我对OD不熟悉，好像他只支持WIN下的反汇编

Ⅵ 安卓app360加固怎么反编译

1 对比

上传demo进行加固，解包后对比下原包和加固包，发现加固包在assets文件夹下多了libjiagu.so，libjiagu_x86，lib文件夹下多了libjiagu_art.so，同时修改了dex文件和AndroidManifest文件

打开manifest文件，看到xxx加固对Application标签做了修改，添加了壳入口，也就是我们反编译后看到的StubApplication.smali这个文件。

相比于之前版本的加固，自从1.x.x.x加固版本之后，多了几次反调试，使得动态难度稍微增大了一些，不过针对脱壳机脱壳，再多了反调试也是无用。或者通过修改系统源码，也能达到消除反调试的作用。

2 动态调试

（1）把app安装到手机，以调试模式打开app

（2）以shell模式root权限打开IDA的android_server监听

（3）tcp转发

（4）打开IDA，修改配置为在进程开始时下断

（5）搜索到进程后jdwp转发，pid值即为我们进程号，并在命令行下附加。

成功附加后，可以下段了，打开Debugger Option

我们选择在线程开始和库加载时下断，修改成功后，jdb附加，点击运行

程序会断在elf头处，按下G键，搜索mmap，在mmap函数的段首和断尾下段

F9运行，来到断尾时F8单步，

来到此处时，在 BLunk_5C999C2C下断，F9一下，F7跟进去

跟进去今后在BLX LR处进行下断，此处就是进行反调试的地方，原理依然是获取TracePid的值判断当前是不是处于调试状态，建议第一次调试的人在fgets和fopen处下断，再f7跟进此调用就可以看到TracePid的值了。

跟进去之后，我们直接把方法移到最下方，就可以看到kill符号了，这就是杀进程的地方，如果当前处于调试状态，则直接结束进程。

我们在此函数的所有cmpR0,#0处下断，F9一下后即断在断点处，观察寄存器窗口的R0值，实质就是当前的TracePid的16进制的值

不确定的可以使用cat /proc/pid/status进行对比一下，我们直接把R0置0，右键选择Zero Value即可清0，继续F9

我们看到程序又来到了mmap处，继续f9

当继续断在调用反调试功能的方法时，继续F7跟进，依然在所有的cmp R0，#0处下断，断下后把R0清0后继续F9运行

目前的规律是，调用BLXLR的第一次，第二次和第四次是进行反调试判断的，第三次并不影响，可以直接f9跳过去，三次反调试搞定后，就可以愉快的F9运行并观察堆栈窗口了

当看到出现如下所示时：

说明壳已经开始解密并释放dex文件了，我们直接F8单步十几步，最后F9一下就可以看到我们需要的dex头了

直接脚本mp出来即可，最后把libjiagu的所有文件删除，并修复下Application标，如果存在则修复，不存在删除即可

Ⅶ ios app客户端可以反编译吗

ipa 文件其实是一个压缩包，里面包括了可执行文件，资源文件等信息。 反编译的话也可以，只是你要有足够强的功底，就可以。这个至少汇编得会吧，然后可以根据反编译出来的汇编写出原来的OC程序。现在我没有发现有什么工具可以直接反编译出ELF文...

Ⅷ 如何反编译 android 中 /data/dalvik-cache/arm 下的文件

所有的 apk 内包含一个 classes.dex 文件。在 Dalvik上，apk包里的 dex文件在安装的时候会通过 dexopt 转化成另一个格式，叫odex（Opitimized dex），然后存在 /data/dalvik-cache里面，如：

/data/dalvik-cache/data@[email protected]@classes.dex
虽然文件后缀还是 .dex，但是这个dex和apk内的那个已经不一样了。这个文件是针对当前机器的硬件对 dex 文件进行了定制化，也就是说把这个放到别的设备上，不一定能运行。

PS: 在要编译 rom 的时候，如果参数加上 "WITH_DEXPREOPT=true"，会在 /system/app/ 下同时生成 .apk 和 .odex 文件（注意，这里后缀又用的 .odex，但实际上和系统在 /data/dalvik-cache/ 下的 .dex文件是一样的）

ART

在 ART上，apk 包里的 dex文件在安装的时候通过 dex2oat，也会生成一个后缀为 .dex 的文件，放在 /data/dalvik-cache中，如：

/data/dalvik-cache/arm/system@app@[email protected]@classes.dex
/data/dalvik-cache/arm64/system@vendor@app@[email protected]@classes.dex
这个文件后缀叫 .dex ，但是这个文件又不一样了，这个既不是 dex 也不是 odex，用 dex2jar 的无法进行反编译的。文件格式也完全不同，因为这其实就是一个实打实的 elf文件，这个文件已经可以直接在机器上运行了。

为何 pm.jar 是空的？

首先来了解一下 ROM 的编译选项，看一下编译的时候能做什么事情， 大致了解就行了 。

编译选项

WITH_DEXPREOPT

使能编译时生成 OAT，避免第一次开机时编译耗时，但会增大 system分区的空间消耗

DONT_DEXPREOPT_PREBUILTS

使能后，将不会对 Android.mk中包含了 include $(BUILD_PREBUILT)的 Apk进行 oat，例如 Gmail，它很可能会在后期通过商店自行升级，而升级后系统中的 oat文件则没有意义了，但又无法删除，会造成空间的浪费（oat比dex文件要大）

WITH_DEXPREOPT_BOOT_IMG_ONLY

仅仅针对 boot.img进行oat优化（boot.img中包含 boot.art和 boot.oat）

LOCAL_DEX_PREOPT ture|false|nostripping

可用于各个 Android.mk，对每个 package进行单独配置，当设置为 true时，dex文件将会从 apk中剔除，如果不想剔除可使用 nostripping WPRODUCT _DEX PREOPT_*

WPRODUCT__DEX_PREOPT_*

PRODUCT_DEX_PREOPT_BOOT_FLAGS

这里的参数将会传至 dex2oat，控制 boot.img的编译优化行为。

PRODUCT_DEX_PREOPT_DEFAULT_FLAGS

控制除 boot.img 外，其他（如 jar, apk）的 OAT编译行为 例如：

PRODUCT_DEX_PREOPT_DEFAULT_FLAGS := --compiler- filter=interpret-only
$(call add-proct-dex-preopt-mole- config,services,--compiler-filter=space)
WITH_DEXPREOPT_PIC ture|false

使能 position-independent code，这样在dex2oat编译生成的 odex文件在运行时将不必再从 /system 下拷贝到 /data/dalvik-cache/ 目录下， 可以节省 /data 空间

WITH_ART_SMALL_MODE true|false

设置为 true 时，将只编译处于 boot classpath 里的类，其他的均不编译，这样既能加快第一次开机时间，因为大部分必要的类已经编译过了； 同时也能节省不少空间，因为 APP 都未进行编译。缺点是可能损失一性能，这可能要平时觉察不出，但在跑分软件上会有所体现

编译选项的经典配置

为了提高第一次开机速度，WITH_DEXPREOPT是必须使能的，这样则在编译阶段会完成 dex2oat的操作，避免在开机时间去做这个转码，节省了开机时间（6min以上缩短2min内）。

但会引起一个缺点，那就是 apk中还是包含了 class.dex（dexopt生成的），同时在对应的apk文件夹中又生成了已经转码成oat的 class.odex（dex2oat生成的），相当于这部分重复，造成了大量的空间浪费。

为了把 apk包里的 class.dex去除，节省空间，可以打开 DEX PREOPT DEFAULT := ture。

然而，这样开机速度是快了，而且节省了不少system空间，但开机后，咱们会发现即使在 system中已经存在 class.odex的 apk，第一次开机后还是会在 /data下面生成 class.odex，如data/dalvik-cache/arm64/system@app@[email protected]@classes.dex，这是何解？原来 Google为了提高安全性，在每一台机器开机时都会在之前的机器码加一个随机的偏移量，这个偏移量是随机的，每台机器都不相同，而 data分区下的这些文件就是从 system下的 class.odex加上偏移而来。

Ⅸ windows下ELF文件反编译，需要看符号表，有什么办法

你可以尝试，你任何项目下面的WEB-INF下面的classes下面的文件试试，排除你这个文件引用了特殊的jar包，又恰巧你这里没有完整的环境

Ⅹ 我想反编译linux下c语言生成的可执行文件！请大家帮个忙告诉我用哪个软件或工具，不胜感激！

没可能，工作量比重新把程序写一遍还要大。