在分析Android APK的时候，除了盯着那些反编译出来的代码去读，还经常需要查看里面塞着的各种图片、界面的布局文件、用到的字符串信息、清单配置文件等等。用JEB Decompiler把资源导出来，通常可以直接在它左边的项目资源树、中间打开的文件视图，或者单元视图里面，把想要的目标资源选中，然后存到本地；而导出之后那一堆文件该怎么分类整理，就得同时参照APK本身的目录结构，和你这次分析到底想查清什么问题，把它们分开放在不同的文件夹里。只要资源文件从一开始就整理得清清楚楚，后面再去找界面布局、查接口地址、核对权限配置，或者翻看多国语言的文本，都会省下一大把来回翻找的时间。

　　一、怎样从JEB Decompiler里导出资源文件

　　在动手往外倒资源以前，最好先确认JEB已经把当前这个APK完整地解析完了。JEB把一个APK打开之后，通常会把里面的DEX代码、AndroidManifest清单、resources.arsc资源映射表、res目录、assets目录这些内容，拆成一个个独立的节点挂在项目树里，大多数资源文件其实并不需要专门跑到代码窗口去找，从项目树里面点开，会方便得多。

　　1、先把APK工程给打开

　　让JEB跑起来，然后点一下【File】→【Open】，把要分析的那个APK文件给导进来，等它把解析步骤跑完就可以。解析结束以后，在左边那一棵项目树里，找到对应的APK节点，再把它一层层展开，常见的藏着资源的地方，主要就是AndroidManifest.xml、res目录、assets目录、lib目录和META-INF目录，这其中res和assets是翻找资源时最需要盯住的两个区域。

　　2、仔细看一遍资源树

　　把res目录展开之后，底下能瞧见很多子文件夹，比如drawable、mipmap、layout、values、xml、raw等等，layout里面放的基本都是页面的布局XML，values里面通常会有strings字符串、colors颜色值、styles样式这些内容，而drawable和mipmap里主要是各种图片和图标。assets这个目录就相对杂一些，里面很可能塞着配置文件、脚本、证书、离线要用到的数据，甚至是被加过密的资源，一不留神就容易漏掉它。

　　3、单独导出一个资源文件

　　在项目树里随便点中一个文件，比如strings.xml、activity_main.xml，或者某一张图片，在它上面右键弹出来的菜单里，一般都会有【Export】、【Save As】之类的保存选项，不同版本的JEB菜单叫法也许会有细微差别，但只要顺着资源节点去找导出入口，就不会错。除此之外，也可以先把文件在右边的内容窗口里打开，再通过文件菜单里的保存功能，把它存到本地硬盘上去。

　　二、导出后的资源文件目录怎么整理

　　资源全部导出来之后，不能只是照着“图片”“文本”这种粗线条的类别来简单地归个类就完事，APK里面的资源从一开始打包就有自己一套固定的目录规则，所以整理的时候，最好先照原样保留一份不作任何改动的副本，再额外去建一套专门用来分析的工作目录。

　　1、保留一份原始APK的目录结构

　　比较稳当的做法是，单独建一个文件夹，名字可以就叫original_resources，然后把从JEB里导出来的res目录、assets目录、AndroidManifest.xml、resources.arsc，全部按照它们原本的样子塞进去。这一份文件，在后面的分析过程里，不要随便改它的名字，更不要去动里面的实际内容，相当于留一本底账，以后需要回到APK最原始的状态去核对什么东西的时候，可以直接拿它来比对。

　　2、按照分析的目的另建一套副本

　　再另外建一个analysis目录，根据这一次分析到底想查清楚什么，往里面建几个子文件夹，比方说ui_layout专门放界面布局，strings_text放文本和字符串，images_icon放图片和图标，network_config放网络配置，permissions放权限相关，suspicious_assets放那些看着比较可疑的资源。这么做，既不会把原始那份给弄脏，写分析报告或者回头来复核问题的时候，也方便按类别去拿。

　　3、把values目录单独抽出来整理

　　values目录底下的strings.xml、colors.xml、styles.xml，还有public.xml，这些文件常常藏着很关键的信息。字符串里面经常夹着接口的路径、页面上出现的提示文字、错误码、渠道的名称，甚至有第三方SDK的蛛丝马迹。整理的时候，可以把不同语言的strings分别保留好，再专门从里面把那些最可能是线索的关键文本，提取出来做成一张清单。

　　4、把图片资源按照屏幕密度分开存放

　　drawable、mipmap这些目录里面，经常会有hdpi、xhdpi、xxhdpi这种按不同密度分出来的版本，不能只随随便便保留其中一张图了事，因为不同密度下的切图，在分析界面来源、比对几种分辨率里的细节时，可能正好是关键的依据。图标、启动页、按钮这类资源，最好还是按它原本的密度路径留着，免得后面想找某个对应版本时怎么也找不到。

　　三、资源导出之后怎样做复核

　　把资源导出来并不是最终目的，还得回头去确认这些文件是不是完整的、能不能正常打开、跟代码或Manifest里面的引用关系是不是吻合得上。

　　1、检查一下XML是不是正常解码了

　　Android的布局文件和Manifest在APK里，很可能是以二进制的XML格式存放的，JEB解析之后能直接看到可读的内容，但导出来之后，就得自己再打开瞧一眼，确认它是不是还是一样能读得懂。要是发现导出来的XML已经变成了乱码，那就要想办法换一种导出方式，或者干脆从JEB显示窗口里把内容另存出来。

　　2、把Manifest和资源的引用对一遍

　　先看Manifest里面都声明了哪些Activity、Service、用到了什么权限、主题名字是什么，再回到res目录里面，去找对应的layout、style和字符串，如果两边资源的名字都能稳稳地对应起来，说明这次导出来的结构是比较完整的，没漏掉什么关键东西。

　　3、检查一下assets里面有没有看起来奇怪的文件

　　assets这个目录里，有时候会藏着一些没有后缀名的文件、体积特别大的东西、加密过的配置，或者是可疑的脚本文件，一旦看见这种，就得把它们单独记下来。可千万别为了图打开方便，随手就把扩展名给改了、把原文件给覆盖掉，比较安全的做法是，把它复制一份放到analysis目录里面，再去做下一步的分析。

　　总结

　　用JEB Decompiler导出APK里的资源，常用的门路就是在打开APK以后，在左边项目树里把res、assets还有Manifest这些节点一层层展开，然后按单个文件或者整个目录的方式把它们导出来。导出之后的目录该怎么整理，比较好的习惯是先保留一份原始结构的original_resources，再按照界面布局、字符串、图片、配置文件和可疑资源这几大类，去建一套分析用的副本。