This shows you the differences between two versions of the page.
iocla:laboratoare:laborator-12 [2022/01/18 13:06] darius.mihai [Feedback] Fix date |
— (current) | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== Laborator 12: CTF ====== | ||
- | În acest laborator veți interacționa cu majoritatea noțiunilor prezentate pe parcursul semestrului prin intermediul unor taskuri de tip ''%%Capture-The-Flag%%''. Acestea vor testa înțelegerea și stăpânirea metodelor și toolurilor specifice de analiză statică și dinamică, înțelegerea procesului de compilare, a limbajului de asamblare - sintaxă, regiștri, lucru cu memoria, funcții - dar și capacitatea de identificare și exploatare a unor vulnerabilități simple de tip buffer overflow. | ||
- | |||
- | ===== Feedback ===== | ||
- | |||
- | Pentru a îmbunătăți cursul de IOCLA, componentele sale și modul de desfășurare, ne sunt foarte utile opiniile voastre. Pentru aceasta, vă rugăm să accesați și completați formularul de feedback de pe site-ul [[https://curs.upb.ro/|curs.upb.ro]]. Trebuie să fiți autentificați și înrolați în cadrul cursului. | ||
- | |||
- | Formularul este anonim și este activ în perioada 17 ianuarie 2022 - 28 ianuarie 2022. Rezultatele vor fi vizibile în cadrul echipei cursului doar după încheierea sesiunii. Puteți accesa formularul de feedback începând cu 17 ianuarie 2022. Este accesibil la link-ul “Formular feedback” a paginii principale a cursului de IOCLA al seriei voastre. Nu este în meta-cursul disponibil tuturor seriilor. | ||
- | |||
- | Vă invităm să evaluați activitatea echipei de IOCLA și să precizați punctele tari și punctele slabe și sugestiile voastre de îmbunătățire a disciplinei. Feedback-ul vostru ne ajută să creștem calitatea materiei în anii următori și să îmbunătățim disciplinele pe care le veți face în continuare. | ||
- | |||
- | Vom publica la începutul semestrului viitor analiza feedback-ului vostru. | ||
- | |||
- | Ne interesează în special: | ||
- | |||
- | - Ce nu v-a plăcut și ce credeți că nu a mers bine? | ||
- | - De ce nu v-a plăcut și de ce credeți că nu a mers bine? | ||
- | - Ce ar trebui să facem ca lucrurile să fie plăcute și să meargă bine? | ||
- | |||
- | ===== Exerciții ===== | ||
- | |||
- | <note> Fiecare dintre exerciții ascunde un flag cu formatul ''%%iocla_{<string>}%%'' </note> | ||
- | |||
- | <note tip> În general, flagul va fi returnat ca și string de o funcție specială, ''%%get_flag()%%''. Scopul exercițiilor nu implică a face reverse-engineering pe această funcție sau apel direct din cadrul debuggerului; se recomandă tratarea ei ca și Black Box. </note> | ||
- | |||
- | <note tip> Pentru generarea payloadurilor la taskurile de tip buffer overflow, puteți folosi în terminal o comandă de tipul: ''%%python -c 'import sys; sys.stdout.write("A"\*10 + b"\x00\x00\x00\x00" + ...)' | ./exec%%''. </note> | ||
- | |||
- | ==== 00. Hey! Hey, listen! ==== | ||
- | |||
- | Dacă ne oferiți feedback, ne ajutați să <del>îl facem pe Lunk mai puternic</del> îmbunătățim materia. Mergeți la secțiunea [[#feedback|feedback]] pentru detalii. | ||
- | |||
- | ==== 1.1. Hidden in plain sight ==== | ||
- | |||
- | Binarul ''%%1-1-hidden-in-plain-sight/link%%'' expune tot ce aveți nevoie. Găsiți un mod de a-l folosi. | ||
- | |||
- | <note tip> If you want a main function to be done right, you gotta do it yourself. </note> | ||
- | |||
- | ==== 1.2. Hidden in plain sight ++ ==== | ||
- | |||
- | Investigați binarul ''%%1-2-hidden-in-plain-sight/link2%%''. Modul în care poate fi executat nu mai este un mister, dar va fi puțin mai dificil să ajungeți la flag. | ||
- | |||
- | <note tip> Nu toate funcțiile sunt private. </note> | ||
- | |||
- | ==== 2. Look at him go ==== | ||
- | |||
- | Binarul ''%%2-look-at-him-go/dynamic%%'' este de data aceasta executabil și are ca unic scop obținerea flagului și plasarea lui undeva in memorie. No tricks here. | ||
- | |||
- | <note tip> GDB is your friend. </note> | ||
- | |||
- | ==== 3. Playing God ==== | ||
- | |||
- | Binarul ''%%3-playing-god/dynamic2%%'' vă cere să ghiciți un număr între 1 și 100000. Găsiți o cale mai bună de a-l afla. | ||
- | |||
- | ==== 4. Indirect business ==== | ||
- | |||
- | Binarul ''%%4-indirect-business/buff-ovf%%'' conține o vulnerabilitate clasică. Folosiți inputul pentru a modifica datele în favoarea voastră. | ||
- | |||
- | ==== 5. RIP my buffers off ==== | ||
- | |||
- | Binarul ''%%5-rip-my-buffers-off/buff-ovf2%%'' nu folosește funcția get_flag(), dar oferă o oportunitate de a o apela. | ||
- | |||
- | <note tip> Unde se poate suprascrie o adresă de funcție? </note> | ||
- | |||
- | ==== 6. Feeling chained ==== | ||
- | |||
- | Urmăriți șirul de operații din funcțiile binarului ''%%6-feeling-chained/buff-ovf3%%''. Identificați-le pe cele necesare și... deja știți cum se apelează. | ||
- | |||
- | ===== Bonus ===== | ||
- | |||
- | ==== 7. ROP ==== | ||
- | |||
- | ''%%7-rop/rop%%'' este un binar pe 64 de biți cu un simplu buffer overflow. | ||
- | |||
- | <note tip> Pe x86_64 argumentele funcțiilor nu se mai găsesc pe stivă, ci în registre. </note> | ||
- | |||
- | <note tip> Return-Oriented-Programming (ROP) este o tehnică de exploatare în care, având posibilitatea de a suprascrie adresa de return, executăm prin înlănțuire diverse porțiuni din codul existent, care se termină într-o instrucțiune ''%%ret%%''. Aceste bucăți de cod se numesc ''%%gadgeturi%%''. </note> | ||
- | |||
- | <note tip> Pentru determinarea adresei unui gadget într-un binar, există tool-ul [[https://github.com/JonathanSalwan/ROPgadget|ROPgadget]]. Alternativ, în ''%%pwndbg%%'', puteți folosi o comandă de tipul ''%%rop --grep "pop rsi"%%''. </note> |