.. | ||
arm64-basic-assembly.md | ||
introduction-to-x64.md | ||
objects-in-memory.md | ||
README.md |
macOS Apps - Інспектування, налагодження та Fuzzing
{% hint style="success" %}
Вивчайте та практикуйте хакінг AWS: Школа хакінгу HackTricks AWS Red Team Expert (ARTE)
Вивчайте та практикуйте хакінг GCP: Школа хакінгу HackTricks GCP Red Team Expert (GRTE)
Підтримайте HackTricks
- Перевірте плани підписки!
- Приєднуйтесь до 💬 групи Discord або групи Telegram або слідкуйте за нами на Twitter 🐦 @hacktricks_live.
- Поширюйте хакінг-прийоми, надсилайте PR до HackTricks та HackTricks Cloud у GitHub.
WhiteIntel
WhiteIntel - це пошуковик, який працює на темному веб-сайті та пропонує безкоштовні функції для перевірки, чи були компанія або її клієнти компрометовані шкідливими програмами-викрадачами.
Основною метою WhiteIntel є боротьба з захопленням облікових записів та атаками вимагання викупу, що виникають внаслідок шкідливих програм, які крадуть інформацію.
Ви можете перевірити їх веб-сайт та спробувати їхній двигун безкоштовно за посиланням:
{% embed url="https://whiteintel.io" %}
Статичний аналіз
otool & objdump & nm
otool -L /bin/ls #List dynamically linked libraries
otool -tv /bin/ps #Decompile application
{% code overflow="wrap" %}
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
{% endcode %}
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
{% hint style="danger" %} jtool застарів на користь disarm {% endhint %}
Codesign / ldid
{% hint style="success" %}
Codesign
можна знайти в macOS, тоді як ldid
можна знайти в iOS
{% endhint %}
# 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
Це буде змонтовано в /Volumes
Упаковані бінарні файли
- Перевірка високої ентропії
- Перевірка рядків (чи є майже незрозумілий рядок, упакований)
- Упаковувач UPX для MacOS генерує розділ під назвою "__XHDR"
Статичний аналіз Objective-C
Метадані
{% hint style="danger" %} Зверніть увагу, що програми, написані на Objective-C, зберігають свої оголошення класів під час компіляції у бінарних файлах Mach-O. Такі оголошення класів включають ім'я та тип: {% endhint %}
- Визначені інтерфейси
- Методи інтерфейсу
- Змінні екземпляра інтерфейсу
- Визначені протоколи
Зверніть увагу, що ці імена можуть бути затемнені, щоб ускладнити розбір бінарного коду.
Виклик функцій
Коли функція викликається в бінарному файлі, який використовує Objective-C, скомпільований код замість виклику цієї функції буде викликати objc_msgSend
. Це викличе остаточну функцію:
Параметри, які очікує ця функція, це:
- Перший параметр (self) - "вказівник, який вказує на екземпляр класу, який має отримати повідомлення". Іншими словами, це об'єкт, на якому викликається метод. Якщо метод є методом класу, це буде екземпляр об'єкта класу (в цілому), тоді як для методу екземпляра self вказуватиме на створений екземпляр класу як об'єкт.
- Другий параметр (op) - "селектор методу, який обробляє повідомлення". Це просто ім'я методу.
- Решта параметрів - будь-які значення, які потрібні для методу (op).
Дивіться, як легко отримати цю інформацію за допомогою lldb
в ARM64 на цій сторінці:
{% content-ref url="arm64-basic-assembly.md" %} arm64-basic-assembly.md {% endcontent-ref %}
x64:
Аргумент | Регістр | (для) objc_msgSend |
---|---|---|
1-й аргумент | rdi | self: об'єкт, на якому викликається метод |
2-й аргумент | rsi | op: ім'я методу |
3-й аргумент | rdx | 1-й аргумент методу |
4-й аргумент | rcx | 2-й аргумент методу |
5-й аргумент | r8 | 3-й аргумент методу |
6-й аргумент | r9 | 4-й аргумент методу |
7+ аргумент | rsp+ |
5+ аргумент методу |
Вивантаження метаданих ObjectiveC
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 - це оригінальний інструмент для генерації декларацій для класів, категорій та протоколів у форматованому коді ObjetiveC.
Це старий і не підтримуваний інструмент, тому ймовірно, що він не працюватиме належним чином.
ICDump
iCDump - це сучасний та крос-платформений дамп класів Objective-C. Порівняно з існуючими інструментами, iCDump може працювати незалежно від екосистеми Apple та надає зв'язки з Python.
import icdump
metadata = icdump.objc.parse("/path/to/bin")
print(metadata.to_decl())
Статичний аналіз Swift
З 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
Динамічний аналіз
{% hint style="warning" %}
Зверніть увагу, що для налагодження бінарних файлів SIP повинен бути вимкнений (csrutil disable
або csrutil enable --without debug
) або скопіювати бінарні файли в тимчасову теку та видалити підпис за допомогою codesign --remove-signature <шлях-до-бінарного-файлу>
або дозволити налагодження бінарного файлу (можна скористатися цим скриптом)
{% endhint %}
{% hint style="warning" %}
Зверніть увагу, що для інструментування системних бінарних файлів (таких як cloudconfigurationd
) на macOS, SIP повинен бути вимкнений (просто видалення підпису не працюватиме).
{% endhint %}
APIs
macOS надає деякі цікаві API, які надають інформацію про процеси:
proc_info
: Це основний, що надає багато інформації про кожен процес. Вам потрібно мати права root, щоб отримати інформацію про інші процеси, але вам не потрібні спеціальні дозволи або порти mach.libsysmon.dylib
: Це дозволяє отримувати інформацію про процеси через викладені функції XPC, однак для цього потрібно мати дозвілcom.apple.sysmond.client
.
Stackshot та microstackshots
Stackshotting - це техніка, яка використовується для захоплення стану процесів, включаючи стеки викликів усіх запущених потоків. Це особливо корисно для налагодження, аналізу продуктивності та розуміння поведінки системи в конкретний момент часу. На iOS та macOS stackshotting можна виконати за допомогою кількох інструментів та методів, таких як інструменти sample
та spindump
.
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/rmpcom.apple.sysdiagnose.kernel.ipc
: Спеціальний порт 23 (ядро)com.apple.sysdiagnose.service.xpc
: Інтерфейс режиму користувача через класLibsysdiagnose
Obj-C. Три аргументи в словнику можуть бути передані (compress
,display
,run
)
Об'єднані журнали
macOS генерує багато журналів, які можуть бути дуже корисними при запуску додатка для розуміння що він робить.
Більше того, є деякі журнали, які міститимуть тег <private>
, щоб приховати деяку ідентифіковану інформацію про користувача або комп'ютер. Однак можна встановити сертифікат для розкриття цієї інформації. Дотримуйтесь пояснень з тут.
Hopper
Ліва панель
У лівій панелі hopper можна побачити символи (Мітки) бінарного файлу, список процедур та функцій (Proc) та рядки (Str). Це не всі рядки, але ті, що визначені в кількох частинах файлу Mac-O (наприклад cstring або objc_methname
).
Середня панель
У середній панелі ви можете побачити розібраний код. І ви можете побачити його у сирому розібранні, як граф, як декомпільований та як бінарний, натиснувши на відповідний значок:
Клацнувши правою кнопкою миші на об'єкті коду, ви можете побачити посилання на/від цього об'єкту або навіть змінити його ім'я (це не працює в декомпільованому псевдокоді):
Більше того, у середній нижній частині ви можете вводити команди python.
Права панель
У правій панелі ви можете побачити цікаву інформацію, таку як історію навігації (щоб знати, як ви потрапили в поточну ситуацію), граф викликів, де ви можете побачити всі функції, які викликають цю функцію, і всі функції, які ця функція викликає, та інформацію про локальні змінні.
dtrace
Це дозволяє користувачам отримати доступ до додатків на дуже низькому рівні та надає спосіб користувачам слідкувати за програмами та навіть змінювати їхній хід виконання. Dtrace використовує проби, які розміщені по всьому ядру і знаходяться в таких місцях, як початок та кінець системних викликів.
DTrace використовує функцію dtrace_probe_create
для створення проби для кожного системного виклику. Ці проби можуть бути викликані в точці входу та виходу кожного системного виклику. Взаємодія з DTrace відбувається через /dev/dtrace, який доступний лише для користувача root.
{% hint style="success" %}
Щоб увімкнути Dtrace без повного вимкнення захисту SIP, ви можете виконати у режимі відновлення: csrutil enable --without dtrace
Ви також можете dtrace
або dtruss
бінарні файли, які ви скомпілювали.
{% endhint %}
Доступні проби 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
). Якщо ви не вказуєте деяку частину назви, 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.
ktrace
API ktrace_*
походять з libktrace.dylib
, яка обгортає ті, що використовуються в Kdebug
. Після цього клієнт може просто викликати ktrace_session_create
та ktrace_events_[single/class]
, щоб встановити зворотні виклики на конкретні коди, а потім запустити його за допомогою ktrace_start
.
Ви можете використовувати це навіть з SIP активованим
Ви можете використовувати як клієнти утиліту ktrace
:
ktrace trace -s -S -t c -c ls | grep "ls("
Або tailspin
.
kperf
Це використовується для профілювання на рівні ядра і побудоване за допомогою викликів Kdebug
.
Основна змінна kernel_debug_active
перевіряється, і якщо вона встановлена, викликається kperf_kdebug_handler
з кодом Kdebug
та адресою виклику ядра. Якщо код Kdebug
відповідає вибраному, отримує "дії", налаштовані як бітова карта (перевірте osfmk/kperf/action.h
для варіантів).
У Kperf також є таблиця MIB sysctl: (як root) sysctl kperf
. Цей код можна знайти в osfmk/kperf/kperfbsd.c
.
Крім того, підмножина функціоналу Kperf знаходиться в kpc
, яка надає інформацію про лічильники продуктивності машини.
ProcessMonitor
ProcessMonitor - це дуже корисний інструмент для перевірки дій, пов'язаних з процесами, які виконує процес (наприклад, відстеження нових процесів, які створює процес).
SpriteTree
SpriteTree - це інструмент для відображення взаємозв'язків між процесами.
Вам потрібно відстежувати свій Mac за допомогою команди, подібної sudo eslogger fork exec rename create > cap.json
(термінал, що запускає це, потребує FDA). Потім ви можете завантажити json у цей інструмент, щоб переглянути всі взаємозв'язки:
FileMonitor
FileMonitor дозволяє відстежувати події файлів (такі як створення, зміни та видалення), надаючи докладну інформацію про такі події.
Crescendo
Crescendo - це графічний інструмент з виглядом, який користувачі Windows можуть знати з Procmon від Microsoft Sysinternal. Цей інструмент дозволяє почати та зупинити запис різних типів подій, фільтрувати ці події за категоріями, такими як файл, процес, мережа і т. д., і надає функціонал для збереження записаних подій у форматі 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
У цьому дописі блогу ви можете знайти приклад того, як налагодити працюючий демон, який використовував PT_DENY_ATTACH
для запобігання налагодженню навіть якщо SIP був вимкнений.
lldb
lldb - це фактичний інструмент для налагодження бінарних файлів macOS.
lldb ./malware.bin
lldb -p 1122
lldb -n malware.bin
lldb -n malware.bin --waitfor
Ви можете встановити intel flavour при використанні lldb, створивши файл під назвою .lldbinit
у вашій домашній папці з наступним рядком:
settings set target.x86-disassembly-flavor intel
{% hint style="warning" %}
Усередині lldb виведіть процес за допомогою process save-core
{% endhint %}
(lldb) Команда | Опис |
run (r) | Початок виконання, яке триватиме безперервно до того, як буде досягнуто точку зупинки або процес завершиться. |
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> #Головна функція вказаного бінарного файлу b -[NSDictionary objectForKey:] 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
Зверніть увагу, що більшість API-інтерфейсів або методів Objective-C від Apple повертають об'єкти, тому їх слід відображати за допомогою команди "print object" (po). Якщо po не виводить змістовний результат, використовуйте |
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> #Розібрати функцію |
parray | parray 3 (char **)$x1 # Перевірити масив з 3 компонентами в регістрі x1 |
{% hint style="info" %}
При виклику функції 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:"
{% endhint %}
Протидія динамічному аналізу
Виявлення віртуальних машин
- Команда
sysctl hw.model
повертає "Mac", коли хост - MacOS, але щось інше, коли це віртуальна машина. - Граючи зі значеннями
hw.logicalcpu
таhw.physicalcpu
, деякі шкідливі програми намагаються виявити, чи це віртуальна машина. - Деякі шкідливі програми також можуть виявити, чи машина базується на VMware за MAC-адресою (00:50:56).
- Також можна виявити, чи процес відлагоджується за допомогою простого коду, наприклад:
if(P_TRACED == (info.kp_proc.p_flag & P_TRACED)){ //процес відлагоджується }
- Також можна викликати системний виклик
ptrace
з прапорцемPT_DENY_ATTACH
. Це запобігає приєднанню та відстеженню відлагоджувача. - Можна перевірити, чи функція
sysctl
абоptrace
імпортується (але шкідлива програма може імпортувати її динамічно) - Як вказано в цьому огляді, “Перемога над анти-відлагоджувальними техніками: варіанти macOS ptrace” :
“Повідомлення Процес # завершився з статусом = 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
.
Fuzzing
ReportCrash
ReportCrash аналізує процеси, що призводять до збоїв, і зберігає звіт про збій на диск. Звіт про збій містить інформацію, яка може допомогти розробнику діагностувати причину збою.
Для додатків та інших процесів, що працюють в контексті запуску користувача, ReportCrash працює як LaunchAgent і зберігає звіти про збої в ~/Library/Logs/DiagnosticReports/
користувача
Для демонів, інших процесів, що працюють в контексті запуску системи та інших привілейованих процесів, 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, System Preferences
- 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
Внутрішні обробники
Перевірте наступну сторінку, щоб дізнатися, яка програма відповідає за обробку вказаної схеми або протоколу:
{% content-ref url="../macos-file-extension-apps.md" %} macos-file-extension-apps.md {% endcontent-ref %}
Перелік мережевих процесів
Це цікаво виявити процеси, які керують мережевими даними:
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
{% code overflow="wrap" %}
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"
{% endcode %}
Fuzzers
AFL++
Працює для інструментів командного рядка
Litefuzz
Він "просто працює" з інструментами GUI macOS. Зверніть увагу, що деякі додатки 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
{% endcode %}
Додаткова інформація про 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 Incident Response: Scripting and Analysis
- https://www.youtube.com/watch?v=T5xfL9tEg44
- https://taomm.org/vol1/analysis.html
- The Art of Mac Malware: The Guide to Analyzing Malicious Software
WhiteIntel
WhiteIntel - це пошуковий двигун, який працює на темному веб-сайті і надає безкоштовні функціональні можливості для перевірки, чи були компанія або її клієнти пошкоджені шкідливими програмами для крадіжки інформації.
Основною метою WhiteIntel є боротьба з захопленням облікових записів та атаками вимагання викупу, що виникають внаслідок шкідливих програм для крадіжки інформації.
Ви можете перевірити їх веб-сайт та спробувати їх двигун безкоштовно за посиланням:
{% embed url="https://whiteintel.io" %}
{% hint style="success" %}
Вивчайте та практикуйте взлом AWS:Навчання HackTricks AWS Red Team Expert (ARTE)
Вивчайте та практикуйте взлом GCP: Навчання HackTricks GCP Red Team Expert (GRTE)
Підтримайте HackTricks
- Перевірте плани підписки!
- Приєднуйтесь до 💬 групи Discord або групи Telegram або слідкуйте за нами в Twitter 🐦 @hacktricks_live.
- Поширюйте хакерські трюки, надсилаючи PR до HackTricks та HackTricks Cloud репозиторіїв на GitHub.