Paano gamitin ang AFL at AFL++ upang epektibong mag-fuzz ng mga binary

Kung interesado ka sa Cybersecurity at pagsasamantala na nakatuon sa binaryMaaga o huli ay makakatagpo ka ng fuzzing, at lalo na ang AFL at AFL++. Hindi natin pinag-uusapan ang isang teoretikal na kagamitan sa laboratoryo, kundi isang bagay na ginagamit araw-araw upang mahanap ang mga totoong depekto sa mga kilalang programa, tulad ng nangyari sa mga kahinaan sa... mga sikat na aplikasyon tulad ng 7-Zip.

Sa mga sumusunod na linya ay makikita natin, nang detalyado at sa isang palakaibigang tono, Paano gamitin ang AFL at AFL++ para mag-fuzz ng mga binaryIpapaliwanag namin nang eksakto kung ano ang fuzz testing, kung bakit ito napakalakas sa mga tuntunin ng seguridad, at kung paano ito isama sa isang modernong daloy ng trabaho sa pag-develop. Susuriin din namin ang isang kaso ng kahinaan sa totoong mundo (isang Integer Underflow na nagpapahintulot sa remote code execution) at susuriin ang mga komplementaryong tool tulad ng GDB na may mga extension, AFLTriage at mga operating module.

Ano ang AFL/AFL++ at bakit sila itinuturing na mga smart fuzzer?

AFL (American Fuzzy Lop) at ang ebolusyon nito AFL++ Ito ay mga open-source fuzzing tool na idinisenyo upang awtomatikong subukan ang mga binary, naghahanap ng mga fault tulad ng mga overflow, mga error sa memorya, o mga hindi inaasahang pag-uugali na humahantong sa mga pag-crash o maging sa mga maaaring mapagsamantalahang kahinaan.

Ang kagandahan ng AFL ay hindi lamang ang pagpapadala ng random na datos, kundi isang matalinong fuzzer o coverage-guided fuzzerSimula sa isa o higit pang wastong halimbawang entry (ang tinatawag na mga kaso ng pagsubok), ang AFL ay patuloy na bumubuo ng mga baryasyon at, salamat sa instrumentasyon ng programa, natutukoy nito kapag ang isang bagong mutasyon ay nagiging sanhi ng pag-iba ng landas ng pagpapatupad ng binary.

Upang makamit ang instrumentasyong ito, ang AFL ay may sariling mga compiler, tulad ng afl-gcc at afl-g++Naglalagay ang mga ito ng maliliit na "hook" sa code habang kino-compile. Ipinapaalam ng mga hook na ito sa AFL na may natuklasang input. mga bagong ruta sa daloy ng programaNagbibigay-daan ito sa iyo na tumuon sa mga mutasyon na talagang nagbibigay ng karagdagang saklaw at hindi mag-aaksaya ng oras sa datos na walang binabago.

Dahil sa pamamaraang ito, ang AFL ay maituturing na parang "dirb of binaries": isang kilalang kagamitan, madaling gamitin kapag naunawaan mo na ang pangunahing daloy, at sapat ang husay upang matuklasan mga malubhang depekto sa mga programa sa produksyonkahit na may mga mas advanced o specialized na fuzzers.

Panimula sa fuzz testing at ang papel nito sa cybersecurity

Ang fuzz testing, o simpleng fuzzing, ay isang pamamaraan ng awtomatikong pagsubok sa seguridad at katataganAng ideya ay magpadala sa isang application ng napakaraming sirang, random, o hindi pangkaraniwang data, na may layuning makita kung ang programa ay masira, magka-crash, o kumilos nang hindi inaasahan.

Kapag ang software ay isinailalim sa fuzzing, ang layunin ay upang mahanap ang mga error tulad ng mga buffer overflow, mga pagkabigo sa pagpapatunay ng input, mga problema sa pamamahala ng memorya, o mga kondisyon ng kareraMarami sa mga depektong ito ay maaaring humantong sa arbitraryong pagpapatupad ng code, mga pagtagas ng impormasyon, o mga pagtanggi sa serbisyo.

