macOSアプリ - 検査、デバッグ、ファジング

Reading time: 37 minutes

静的解析

otool & objdump & nm

otool -L /bin/ls #List dynamically linked libraries
otool -tv /bin/ps #Decompile application

objdump -m --dylibs-used /bin/ls #List dynamically linked libraries
objdump -m -h /bin/ls # Get headers information
objdump -m --syms /bin/ls # Check if the symbol table exists to get function names
objdump -m --full-contents /bin/ls # Dump every section
objdump -d /bin/ls # Dissasemble the binary
objdump --disassemble-symbols=_hello --x86-asm-syntax=intel toolsdemo #Disassemble a function using intel flavour

nm -m ./tccd # List of symbols

jtool2 & Disarm

ここからdisarmをダウンロードできます。

ARCH=arm64e disarm -c -i -I --signature /path/bin # Get bin info and signature
ARCH=arm64e disarm -c -l /path/bin # Get binary sections
ARCH=arm64e disarm -c -L /path/bin # Get binary commands (dependencies included)
ARCH=arm64e disarm -c -S /path/bin # Get symbols (func names, strings...)
ARCH=arm64e disarm -c -d /path/bin # Get disasembled
jtool2 -d __DATA.__const myipc_server | grep MIG # Get MIG info

ここからjtool2をダウンロードするか、brewを使ってインストールできます。

# Install
brew install --cask jtool2

jtool2 -l /bin/ls # Get commands (headers)
jtool2 -L /bin/ls # Get libraries
jtool2 -S /bin/ls # Get symbol info
jtool2 -d /bin/ls # Dump binary
jtool2 -D /bin/ls # Decompile binary

# Get signature information
ARCH=x86_64 jtool2 --sig /System/Applications/Automator.app/Contents/MacOS/Automator

# Get MIG information
jtool2 -d __DATA.__const myipc_server | grep MIG

[!CAUTION] > jtoolはdisarmに取って代わられました

Codesign / ldid

[!TIP] > CodesignはmacOSにあり、ldidはiOSにあります

# Get signer
codesign -vv -d /bin/ls 2>&1 | grep -E "Authority|TeamIdentifier"

# Check if the app’s contents have been modified
codesign --verify --verbose /Applications/Safari.app

# Get entitlements from the binary
codesign -d --entitlements :- /System/Applications/Automator.app # Check the TCC perms

# Check if the signature is valid
spctl --assess --verbose /Applications/Safari.app

# Sign a binary
codesign -s <cert-name-keychain> toolsdemo

# Get signature info
ldid -h <binary>

# Get entitlements
ldid -e <binary>

# Change entilements
## /tmp/entl.xml is a XML file with the new entitlements to add
ldid -S/tmp/entl.xml <binary>

SuspiciousPackage

SuspiciousPackage は、.pkg ファイル（インストーラー）を検査し、インストールする前にその内容を確認するのに役立つツールです。
これらのインストーラーには、マルウェア作成者が通常悪用する preinstall および postinstall bash スクリプトがあります。

hdiutil

このツールは、Apple のディスクイメージ（.dmg）ファイルをマウントして、何かを実行する前に検査することを可能にします：

hdiutil attach ~/Downloads/Firefox\ 58.0.2.dmg

It will be mounted in /Volumes

Packed binaries

• 高エントロピーをチェック
• 文字列をチェック（理解できる文字列がほとんどない場合、パックされている）
• MacOS用のUPXパッカーは、"__XHDR"というセクションを生成します。

Static Objective-C analysis

Metadata

• 定義されたインターフェース
• インターフェースメソッド
• インターフェースインスタンス変数
• 定義されたプロトコル

これらの名前は、バイナリのリバースエンジニアリングをより困難にするために難読化される可能性があることに注意してください。

Function calling

Objective-Cを使用するバイナリで関数が呼び出されると、コンパイルされたコードはその関数を呼び出すのではなく、**objc_msgSend**を呼び出します。これが最終的な関数を呼び出します：

この関数が期待するパラメータは次のとおりです：

