macOS Apps - Inspecting, debugging and Fuzzing
Last updated
Last updated
Jifunze & fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Jifunze & fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Unaweza kupakua disarm kutoka hapa.
Unaweza kupakua jtool2 hapa au kuisakinisha kwa kutumia brew.
jtool imeachwa kwa ajili ya disarm
Codesign inaweza kupatikana katika macOS wakati ldid inaweza kupatikana katika iOS
SuspiciousPackage ni chombo kinachofaa kuchunguza .pkg faili (wawekaji) na kuona kilichomo ndani kabla ya kuisakinisha.
Wawekaji hawa wana preinstall na postinstall bash scripts ambazo waandishi wa malware mara nyingi hutumia vibaya ili kuendelea na malware.
Chombo hiki kinaruhusu kuunganisha picha za diski za Apple (.dmg) ili kuzichunguza kabla ya kuendesha chochote:
It will be mounted in /Volumes
Angalia kwa entropy ya juu
Angalia nyuzi (kama kuna karibu nyuzi zisizoeleweka, zimepakwa)
Mpakaji wa UPX kwa MacOS huunda sehemu inayoitwa "__XHDR"
Kumbuka kwamba programu zilizoandikwa kwa Objective-C zinahifadhi matangazo yao ya darasa wakati zinapokanzwa kuwa Mach-O binaries. Matangazo kama haya ya darasa yanajumuisha jina na aina ya:
Interfaces zilizofafanuliwa
Mbinu za interface
Vigezo vya mfano wa interface
Itifaki zilizofafanuliwa
Kumbuka kwamba majina haya yanaweza kufichwa ili kufanya kurudi nyuma kwa binary kuwa ngumu zaidi.
Wakati mbinu inapoitwa katika binary inayotumia objective-C, msimbo uliokanzwa badala ya kuita mbinu hiyo, utaita objc_msgSend. Ambayo itakuwa ikitafuta mbinu ya mwisho:
Paramu ambazo mbinu hii inatarajia ni:
Paramu ya kwanza (self) ni "kiashiria kinachopointia mfano wa darasa ambalo linapaswa kupokea ujumbe". Au kwa kusema kwa urahisi, ni kitu ambacho mbinu inaitwa juu yake. Ikiwa mbinu ni mbinu ya darasa, hii itakuwa mfano wa kitu cha darasa (kama jumla), wakati kwa mbinu ya mfano, self itapointia mfano ulioanzishwa wa darasa kama kitu.
Paramu ya pili, (op), ni "mchaguzi wa mbinu inayoshughulikia ujumbe". Tena, kwa kusema kwa urahisi, hii ni tu jina la mbinu.
Paramu zilizobaki ni thamani zozote zinazohitajika na mbinu (op).
Tazama jinsi ya kupata habari hii kwa urahisi na lldb katika ARM64 katika ukurasa huu:
x64:
Argument | Register | (kwa) objc_msgSend |
1st argument | rdi | self: kitu ambacho mbinu inaitwa juu yake |
2nd argument | rsi | op: jina la mbinu |
3rd argument | rdx | paramu ya 1 kwa mbinu |
4th argument | rcx | paramu ya 2 kwa mbinu |
5th argument | r8 | paramu ya 3 kwa mbinu |
6th argument | r9 | paramu ya 4 kwa mbinu |
7th+ argument | rsp+ (katika stack) | paramu ya 5+ kwa mbinu |
Dynadump ni chombo cha kutupa darasa la Objective-C binaries. Github inaelezea dylibs lakini hii pia inafanya kazi na executable.
Wakati wa uandishi, hii ni sasa ndiyo inayo fanya kazi vizuri zaidi.
class-dump ni chombo cha asili kinachozalisha matamko ya madarasa, makundi na protokali katika msimbo wa muundo wa ObjetiveC.
Ni ya zamani na haina matengenezo hivyo huenda isifanye kazi vizuri.
iCDump ni chombo cha kisasa na chenye uwezo wa kufanya kazi kwenye majukwaa tofauti cha Objective-C. Ikilinganishwa na zana zilizopo, iCDump inaweza kufanya kazi bila kutegemea mfumo wa Apple na inatoa viunganishi vya Python.
Kwa binaries za Swift, kwa kuwa kuna ulinganifu wa Objective-C, wakati mwingine unaweza kutoa matamko kwa kutumia class-dump lakini si kila wakati.
Kwa kutumia amri za jtool -l au otool -l inawezekana kupata sehemu kadhaa zinazooanza na kiambishi __swift5:
Unaweza kupata taarifa zaidi kuhusu taarifa zilizohifadhiwa katika sehemu hizi katika chapisho hili la blog.
Zaidi ya hayo, binaries za Swift zinaweza kuwa na alama (kwa mfano maktaba zinahitaji kuhifadhi alama ili kazi zake ziweze kuitwa). Alama hizo kwa kawaida zina taarifa kuhusu jina la kazi na attr kwa njia isiyo nzuri, hivyo ni muhimu sana na kuna "demanglers" ambazo zinaweza kupata jina la asili:
Kumbuka kwamba ili kufanyia debug binaries, SIP inahitaji kuzuiliwa (csrutil disable au csrutil enable --without debug) au nakala ya binaries kwenye folda ya muda na kuondoa saini kwa codesign --remove-signature <binary-path> au kuruhusu ufanyaji debug wa binary (unaweza kutumia hiki skripti)
Kumbuka kwamba ili kuweka vifaa vya mfumo, (kama cloudconfigurationd) kwenye macOS, SIP inapaswa kuzuiliwa (kuondoa saini pekee hakutafanya kazi).
macOS inatoa APIs kadhaa za kuvutia ambazo zinatoa habari kuhusu michakato:
proc_info: Hii ndiyo kuu inayoleta habari nyingi kuhusu kila mchakato. Unahitaji kuwa root ili kupata habari za michakato mingine lakini huhitaji ruhusa maalum au mach ports.
libsysmon.dylib: Inaruhusu kupata habari kuhusu michakato kupitia kazi zilizofichwa za XPC, hata hivyo, inahitajika kuwa na ruhusa com.apple.sysmond.client.
Stackshotting ni mbinu inayotumika kukamata hali ya michakato, ikiwa ni pamoja na stacks za wito za nyuzi zote zinazofanya kazi. Hii ni muhimu sana kwa ufanyaji debug, uchambuzi wa utendaji, na kuelewa tabia ya mfumo katika wakati maalum. Kwenye iOS na macOS, stackshotting inaweza kufanywa kwa kutumia zana na mbinu kadhaa kama zana sample na spindump.
Zana hii (/usr/bini/ysdiagnose) kimsingi inakusanya habari nyingi kutoka kwa kompyuta yako ikitekeleza amri tofauti kumi kama ps, zprint...
Inapaswa kuendeshwa kama root na daemon /usr/libexec/sysdiagnosed ina ruhusa za kuvutia kama com.apple.system-task-ports na get-task-allow.
Plist yake iko katika /System/Library/LaunchDaemons/com.apple.sysdiagnose.plist ambayo inatangaza MachServices 3:
com.apple.sysdiagnose.CacheDelete: Inafuta archives za zamani katika /var/rmp
com.apple.sysdiagnose.kernel.ipc: Bandari maalum 23 (kernel)
com.apple.sysdiagnose.service.xpc: Kiolesura cha hali ya mtumiaji kupitia Libsysdiagnose darasa la Obj-C. Hoja tatu katika dict zinaweza kupitishwa (compress, display, run)
MacOS inazalisha magogo mengi ambayo yanaweza kuwa ya manufaa wakati wa kuendesha programu ikijaribu kuelewa kila inafanya.
Zaidi ya hayo, kuna baadhi ya magogo ambayo yatakuwa na lebo <private> ili kuficha baadhi ya habari za mtumiaji au kompyuta zinazoweza kutambulika. Hata hivyo, inawezekana kufunga cheti kufichua habari hii. Fuata maelezo kutoka hapa.
Katika paneli ya kushoto ya hopper inawezekana kuona alama (Labels) za binary, orodha ya taratibu na kazi (Proc) na nyuzi (Str). Hizi si nyuzi zote lakini zile zilizofafanuliwa katika sehemu kadhaa za faili la Mac-O (kama cstring au objc_methname).
Katika paneli ya kati unaweza kuona kanuni iliyovunjwa. Na unaweza kuona kama kuvunjwa kwa raw, kama grafu, kama iliyotafsiriwa na kama binary kwa kubofya kwenye ikoni husika:
Kubofya kulia kwenye kitu cha kanuni unaweza kuona marejeleo kwa/kutoka kwa kitu hicho au hata kubadilisha jina lake (hii haifanyi kazi katika pseudocode iliyotafsiriwa):
Zaidi ya hayo, katika chini ya kati unaweza kuandika amri za python.
Katika paneli ya kulia unaweza kuona habari za kuvutia kama historia ya urambazaji (ili ujue jinsi ulivyofika katika hali ya sasa), grafu ya wito ambapo unaweza kuona kazi zote zinazoiita kazi hii na kazi zote ambazo kazi hii inaita, na habari za mabadiliko ya ndani.
Inaruhusu watumiaji kufikia programu kwa kiwango cha chini sana na inatoa njia kwa watumiaji kufuatilia programu na hata kubadilisha mtiririko wa utekelezaji wao. Dtrace inatumia probes ambazo zimewekwa katika kernel na ziko katika maeneo kama mwanzo na mwisho wa wito wa mfumo.
DTrace inatumia kazi dtrace_probe_create kuunda probe kwa kila wito wa mfumo. Probes hizi zinaweza kuanzishwa katika kiingilio na kutoka kwa kila wito wa mfumo. Maingiliano na DTrace yanatokea kupitia /dev/dtrace ambayo inapatikana tu kwa mtumiaji wa root.
Ili kuwezesha Dtrace bila kuzima kabisa ulinzi wa SIP unaweza kutekeleza katika hali ya urejeleaji: csrutil enable --without dtrace
Unaweza pia dtrace au dtruss binaries ambazo umeziunda.
Probes zinazopatikana za dtrace zinaweza kupatikana kwa:
Jina la probe linajumuisha sehemu nne: mtoa huduma, moduli, kazi, na jina (fbt:mach_kernel:ptrace:entry). Ikiwa hujatoa sehemu fulani ya jina, Dtrace itatumia sehemu hiyo kama wildcard.
Ili kuunda DTrace ili kuamsha probes na kubaini ni hatua zipi za kuchukua wakati zinapowaka, tutahitaji kutumia lugha ya D.
Maelezo ya kina zaidi na mifano zaidi yanaweza kupatikana katika https://illumos.org/books/dtrace/chp-intro.html
Kimbia man -k dtrace ili orodheshe scripts za DTrace zinazopatikana. Mfano: sudo dtruss -n binary
Katika mstari
script
Ni kituo cha kufuatilia kernel. M codes zilizoorodheshwa zinaweza kupatikana katika /usr/share/misc/trace.codes.
Zana kama latency, sc_usage, fs_usage na trace zinatumia ndani yake.
Ili kuungana na kdebug, sysctl inatumika juu ya namespace ya kern.kdebug na MIBs zinazoweza kutumika zinaweza kupatikana katika sys/sysctl.h zikiwa na kazi zilizotekelezwa katika bsd/kern/kdebug.c.
Ili kuingiliana na kdebug na mteja maalum, hatua hizi kawaida hufuatwa:
Ondoa mipangilio iliyopo na KERN_KDSETREMOVE
Weka trace na KERN_KDSETBUF na KERN_KDSETUP
Tumia KERN_KDGETBUF kupata idadi ya entries za buffer
Pata mteja wako kutoka kwenye trace na KERN_KDPINDEX
Washa kufuatilia na KERN_KDENABLE
Soma buffer kwa kuita KERN_KDREADTR
Ili kulinganisha kila thread na mchakato wake, piga KERN_KDTHRMAP.
Ili kupata habari hii, inawezekana kutumia zana ya Apple trace au zana maalum kDebugView (kdv).
Kumbuka kwamba Kdebug inapatikana kwa mteja 1 tu kwa wakati mmoja. Hivyo zana moja iliyo na k-debug inaweza kutekelezwa kwa wakati mmoja.
APIs za ktrace_* zinatoka libktrace.dylib ambazo zinafungua zile za Kdebug. Kisha, mteja anaweza tu kuita ktrace_session_create na ktrace_events_[single/class] kuweka callbacks kwenye codes maalum na kisha kuanza nayo kwa ktrace_start.
Unaweza kuitumia hata na SIP imewashwa
Unaweza kutumia kama wateja zana ktrace:
Or tailspin.
Hii inatumika kufanya profiling ya kiwango cha kernel na imejengwa kwa kutumia Kdebug callouts.
Kimsingi, variable ya kimataifa kernel_debug_active inakaguliwa na inapowekwa inaita kperf_kdebug_handler na Kdebug code na anwani ya kernel frame inayoiita. Ikiwa Kdebug code inalingana na moja iliyochaguliwa inapata "vitendo" vilivyowekwa kama bitmap (angalia osfmk/kperf/action.h kwa chaguzi).
Kperf ina meza ya sysctl MIB pia: (kama root) sysctl kperf. Mifumo hii inaweza kupatikana katika osfmk/kperf/kperfbsd.c.
Zaidi ya hayo, subset ya kazi za Kperf inapatikana katika kpc, ambayo inatoa habari kuhusu mashine ya kuhesabu utendaji.
ProcessMonitor ni chombo muhimu sana kuangalia vitendo vinavyohusiana na mchakato ambao mchakato unatekeleza (kwa mfano, kufuatilia mchakato mpya ambao mchakato unaunda).
SpriteTree ni chombo kinachochapisha uhusiano kati ya michakato.
Unahitaji kufuatilia mac yako kwa amri kama sudo eslogger fork exec rename create > cap.json (terminal inayozindua hii inahitaji FDA). Na kisha unaweza kupakia json katika chombo hiki ili kuona uhusiano wote:
FileMonitor inaruhusu kufuatilia matukio ya faili (kama vile uundaji, marekebisho, na kufutwa) ikitoa habari ya kina kuhusu matukio hayo.
Crescendo ni chombo cha GUI chenye muonekano na hisia ambazo watumiaji wa Windows wanaweza kujua kutoka Microsoft Sysinternal’s Procmon. Chombo hiki kinaruhusu kurekodi aina mbalimbali za matukio kuanzishwa na kusitishwa, kinaruhusu kuchuja matukio haya kwa makundi kama faili, mchakato, mtandao, nk, na kinatoa uwezo wa kuhifadhi matukio yaliyorekodiwa katika muundo wa json.
Apple Instruments ni sehemu ya zana za Developer za Xcode – zinazotumika kwa kufuatilia utendaji wa programu, kubaini leaks za kumbukumbu na kufuatilia shughuli za mfumo wa faili.
Inaruhusu kufuatilia vitendo vinavyofanywa na michakato:
Taskexplorer ni muhimu kuona maktaba zinazotumiwa na binary, faili inazotumia na muunganisho wa mtandao. Pia inakagua michakato ya binary dhidi ya virustotal na kuonyesha taarifa kuhusu binary.
Katika hiki chapisho la blog unaweza kupata mfano kuhusu jinsi ya kudebug daemon inayotembea ambayo ilitumia PT_DENY_ATTACH kuzuia debugging hata kama SIP ilikuwa imezimwa.
lldb ni chombo cha de facto kwa macOS binary debugging.
Unaweza kuweka ladha ya intel unapotumia lldb kwa kuunda faili inayoitwa .lldbinit katika folda yako ya nyumbani na mstari ufuatao:
Ndani ya lldb, dump mchakato kwa process save-core
(lldb) Amri | Maelezo |
run (r) | Kuanza utekelezaji, ambayo itaendelea bila kukatizwa hadi breakpoint ipatikane au mchakato uishe. |
process launch --stop-at-entry | Kuanza utekelezaji ukisimama kwenye kiingilio |
continue (c) | Endelea na utekelezaji wa mchakato unaosimamiwa. |
nexti (n / ni) | Tekeleza amri inayofuata. Amri hii itakataa kupita kwenye simu za kazi. |
stepi (s / si) | Teekeleza amri inayofuata. Tofauti na amri ya nexti, amri hii itachambua simu za kazi. |
finish (f) | Teekeleza maagizo mengine katika kazi ya sasa (“frame”) rudisha na simamisha. |
control + c | Simamisha utekelezaji. Ikiwa mchakato umekuwa ukikimbia (r) au umeendelea (c), hii itasababisha mchakato kusimama ... popote ambapo unatekelezwa kwa sasa. |
breakpoint (b) |
breakpoint delete <num> |
help | help breakpoint #Pata msaada wa amri ya breakpoint help memory write #Pata msaada wa kuandika kwenye kumbukumbu |
reg | |
x/s <reg/memory address> | Onyesha kumbukumbu kama mfuatano wa herufi unaomalizika na null. |
x/i <reg/memory address> | Onyesha kumbukumbu kama amri ya mkusanyiko. |
x/b <reg/memory address> | Onyesha kumbukumbu kama byte. |
print object (po) | Hii itachapisha kitu kinachorejelewa na param po $raw
Kumbuka kwamba nyingi ya APIs au mbinu za Apple za Objective-C hurudisha vitu, na hivyo zinapaswa kuonyeshwa kupitia amri ya “print object” (po). Ikiwa po haitoi matokeo yenye maana tumia |
memory | memory read 0x000.... memory read $x0+0xf2a memory write 0x100600000 -s 4 0x41414141 #Andika AAAA katika anwani hiyo memory write -f s $rip+0x11f+7 "AAAA" #Andika AAAA katika anwani |
disassembly | dis #Disas kazi ya sasa dis -n <funcname> #Disas func dis -n <funcname> -b <basename> #Disas func dis -c 6 #Disas mistari 6 dis -c 0x100003764 -e 0x100003768 # Kutoka moja kuongeza hadi nyingine dis -p -c 4 # Anza katika anwani ya sasa ikichambua |
parray | parray 3 (char **)$x1 # Angalia array ya vipengele 3 katika x1 reg |
image dump sections | Chapisha ramani ya kumbukumbu ya mchakato wa sasa |
image dump symtab <library> |
|
Wakati wa kuita kazi ya objc_sendMsg, register ya rsi ina jina la mbinu kama mfuatano wa herufi unaomalizika na null (“C”). Ili kuchapisha jina kupitia lldb fanya:
(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:"
Amri ya sysctl hw.model inarudisha "Mac" wakati mwenyeji ni MacOS lakini kitu tofauti wakati ni VM.
Kucheza na thamani za hw.logicalcpu na hw.physicalcpu baadhi ya malware hujaribu kugundua ikiwa ni VM.
Baadhi ya malware pia inaweza gundua ikiwa mashine ni VMware kulingana na anwani ya MAC (00:50:56).
Pia inawezekana kupata ikiwa mchakato unachunguzwa kwa kutumia msimbo rahisi kama:
if(P_TRACED == (info.kp_proc.p_flag & P_TRACED)){ //mchakato unachunguzwa }
Inaweza pia kuita ptrace mfumo wa wito na bendera ya PT_DENY_ATTACH. Hii inaepusha debugger kuungana na kufuatilia.
Unaweza kuangalia ikiwa sysctl au ptrace kazi inayo ingizwa (lakini malware inaweza kuingiza kwa njia ya kidinamik).
Kama ilivyotajwa katika andiko hili, “Kushinda Mbinu za Anti-Debug: macOS ptrace variants” : “Ujumbe Mchakato # ulitoka na hali = 45 (0x0000002d) mara nyingi ni ishara ya wazi kwamba lengo la debug linatumia PT_DENY_ATTACH”
Core dumps zinaundwa ikiwa:
kern.coredump sysctl imewekwa kuwa 1 (kwa kawaida)
Ikiwa mchakato haukuwa suid/sgid au kern.sugid_coredump ni 1 (kwa kawaida ni 0)
Kiwango cha AS_CORE kinaruhusu operesheni. Inawezekana kuzuiya uundaji wa core dumps kwa kuita ulimit -c 0 na kuziwezesha tena kwa ulimit -c unlimited.
Katika hali hizo core dumps inaundwa kulingana na kern.corefile sysctl na kuhifadhiwa kwa kawaida katika /cores/core/.%P.
ReportCrash inafanya uchambuzi wa michakato inayoshindwa na kuhifadhi ripoti ya ajali kwenye diski. Ripoti ya ajali ina habari ambayo inaweza kusaidia mendelezi kutambua sababu ya ajali.
Kwa programu na michakato mingine inayoendesha katika muktadha wa per-user launchd, ReportCrash inakimbia kama LaunchAgent na kuhifadhi ripoti za ajali katika ~/Library/Logs/DiagnosticReports/ ya mtumiaji
Kwa daemons, michakato mingine inayoendesha katika muktadha wa system launchd na michakato mingine yenye mamlaka, ReportCrash inakimbia kama LaunchDaemon na kuhifadhi ripoti za ajali katika /Library/Logs/DiagnosticReports ya mfumo.
Ikiwa unahofia ripoti za ajali zinatumwa kwa Apple unaweza kuzizima. Ikiwa la, ripoti za ajali zinaweza kuwa na manufaa katika kugundua jinsi seva ilivyoshindwa.
Wakati wa fuzzing katika MacOS, ni muhimu kutokuruhusu Mac kulala:
systemsetup -setsleep Never
pmset, Mipangilio ya Mfumo
Ikiwa unafuzzing kupitia muunganisho wa SSH, ni muhimu kuhakikisha kuwa kikao hakitakufa. Hivyo badilisha faili ya sshd_config na:
TCPKeepAlive Yes
ClientAliveInterval 0
ClientAliveCountMax 0
Angalia ukurasa ufuatao ili kujua jinsi unavyoweza kupata ni programu ipi inayohusika na kushughulikia mpango au itifaki iliyoainishwa:
macOS File Extension & URL scheme app handlersHii ni ya kuvutia kupata michakato inayosimamia data ya mtandao:
Au tumia netstat au lsof
Inafanya kazi kwa zana za CLI
Inafanya kazi tu na zana za GUI za macOS. Kumbuka kwamba baadhi ya programu za macOS zina mahitaji maalum kama vile majina ya faili ya kipekee, kiambatisho sahihi, zinahitaji kusoma faili kutoka kwenye sandbox (~/Library/Containers/com.apple.Safari/Data)...
Baadhi ya mifano:
Jifunze & fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Jifunze & fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