Sa isang tipikal na daloy ng trabaho, ang fuzz testing ay sumusunod sa tatlong malinaw na yugto: una, ang test dataset ay nabubuo (ganap man itong random, nabubuo kasunod ng isang partikular na format, o sa pamamagitan ng pag-mutate ng mga valid na input); pagkatapos... isagawa ang binary na sinusubukan habang sinusubaybayan Ang kilos nito ay minomonitor; at panghuli, ang mga pag-crash o hindi pangkaraniwang kilos ay itinatala at sinusuri upang maimbestigahan ng mga developer ang pinagmumulan ng problema.

Mayroong iba't ibang mga estratehiya sa pagpapabulong. Ang ilang mga kagamitan ay nakatuon sa kaguluhan sa henerasyonpaglikha ng mga entry na sumusunod sa isang mahusay na natukoy na format (halimbawa, isang istruktura ng file o isang network protocol); ang iba ay batay sa mutasyon ng mga wastong inputIto mismo ang pamamaraan kung saan nangunguna ang AFL at AFL++. Mayroon ding mga mas random na pamamaraan at iba pa na umaasa sa partikular na kaalaman sa sistemang sinusubok upang ma-target ang pinakamahina nitong mga punto.

Sa modernong cybersecurity, ang fuzz testing ay isang pangunahing kakampi: nakakatulong ito upang mahanap ang mga kahinaan sa isang maagap, bago pa man magsimula ang produksyon ng softwareat nakakatulong sa pagsunod sa mga regulasyon at pamantayan tulad ng ISO 27001 o mga kinakailangan sa proteksyon ng datos. Bukod pa rito, binabawasan nito ang panganib sa reputasyon na magreresulta mula sa isang kritikal na kahinaan na maaaring pagsamantalahan na mahulog sa mga kamay ng mga umaatake.

Isang totoong kaso: Integer Underflow at kahinaan ng RCE sa isang decompressor

Upang maunawaan ang tunay na halaga ng AFL at fuzzing, lubhang kapaki-pakinabang na tingnan ang isang partikular na kahinaan batay sa isang Integer Underflow sa loob ng isang napakasikat na file decompressorIto ay isang remote code execution (RCE) fault na nati-trigger kapag pinoproseso ang mga naka-compress na file gamit ang Zstandard algorithm, na may mataas, bagama't hindi pinakamataas, na marka ng CVSS, dahil mismo sa nangangailangan ito ng medyo mas espesipikong konteksto (halimbawa, na pinoproseso ang mga partikular na file).

Nangyayari ang Integer Underflow kapag ang isang integer variable na may mahusay na natukoy na mga lower bounds Ginagamit ito sa mga operasyon ng pagbabawas hanggang sa maabot ang pinakamababang halaga nito.Dahil maraming uri ng integer ang hindi nagpapahintulot ng mga negatibong halaga, kapag "bumababa", sa halip na makakuha ng numerong mas mababa sa zero, nangyayari ang pagtalon sa pinakamataas na posibleng halaga ng saklaw, dahil sa kung paano kinakatawan ang mga numerong iyon sa loob.

Isipin ang isang integer variable na, sa teorya, ay hindi dapat maging negatibo. Kung patuloy kang magbabawas ng isang constant hanggang sa maabot mo ang 0 at patuloy na magbawas, Hindi ka makakakuha ng -1, -2, atbp.Sa halip, ang halaga ay babaliktad at magiging isang napakalaking numero sa itaas na dulo ng pinapayagang saklaw. Ang kakatwang pigurang ito, kung gagamitin bilang indeks o laki sa mga operasyon ng memorya, ay maaaring magdulot ng mga pagbasa o pagsulat na lampas sa nilalayong mga limitasyon.

