实际上安卓的应用都是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要安全许多。