• 最初のパラメータ（self）は、「メッセージを受け取るクラスのインスタンスを指すポインタ」です。簡単に言えば、メソッドが呼び出されるオブジェクトです。メソッドがクラスメソッドの場合、これはクラスオブジェクトのインスタンス（全体）になりますが、インスタンスメソッドの場合、selfはクラスのインスタンス化されたオブジェクトを指します。
• 2番目のパラメータ（op）は、「メッセージを処理するメソッドのセレクタ」です。再度、簡単に言えば、これはメソッドの名前です。
• 残りのパラメータは、メソッドに必要な値（op）です。

この情報をARM64でlldbを使って簡単に取得する方法をこのページで確認してください：

Introduction to ARM64v8

x64:

Dump ObjectiveC metadata

Dynadump

Dynadumpは、Objective-Cバイナリをクラスダンプするためのツールです。GitHubではdylibsが指定されていますが、実行可能ファイルでも機能します。

./dynadump dump /path/to/bin

執筆時点では、これは現在最も効果的なものです。

一般的なツール

nm --dyldinfo-only /path/to/bin
otool -ov /path/to/bin
objdump --macho --objc-meta-data /path/to/bin

class-dump

class-dump は、ObjectiveC形式のコードでクラス、カテゴリ、およびプロトコルの宣言を生成するための元のツールです。

古くてメンテナンスされていないため、正しく動作しない可能性があります。

ICDump

iCDump は、モダンでクロスプラットフォームのObjective-Cクラスダンプです。既存のツールと比較して、iCDumpはAppleエコシステムから独立して実行でき、Pythonバインディングを公開しています。

import icdump
metadata = icdump.objc.parse("/path/to/bin")

print(metadata.to_decl())

Static Swift analysis

Swiftバイナリでは、Objective-Cとの互換性があるため、時々class-dumpを使用して宣言を抽出できますが、常に可能というわけではありません。

**jtool -lまたはotool -lコマンドラインを使用すると、__swift5**プレフィックスで始まるいくつかのセクションを見つけることができます:

jtool2 -l /Applications/Stocks.app/Contents/MacOS/Stocks
LC 00: LC_SEGMENT_64              Mem: 0x000000000-0x100000000    __PAGEZERO
LC 01: LC_SEGMENT_64              Mem: 0x100000000-0x100028000    __TEXT
[...]
Mem: 0x100026630-0x100026d54        __TEXT.__swift5_typeref
Mem: 0x100026d60-0x100027061        __TEXT.__swift5_reflstr
Mem: 0x100027064-0x1000274cc        __TEXT.__swift5_fieldmd
Mem: 0x1000274cc-0x100027608        __TEXT.__swift5_capture
[...]

これらのセクションに保存されている情報についての詳細は、このブログ投稿で見つけることができます。

さらに、Swiftバイナリにはシンボルが含まれている可能性があります（たとえば、ライブラリはその関数を呼び出すためにシンボルを保存する必要があります）。シンボルには通常、関数名と属性に関する情報が含まれていますが、見栄えが悪いため非常に便利であり、元の名前を取得できる「デマンガラー」があります。

# Ghidra plugin
https://github.com/ghidraninja/ghidra_scripts/blob/master/swift_demangler.py

# Swift cli
swift demangle

ダイナミック分析

APIs

macOSはプロセスに関する情報を提供するいくつかの興味深いAPIを公開しています：

• proc_info: 各プロセスに関する多くの情報を提供する主要なAPIです。他のプロセスの情報を取得するにはroot権限が必要ですが、特別な権限やmachポートは必要ありません。
• libsysmon.dylib: XPCで公開された関数を介してプロセスに関する情報を取得することを可能にしますが、com.apple.sysmond.clientの権限が必要です。

Stackshot & microstackshots

Stackshottingは、プロセスの状態をキャプチャするための技術で、すべての実行中のスレッドのコールスタックを含みます。これは、デバッグ、パフォーマンス分析、特定の時点でのシステムの動作を理解するために特に有用です。iOSおよびmacOSでは、**sampleやspindump**などのツールや方法を使用してstackshottingを実行できます。