Nagiging kritikal ang problema kapag ang variable na integer na maaaring mag-underflow ay ginamit para sa para pamahalaan ang isang buffer o para kalkulahin ang mga offsetAng isang tipikal na pseudo-example ay ang paggamit ng isang user-controlled variable nang hindi direkta bilang isang offset sa isang memcpy-type function, sa isang loop na nagbabawas ng isang constant sa bawat iteration hanggang sa umano'y umabot ito sa zero o isang non-positive number.

Sa ganitong senaryo, kung ang paunang halaga ay hindi kailanman "malinis" na matugunan ang kondisyon ng paglabas, ang underflow ay kalaunan ay magpapalaki sa bilang, ang loop ay magpapatuloy sa pagtakbo, at ang isang malawakang pagkasira ng memoryaIto ay isinasalin sa mga pag-crash at, kung sapat ang gawaing pagsasamantala, ang posibilidad ng pagpapatupad ng arbitraryong code.

Paano nakakatulong ang AFL na matukoy ang mga ganitong uri ng kahinaan

Kapag naunawaan na ang konsepto ng Integer Underflow, nagiging malinaw kung bakit lubhang kapaki-pakinabang ang AFL at AFL++: simula sa isa o ilang perpektong wastong input fileAng fuzzer ay maaaring makabuo ng sampu-sampung libong baryasyon, hanggang sa matagpuan nito ang isa na nagti-trigger ng partikular na bug sa apektadong landas ng decompression.

Habang nagfu-fuzz, minomonitor ng AFL ang instrumented binary upang matukoy kung kailan nagiging sanhi ng pagpapatupad ng ibang flow control path ang isang input. Sa bawat pagkakataong makakakita ito ng bagong path, Markahan ang entry na iyon bilang kawili-wili at pinapanatili ito bilang batayan para sa mga mutasyon sa hinaharap. Sa ganitong paraan, hindi lamang ang karaniwang mga landas ng pagpapatupad ang ginalugad, kundi pati na rin ang mga kumbinasyon ng datos na nagpapagana ng mga hindi pangkaraniwang ruta ng code, tulad ng proseso ng decompression na may kakaibang mga parameter.

Sa kaso ng Integer Underflow, makakahanap ang AFL ng sample na nagiging sanhi ng hindi kailanman pag-abot ng variable na kasangkot sa inaasahang halaga ng output sa loop. Ang resulta ay isang matukoy na pag-crash, na itatago sa kaukulang folder ng mga resulta ng AFL, handa na para sa karagdagang pagsusuri.

Pagkatapos ng ilang minuto o oras ng pagpapatupad, karaniwan para sa AFL na ipahiwatig ang unang kaugnay na pag-crashHindi lahat ng bug na mahahanap mo ay maaaring gamitin, ngunit ang mga ito ay isang malinaw na indikasyon na may isang bagay sa pamamahala ng memorya, pagpapatunay ng input, o panloob na lohika ng binary na hindi gumagana nang maayos.

Dito pumapasok ang mga support tool tulad ng AFLTriage o isang debugger tulad ng GDB, na nagbibigay-daan sa iyong mas malalimang suriin ang pag-crash, obserbahan ang estado ng mga register at memory, at suriin kung ang failure ay maaasahang magagamit o kung ito ay isa lamang kalokohan na hindi gaanong kapaki-pakinabang mula sa pananaw ng attacker.

Pangunahing pag-install ng AFL / AFL++ at kapaligirang pang-analisa

Ang pag-set up ng minimal environment para sa fuzzing gamit ang AFL sa isang karaniwang sistema ng Linux ay medyo simple. Sa maraming distribusyon, sapat na ang pag-install ng package na naaayon sa mga instrumented compiler, halimbawa, gamit ang isang command tulad ng i-install ang afl-g++ o ang katumbas na pakete ng AFL++ Dalhin ang buong suite.

