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語言生成的可執行文件！請大家幫個忙告訴我用哪個軟體或工具，不勝感激！

沒可能，工作量比重新把程序寫一遍還要大。