diff --git a/src/generic-methodologies-and-resources/basic-forensic-methodology/malware-analysis.md b/src/generic-methodologies-and-resources/basic-forensic-methodology/malware-analysis.md index 4bfb45c09..e7fec1342 100644 --- a/src/generic-methodologies-and-resources/basic-forensic-methodology/malware-analysis.md +++ b/src/generic-methodologies-and-resources/basic-forensic-methodology/malware-analysis.md @@ -22,23 +22,23 @@ ```bash sudo apt-get install -y yara ``` -#### ルールの準備 +#### ルールを準備する -このスクリプトを使って github からすべての yara malware rules をダウンロードしてマージしてください: [https://gist.github.com/andreafortuna/29c6ea48adf3d45a979a78763cdc7ce9](https://gist.github.com/andreafortuna/29c6ea48adf3d45a979a78763cdc7ce9)\ -_**rules**_ ディレクトリを作成し、スクリプトを実行してください。これにより、すべての yara malware rules が含まれる _**malware_rules.yar**_ というファイルが作成されます。 +このスクリプトを使って github からすべての yara malware rules をダウンロードして結合してください: [https://gist.github.com/andreafortuna/29c6ea48adf3d45a979a78763cdc7ce9](https://gist.github.com/andreafortuna/29c6ea48adf3d45a979a78763cdc7ce9)\ +_**rules**_ ディレクトリを作成して実行してください。これにより、すべての yara rules for malware を含む _**malware_rules.yar**_ というファイルが作成されます。 ```bash wget https://gist.githubusercontent.com/andreafortuna/29c6ea48adf3d45a979a78763cdc7ce9/raw/4ec711d37f1b428b63bed1f786b26a0654aa2f31/malware_yara_rules.py mkdir rules python malware_yara_rules.py ``` -#### Scan +#### スキャン ```bash yara -w malware_rules.yar image #Scan 1 file yara -w malware_rules.yar folder #Scan the whole folder ``` -#### YaraGen: malwareの検出とルール作成 +#### YaraGen: malware をチェックしてルールを作成 -ツール [**YaraGen**](https://github.com/Neo23x0/yarGen) を使って、バイナリから yara rules を生成できます。以下のチュートリアルを参照してください: [**Part 1**](https://www.nextron-systems.com/2015/02/16/write-simple-sound-yara-rules/), [**Part 2**](https://www.nextron-systems.com/2015/10/17/how-to-write-simple-but-sound-yara-rules-part-2/), [**Part 3**](https://www.nextron-systems.com/2016/04/15/how-to-write-simple-but-sound-yara-rules-part-3/) +バイナリからyara rulesを生成するには、ツール [**YaraGen**](https://github.com/Neo23x0/yarGen) を使用できます。以下のチュートリアルを参照してください: [**Part 1**](https://www.nextron-systems.com/2015/02/16/write-simple-sound-yara-rules/), [**Part 2**](https://www.nextron-systems.com/2015/10/17/how-to-write-simple-but-sound-yara-rules-part-2/), [**Part 3**](https://www.nextron-systems.com/2016/04/15/how-to-write-simple-but-sound-yara-rules-part-3/) ```bash python3 yarGen.py --update python3.exe yarGen.py --excludegood -m ../../mals/ @@ -49,7 +49,7 @@ python3.exe yarGen.py --excludegood -m ../../mals/ ``` sudo apt-get install -y clamav ``` -#### Scan +#### スキャン ```bash sudo freshclam #Update rules clamscan filepath #Scan 1 file @@ -57,26 +57,26 @@ clamscan folderpath #Scan the whole folder ``` ### [Capa](https://github.com/mandiant/capa) -**Capa** は実行ファイル（PE、ELF、.NET）内の潜在的に悪意のある **capabilities** を検出します。したがって、Att\&ck tactics のようなものや、次のような疑わしい **capabilities** を見つけます: +**Capa** は実行ファイル: PE, ELF, .NET 内の潜在的に悪意のある **capabilities** を検出します。したがって、Att\&ck tactics のようなものや、次のような疑わしい capabilities を見つけます: -- OutputDebugString のエラーをチェックする +- OutputDebugString エラーをチェックする - サービスとして実行する - プロセスを作成する -入手先は [**Github repo**](https://github.com/mandiant/capa)。 +入手は [**Github repo**](https://github.com/mandiant/capa) 。 ### IOCs -IOC は Indicator Of Compromise（侵害の指標）を意味します。IOC は、潜在的に望ましくないソフトウェアや確認された **malware** を特定するための **conditions that identify** の集合です。Blue Teams はこの種の定義を使って、自分たちの **systems** や **networks** 内でこの種の悪意あるファイルを **search for this kind of malicious files** します。\ -これらの定義を共有することは非常に有益です。コンピュータで malware が特定され、その malware 用の IOC が作成されると、他の Blue Teams はそれを使って malware をより速く特定できます。 +IOC は Indicator Of Compromise を意味します。IOC は、潜在的に望ましくないソフトウェアや確認済みの **malware** を特定するための **conditions that identify** の集合です。Blue Teams はこの種の定義を使って、自組織の **systems** や **networks** 内で **search for this kind of malicious files** を行います。\ +これらの定義を共有することは有用です。なぜなら、あるコンピュータ上で malware が確認され、その malware の IOC が作成されれば、他の Blue Teams はそれを使ってより速くその malware を特定できるからです。 -IOC を作成または修正するためのツールとして [**IOC Editor**](https://www.fireeye.com/services/freeware/ioc-editor.html)**.**\ -[**Redline**](https://www.fireeye.com/services/freeware/redline.html) のようなツールを使用して、デバイス上で **search for defined IOCs in a device** を行うことができます。 +A tool to create or modify IOCs is [**IOC Editor**](https://www.fireeye.com/services/freeware/ioc-editor.html)**.**\ +You can use tools such as [**Redline**](https://www.fireeye.com/services/freeware/redline.html) to **search for defined IOCs in a device**. ### Loki -[**Loki**](https://github.com/Neo23x0/Loki) は Simple Indicators of Compromise のスキャナーです。\ -検出は4つの検出方法に基づいています: +[**Loki**](https://github.com/Neo23x0/Loki) は Simple Indicators of Compromise を対象としたスキャナーです。\ +Detection is based on four detection methods: ``` 1. File Name IOC Regex match on full file path/name @@ -92,41 +92,41 @@ Compares process connection endpoints with C2 IOCs (new since version v.10) ``` ### Linux Malware Detect -[**Linux Malware Detect (LMD)**](https://www.rfxn.com/projects/linux-malware-detect/) は GNU GPLv2 ライセンスで配布される Linux 向けの malware scanner で、共有ホスティング環境で直面する脅威を念頭に設計されています。network edge intrusion detection systems からの脅威データを使用して、攻撃で実際に使用されている malware を抽出し、検出用の signatures を生成します。さらに、脅威データは LMD の checkout feature を使った user submissions や malware community resources からも得られます。 +[**Linux Malware Detect (LMD)**](https://www.rfxn.com/projects/linux-malware-detect/) は GNU GPLv2 ライセンスで公開された Linux 用の malware scanner で、共有ホスティング環境で直面する脅威を考慮して設計されています。ネットワークエッジの intrusion detection systems から得た threat data を用いて、攻撃で実際に使われている malware を抽出し、検出用のシグネチャを生成します。さらに、threat data は LMD の checkout feature を使ったユーザー提出や malware community resources からも得られます。 ### rkhunter -Tools like [**rkhunter**](http://rkhunter.sourceforge.net) can be used to check the filesystem for possible **rootkits** and malware. +[**rkhunter**](http://rkhunter.sourceforge.net) のようなツールは、ファイルシステムをチェックして可能性のある **rootkits** や malware を検出するために使用できます。 ```bash sudo ./rkhunter --check -r / -l /tmp/rkhunter.log [--report-warnings-only] [--skip-keypress] ``` ### FLOSS -[**FLOSS**](https://github.com/mandiant/flare-floss) は、様々な手法を用いて executables 内の obfuscated strings を検出しようとするツールです。 +[**FLOSS**](https://github.com/mandiant/flare-floss) は、さまざまな手法を用いて実行可能ファイル内の難読化された文字列を検出しようとするツールです。 ### PEpper -[PEpper ](https://github.com/Th3Hurrican3/PEpper) は executable 内の基本的な情報（binary data、entropy、URLs and IPs、some yara rules）をチェックします。 +[PEpper ](https://github.com/Th3Hurrican3/PEpper) は実行可能ファイル内部の基本的な項目（バイナリデータ、エントロピー、URLs と IPs、いくつかの yara ルール）をチェックします。 ### PEstudio -[PEstudio](https://www.winitor.com/download) は、Windows executables の imports、exports、headers といった情報を取得できるツールで、virus total のチェックや潜在的な Att\&ck techniques の検出も行います。 +[PEstudio](https://www.winitor.com/download) は Windows の実行可能ファイルについて、インポート、エクスポート、ヘッダーなどの情報を取得できるツールで、virus total をチェックし、潜在的な Att\&ck テクニックを見つけます。 ### Detect It Easy(DiE) -[**DiE**](https://github.com/horsicq/Detect-It-Easy/) は、ファイルが **encrypted** かどうかを検出し、**packers** を見つけるツールです。 +[**DiE**](https://github.com/horsicq/Detect-It-Easy/) は、ファイルが **暗号化されている** かどうかを検出し、**パッカー** を見つけるツールです。 ### NeoPI -[**NeoPI** ](https://github.com/CiscoCXSecurity/NeoPI) は、様々な **statistical methods** を用いて text/script files 内の **obfuscated** や **encrypted** コンテンツを検出する Python スクリプトです。NeoPI の目的は、**detection of hidden web shell code** を支援することです。 +[**NeoPI** ](https://github.com/CiscoCXSecurity/NeoPI) は、テキスト/スクリプトファイル内の **難読化された** および **暗号化された** コンテンツを検出するために、さまざまな **統計的手法** を用いる Python スクリプトです。NeoPI の目的は、**隠された web shell コードの検出** を支援することです。 ### **php-malware-finder** -[**PHP-malware-finder**](https://github.com/nbs-system/php-malware-finder) は、**obfuscated**/**dodgy code** の検出や、**PHP** 関数を使った **malwares**/webshells によく使われるファイルの検出に最善を尽くします。 +[**PHP-malware-finder**](https://github.com/nbs-system/php-malware-finder) は **難読化された**/**不審なコード** を検出することに注力しており、また **PHP** 関数を多用する **マルウェア**/webshells を含むファイルも検出します。 ### Apple Binary Signatures -いくつかの **malware sample** を調査する際は、署名されたバイナリの **signature** を常に確認してください。署名した **developer** が既に **malware** と関連している可能性があるためです。 +いくつかの **マルウェアサンプル** をチェックする際は、バイナリの **署名を確認する** ことを常に行ってください。署名した **開発者** が既に **マルウェア** と関連している場合があります。 ```bash #Get signer codesign -vv -d /bin/ls 2>&1 | grep -E "Authority|TeamIdentifier" @@ -141,21 +141,21 @@ spctl --assess --verbose /Applications/Safari.app ### File Stacking -もしあるフォルダに含まれる **files** が **last updated on some date** と分かっている場合は、web server の全ての **files** が作成・変更された **date** を確認し、いずれかの **date** が **suspicious** ならそのファイルを調べてください。 +もしあるフォルダに含まれる **files** が **ある日付に最後に更新された** と分かっているなら、**web server** 上のすべての **files** の作成日・更新日を **確認** し、いずれかの日付が **疑わしい** 場合はそのファイルを確認してください。 ### Baselines -フォルダ内の files が **shouldn't have been modified** はずであれば、そのフォルダの **original files** の **hash** を計算して **current** なものと **compare** できます。変更されたものは **suspicious** です。 +フォルダ内のファイルが **変更されてはいけない** 場合、フォルダの **original files** の **hash** を計算して現在のものと **compare** できます。変更されたものは **suspicious** です。 ### Statistical Analysis -情報が logs に保存されている場合、web server の各ファイルが何回アクセスされたかのような統計を **check** できます。web shell が最も多くアクセスされたものの一つかもしれません。 +情報が logs に保存されている場合、web server の各ファイルが何回アクセスされたかのような統計を **確認** できます。web shell が最も多くアクセスされているファイルの1つである可能性があります。 --- ### Android in-app native telemetry (no root) -On Android, you can instrument native code inside the target app process by preloading a tiny logger library before other JNI libs initialize. This gives early visibility into native behavior without system-wide hooks or root. A popular approach is SoTap: drop libsotap.so for the right ABI into the APK and inject a System.loadLibrary("sotap") call early (e.g., static initializer or Application.onCreate), then collect logs from internal/external paths or Logcat fallback. +Android では、ターゲットアプリプロセス内の native code に、他の JNI libs が初期化される前に小さな logger library を preload して計測を仕込むことができます。これによりシステム全体のフックや root を必要とせずにネイティブの挙動を早期に可視化できます。一般的なアプローチは SoTap：対応する ABI 向けに libsotap.so を APK に入れ、早い段階（static initializer や Application.onCreate など）で System.loadLibrary("sotap") を注入し、internal/external パスや Logcat フォールバックからログを収集します。 See the Android native reversing page for setup details and log paths: @@ -180,7 +180,7 @@ mnem = idc.print_insn_mnem(ea) if mnem in ("jmp", "call") and idc.print_operand(ea, 0) == "rax": print(f"[+] Dispatcher found @ {ea:X}") ``` -### 2. ディスパッチャーのバイトコードを抽出する +### 2. dispatcher byte-code を抽出する ```python import idc @@ -211,9 +211,9 @@ mu.reg_write(UC_X86_REG_RAX, 0) mu.emu_start(BASE, BASE+len(code)) return mu.reg_read(UC_X86_REG_RAX) ``` -Run `run(code,0,0)` と `run(code,1,1)` を実行して、*false* および *true* のブランチターゲットを取得する。 +Run `run(code,0,0)` と `run(code,1,1)` を実行して、ブランチの *false* と *true* ターゲットを取得します。 -### 4. パッチで直接 jump / call を元に戻す +### 4. 直接の jump / call をパッチで復元する ```python import struct, ida_bytes @@ -222,22 +222,22 @@ op = 0xE8 if is_call else 0xE9 # CALL rel32 or JMP rel32 disp = target - (ea + 5) & 0xFFFFFFFF ida_bytes.patch_bytes(ea, bytes([op]) + struct.pack(' cat lib/arm64-v8a/libfoo.so" > libfoo.so # Or from the APK (zip) unzip -j target.apk "lib/*/libfoo.so" -d extracted_libs/ ``` -2. **アーキテクチャと保護を特定** +2. **アーキテクチャと保護設定を確認** ```bash file libfoo.so # arm64 or arm32 / x86 readelf -h libfoo.so # OS ABI, PIE, NX, RELRO, etc. checksec --file libfoo.so # (peda/pwntools) ``` -3. **エクスポートされたシンボルとJNIバインディングを列挙** +3. **エクスポートされたシンボルとJNIバインディングの一覧** ```bash readelf -s libfoo.so | grep ' Java_' # dynamic-linked JNI strings libfoo.so | grep -i "RegisterNatives" -n # static-registered JNI ``` -4. **デコンパイラで読み込んで自動解析を実行** (Ghidra ≥ 11.0, IDA Pro, Binary Ninja, Hopper or Cutter/Rizin)。 -新しい Ghidra バージョンは AArch64 decompiler を導入し、PAC/BTI スタブや MTE タグを認識するようになったため、Android 14 NDK でビルドされたライブラリの解析が大幅に改善しています。 -5. **静的解析 vs 動的解析 を決定:** ストリップ済みや難読化されたコードは通常*計測・操作*（Frida, ptrace/gdbserver, LLDB）を必要とします。 +4. **デコンパイラで読み込む** (Ghidra ≥ 11.0, IDA Pro, Binary Ninja, Hopper or Cutter/Rizin) と自動解析を実行。 +新しいGhidraバージョンはAArch64デコンパイラを導入し、PAC/BTIスタブやMTEタグを認識するため、Android 14 NDKでビルドされたライブラリの解析が大幅に改善されています。 +5. **静的解析と動的解析を選定:** ストリップされ難読化されたコードはしばしば *instrumentation*（Frida, ptrace/gdbserver, LLDB）が必要になります。 --- ### Dynamic Instrumentation (Frida ≥ 16) -Frida の 16 系では、ターゲットが最新の Clang/LLD 最適化を使用している場合に役立つ、Android 固有の改善がいくつか導入されました: +Fridaの16系列は、ターゲットが最新のClang/LLD最適化を使用している場合に役立つ、いくつかのAndroid特有の改善をもたらしました： -* `thumb-relocator` は、LLD の攻撃的なアラインメント（`--icf=all`）によって生成される小さな ARM/Thumb 関数を*フックできるようになりました*。 -* 列挙と再バインドによる*ELF import slots*の操作が Android で動作するようになり、inline hooks が拒否された場合にモジュール単位での `dlopen()`/`dlsym()` パッチが可能になりました。 -* Java フッキングは、Android 14 でアプリが `--enable-optimizations` でコンパイルされた際に使用される新しい **ART quick-entrypoint** に対応するよう修正されました。 +* `thumb-relocator` は、LLDの積極的なアラインメント（`--icf=all`）で生成される小さな ARM/Thumb 関数を hook できるようになりました。 +* Android上で*ELF import slots*の列挙と再バインドが動作するようになり、inline hooksが拒否された場合にモジュール単位での `dlopen()`/`dlsym()` パッチ適用が可能になりました。 +* Android 14で `--enable-optimizations` 付きでコンパイルされたアプリが使用する新しい **ART quick-entrypoint** に対する Java hooking が修正されました。 -Example: `RegisterNatives` を通じて登録されたすべての関数を列挙し、実行時にそのアドレスをダンプする: +例: `RegisterNatives` を通じて登録されたすべての関数を列挙し、実行時にそのアドレスをダンプする: ```javascript Java.perform(function () { var Runtime = Java.use('java.lang.Runtime'); @@ -61,11 +61,11 @@ console.log('[+] RegisterNatives on ' + clazz.getName() + ' -> ' + count + ' met }); }); ``` -Fridaは、PAC/BTI-enabled devices (Pixel 8/Android 14+) 上でも frida-server 16.2 以降を使用すればそのまま動作します — それ以前のバージョンは inline hooks 用のパディングを検出できませんでした。 +Fridaは、PAC/BTI-enabledデバイス（Pixel 8/Android 14+）で、frida-server 16.2以降を使用すればそのまま動作します — それ以前のバージョンはinline hooks用のパディングを検出できませんでした。 -### 事前読み込みされた .so によるプロセスローカル JNI テレメトリ (SoTap) +### Process-local JNI telemetry via preloaded .so (SoTap) -full-featured instrumentation が過剰またはブロックされている場合でも、ターゲットプロセス内に小さなロガーを事前読み込みすることでネイティブレベルの可視性を得られます。SoTap は同一アプリプロセス内の他の JNI (.so) ライブラリの実行時挙動をログする軽量の Android ネイティブ (.so) ライブラリです（root 不要）。 +フル機能のinstrumentationが過剰だったりブロックされている場合でも、ターゲットプロセス内に小さなロガーを事前ロードすることでネイティブレベルの可視性を得られます。SoTapは軽量なAndroidネイティブ（.so）ライブラリで、同一アプリプロセス内の他のJNI（.so）ライブラリの実行時挙動をログに記録します（root不要）。 Key properties: - Initializes early and observes JNI/native interactions inside the process that loads it. @@ -73,7 +73,7 @@ Key properties: - Source-customizable: edit sotap.c to extend/adjust what gets logged and rebuild per ABI. Setup (repack the APK): -1) Drop the proper ABI build into the APK so the loader can resolve libsotap.so: +1) ローダーがlibsotap.soを解決できるよう、適切なABIビルドをAPKに入れる: - lib/arm64-v8a/libsotap.so (for arm64) - lib/armeabi-v7a/libsotap.so (for arm32) 2) Ensure SoTap loads before other JNI libs. Inject a call early (e.g., Application subclass static initializer or onCreate) so the logger is initialized first. Smali snippet example: @@ -92,40 +92,40 @@ Log paths (checked in order): # If all fail: fallback to Logcat only ``` Notes and troubleshooting: -- ABIの整合は必須です。ミスマッチがあると UnsatisfiedLinkError が発生し、ロガーはロードされません。 -- 現代の Android ではストレージ制約が一般的です。ファイル書き込みに失敗した場合でも、SoTap は Logcat 経由で出力します。 -- 動作／冗長性はカスタマイズすることを想定しています。sotap.c を編集したらソースから再ビルドしてください。 +- ABI アラインメントは必須です。ミスマッチがあると UnsatisfiedLinkError が発生し、logger はロードされません。 +- 近年の Android ではストレージ制約が一般的です。ファイル書き込みが失敗しても、SoTap は Logcat 経由で出力します。 +- 動作や冗長度はカスタマイズを想定しています。編集後はソースから再ビルドしてください（sotap.c を編集した場合）。 -このアプローチは、プロセス開始時からのネイティブ呼び出しフローを観察することが重要で、root やシステム全体のフックが利用できない場合の malware triage と JNI デバッグに有用です。 +この手法は、プロセス開始時点からネイティブ呼び出しフローを観察することが重要で、root / system-wide hooks が使えない状況での malware トリアージや JNI デバッグに有用です。 --- -### APK 内で探す価値のある最近の脆弱性 +### Recent vulnerabilities worth hunting for in APKs -| 年 | CVE | 影響ライブラリ | 備考 | +| Year | CVE | Affected library | Notes | |------|-----|------------------|-------| -|2023|CVE-2023-4863|`libwebp` ≤ 1.3.1|WebP 画像をデコードするネイティブコードから到達可能なヒープバッファオーバーフロー。複数の Android アプリが脆弱なバージョンをバンドルしています。APK 内に `libwebp.so` がある場合は、そのバージョンを確認し、エクスプロイトまたはパッチ適用を試みてください.| | -|2024|Multiple|OpenSSL 3.x series|複数のメモリ安全性の問題やパディングオラクル問題。多くの Flutter & ReactNative バンドルは独自の `libcrypto.so` を同梱します。| +|2023|CVE-2023-4863|`libwebp` ≤ 1.3.1|WebP 画像をデコードするネイティブコードから到達可能なヒープバッファオーバーフロー。複数の Android アプリが脆弱なバージョンをバンドルしています。APK 内に `libwebp.so` を見つけたら、そのバージョンを確認し、エクスプロイトまたはパッチの検討を行ってください.| | +|2024|Multiple|OpenSSL 3.x series|複数のメモリ安全性やパディングオラクル関連の問題。多くの Flutter & ReactNative バンドルは独自の `libcrypto.so` を同梱しています。| -APK 内で *third-party* の `.so` ファイルを見つけたら、必ず上流のアドバイザリとハッシュを照合してください。SCA (Software Composition Analysis) はモバイルではあまり行われないため、古い脆弱なビルドが蔓延しています。 +APK 内にサードパーティの `.so` ファイルを見つけたら、必ず上流のアドバイザリとハッシュを突き合わせて確認してください。SCA (Software Composition Analysis) はモバイルでは普及しておらず、古い脆弱なビルドが横行しています。 --- -### 逆解析対策とハードニングの傾向 (Android 13-15) +### Anti-Reversing & Hardening trends (Android 13-15) -* **Pointer Authentication (PAC) & Branch Target Identification (BTI):** Android 14 は、サポートされる ARMv8.3+ シリコン上のシステムライブラリで PAC/BTI を有効にします。Decompilers は現在 PAC 関連の疑似命令を表示します。動的解析では Frida が PAC を剥がした後にトランポリンを注入しますが、カスタムトランポリンは必要に応じて `pacda`/`autibsp` を呼び出すべきです。 -* **MTE & Scudo hardened allocator:** memory-tagging はオプトインですが、多くの Play-Integrity 対応アプリは `-fsanitize=memtag` でビルドしています。タグフォルトを捕捉するには `setprop arm64.memtag.dump 1` と `adb shell am start ...` を使用してください。 -* **LLVM Obfuscator (opaque predicates, control-flow flattening):** 商用のパッカー（例: Bangcle, SecNeo）はネイティブコードも保護することが増え、Java のみならず `.rodata` に偽のコントロールフローや暗号化された文字列ブロブが存在することを想定してください。 +* **Pointer Authentication (PAC) & Branch Target Identification (BTI):** Android 14 は対応する ARMv8.3+ シリコン上でシステムライブラリに対して PAC/BTI を有効にします。Decompiler は PAC 関連の疑似命令を表示するようになりました。動的解析では Frida が PAC を剥がした後でトランポリンを挿入しますが、カスタムトランポリンは必要に応じて `pacda`/`autibsp` を呼び出すべきです。 +* **MTE & Scudo hardened allocator:** メモリタグ付けはオプトインですが、多くの Play-Integrity 対応アプリは `-fsanitize=memtag` でビルドしています。タグ違反を取得するには `setprop arm64.memtag.dump 1` と `adb shell am start ...` を組み合わせてください。 +* **LLVM Obfuscator (opaque predicates, control-flow flattening):** 商用パッカー（例: Bangcle、SecNeo）はネイティブコードも保護対象にすることが増えています。疑似的なコントロールフローや `.rodata` 内の暗号化された文字列ブロブに注意してください。 --- -### リソース +### Resources - **Learning ARM Assembly:** [Azeria Labs – ARM Assembly Basics](https://azeria-labs.com/writing-arm-assembly-part-1/) - **JNI & NDK Documentation:** [Oracle JNI Spec](https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/jniTOC.html) · [Android JNI Tips](https://developer.android.com/training/articles/perf-jni) · [NDK Guides](https://developer.android.com/ndk/guides/) - **Debugging Native Libraries:** [Debug Android Native Libraries Using JEB Decompiler](https://medium.com/@shubhamsonani/how-to-debug-android-native-libraries-using-jeb-decompiler-eec681a22cf3) -### 参考 +### References - Frida 16.x change-log (Android hooking, tiny-function relocation) – [frida.re/news](https://frida.re/news/) - NVD advisory for `libwebp` overflow CVE-2023-4863 – [nvd.nist.gov](https://nvd.nist.gov/vuln/detail/CVE-2023-4863) diff --git a/src/mobile-pentesting/android-app-pentesting/smali-changes.md b/src/mobile-pentesting/android-app-pentesting/smali-changes.md index 4bf6199cf..deaf6eba0 100644 --- a/src/mobile-pentesting/android-app-pentesting/smali-changes.md +++ b/src/mobile-pentesting/android-app-pentesting/smali-changes.md @@ -1,86 +1,86 @@ -# Smali - 逆コンパイル/[修正]/コンパイル +# Smali - デコンパイル/[変更]/コンパイル {{#include ../../banners/hacktricks-training.md}} -アプリケーションのコードを変更して隠された情報（例えば難読化されたパスワードやフラグ）にアクセスすることが有用な場合があります。その場合、apkを逆コンパイルしてコードを修正し、再コンパイルすることが有効です。 +アプリケーションのコードを変更して隠された情報にアクセスすること（難読化されたパスワードやフラグなど）が有用な場合があります。その際、apk をデコンパイルしてコードを変更し、再コンパイルすることが有用です。 -**Opcodes リファレンス:** [http://pallergabor.uw.hu/androidblog/dalvik_opcodes.html](http://pallergabor.uw.hu/androidblog/dalvik_opcodes.html) +**オペコード参照:** [http://pallergabor.uw.hu/androidblog/dalvik_opcodes.html](http://pallergabor.uw.hu/androidblog/dalvik_opcodes.html) -## 簡単な方法 +## 手早い方法 Using **Visual Studio Code** and the [APKLab](https://github.com/APKLab/APKLab) extension, you can **automatically decompile**, modify, **recompile**, sign & install the application without executing any command. -Another **script** that facilitates this task a lot is [**https://github.com/ax/apk.sh**](https://github.com/ax/apk.sh) +この作業を大幅に簡単にする別の**スクリプト**は [**https://github.com/ax/apk.sh**](https://github.com/ax/apk.sh) です。 -## Decompile the APK +## APK をデコンパイルする -APKTool を使用すると **smali code and resources** にアクセスできます： +APKTool を使用すると、**smali コードとリソース**にアクセスできます: ```bash apktool d APP.apk ``` -もし**apktool**がエラーを出す場合は、[ installing the **latest version**](https://ibotpeaches.github.io/Apktool/install/) をインストールしてみてください。 +もし **apktool** がエラーを返す場合は、[ installing the **latest version**](https://ibotpeaches.github.io/Apktool/install/) をインストールしてみてください。 -Some **interesting files you should look are**: +調べるべき**興味深いファイル**: -- _res/values/strings.xml_ (and all xmls inside res/values/*) +- _res/values/strings.xml_ (および res/values/* 内のすべての xml) - _AndroidManifest.xml_ -- Any file with extension _.sqlite_ or _.db_ +- 拡張子が _.sqlite_ または _.db_ のファイル -もし `apktool` がアプリケーションのデコードに**問題がある場合**、[https://ibotpeaches.github.io/Apktool/documentation/#framework-files](https://ibotpeaches.github.io/Apktool/documentation/#framework-files) を確認するか、引数 **`-r`**（リソースをデコードしない）を使ってみてください。もし問題がリソース側にありソースコード側にない場合、この方法で問題を回避できます（リソースはデコンパイルされません）。 +`apktool` が**アプリケーションのデコードに問題がある**場合は、[https://ibotpeaches.github.io/Apktool/documentation/#framework-files](https://ibotpeaches.github.io/Apktool/documentation/#framework-files) を参照するか、引数 **`-r`**（リソースをデコードしない）を試してください。問題がソースコードではなくリソース側にある場合、これで問題は発生しなくなります（リソースはデコンパイルされません）。 -## Change smali code +## smali コードの変更 -命令を**変更**したり、いくつかの変数の**値**を変更したり、新しい命令を**追加**することができます。私はSmaliコードを[**VS Code**](https://code.visualstudio.com)で編集します。**smalise extension**をインストールすると、エディタが命令に誤りがあるかどうかを教えてくれます。\ +命令を**変更**したり、いくつかの変数の**値**を変更したり、新しい命令を**追加**したりできます。私は Smali コードを [**VS Code**](https://code.visualstudio.com) で編集します。smalise extension をインストールすると、エディタが不正な**命令**を教えてくれます。\ いくつかの**例**は以下にあります: - [Smali changes examples](smali-changes.md) - [Google CTF 2018 - Shall We Play a Game?](google-ctf-2018-shall-we-play-a-game.md) -または、[**check below some Smali changes explained**](smali-changes.md#modifying-smali) を確認してください。 +または [**check below some Smali changes explained**](smali-changes.md#modifying-smali) を参照してください。 -## Recompile the APK +## APK を再コンパイルする -コードを変更した後、次のコマンドでコードを**再コンパイル**できます： +コードを変更した後、次のようにしてコードを**再コンパイル**できます: ```bash apktool b . #In the folder generated when you decompiled the application ``` -新しい APK は _**dist**_ フォルダ内でコンパイルされます。 +これにより、新しい APK が _**dist**_ フォルダの**内部**で**コンパイル**されます。 -もし **apktool** がエラーを出す場合は、[最新バージョンをインストールしてみてください](https://ibotpeaches.github.io/Apktool/install/) +もし **apktool** が**エラー**を出す場合は、[**最新バージョン**をインストールしてみてください](https://ibotpeaches.github.io/Apktool/install/)。 ### **新しい APK に署名する** -次に、**キーを生成する**必要があります（パスワードや、ランダムに入力して構わないいくつかの情報を尋ねられます）: +次に、**キーを生成**する必要があります（パスワードやランダムに入力して構わないいくつかの情報を尋ねられます）: ```bash keytool -genkey -v -keystore key.jks -keyalg RSA -keysize 2048 -validity 10000 -alias ``` -最後に、新しい APK に **署名**してください: +最後に、**署名**して新しいAPKを作成します： ```bash jarsigner -keystore key.jks path/to/dist/* ``` -### 新しいアプリケーションを最適化 +### 新しいアプリケーションの最適化 -**zipalign** は、Android application (APK) files に重要な最適化を提供するアーカイブ整列ツールです。 [More information here](https://developer.android.com/studio/command-line/zipalign). +**zipalign** は、Android application (APK) files に対して重要な最適化を提供するアーカイブ整列ツールです。 [More information here](https://developer.android.com/studio/command-line/zipalign). ```bash zipalign [-f] [-v] infile.apk outfile.apk zipalign -v 4 infile.apk ``` ### **新しい APK に署名（また？）** -もし **好む** なら [**apksigner**](https://developer.android.com/studio/command-line/) を jarsigner の代わりに使う場合は、**zipaling による最適化** を適用した後で apk に **署名してください**。ただし、jarsigner（zipalign の前）で、または aspsigner（zipaling の後）で **アプリケーションを一度だけ署名すればよい** という点に注意してください。 +もし jarsigner の代わりに [**apksigner**](https://developer.android.com/studio/command-line/) を使うことを**好む**なら、zipaling による**最適化を適用した後に**APK に**署名するべきです**。ただし、アプリケーションは jarsigner（zipalign の前）で、または aspsigner（zipaling の後）で**一度だけ署名すればよい**という点に注意してください。 ```bash apksigner sign --ks key.jks ./dist/mycompiled.apk ``` ## Smaliの変更 -以下の Hello World Java コードの場合: +次の Hello World Java コードの場合： ```java public static void printHelloWorld() { System.out.println("Hello World") } ``` -Smali コードは次のようになります: +Smali のコードは次のようになります: ```java .method public static printHelloWorld()V .registers 2 @@ -90,13 +90,13 @@ invoke-virtual {v0,v1}, Ljava/io/PrintStream;->println(Ljava/lang/String;)V return-void .end method ``` -Smali命令セットは[here](https://source.android.com/devices/tech/dalvik/dalvik-bytecode#instructions)で参照できます。 +Smali の命令セットは [here](https://source.android.com/devices/tech/dalvik/dalvik-bytecode#instructions) で確認できます。 ### 軽微な変更 -### 関数内で変数の初期値を変更する +### 関数内の変数の初期値を変更する -いくつかの変数は関数の先頭で opcode _const_ を使って定義されており、その値を変更したり、新しい変数を定義したりできます: +一部の変数は関数の先頭で opcode _const_ を使って定義されています。値を変更したり、新しいものを定義したりできます: ```bash #Number const v9, 0xf4240 @@ -127,7 +127,7 @@ iput v0, p0, Lcom/google/ctf/shallweplayagame/GameActivity;->o:I #Save v0 inside if-ne v0, v9, :goto_6 #If not equals, go to: :goto_6 goto :goto_6 #Always go to: :goto_6 ``` -### 大きな変更点 +### 大きな変更 ### ロギング ```bash @@ -140,17 +140,17 @@ invoke-static {v5, v1}, Landroid/util/Log;->d(Ljava/lang/String;Ljava/lang/Strin ``` 推奨事項: -- 関数内で宣言済みの変数（宣言された v0,v1,v2...）を使用する場合、これらの行を _.local _ と変数の宣言（_const v0, 0x1_）の間に置いてください。 -- 関数のコードの途中にログ用コードを挿入したい場合: -- 宣言済み変数の数に2を足します：例: _.locals 10_ から _.locals 12_ -- 新しい変数は既に宣言されている変数の次の番号にします（この例では _v10_ と _v11_ になります。先頭は v0 から始まることを忘れないでください）。 -- ログ関数のコードを変更し、_v10_ と _v11_ を _v5_ と _v1_ の代わりに使用してください。 +- 関数内で宣言済みの変数を使用する場合（宣言は v0,v1,v2...）、これらの行を _.local _ と変数の宣言（_const v0, 0x1_）の間に入れてください。 +- 関数のコードの途中にロギングコードを置きたい場合: +- 宣言済み変数の数に2を追加してください。例: _.locals 10_ から _.locals 12_ へ +- 新しい変数は既に宣言されている変数の次の番号にしてください（この例では _v10_ と _v11_ になります。v0 から始まることを忘れないでください）。 +- ロギング関数のコードを変更し、_v10_ と _v11_ を _v5_ と _v1_ の代わりに使用してください。 ### トースト表示 関数の先頭で _.locals_ の数に3を追加することを忘れないでください。 -このコードは **関数の途中** に挿入するために準備されています（必要に応じて **変数** の数を変更してください）。これは **this.o** の値を取得して **String** に変換し、その値で **toast** を表示します。 +このコードは **関数の途中** に挿入するために用意されています（必要に応じて **変数** の数を変更してください）。this.o の値を取得し、String に変換して、その値で toast を表示します。 ```bash const/4 v10, 0x1 const/4 v11, 0x1 @@ -162,9 +162,9 @@ invoke-static {p0, v11, v12}, Landroid/widget/Toast;->makeText(Landroid/content/ move-result-object v12 invoke-virtual {v12}, Landroid/widget/Toast;->show()V ``` -### 起動時にネイティブライブラリを読み込む (System.loadLibrary) +### スタートアップでネイティブライブラリをロードする (System.loadLibrary) -場合によっては、他の JNI libs より先に初期化されるようにネイティブライブラリを事前ロードする必要があります（例: プロセスローカルのテレメトリ/ロギングを有効にするため）。静的イニシャライザまたは Application.onCreate() の早い段階に System.loadLibrary() の呼び出しを注入できます。静的クラスイニシャライザ () の smali 例: +他の JNI ライブラリより先に初期化されるように、ネイティブライブラリを事前にロードする必要があることがあります（例: プロセスローカルの telemetry/logging を有効にするため）。System.loadLibrary() の呼び出しを static 初期化子または Application.onCreate() の早い段階に注入できます。static クラスイニシャライザ () の smali の例: ```smali .class public Lcom/example/App; .super Landroid/app/Application; @@ -176,7 +176,7 @@ invoke-static {v0}, Ljava/lang/System;->loadLibrary(Ljava/lang/String;)V return-void .end method ``` -あるいは、同じ2つの命令を Application.onCreate() の先頭に配置して、ライブラリができるだけ早くロードされるようにしてください: +あるいは、同じ2つの命令を Application.onCreate() の先頭に置いて、ライブラリが可能な限り早くロードされるようにします: ```smali .method public onCreate()V .locals 1 @@ -188,12 +188,12 @@ invoke-super {p0}, Landroid/app/Application;->onCreate()V return-void .end method ``` -注意: -- UnsatisfiedLinkErrorを避けるため、ライブラリの正しいABIバリアントが lib//（例: arm64-v8a/armeabi-v7a）に存在することを確認してください。 -- 非常に早いタイミング（class static initializer）でロードすると、native loggerがその後のJNI活動を観測できることが保証されます。 +注意事項: +- ライブラリの正しい ABI バリアントが lib//（例: arm64-v8a/armeabi-v7a）の下に存在することを確認し、UnsatisfiedLinkError を回避してください。 +- 非常に早い段階で読み込む（class static initializer）ことで、native logger が以後の JNI activity を観測できることが保証されます。 ## 参考 -- SoTap: アプリ内での JNI (.so) 挙動を記録する軽量 logger – [github.com/RezaArbabBot/SoTap](https://github.com/RezaArbabBot/SoTap) +- SoTap: 軽量なアプリ内 JNI (.so) 挙動ロガー – [github.com/RezaArbabBot/SoTap](https://github.com/RezaArbabBot/SoTap) {{#include ../../banners/hacktricks-training.md}}