Ang paggawa nito ay mag-i-install ng parehong fuzzing tools (tulad ng afl-fuzz) tulad ng mga espesyalisadong compiler (afl-gcc, afl-g++, at ang kanilang mga modernong variant sa AFL++). Ang mga compiler na ito ang gagamitin mo kapag gusto mong i-recompile ang iyong target gamit ang instrumentation, na mahalaga upang masulit ang coverage-guided fuzzing.

Bukod sa mismong fuzzer, halos kinakailangan ang isang mahusay na debugging environment. Isang pinalawak na GDB na may mga plugin tulad ng PEDA o GEF Ginagawa nitong mas madali ang buhay salamat sa mga karagdagang utos, maginhawang pag-format ng memorya, mga stack visualization, at mga shortcut para sa pagsuri ng mga rehistro at mga mapa ng memorya.

Kung wala ka pang GDB, maaari mo itong i-install gamit ang package manager ng iyong distribution. Pagkatapos, i-integrate lang ang napili mong plugin (halimbawa, sa pamamagitan ng pag-download ng GEF o PEDA mula sa kanilang mga repository at pagdaragdag ng mga ito sa iyong GDB configuration file, o sa pamamagitan ng paggamit ng command na `source` sa loob mismo ng debugger).

Ang pagkakaroon ng ganitong "GDB on steroids" ay magbibigay-daan sa iyo na suriin ang mga instrumented binary na gumuho kapag na-fuzz, i-download ang mga input na nagdudulot ng pag-crash at sundan nang sunud-sunod kung ano ang nangyayari sa pagpapatupad nang eksakto sa punto ng pagkabigo.

Gumawa ng isang target na binary gamit ang AFL para sa fuzzing

Kapag handa ka na sa AFL o AFL++, ang susunod na hakbang para sa seryosong pag-aayos ng buhok ay i-compile ang target gamit ang mga AFL compilerat gawin ito gamit ang mga naaangkop na opsyon upang mapadali ang parehong pagsusuri at potensyal na pagsasamantala, kung sakaling ang layunin ng pagsasanay ay nakakasakit na pananaliksik.

