macOS Apps - Inspecting, debugging and Fuzzing

HackTricksをサポートする

静的分析

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

jtoolはdisarmに取って代わられました

コード署名 / ldid

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

Objective-Cで書かれたプログラムは、Mach-Oバイナリにコンパイルされるときに、クラス宣言を保持します。このようなクラス宣言には、以下の名前とタイプが含まれます

  • 定義されたインターフェース

  • インターフェースメソッド

  • インターフェースインスタンス変数

  • 定義されたプロトコル

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

Function calling

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

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

  • 最初のパラメータ(self)は「メッセージを受け取るクラスのインスタンスを指すポインタ」です。簡単に言えば、これはメソッドが呼び出されるオブジェクトです。メソッドがクラスメソッドの場合、これはクラスオブジェクトのインスタンス(全体)になりますが、インスタンスメソッドの場合、selfはクラスのインスタンス化されたインスタンスをオブジェクトとして指します。

  • 2番目のパラメータ(op)は「メッセージを処理するメソッドのセレクタ」です。再度、簡単に言えば、これは単にメソッドの名前です。

  • 残りのパラメータは、メソッド(op)によって必要とされるです。

この情報を**lldbを使用してARM64で簡単に取得する方法**については、このページを参照してください:

Introduction to ARM64v8

x64:

Argument

Register

(for) objc_msgSend

1st argument

rdi

self: メソッドが呼び出されるオブジェクト

2nd argument

rsi

op: メソッドの名前

3rd argument

rdx

メソッドへの1番目の引数

4th argument

rcx

メソッドへの2番目の引数

5th argument

r8

メソッドへの3番目の引数

6th argument

r9

メソッドへの4番目の引数

7th+ argument

rsp+ (スタック上)

メソッドへの5番目以降の引数

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 は、Objective-C 形式のコード内のクラス、カテゴリ、およびプロトコルの宣言を生成するための元のツールです。

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

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

動的分析

バイナリをデバッグするには、SIPを無効にする必要がありますcsrutil disableまたはcsrutil enable --without debug)またはバイナリを一時フォルダにコピーして署名を削除する必要があります(codesign --remove-signature <binary-path>)またはバイナリのデバッグを許可する必要があります(このスクリプトを使用できます)。

macOSでシステムバイナリ(例えばcloudconfigurationd)を計測するには、SIPを無効にする必要があります(署名を削除するだけでは機能しません)。

API

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

  • proc_info: 各プロセスに関する多くの情報を提供する主要なAPIです。他のプロセスの情報を取得するにはroot権限が必要ですが、特別な権限やmachポートは必要ありません。

  • libsysmon.dylib: XPCで公開された関数を介してプロセスに関する情報を取得することを可能にしますが、com.apple.sysmond.clientの権限が必要です。

スタックショットとマイクロスタックショット

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

Sysdiagnose

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

