Fråga:
Anti-debug-tekniker på Unix-plattformar?
perror
2013-03-20 14:13:52 UTC
view on stackexchange narkive permalink

Jag försöker skanna alla möjliga tekniker för att störa användningen av en felsökare på en Unix-plattform (t.ex. POSIX och lite mer).

Jag tänker på tekniker som PTRACE test i början av ett program (eller vid olika tidpunkter för dess körning), infogning av falska brytpunkter (t.ex. int3 / 0xcc x86 opkod) eller tid kontroller. Men även globala strategier som definierats i programmet för att sakta ner analysen av programmet.

För närvarande var alla tekniker som jag hittade på Internet lätt bearbetade så snart anti-debug-tekniken har förståts . Så jag undrar om det finns starkare.

"alla tekniker som jag hittade på Internet fungerade enkelt så fort anti-felsökningstekniken har förståts" <- detta är fallet med de flesta av dem men inte en anledning att rabattera dem bara på grund av det.
Du kanske vill kontrollera [detta] [1] ämne. [1]: http://reverseengineering.stackexchange.com/questions/1930/detecting-tracing-in-linux
Två svar:
Igor Skochinsky
2013-03-21 00:27:37 UTC
view on stackexchange narkive permalink

Här är några jag har sett eller hört talas om:

  • Strippa av sektionsrubrikerna. En enkel och helt laglig åtgärd som stoppar GDB död i sina spår. Fungerar inte mot andra felsökare (t.ex. IDA). Kan göras med verktyget sstrip .

  • Med funktionen syscall eller instruktioner för direkt syscalls istället för att anropa specifika funktioner som ptrace () . Kan besegras genom att ställa in brytpunkten på syscall -funktionen eller bara gå igenom filen, men kan vara självklart om du inte vet om det.

  • Utföra anti-felsökningsåtgärder före main () , t.ex. i konstruktörer av globala objekt eller använder __attribut __ ((konstruktör)) . Eftersom GDB vanligtvis ställer in initial brytpunkt i huvud () tar den hand om standardsituationen. Lösning är enkel: sätt brytpunkt på den aktuella filens startpunkt ( infofil i GDB).

  • Skickar sig själv felsökningsrelaterade signaler som SIGTRAP . (Observera att detta kan ignoreras med hantera SIGTRAP nostop i GDB.)

  • Gafflar och spårar sig själv med ptrace .

  • Falska brytpunkter införs: Att infoga int3 / 0xcc tvingar felsökaren att stoppa på dessa byte eftersom de kommer att behandlas som mjukvarupauser. Om de är många kan det bromsa analysen avsevärt.

  • Detektering av brytpunkt: Jag såg den här tekniken i detta papper, du kan bifoga en funktion som kommer att utlösas när en brytpunkt anges. Denna uppsats täcker också några andra knep.

Okej, det här verkar vara en rimlig lista över tekniker men inget överraskande hittills. Och du saknar breakpoints-knep (infogning av falska brytpunkter för att förvirra felsökaren när PTRACEd och kontrollera hash för nästa kodblock för att se om nya brytpunkter för programvara har satts in eller inte). Men skulle du veta ett papper som beskriver alla dessa tekniker för Unix (jag känner till vissa papper för MS-Windows men ingen för Unix-system).
@Emmanuel: gärna redigera den och lägga till mer, det är därför jag gjorde det till en wiki. Jag känner inte till några papper, men möjligen kan du hitta några fler knep i något som Phrack.
Min IDA dog när jag försökte ladda en ARM-binär som fick avdelningsrubrikerna avskalade. Så # 1 kan fortfarande vara ett användbart trick (även om jag till slut skrev ett manus för att rekonstruera rubrikerna).
@nneonneo: om det händer med den aktuella versionen, skicka en felrapport. tack.
Det riktiga roliga är gaffel och använd ptrace () på dig själv som en form av IPC.
Andrew
2013-03-20 19:31:52 UTC
view on stackexchange narkive permalink

Min förståelse av antidebugging-teknik är att det är ett spel av katt och mus (eller katt och även katt). En teknik fungerar tills den förstås av den motsatta sidan och då fungerar den inte längre. Jag tror att i slutändan är fördelen på felsökarens sida. Tänk på dynamiska binära instrument eller system för virtuella maskiner. Du kan upptäcka förekomsten av DBI eller emulering genom att leta efter sprickor eller fel i emuleringen av plattformen, men det är bara fel i emulerings- / översättningsprogrammet. Om du hade ett "perfekt" emuleringssystem, kunde ett felsökat program inte veta att det spårades?

Så jag tror att det bästa du kan göra är små saker som lätt kan bearbetas. Shiva-systemet tycker jag fortfarande representerar "okej" skydd mot felsökning på Unix-plattformar, eftersom det dekrypterar små delar av sig själv för att köras på begäran och sedan krypterar dem, som jag minns.

Jag skulle tagga Shiva-systemet som en avancerad packare men egentligen inte en anti-felsökningsteknik (även om dess huvudsakliga effekt är att göra användningen av en felsökare extremt tråkig eftersom ditt fönster i minnet där du effektivt kan ställa in brytpunkter är extremt litet jämfört med ett "normalt" program).


ⓘ
Denna fråga och svar översattes automatiskt från det engelska språket.Det ursprungliga innehållet finns tillgängligt på stackexchange, vilket vi tackar för cc by-sa 3.0-licensen som det distribueras under.
Loading...