Sysdiagnose

このツール（/usr/bini/ysdiagnose）は、基本的にps、zprintなどの数十の異なるコマンドを実行してコンピュータから多くの情報を収集します。

rootとして実行する必要があり、デーモン/usr/libexec/sysdiagnosedには、com.apple.system-task-portsやget-task-allowなどの非常に興味深い権限があります。

そのplistは/System/Library/LaunchDaemons/com.apple.sysdiagnose.plistにあり、3つのMachServicesを宣言しています：

• com.apple.sysdiagnose.CacheDelete: /var/rmp内の古いアーカイブを削除します
• com.apple.sysdiagnose.kernel.ipc: 特殊ポート23（カーネル）
• com.apple.sysdiagnose.service.xpc: Libsysdiagnose Obj-Cクラスを介したユーザーモードインターフェース。辞書内に3つの引数を渡すことができます（compress、display、run）

統一ログ

MacOSは、アプリケーションを実行して何をしているのかを理解する際に非常に役立つ多くのログを生成します。

さらに、いくつかのログには<private>タグが含まれ、ユーザーまたはコンピュータの識別可能な情報を隠すために使用されます。ただし、この情報を開示するための証明書をインストールすることが可能です。詳細はこちらを参照してください。

Hopper

左パネル

Hopperの左パネルでは、バイナリのシンボル（Labels）、手続きと関数のリスト（Proc）、および文字列（Str）を見ることができます。これらはすべての文字列ではなく、Mac-Oファイルのいくつかの部分（_cstringやobjc_methnameなど）で定義されたものです。

中央パネル

中央パネルでは、逆アセンブルされたコードを見ることができます。また、生の逆アセンブル、グラフ、デコンパイルされたもの、バイナリとしてそれぞれのアイコンをクリックすることで表示できます：

コードオブジェクトを右クリックすると、そのオブジェクトへの参照や参照元を見ることができ、名前を変更することもできます（これはデコンパイルされた擬似コードでは機能しません）：

さらに、中央下部ではPythonコマンドを入力できます。

右パネル

右パネルでは、ナビゲーション履歴（現在の状況に到達した方法を知るため）、コールグラフ（この関数を呼び出すすべての関数と、この関数が呼び出すすべての関数を見ることができます）、およびローカル変数の情報など、興味深い情報を見ることができます。

dtrace

これは、ユーザーがアプリケーションに非常に低レベルでアクセスできるようにし、プログラムをトレースし、その実行フローを変更する方法を提供します。Dtraceは、カーネル全体に配置されたプローブを使用し、システムコールの開始と終了などの場所にあります。

DTraceは、各システムコールのプローブを作成するために**dtrace_probe_create関数を使用します。これらのプローブは、各システムコールのエントリポイントとエグジットポイント**で発火することができます。DTraceとのインタラクションは、/dev/dtraceを介して行われ、これはrootユーザーのみが利用可能です。

dtraceの利用可能なプローブは次のコマンドで取得できます：

dtrace -l | head
ID   PROVIDER            MODULE                          FUNCTION NAME
1     dtrace                                                     BEGIN
2     dtrace                                                     END
3     dtrace                                                     ERROR
43    profile                                                     profile-97
44    profile                                                     profile-199

プローブ名は、プロバイダー、モジュール、関数、および名前（fbt:mach_kernel:ptrace:entry）の4つの部分で構成されています。名前の一部を指定しない場合、Dtraceはその部分をワイルドカードとして適用します。

DTraceを構成してプローブをアクティブにし、発火したときに実行するアクションを指定するには、D言語を使用する必要があります。

より詳細な説明と例については、https://illumos.org/books/dtrace/chp-intro.htmlを参照してください。

例

man -k dtraceを実行して利用可能なDTraceスクリプトのリストを表示します。例: sudo dtruss -n binary

#Count the number of syscalls of each running process
sudo dtrace -n 'syscall:::entry {@[execname] = count()}'

• スクリプト