rootとして実行する必要があり、デーモン/usr/libexec/sysdiagnosedcom.apple.system-task-portsget-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つの引数を渡すことができます(compressdisplayrun

統一ログ

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

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

Hopper

左パネル

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

中央パネル

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

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

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

右パネル

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

dtrace

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

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

SIP保護を完全に無効にせずにDtraceを有効にするには、リカバリモードで次のコマンドを実行できます:csrutil enable --without dtrace

また、dtraceまたはdtrussバイナリをコンパイルしたものを使用することもできます。

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 にあります。

latencysc_usagefs_usage、および trace などのツールは内部でこれを使用します。

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

カスタムクライアントで 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_createktrace_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_handlerKdebug コードとカーネルフレームのアドレスで呼び出します。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

lldbmacOS バイナリ デバッグ のための事実上のツールです。

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

あなたは、次の行を含む**.lldbinit**というファイルをホームフォルダに作成することで、lldbを使用する際にintelフレーバーを設定できます:

settings set target.x86-disassembly-flavor intel

lldb内で、process save-coreを使用してプロセスをダンプします

(lldb) コマンド

説明

run (r)

実行を開始し、ブレークポイントがヒットするかプロセスが終了するまで継続します。

process launch --stop-at-entry

エントリポイントで停止する実行を開始します

continue (c)

デバッグ中のプロセスの実行を続けます。

nexti (n / ni)

次の命令を実行します。このコマンドは関数呼び出しをスキップします。

stepi (s / si)

次の命令を実行します。nextiコマンドとは異なり、このコマンドは関数呼び出しに入ります。

finish (f)

現在の関数(“フレーム”)内の残りの命令を実行し、戻って停止します。

control + c

実行を一時停止します。プロセスが実行(r)または続行(c)されている場合、これはプロセスを現在実行中の場所で停止させます。

breakpoint (b)

b main #mainと呼ばれる任意の関数

b <binname>`main #バイナリのメイン関数

b set -n main --shlib <lib_name> #指定されたバイナリのメイン関数

breakpoint set -r '\[NSFileManager .*\]$' #任意のNSFileManagerメソッド

breakpoint set -r '\[NSFileManager contentsOfDirectoryAtPath:.*\]$'

break set -r . -s libobjc.A.dylib #そのライブラリのすべての関数でブレーク

b -a 0x0000000100004bd9

br l #ブレークポイントリスト

br e/dis <num> #ブレークポイントを有効/無効にする

breakpoint delete <num>

help

help breakpoint #ブレークポイントコマンドのヘルプを取得

help memory write #メモリへの書き込みのヘルプを取得

reg

reg read

reg read $rax

reg read $rax --format <format>

reg write $rip 0x100035cc0

x/s <reg/memory address>

メモリをヌル終端の文字列として表示します。

x/i <reg/memory address>

メモリをアセンブリ命令として表示します。

x/b <reg/memory address>

メモリをバイトとして表示します。

print object (po)

これは、パラメータで参照されるオブジェクトを印刷します

po $raw

{

dnsChanger = {

"affiliate" = "";

"blacklist_dns" = ();

AppleのObjective-C APIやメソッドのほとんどはオブジェクトを返すため、"print object" (po) コマンドを介して表示する必要があります。poが意味のある出力を生成しない場合は、x/bを使用してください。

memory

memory read 0x000.... memory read $x0+0xf2a memory write 0x100600000 -s 4 0x41414141 #そのアドレスにAAAAを書き込みます memory write -f s $rip+0x11f+7 "AAAA" #そのアドレスにAAAAを書き込みます

disassembly

dis #現在の関数を逆アセンブル

dis -n <funcname> #関数を逆アセンブル

dis -n <funcname> -b <basename> #関数を逆アセンブル dis -c 6 #6行を逆アセンブル dis -c 0x100003764 -e 0x100003768 #1つのアドレスから別のアドレスまで dis -p -c 4 #現在のアドレスから逆アセンブルを開始

parray

parray 3 (char **)$x1 # x1レジスタの3コンポーネントの配列を確認

image dump sections

現在のプロセスメモリのマップを印刷します

image dump symtab <library>

image dump symtab CoreNLP #CoreNLPのすべてのシンボルのアドレスを取得

objc_sendMsg関数を呼び出すと、rsiレジスタにはヌル終端の(“C”)文字列としてメソッドの名前が保持されます。lldbを介して名前を印刷するには、次のようにします:

(lldb) x/s $rsi: 0x1000f1576: "startMiningWithPort:password:coreCount:slowMemory:currency:"

(lldb) print (char*)$rsi: (char *) $1 = 0x00000001000f1576 "startMiningWithPort:password:coreCount:slowMemory:currency:"

(lldb) reg read $rsi: rsi = 0x00000001000f1576 "startMiningWithPort:password:coreCount:slowMemory:currency:"

動的解析防止

VM検出

  • コマンド**sysctl hw.model**は、ホストがMacOSの場合は"Mac"を返しますが、VMの場合は異なるものを返します。

  • **hw.logicalcpuhw.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はクラッシュしたプロセスを分析し、クラッシュレポートをディスクに保存します。クラッシュレポートには、開発者がクラッシュの原因を診断するのに役立つ情報が含まれています。 ユーザーごとの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がスリープしないようにすることが重要です:

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

CLIツールに対応しています。

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情報

参考文献

HackTricksをサポートする

Last updated