Sa malalaking proyekto, tulad ng decompressor o archive utility suite, mainam na paganahin ang mga debugging symbol (opsyon DEBUG o mga flag tulad ng -gat bawasan ang mga pag-optimize (halimbawa, paggamit ng -O0 sa halip na -O2). Malaki ang naitutulong nito sa pag-unawa sa nangyayari sa source code kaugnay ng naobserbahang pag-crash.

Karaniwan mong kakailanganing hanapin ang naaangkop na makefile o build file at baguhin ang mga linya kung saan tinukoy ang mga flag ng compilationMaaaring kabilang dito ang pag-activate ng isang DEBUG variable, pagpwersa ng isang partikular na antas ng pag-optimize, at, higit sa lahat, ang pagpapalit ng CC at CXX ng afl-gcc at afl-g++ (o ang katumbas na mga tool na AFL++).

Halimbawa, maaari mong ilunsad ang build gamit ang isang bagay tulad ng CC=afl-gcc at CXX=afl-g++ kasama ang naaangkop na makefile. Ang resulta ay isang instrumented binary na isinasama ang mga kinakailangang hook upang masukat ng AFL ang coverage sa buong pagpapatupad.

Kapag kumpleto na ang compilation, mainam na suriin kung ang resultang binary ay mayroon talagang mga debugging symbol at tamang arkitektura, gamit ang isang command tulad ng file tungkol sa executableTinitiyak nito na hindi ka basta-basta nagkakamali at madali mong maa-debug ang anumang lumalabas na pag-crash.

Paghahanda ng mga kaso ng pagsubok at pagpapatupad ng AFL

Bago ilunsad ang AFL laban sa iyong binary, kailangan mong maghanda ng isang set ng minimum na wastong mga entryKung sinusubukan mo ang isang decompressor na nabigo sa mga file na na-compress gamit ang isang partikular na algorithm, kakailanganin mong lumikha ng kahit isang maayos na file na gumagamit ng paraan ng compression na iyon.

Ang karaniwang gawain ay ang paglikha ng isang direktoryo, halimbawa na tinatawag na mga testcase, at pag-iimbak ng isa o higit pang mga gumaganang sample doon. Ang mga ito ang magsisilbing panimulang punto para sa AFL. lumilikha ng lalong agresibong mga mutasyonsinusubukang tumuklas ng mga bagong landas sa pagpapatupad at, kalaunan, nagka-crash.

Ang karaniwang utos para simulan ang AFL ay ganito ang hitsura: tukuyin ang pangalan ng session o synchronization, ang input folder na may mga test case, ang output path kung saan itatago ang mga resulta, at ilang karagdagang parameter tulad ng timeout upang maiwasan ang pagka-stuck sa infinite loops.

Tinutukoy din ng command line kung paano isinasagawa ang target na programa gamit ang ang scoreboard @@na awtomatikong papalitan ng AFL ng path ng bawat test case na nabubuo nito. Kaya maaari kang tumukoy ng isang bagay tulad ng ./binary na mga argumento @@ at ang AFL ang magiging responsable sa paglulunsad ng executable nang libu-libong beses gamit ang iba't ibang file.

Mahalagang malaman na maaaring magreklamo ang AFL sa simula tungkol sa configuration ng system (dahil sa mga limitasyon ng resource, core dumps, atbp.). Sa ganitong kaso, karaniwang mayroong helper script o tool na nag-aayos ng mga parameter ng kernel at session upang ma-optimize ang fuzzing environment, na dapat patakbuhin nang may naaangkop na mga pahintulot bago ulitin ang pagsubok.

Pagsusuri ng pag-crash gamit ang AFLTriage at GDB

Pagkatapos ng isang panahon ng pag-iisip, unti-unting pupunuin ng AFL ang output folder ng mga kawili-wiling bagong entry at, higit sa lahat, ng mga file na nagdulot ng mga pag-crashKaraniwang nakaimbak ang mga ito sa isang partikular na subdirectory (halimbawa, mga pag-crash sa loob ng session folder).

Para maiwasan ang pagkabaliw sa pagsusuri ng bawat input nang paisa-isa, may mga tool tulad ng AFLTriage na nagbibigay-daan sa iyo upang Awtomatikong patakbuhin ang binary laban sa bawat crash file at bumuo ng mga nakabalangkas na ulat na may mga detalye tungkol sa kung saan at paano naganap ang pagkabigo.

Kapag inilulunsad ang AFLTriage, tinutukoy mo ang input directory (ang crash folder), isang output directory para i-save ang mga ulat, at ang command para patakbuhin ang binary gamit ang @@. Susuriin ng tool ang bawat kaso at Bubuo ito ng mga text file na may impormasyong interesado ka. para sa analista.

Kasama sa karaniwang nilalaman ng mga ulat na ito ang uri ng signal na nagdulot ng pag-crash, ang direksyon kung saan ito nabigo, isang pangunahing stack trace, at, sa maraming kaso, ang function o macro kung saan nasira ang code (halimbawa, isang partikular na operasyon ng pagkopya, isang compression loop, o isang COPY_CHUNKS macro na nagbabawas ng mga laki sa bawat iteration).

Kapag natagpuan na ang isang kawili-wiling pag-crash, ang susunod na hakbang ay ang muling paggawa nito sa GDB. Upang gawin ito, ilulunsad ang debugger kasama ang binary at ang culprit input file bilang mga argumento, at ang programa ay isinasagawa mula sa loob ng GDB. Kapag ang pag-crash ay muling ginawa, ang estado ng Mga pangunahing talaan tulad ng RAX, RDX, atbp., suriin ang eksaktong instruksyon na isinasagawa at sumangguni sa mga memory maps (vmmap) upang makita kung aling rehiyon ang binabasa o sinusulatan.

Mula sa pagbagsak hanggang sa potensyal na pagsasamantala: mga modyul ng pagsusuri sa GDB

Ang pagkakita ng pagbagsak ng isang binary ay hindi palaging nangangahulugan na ang kahinaan ay maaaring pagsamantalahan. Dito pumapasok ang mga extension ng GDB tulad ng module. mapagsamantalahan, na idinisenyo upang suriin ang konteksto ng isang pag-crash at mag-alok ng isang magaspang na klasipikasyon kung ang pagkabigo ay maaaring pagsamantalahan o hindi.

Pinag-aaralan ng mga ganitong uri ng extension ang mga aspeto tulad ng bisa ng instruction pointer, ang estado ng stack pointer, ang mga pahintulot sa memorya ng address kung saan ginawa ang pagtatangkang magbasa o sumulat, at ang uri ng signal na nagdulot ng pag-crash. Gamit ang lahat ng impormasyong ito, nagbibigay ang mga ito ng indikatibong hatol sa potensyal ng pagsasamantala (halimbawa, sa pamamagitan ng pag-uuri sa bug bilang malamang na mapagsamantalahan, posibleng mapagsamantalahan, o walang gaanong interes).

Sa kaso ng Integer Underflow na nagtatapos sa pagsusulat sa read-only memory, maaaring iminumungkahi ng plugin na ito ay isang posibleng mapagsamantalahang kaso dahil ang isang write operation ay isinasagawa sa labas ng inaasahang mga limitasyon sa isang rehiyon kung saan walang dapat hawakan.

Hindi lahat ng senaryo ay magiging ganito kasimple, ngunit ang kombinasyong ito ng AFL upang matuklasan ang pagbagsak, AFLTriage upang pangkatin at ilarawan ang mga kaso, at GDB na may mga extension upang masuri ang kakayahang magamit, ay bumubuo ng isang Napakatatag na pipeline ng binary auditMula roon, ang natitirang gawain ay puro pananaliksik at pagpapaunlad ng exploit, isang bagay na maaaring mag-iba nang malaki sa pagiging kumplikado depende sa binary at aktibong proteksyon.

Ang isa pang mahalagang bahagi ng pagsusuri, lalo na kapag ang isang CVE at kaugnay na patch ay inilathala, ay ang pagsusuri kung paano naayos ang kahinaan sa source code. Karaniwang kinabibilangan ito ng mga pagbabago sa uri ng datos na ginamit (halimbawa, paglipat mula sa isang signed byte patungo sa isang unsigned byte, pagpapalawak ng saklaw) at ang pagsasama ng mga karagdagang tseke (mga kung na magbabalik ng mga error code kung lumampas sa ilang partikular na limitasyon) upang maiwasan ang underflow o katiwalian ng memorya.

Iba pang kaugnay na mga fuzzer at tool sa ecosystem

Bagama't ang AFL at AFL++ ay kabilang sa mga pinakakilalang opsyon para sa pag-fuzz ng mga native binary, ang fuzz testing ecosystem ay mas malawak at sulit na bantayan kung regular kang nakikipagtulungan sa... seguridad ng software.

Kabilang sa mga pinakaginagamit na opsyon ay ang LibFuzzer, isang library na orihinal na binuo ng Google na direktang nagsasama sa C/C++ code at gumaganap pagkalito sa antas ng mga partikular na tungkulin, mainam para sa pagsubok ng mga indibidwal na bahagi na may mga lubos na kontroladong input.

Mayroon ding Peach Fuzzer, isang mas pangkalahatang layunin at maaaring i-configure na plataporma na nagbibigay-daan sa iyong tukuyin mga tumpak na modelo ng mga protocol, format ng file, at mga kumplikadong istrukturaIto ay napakapopular sa mga sektor kung saan mahalaga ang pagiging maaasahan, tulad ng mga sistemang pang-industriya o mga kapaligirang IoT.

Sa web domain, ang mga tool tulad ng OWASP ZAP ay may kasamang mga fuzzing module na nakatuon sa mga web application, na may kakayahang magpadala mga manipuladong kahilingan, mga maling porma ng karga, at mga pagsubok sa iniksyon Mga HTTP endpoint upang matukoy ang mga kahinaan tulad ng mga SQL injection, mga problema sa pagpapatunay ng input, o mga error sa pagproseso ng form.

Ang lahat ng ito ay nakakatulong sa AFL/AFL++ binary fuzzing, dahil pinapayagan nito ang saklaw mula sa mababang antas ng native code hanggang sa mga layer ng application na pinaka-nakakalantad sa end user. Ang karaniwang layunin sa lahat ng kaso ay pareho: ang i-automate ang paghahanap ng mga kahinaan bago pa man gawin ito ng mga umaatake.

Paano isama ang fuzz testing sa development cycle

Para patuloy na makapaghatid ng tunay na halaga ang fuzzing, hindi sapat na paminsan-minsan lang ilunsad ang AFL o AFL++ at kalimutan na lang ito. Mas epektibo ito. pagsasama ng fuzz testing sa lifecycle ng pagbuo ng software, sa katulad na paraan ng kung paano ito ginagawa sa mga unit o integration test.

Ang unang hakbang ay upang tukuyin kung aling mga bahagi ng sistema ang pinakamahalagaMga file parser, network module, mga component na nagpoproseso ng data ng user, o mga serbisyong nakalantad sa labas. Maaaring idisenyo ang mga partikular na fuzzing campaign batay sa mga target na ito, gamit ang maingat na napiling mga test case.

Susunod, kailangan mong pumili ng tamang tool para sa bawat kaso. Para sa mga kumplikadong native binary, ang AFL++ o LibFuzzer ay karaniwang natural na mga kandidato, habang para sa mga web API o HTTP application, mas makatuwiran ang isang web-oriented tool. Ang mahalaga ay ang wastong pagpapatupad ng fuzzing. mauulit at awtomatiko.

Ang integrasyon sa mga sistema ng CI/CD ay lubhang kapaki-pakinabang: maaaring i-configure ang pipeline upang, sa ilang mga sangay o bago ang ilang mga deployment, isang fuzzing battery ang ilunsad sa limitadong oras, na nagse-save ng anumang mga bagong pag-crash na natagpuan at nagpapabagsak sa build kung sakaling lumitaw ang mga potensyal na malubhang kahinaan.

Panghuli, mahalagang maunawaan na ang fuzzing ay isang paulit-ulit na proseso. Sa bawat oras na naayos ang isang bug, dapat muling i-fuzz ang apektadong bahagi upang mapatunayan na gumagana ang patch at walang mga bagong bug na naipakilala. walang mga bagong regresyon o kahinaanSa ganitong paraan, ang fuzz testing ay nagiging isang karagdagang patong ng patuloy na proteksyon at hindi isang nakahiwalay na pag-audit.

Kung pagsasama-samahin, ipinapakita ng lahat ng nabanggit kung paano tayo pinapayagan ng AFL, AFL++, at fuzz testing sa pangkalahatan na lumipat mula sa isang diskarte sa seguridad na nakabatay lamang sa mga manu-manong pagsusuri patungo sa isang mas komprehensibong diskarte. mas awtomatiko at mas masinsinanKaya nitong tuklasin ang mga error na kung hindi man ay mananatiling nakatago. Ang paggamit ng mga totoong kaso, tulad ng mga kahinaan sa underflow sa malawakang ginagamit na mga decompressor, ay nakakatulong din upang maunawaan na hindi lamang ito teorya, kundi mga problemang sinasamantala na. Samakatuwid, ang pagpapanatiling updated at regular na pag-aayos ng software ay maaaring magdulot ng pagkakaiba sa pagitan ng isang nakompromisong sistema at isang matatag na sistema.