syscall:::entry
/pid == $1/
{
}

#Log every syscall of a PID
sudo dtrace -s script.d 1234

syscall::open:entry
{
printf("%s(%s)", probefunc, copyinstr(arg0));
}
syscall::close:entry
{
printf("%s(%d)\n", probefunc, arg0);
}

#Log files opened and closed by a process
sudo dtrace -s b.d -c "cat /etc/hosts"

syscall:::entry
{
;
}
syscall:::return
{
printf("=%d\n", arg1);
}

#Log sys calls with values
sudo dtrace -s syscalls_info.d -c "cat /etc/hosts"

dtruss

dtruss -c ls #Get syscalls of ls
dtruss -c -p 1000 #get syscalls of PID 1000

kdebug

これはカーネルトレース機能です。文書化されたコードは**/usr/share/misc/trace.codes**にあります。

latency、sc_usage、fs_usage、およびtraceのようなツールは内部でこれを使用します。

kdebugとインターフェースするために、sysctlがkern.kdebug名前空間を介して使用され、使用するMIBはsys/sysctl.hにあり、関数はbsd/kern/kdebug.cに実装されています。

カスタムクライアントでkdebugと対話するための一般的な手順は次のとおりです：

• KERN_KDSETREMOVEで既存の設定を削除
• KERN_KDSETBUFおよびKERN_KDSETUPでトレースを設定
• KERN_KDGETBUFを使用してバッファエントリの数を取得
• KERN_KDPINDEXでトレースから自分のクライアントを取得
• KERN_KDENABLEでトレースを有効化
• KERN_KDREADTRを呼び出してバッファを読み取る
• 各スレッドをそのプロセスにマッピングするにはKERN_KDTHRMAPを呼び出します。

この情報を取得するために、Appleのツール**trace**またはカスタムツールkDebugView (kdv)を使用することができます。

Kdebugは同時に1つの顧客にのみ利用可能であることに注意してください。 したがって、同時に実行できるk-debug対応ツールは1つだけです。

ktrace

ktrace_* APIはlibktrace.dylibから来ており、これがKdebugのラッパーです。クライアントはktrace_session_createおよびktrace_events_[single/class]を呼び出して特定のコードにコールバックを設定し、ktrace_startで開始できます。

これはSIPが有効な状態でも使用できます。

クライアントとしてユーティリティktraceを使用できます：

ktrace trace -s -S -t c -c ls | grep "ls("

Or tailspin.

kperf

これはカーネルレベルのプロファイリングを行うために使用され、Kdebug コールアウトを使用して構築されています。

基本的に、グローバル変数 kernel_debug_active がチェックされ、設定されている場合は kperf_kdebug_handler を Kdebug コードとカーネルフレームのアドレスで呼び出します。Kdebug コードが選択されたものと一致する場合、ビットマップとして構成された「アクション」を取得します（オプションについては osfmk/kperf/action.h を確認してください）。

Kperf には sysctl MIB テーブルもあります：（root として）sysctl kperf。これらのコードは osfmk/kperf/kperfbsd.c にあります。

さらに、Kperf の機能のサブセットは kpc に存在し、マシンのパフォーマンスカウンタに関する情報を提供します。

ProcessMonitor

ProcessMonitor は、プロセスが実行しているプロセス関連のアクションを確認するための非常に便利なツールです（例えば、プロセスが作成している新しいプロセスを監視します）。

SpriteTree

SpriteTree は、プロセス間の関係を表示するツールです。
sudo eslogger fork exec rename create > cap.json のようなコマンドで Mac を監視する必要があります（これを起動するには FDA が必要です）。その後、このツールに json を読み込んで、すべての関係を表示できます：

FileMonitor

FileMonitor は、ファイルイベント（作成、変更、削除など）を監視し、そのようなイベントに関する詳細情報を提供します。

Crescendo

Crescendo は、Windows ユーザーが Microsoft Sysinternal の Procmon から知っているかもしれないルックアンドフィールを持つ GUI ツールです。このツールは、さまざまなイベントタイプの記録を開始および停止でき、ファイル、プロセス、ネットワークなどのカテゴリによってこれらのイベントをフィルタリングでき、記録されたイベントを json 形式で保存する機能を提供します。

