Küsimus:
Silumisvastased tehnikad Unixi platvormidel?
perror
2013-03-20 14:13:52 UTC
view on stackexchange narkive permalink

Püüan skannida kõiki võimalikke võtteid, et häirida siluri kasutamist Unixi platvormil (st POSIX ja natuke muud).

Mõtlen sellistele tehnikatele nagu PTRACE test programmi alguses (või selle täitmise erinevates punktides), võltsitud katkestuspunktide (nt int3 / 0xcc x86 opcode) või kellaaja sisestamine kontrollid. Kuid ka programmi jaoks määratletud globaalsed strateegiad programmi analüüsi aeglustamiseks.

Praegu on kõik Internetis leitud tehnikad hõlpsasti ümber töötatud kohe, kui silumisvastane tehnika on mõistetud . Nii et ma ei tea, kas on ka tugevamaid.

"Kõik Internetis leitud tehnikad said hõlpsasti ümber töötatud, niipea kui silumisvastasest tehnikast on aru saadud" <- see on enamiku puhul nii, kuid mitte põhjus, miks neid lihtsalt sellepärast allahindleda.
Võite kontrollida [seda] [1] teemat. [1]: http://reverseengineering.stackexchange.com/questions/1930/detecting-tracing-in-linux
Kaks vastused:
Igor Skochinsky
2013-03-21 00:27:37 UTC
view on stackexchange narkive permalink

Siin on mõned, mida olen näinud või millest olen kuulnud:

  • Jaotiste päiste eemaldamine. Lihtne ja täielikult seaduslik tegevus, mis peatab GDB oma jälgedes surnud. Ei tööta mõnede teiste silurite (nt IDA) vastu. Seda saab teha tööriista sstrip abil.

  • Funktsiooni syscall või otseste syscallsi juhiste kasutamine konkreetsete funktsioonide nagu ptrace () kutsumise asemel. Saab alistada, määrates katkestuspunkti funktsioonis syscall või lihtsalt failist läbi astudes, kuid see ei pruugi olla ilmne, kui te sellest ei tea.

  • Silumisvastaste toimingute tegemine enne main () , nt globaalsete objektide konstruktorites või __attribute __ ((constructor)) abil. Kuna GDB määrab algse murdepunkti tavaliselt main () -is, hoolitseb ta vaikesituatsiooni eest. Lahendus on lihtne: asetage katkestuspunkt faili tegelikule sisestuspunktile ( infofail GDB-s).

  • Silumisega seotud signaalide nagu SIGTRAP saatmine ise . (Pange tähele, et seda saab GDB-s handle SIGTRAP nostop -ga ignoreerida.)

  • Hargnemine ja jälitamine funktsiooniga ptrace .

  • Võltsmurdepunktide sisestamine: int3 / 0xcc sisestamine sunnib siluri nendel baitidel peatuma, kuna neid käsitletakse tarkvara katkestuspunktidena. Kui neid on palju, võib see analüüsi märkimisväärselt aeglustada.

  • Murdepunkti tuvastamine: nägin seda tehnikat sellest paberist, saate lisada funktsiooni, mis käivitatakse, kui murdepunkt on sisse lülitatud. See artikkel hõlmab ka mõningaid muid trikke.

Ok, see tundub mõistlik tehnikate loetelu, kuid praegu pole midagi üllatavat. Ja puuduvad katkestuspunktide nipid (võltsitud katkestuspunktide sisestamine siluri segamiseks PTRACEd ajal ja järgmise koodiploki räsi kontrollimine, et näha, kas uued tarkvara katkestuspunktid on sisestatud või mitte). Kuid kas teaksite paberit, mis kirjeldaks kõiki neid Unixi tehnikaid (tean mõnda MS-Windowsi jaoks mõeldud dokumenti, kuid ühtegi Unixi süsteemi jaoks).
@Emmanuel: redigeerige seda julgelt ja lisage veel, sellepärast tegin selle vikiks. Ma ei ole teadlik ühestki paberist, kuid võib-olla leiate Phracki-laadsest veel mõned trikid.
Minu IDA suri, kui üritasin laadida ARM-binaarkaarti, mille sektsiooni päised eemaldati. Nii et # 1 võib endiselt olla kasulik trikk (kuigi lõpuks kirjutasin päiste taastamiseks skripti).
@nneonneo:, kui see juhtub praeguse versiooniga, saatke veaaruanne. aitäh.
Tõeline lõbu on kahvel ja kasutage IPC vormina enda peal ptrace ().
Andrew
2013-03-20 19:31:52 UTC
view on stackexchange narkive permalink

Minu arusaam silumisvastasest tehnoloogiast on see, et see on kassi ja hiire (või kassi ja ka kassi) mäng. Tehnika töötab seni, kuni vastaspool saab sellest aru ja siis see enam ei toimi. Ma arvan, et lõppkokkuvõttes on eelis siluri pool. Mõelge dünaamilistele binaarsetele seadmetele või virtuaalsete masinate süsteemidele. DBI või emuleerimise olemasolu saate tuvastada, kui otsite platvormi emuleerimisel pragusid või vigu, kuid need on vaid vead emuleerimise / tõlkimise tarkvaras. Kui teil oli "täiuslik" emuleerimissüsteem, siis ei saanud silutud rakendus teada, et seda jälitati?

Shiva süsteem kujutab minu meelest ikkagi olevat "korras" kaitset silumise eest Unixi platvormidel, kuna see dekrüpteerib enda väikeste osade nõudmisel töötamiseks ja seejärel krüpteerib need, nagu ma mäletan.
Ma märkiksin Shiva süsteemi täiustatud pakendajana, kuid tegelikult mitte silumisvastaseks tehnikaks (isegi kui selle peamine efekt on siluri kasutamise muutmine äärmiselt tüütuks, sest teie aken mälus, kus saate tõhusalt seada murdepunkte, on võrreldes "tavaline" programm).


ⓘ
See küsimus ja vastus tõlgiti automaatselt inglise keelest.Algne sisu on saadaval stackexchange-is, mida täname cc by-sa 3.0-litsentsi eest, mille all seda levitatakse.
Loading...