apkの逆アセンブルの話(2018年度版)
はじめに
DroidKaigi2018で逆アセンブルに関する発表がありましたが
同時期に仕事場で
AS2.3=>AS3.0に移行した状態で apkの評価をしていたので調べてみようとした次第
動作環境
- Windows 10
- 8G
- AS 3.0.1 /AS 3.1-Beta1 /AS 3.2-Canary3
- gradle plugin 3.0.1 / 3.1-beta1 / 3.2-alpha03
- gradle runtime 3.5.1
DroidKaigi2018で発表されていたスライド
状況
android studio 3.2 Canary1
— close_yutori (@kimukou2628) 2018年2月9日
apkがおかしくなる件
dependency
gradle runtime 4.5.1に変更
Manifest.xml
src配下のManifest.xmlをみなくなった?ようで、パッケージ名とかbuild.gradleの
applicationIdの指定優先で、そこら辺が悪さしてるっぽいな。
もう少し追ってみよう
android gradle
— close_yutori (@kimukou2628) 2018年2月9日
d8有効にしてると、
dex2jar 2.0だとentry参照エラー(解析が途中でとまる)になるのか、、
(3系はデフオ有効
githubのソースには修正が入ってる(2.1-SNAPSHOT)のでbuildして参照変えればOKと。
あと3系からclasses.dexって複数出きるんだな~(解析対象だと7個出来てた
な状況でうまくいかなかったので調べていた状態
なんでd8有効にしたの?
3.2 から 1_8 ビルドをする場合、下記の状態が必須になっているからですね
あと plugin 3.1/3.2 からbuild が何回か1回は失敗する状態で 1_7 buildのせいか疑った感じ。
確かに 1_8 buildの方が安定します。
これ gradle pluginが依存しているlibraryがJDK8 buildだからかもなー
- gradle.properties
android.enableD8=true
これがやたら警告出てる。2018年にこの属性使えなくするよ的な警告
- app/build.gradle
compileOptions { sourceCompatibility JavaVersion.VERSION_1_8 targetCompatibility JavaVersion.VERSION_1_8 }
jackOptionは凄いシンプルなプロジェクト以外動かせた記憶が無いので
offにするとpreBuildタスクのチェック段階でタスク失敗で止まってしまうと。
android gradle plugin 3.2.0-alpha03
— close_yutori (@kimukou2628) 2018年2月16日
1_8 buildを指定するとき
D8がoffだとbuild errorになるようになってた
ますますG様 libraryのみ利用に留めとかないとハマりそうだな~(^^;;
後日譚的な話
androd gradle plugin 3.1/3.2 系は後日
- 1_7 ビルドは安定
- 逆にJDK1_8ビルドが怪しい
- kotlin対応に力注いでるからそっちに倒れたのかな?
って感じになっててなんだかなーという感じ。選択と集中ではあるのですが・・・
先週はちゃんとビルドできたじゃん、なんでわけわからんエラー出すねん😵
— さきちゃんの中の人、カピバラになりたい🐁 (@serenegiant) 2018年5月23日
あぁー💫💫💫
— さきちゃんの中の人、カピバラになりたい🐁 (@serenegiant) 2018年5月23日
ラムダ式の中で無名クラスを生成したらあかんねんわたぶん…あれ?でも他にもあるよなそういうところ😓
あかんラムダ式を取っ払ったらapk作れた?
これに関しては、pluginのバージョンで Defaultのproguardのバージョンが上がってるせいもあるのかもしれない
https://qiita.com/Nkzn/items/50a1d49fbd1515a383aa
1_8 buildの他の問題
1_8 の指定羨ましいw(ラムダ式使えない
— close_yutori (@kimukou2628) 2018年2月14日
1_7のままなら使えますよね
(java8でbuildしてないから問題らしいけど
デフォルトでG様有効にしてくれればいいのにな~とかよく思います
では有るんだけど、compileは確かに通りますが
それも有るんですが、Android Studio のjava8のコード補完がいまいちチャンと動いてない気がするんですよね。
— close_yutori (@kimukou2628) 2018年5月23日
(純粋なideaだと動くのか不明瞭ですが、、、)ラムダ式とかが、、
kotlinの方はまだ動くので、そっちに向かってしまうという事情がある気がしますw
な形でIDEサポートが弱い気がするから、結局kotlinに流れている気がする。
android ktx とか 最新の Google codeLabみると kotlinやらざるを得ない状況にはなってるし
そういえば現在G様は
githubのgoogleSampleは殆ど更新して無くてCodeLabに力入れてるみたいなんだよなー
結局のところ
- 1_8 build対応には,dex2jarの 2.1-snapshot が必要
- apktool も 2.2.3で最新化
- classesXX.dexが複数できる物 =>その分ぶん回す
形で対応しました。
いまさら再導入 peco for mac (2) - exception think
らへんの apkd.bat の辺りをベースにして改変 * apkd.bat
@echo off set PECO_HOME=C:/soft/peco set APKTOOL_HOME=%PECO_HOME% set DEX2JAR_HOME=%PECO_HOME%/dex-tools-2.1-SNAPSHOT for /f %%i in ('dir /s /b *.apk ^| peco --select-1') do ( echo apk file %%i java -jar %APKTOOL_HOME%/apktool_2.2.3.jar d %%i -o out/%%~ni cp %%i out rem ★d2j-dex2jarは古いため、最近はAndroidManifest.xmlを正常に解凍できないためバックアップをとっておく mv out/%%~ni/AndroidManifest.xml out/%%~ni/AndroidManifest_mst.xml unzip -d out/%%~ni out/%%~nxi rem ★unixUtilsのlsを利用。classes*.dex 分ループ for /f %%j in ('ls out/%%~ni/classes*.dex') do ( %DEX2JAR_HOME%/d2j-dex2jar.bat out/%%~ni/classes%%j.dex -o out/%%~ni/classes%%j-dex2jar.jar --force ) )