Apple Instruments

Apple Instruments は、アプリケーションのパフォーマンスを監視し、メモリリークを特定し、ファイルシステムのアクティビティを追跡するために使用される Xcode の開発者ツールの一部です。

fs_usage

プロセスによって実行されるアクションを追跡することができます：

fs_usage -w -f filesys ls #This tracks filesystem actions of proccess names containing ls
fs_usage -w -f network curl #This tracks network actions

TaskExplorer

Taskexplorer は、バイナリで使用されている ライブラリ、使用している ファイル、および ネットワーク 接続を確認するのに便利です。
また、バイナリプロセスを virustotal と照合し、バイナリに関する情報を表示します。

PT_DENY_ATTACH

このブログ記事 では、SIP が無効になっていてもデバッグを防ぐために PT_DENY_ATTACH を使用した 実行中のデーモンをデバッグする 方法の例を見つけることができます。

lldb

lldb は macOS バイナリ デバッグ のためのデファクトツールです。

lldb ./malware.bin
lldb -p 1122
lldb -n malware.bin
lldb -n malware.bin --waitfor

ホームフォルダに .lldbinit というファイルを作成し、次の行を追加することで、intel フレーバーを設定できます:

settings set target.x86-disassembly-flavor intel

アンチダイナミック分析

VM検出

