實際上安卓的應用都是zip包,只不過把zip擴展名修改了,修改成了APK.所以如果你想拿到它的圖片的話,實際上特別簡單，你就把它這個.apk換成.zip.換成.zip之后這里的圖片資源就都可以拿到了.

有些公司可能美工的水平或者美工的人數比較少，項目還比較急，這個時候就上網上去找。看誰的比較好看。下載下來之后擴展名換一換換成.zip就把它里面的資源就都拿出來了。這樣就減少了一些成本。所以說這就是一個比較簡單的辦法。

它大部分圖片都是放在hdpi。

用像素密度來區分不同的圖片的文件夾。

?x越多，代表當前這個文件夾所對應的圖片的分辨率、支持的像素密度就越高。

但是實際上大部分的應用并不會把所有的圖片，每一個都搞出一份來丟到不同的目錄下。這是沒有人那么做的，因為你要那么搞的話你的應用的體積就會比較大了。它會根據不同的像素密度對這個圖片進行壓縮或者放大，就是自動去實現。大部分情況咱們只需要把這個東西丟在比較常見的像素密度的文件夾里，就是xhdpi或者是hdpi.這樣就可以了。因為現在像mdpi的手機基本上已經絕跡了。ldpi和mdpi的手機特別特別少。所以咱們只需要把它放在hdpi和xhdpi.通過這種方式只能去拿到它的圖片資源，你像所有的XML文件咱們是看不到的。

---

早期的反編譯工具：

apktool是幫助把你的應用進行反編譯的。

反編譯之后咱們拿到的就是這兩個東西

反編譯之后再去看res/anim下相關的XML文件就沒有問題了。

這樣咱們就只能看到XML和它的資源。但是咱們現在是看不到源代碼的。想看源代碼就要用另外一個工具dex2jar.安卓中所有的.class最終都會打包生成一個dex文件。dex文件通過dex2jar可以轉換成.jar.之前通過.jar來查看java代碼就使用了一個工具叫JD-GUI.把.jar丟進去,丟進去之后就可以看到它對應的java的源代碼了。

所以呢早期要通過三個工具：apktool、dex2jar、jd-gui這三個工具才可以把應用進行反編譯。但是現在安卓逆向助手就把這些東西打了個包，我們可以使用安卓逆向助手的圖形化界面進行反編譯操作了，不用去記那些命令了。

?

?

?

?

java基礎講過，java不管是方法名還是類名都應該是有意義的，不能隨便寫。但是實際上在打包之前，它做了一件事情叫做混淆，混淆的作用就是迷惑你。提高了你把它代碼讀懂的難度。因為它的類名都沒有意義。而且它的項目都比較大，有那么多個文件，都是a、b、c、d、e、f、g的。你想把它拆出來的話可能就比較費工夫了。安卓其實也沒有特別復雜的一些邏輯，你有工夫猜它還不如自己寫了。花功夫也是沒問題的，也能猜個大概。但是真要花那么多時間去搞這個事的話還真不如自己寫了。所以說一般的應用在上線之前都會去進行一個混淆的操作。但是有一些小的應用它也就懶得做這些事了，可能在混淆的過程當中會出現一些問題。比如你引入一些第三方的庫，它這個庫實際上在放到你的項目里面已經做了一次混淆了。做了混淆的話呢你再混淆它的時候就得加一些例外的情況。如果說這個小公司有一些開發的人懶得去搞這個事可能也就不混淆，拿著這個源代碼直接就傳上去了。所以你上市場上去找一些下載量不是很大的應用，你去翻一翻，也會有一定的積累能直接拿到它的源代碼。

看一下這個java反編譯之后實際上我拿到的就是混淆之前的源碼。實際上我拿到的就是java的源代碼.只不過呢它在打包之前做了一次混淆，雖說通過混淆可以去提高這個代碼被破譯的難度，但是呢真的去做的話實際上有一些邏輯還是可以看出來的。比如一些數據結構,例如HashMap

private int a = 0;private int b = 0;private int c = 0;private int d = 0;private HashMap e = new HashMap();

還有一些是Map.Entry

Map.Entry localEntry = (Map.Entry)localIterator1.next();

這些你真的是花點功夫的話，相對還是比較容易給它還原成最開始的樣子。如果是沒進行混淆的，例如之前寫的ip撥號器.

?

如果你沒做混淆的話基本上就相當于把你的源代碼就丟到市場上了。正常來講咱們發布之前都要對它進行混淆。關于混淆這部分的內容以后在就業之前還會有幾天的課程。關于加密、打包、還有混淆相關的內容。現在咱們只需要搞清楚你反編譯之后能拿到一個什么樣的代碼這樣就可以了。

所以說如果你不做混淆這個java代碼基本上就是相當于你把它丟到市場上去了。如果你不混淆的話，差不多就相當于你把這個源碼就直接發到市場上了。你辛辛苦苦敲的這些東西別人一眼就可以看到。很簡單，點一點就可以拿到它。

這個就是java的反編譯的過程。

---

C的相對來講就更安全一些。 有一個對C進行反匯編的工具。

?

?

?

這就是匯編的代碼。PUSH就是壓到寄存器里面。PUSH壓到棧里。MOVS在寄存器里給它挪一挪。這個都是在ARM下的匯編的代碼。如果你不懂匯編那就看不懂了。所以這個就相對來講要比java要安全一些。

現在這個工具也有通過匯編給猜出C的功能。按F5

Pseudcode-A：偽代碼-A.這就能通過匯編猜出它的偽代碼出來.雖說它猜出了C的偽代碼，但是實際上咱們寫的跟這個還是差距蠻大的。專門做JNI的逆向的，可以自己去先寫，寫完之后他拿著自己的代碼去進行反匯編。反匯編之后看一看這個東西長成什么樣。

一看什么helloFromJava是方法名,()V是方法簽名.也可以去猜你是要C回調Java.

所以說呢你說哪一種方式特別特別的安全，這個沒有太特別安全的。只要被高水平的黑客盯上的話，被破解就是時間的問題。但是呢你要這么搞的話相對來講這個安全性會高許多，比java的代碼要高許多。所以一般都要把跟錢相關的，或者說像銀行這樣的應用，去跟動物相關的加密的這些業務邏輯，都要放在C這邊去處理。而且C的代碼它也可以去混淆。你也可以給它起一些很惡心的名字。也可以給代碼里面加一些垃圾代碼。所以說呢通過C來去做跟安全相關的這些業務邏輯，它是比java要安全很多。

這個就是java和C之間的反編譯和反匯編的對比。實際上java的這個反編譯直接就拿到了之前寫的源碼，或者說是混淆之后的源代碼。但是C的這個.so文件對它進行反匯編你即使猜一下它的偽代碼看起來呢也不是太靠譜。所以C的.so要比java的.dex或者是.jar或者是.class要安全許多。

轉載于:https://www.cnblogs.com/ZHONGZHENHUA/p/7148633.html

總結

以上是生活随笔為你收集整理的02_反汇编_反编译的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。