• コマンド**sysctl hw.model**は、ホストがMacOSの場合は「Mac」を返し、VMの場合は異なるものを返します。
• **hw.logicalcpuとhw.physicalcpu**の値を操作することで、一部のマルウェアはVMかどうかを検出しようとします。
• 一部のマルウェアは、MACアドレス（00:50:56）に基づいてVMwareであるかどうかを検出することもできます。
• 簡単なコードを使用して、プロセスがデバッグされているかどうかを確認することも可能です：
• if(P_TRACED == (info.kp_proc.p_flag & P_TRACED)){ //プロセスがデバッグされています }
• ptraceシステムコールをPT_DENY_ATTACHフラグで呼び出すこともできます。これにより、デバッガがアタッチしてトレースするのを防ぎます。
• sysctlまたはptrace関数がインポートされているかどうかを確認できます（ただし、マルウェアは動的にインポートする可能性があります）。
• この書き込みで指摘されているように、「アンチデバッグ技術を打破する：macOS ptraceのバリアント」：
  “メッセージProcess # exited with status = 45 (0x0000002d)は、デバッグターゲットがPT_DENY_ATTACHを使用していることを示す兆候です”

コアダンプ

コアダンプは次の場合に作成されます：

• kern.coredump sysctlが1に設定されている（デフォルト）
• プロセスがsuid/sgidでない場合、またはkern.sugid_coredumpが1である（デフォルトは0）
• AS_CORE制限が操作を許可します。ulimit -c 0を呼び出すことでコアダンプの作成を抑制でき、ulimit -c unlimitedで再度有効にできます。

これらの場合、コアダンプはkern.corefile sysctlに従って生成され、通常は/cores/core/.%Pに保存されます。

ファジング

ReportCrash

ReportCrashはクラッシュしたプロセスを分析し、クラッシュレポートをディスクに保存します。クラッシュレポートには、開発者がクラッシュの原因を診断するのに役立つ情報が含まれています。
ユーザーごとのlaunchdコンテキストで実行されているアプリケーションや他のプロセスの場合、ReportCrashはLaunchAgentとして実行され、ユーザーの~/Library/Logs/DiagnosticReports/にクラッシュレポートを保存します。
デーモン、システムlaunchdコンテキストで実行されている他のプロセスおよび他の特権プロセスの場合、ReportCrashはLaunchDaemonとして実行され、システムの/Library/Logs/DiagnosticReportsにクラッシュレポートを保存します。

クラッシュレポートがAppleに送信されることを心配している場合は、それらを無効にできます。そうでない場合、クラッシュレポートはサーバーがどのようにクラッシュしたかを理解するのに役立ちます。

#To disable crash reporting:
launchctl unload -w /System/Library/LaunchAgents/com.apple.ReportCrash.plist
sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.ReportCrash.Root.plist

#To re-enable crash reporting:
launchctl load -w /System/Library/LaunchAgents/com.apple.ReportCrash.plist
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.ReportCrash.Root.plist

スリープ

MacOSでファジングを行う際は、Macがスリープしないようにすることが重要です：

• systemsetup -setsleep Never
• pmset, システム環境設定
• KeepingYouAwake

SSH切断

SSH接続を介してファジングを行う場合、セッションが切断されないようにすることが重要です。次のようにsshd_configファイルを変更してください：

• TCPKeepAlive Yes
• ClientAliveInterval 0
• ClientAliveCountMax 0

sudo launchctl unload /System/Library/LaunchDaemons/ssh.plist
sudo launchctl load -w /System/Library/LaunchDaemons/ssh.plist

Internal Handlers

次のページを確認してください どのアプリが 指定されたスキームまたはプロトコルを処理しているかを見つける方法を知るために:

macOS File Extension & URL scheme app handlers

Enumerating Network Processes

これは、ネットワークデータを管理しているプロセスを見つけるのに興味深いです:

dtrace -n 'syscall::recv*:entry { printf("-> %s (pid=%d)", execname, pid); }' >> recv.log
#wait some time
sort -u recv.log > procs.txt
cat procs.txt

または netstat または lsof を使用します。

Libgmalloc

lldb -o "target create `which some-binary`" -o "settings set target.env-vars DYLD_INSERT_LIBRARIES=/usr/lib/libgmalloc.dylib" -o "run arg1 arg2" -o "bt" -o "reg read" -o "dis -s \$pc-32 -c 24 -m -F intel" -o "quit"

Fuzzers

AFL++

CLIツールで動作します。

Litefuzz

macOS GUIツールで「そのまま動作します」。いくつかのmacOSアプリには、ユニークなファイル名、正しい拡張子、サンドボックスからファイルを読み取る必要があるなど、特定の要件があります（~/Library/Containers/com.apple.Safari/Data）...

いくつかの例:

# iBooks
litefuzz -l -c "/System/Applications/Books.app/Contents/MacOS/Books FUZZ" -i files/epub -o crashes/ibooks -t /Users/test/Library/Containers/com.apple.iBooksX/Data/tmp -x 10 -n 100000 -ez

# -l : Local
# -c : cmdline with FUZZ word (if not stdin is used)
# -i : input directory or file
# -o : Dir to output crashes
# -t : Dir to output runtime fuzzing artifacts
# -x : Tmeout for the run (default is 1)
# -n : Num of fuzzing iterations (default is 1)
# -e : enable second round fuzzing where any crashes found are reused as inputs
# -z : enable malloc debug helpers

# Font Book
litefuzz -l -c "/System/Applications/Font Book.app/Contents/MacOS/Font Book FUZZ" -i input/fonts -o crashes/font-book -x 2 -n 500000 -ez

# smbutil (using pcap capture)
litefuzz -lk -c "smbutil view smb://localhost:4455" -a tcp://localhost:4455 -i input/mac-smb-resp -p -n 100000 -z

# screensharingd (using pcap capture)
litefuzz -s -a tcp://localhost:5900 -i input/screenshared-session --reportcrash screensharingd -p -n 100000

さらなるFuzzing MacOS情報

• https://www.youtube.com/watch?v=T5xfL9tEg44
• https://github.com/bnagy/slides/blob/master/OSXScale.pdf
• https://github.com/bnagy/francis/tree/master/exploitaben
• https://github.com/ant4g0nist/crashwrangler

参考文献

• OS X インシデントレスポンス: スクリプティングと分析
• https://www.youtube.com/watch?v=T5xfL9tEg44
• https://taomm.org/vol1/analysis.html
• Macマルウェアの技術: 悪意のあるソフトウェアの分析ガイド