Az élet kódjai

Közeleg a Húsvét. A hallgatók már a vonatjegyeket foglalják a hazaútra, az egyetemi dolgozók a szabadságukkal toldják meg hosszú hétvégét, hogy minél több időt szentelhessenek családjuknak. Mindenki a csokinyulak, sonkák és festett tojások megemelkedett fogyasztására készül. Én meg a Revision-t várom már nagyon. Lankad a figyelem, az emberek gondolatai máshol járnak.

Kik nem pihennek ilyenkor? Természetesen a jelszólopók. Egy ügyes húzással a Húsvét előtti napokra ütemezték az adathalász támadást. Nem akarok hazudni: én is majdnem bedőltem nekik.

A levél szerint le fog járni a jelszavam, de a levélben foglalt link segítségével megtarthatom a régi jelszavamat. Ilyen leveleket tényleg szokott kiküldeni az IT, de ők új jelszót szoktak kérni, nem engedik a régi megtartását! Viszont őszintén megmondom, nem volt kedvem pont ezen a napon jelszót változtatni, egy csomó munkát akartam letudni a tavaszi szünet előtt, nem hiányzott még ez is. Félre is dobtam a levelet, hogy a határidős teendőkkel foglalkozzam.

Viszont nem hagyott nyugodni, hogy miért kell ez a cécó, hogy megtartsam a régi jelszavamat? Újra megnyitottam a levelet és jobban megnéztem. A válasz a kérdésemre a linkben rejlett, ami nem egyetemi domainre mutatott. Ahá, értem már! Utána már feltűnt a megszólítás hiánya, és az is, hogy a feladó egy teljesen másik egyetem munkatársa (ezt elsőre is láttam, csak ezen az egyetemen is alkalmazásban állok, ezért nem kapcsoltam).

A szerver, amire át akartak az adathalászok vinni, már érdekesebb volt. Egy kb. 12 éves brazíliai telemarketinggel kapcsolatos weboldal volt rajta, ahol valószínűleg egy fájlfeltöltési hibát használtak ki a támadók (a nevezetes uploaded_script.php). A könyvtár listázás nem volt kikapcsolva, ezért szépen látszott minden fájl és könyvtár a webszerveren. Legérdekesebb a cgi-bin könyvtár volt, 2013-as dátummal. Nem is tudom, mióta nem láttam cgi-bin könyvtára.

A támadók készítettek egy alkönyvtárat (bc), feltöltötték a saját kódjukat, kiküldték az adathalász leveleket, majd várták az áldozatokat. A létrehozás dátuma alapján aznap reggel töltötték fel a kódokat, amikor az email-t megkaptam. A felület három részből állt: Egy HTML-ből, ami az adott egyetem levelező rendszerének bejelentkező oldalát utánozta rendkívül részletesen.

Ez nem a korábban látott fércművek egyike. Volt még ezen kívül egy PHP kód, és egy szövegfájl (sayee.txt). Ez utóbbi tartalmazta a már ellopott email címeket és jelszavakat. Természetesen mindenféle titkosítás nélkül. A fájl formátuma a következő volt (a benne szereplő adatokat megváltoztattam):

--------------+ FT +--------------nUs3rn@m3: victim1@uni-versity.hunP@55: password123nIP: ---------------------------------------------------------nCity: Region: Country Name: Country Code: ---------------+ FT +--------------nUs3rn@m3: victim2@uni-versity.hunP@55: passwordnIP: ---------------------------------------------------------nCity: Region: Country Name: Country Code:

Nagyon furcsa fájlformátum. Én biztosan valami sokkal struktúráltabb formát választottam volna, hogy könnyebb legyen dolgozni vele. Ez az 'n' karakteres elválasztás nem túl hatékony. Mivel l337 kódot használt, biztos egy nagyon komoly hekker :-)

Viszont felfigyeltem arra, hogy van egy másik könyvtár is (dc), hasonló elnevezésű fájlokkal. Megnéztem az ottani statikus HTML-t, mire a Széchenyi egyetem levelezőrendszerének utánzata jelent meg. Nocsak, nocsak, egy egyetem már nem is elég? Arra számítottak a támadók, hogy a nyuszi két helyről is hoz jelszavakat?

Összeszedtem az információkat, majd írtam a két egyetem helpdesk-jére. Az én egyetemem gyorsan reagált, megköszönték a segítséget, és küldtek egy köremailt, hogy vigyázzanak ezzel a levéllel. A Széchenyiről eddig nem kaptam választ. Akárhogy is, napi jócselekedet kipipálva.

Emlékeztek még az tavalyi Assembly-re készített produkciónkra? Nem? Persze, hiszen nem release-eltük. De miért? Hol is kezdjem?

Amikor elkészült nagyjából a videó, megosztottam a MoonShine tagokkal, és megkérdeztem, kinek lenne kedve zenét készíteni hozzá. Alexmus önszántából, minden külső kényszerítéstől függetlenül jelentkezett. Pár nap alatt készített is egy igen ígéretes zenét, amivel a videó egyharmadát le is fedte. Ennek nagyon örültem, úgy éreztem, végre nem csak egyedül alkotok.

Utána két hónapig nem csinált semmit. Mivel a zene nagyon jó volt, úgy döntöttem, sokkal jobb, ha kihagyjuk az Assembly-t és majd a következő demópartyra elkészül. QBParty szemptemberben, Ultimate Meeting decemberben, és már vége is volt az évnek. A zene a videó 80%-t lefedte. Ebből adódóan a fenti partyk egyikére sem küldtem be.

Azután semmi hír. Kezdtem úgy érezni, a projekt teljesen lehalt. Január, február elrepült. Végül elfogyott a türelmem. Márciusban ultimátumot intéztem Alexmus felé. Nem kértem, hogy fejezze be, nem könyörögtem. Egyszerűen csak megírtam, hogy Revision-ön bemutatom. Pont. Úgy gondoltam, 80% zene elég jó, mástnem a végére rákeverem a zene elejét, és kész.

Őszintén szólva, nem hittem, hogy a zene elkészül. Azt hittem megint össze kell csapni az egészet, ahogy máskor is tettem. Grassnak panaszkodtam, elmeséltem neki milyen hányattatott sorsú is ez a produkció. Nevetve annyit mondott, használjak AI-t mert az megvan pár perc alatt. Ezt nem akartam. Nem azért, mert AI ellenség vagyok, hanem ha már Alexmus ennyi időt beleölt, jár neki, hogy a neve ott legyen a nagy képernyőn. Meg annyi bajom van az AI zenékkel, hogy számomra úgy tűnik, a zene lezárása nem megy még.

A másik ok, hogy a MoonShine-ban valahogy nincs közös munka. Mindenki csinálja a saját vackait, mint a közös pályázaton lévő akadémiai kutatócsoportok. Na jó, ez talán erős hasonlat volt. A MoonShine-ban legalább bemutatják egymásnak a saját cuccaikat, kutatócsoportok ilyenre nem veszik a fáradságot.

A legjobban egyébként az zavart, hogy Alexmus korábban a határidő előtt egy nappal küldte az update-et, amikor már nekem nem lett volna időm berakni a hangsávot, és időzíteni, ha szükség lenne rá. Mit csináljak, ha megint Revision előtt egy nappal odaadja a végleges zenét?

Márciusban történt valami. Elkészült a zene! És tök jó lett! Micsoda megkönnyebbülés volt! A zene tökéletesen passzolt, minden rendben volt vele. Pár helyen a hangerőt kell majd állítani, de egyébként minden rendben vele. Most már az én térfelemen pattog a labda, mert például a feliratokban még QBParty, meg 2024 szerepel.

Talán ez a projekt is ösztönzi a többi tagot, hogy jobban kooperáljanak. Talán egy igazi demócsapatot lehet faragni a MoonShine tagokból. Nem lesz könnyű, de valahol el kell indulni.

Először feltérképezzük a rendszert a jó öreg nmap-el:

nmap -p- -Pn $IP

Eredményül megkapjuk a 22-es SSH portot, a 80-as webet és a 3306-os porton a MySQL-t. Az adatbázishoz nem lehet csatlakozni, az SSH-hoz még nincs elég információnk, marad a web.

A webes felületen először egy logó jelenik meg, majd átirányít egy bejelentkező felületre. Először végigpróbáltam a könnyű jelszó kombinációkat, hátha szerencsém lesz, de nem volt. A hibaüzenetek semmitmondóak, a forráskódban nincs használható nyom.

Kipróbáltam néhány SQL injection-t, de egyik sem vezetett sikerre, sőt észrevettem, hogy a túl sok próbálkozás után a webes felület végtelen homokórázásba kezd, tehát van valami védelem a tömeges próbálkozással szemben. Ezt erősítette meg, hogy a gobuster rendre elhasalt, ha a könyvtárakat akartam feltérképezni.

Gyakorlatilag az összes általam ismert támadási felületet védték. Vagy mégsem? Feltűnt, hogy a weboldal forráskódja elég bonyolult, sok átirányítás és beállítási lehetőség van benne. Ez valami keretrendszer lesz! Hátha annak van valami hibája.

A keretrendszerek általában feltűntetik a nevüket és a verziószámukat a forráskódban, de ebben az esetben nem találtam semmi használható nyomot. Mi lenne, ha megnézném a logót?

A logót lementette, majd egy képkereséssel megkaptam, hogy ez a MagnusBilling nevű rendszer. Egy gyors keresés az exploitot között:

searchsploit magnus

Semmi. Gyors keresés a weben, mire a Rapid7 weboldalán találtam valamit. Hoppá, a Metasploitban van hozzá exploit. Innentől gyorsan haladtam, követve a leírást a linken. Nemsokára volt konzolom.

A sudo -l szerint a fail2ban-client programot tudjuk futtatni. Mi a fene az a fail2ban? Néhány keresés után kiderült, hogy ez egy olyan program, ami IP-ket tud kitiltani különböző szabályok szerint. Például ha túl sok kérés érkezik. Ezért nem tudtam sokat próbálgatni a weboldalt, és ezért nem ment a gobuster sem.

Találtam sok leírást arról, hogy hogyan lehet root jogokra szert tenni, ha tudjuk szerkeszteni a konfigurációs állományokat. Balszerencsémre én semmit nem tudtam szerkeszteni, csak a fail2ban-client programot futtatni.

A dokumentáció alapján úgy tűnik, mindent be lehet állítani a kliens programból is. Sajnos a legtöbb tutorial arról szólt, hogyan szerkesszük a konfigurációs fájlokat, vagy hogyan tudjuk megszüntetni egy IP tiltását.

Röviden a fail2ban definiált szabályokat, és akciókat, hogy mit kell csinálni, ha egy szabályt megsértenek, majd az akción belül parancsokat, ami a tényleges feladat végrehajtása. Tehát az egyik akciót kell átdefiniálnom, hogy futtasson egy root shellt, ha túl sokszor írok be hibás jelszót a webre. Egyszerűen hangzik.

A konfigurációs fájlban két nagyobb szabály volt. Az egyik a weboldal bejelentkezéseit figyeli, a másik az ssh-ról érkező kéréseket. Az ssh-nál viszont volt egy elírás, amiből arra következtetek, hogy abban az esetben nem tud lefutni az akció.

Ha átírtam az akciót, akkor futási hibát kaptam, ha túl sokszor próbáltam belépni. Tehát valamit felüldefiniáltam, de nem kaptam meg a várt root shell-t. Gondoltam, talán rossz akcióval próbálkoztam, mert lehet akciót definiálni arra is, hogy a bannolás előtt mit futtasson. A vége az lett, hogy teljesen elrontottam a fail2ban-t. Működésképtelenné vált.

Leállítottam a virtuális gépet, és pihentettem a dolgot. Közben elkeztem túrni a netet, hátha találok valamit, hogyan lehet a kliens programmal átírni az akciókat.

Végül ezt találtam. A megoldás nem az volt, hogy átdefiniálok egy akciót, hanem új akciót adok hozzá. Erre a lehetőségre nem gondoltam. Megcsináltam a lépéseket, és már root is voltam.

Eredetileg erről a publikációról nem akartam semmit írni, de sdani kommentje után úgy gondoltam, érdemes megmutatni, hogy nem csak élőhalott kutatások vannak Magyarországon, és én sem csak selejtes vizsgálatokban veszek részt. Szóval van még élet az akadémiai szférában. Egyszerűen csak arról van szó, hogy a kutatások hullámzó tendenciát mutatnak. Ahogy egy sportolónak is van rosszabb éve, úgy vannak rosszabb projektek.

Egy perfekcionista csoport megteheti, hogy a kevésbé ígéretes témákat eltemeti, mi nem vagyunk ilyen szerencsések. Ráadásul mi inkább csak támogatunk egy meglévő kutatást, ritkán vezetjük azt, ezért kisebb ráhatásunk van a folyamatokra.

Kérdezhetitek, akkor erről a cikkról miért nem akartam írni? Nos, mert nem sokat csináltam. Szokásos smCounter2 bűvészkedés volt. Eredetileg úgy éreztem, hogy nincs benne olyan tanúság, ami más posztokban meg nem jelent volna.

Most viszont úgy gondolom, hogy igenis van tanúság. Egyszerűen az, hogy annyira elmerülünk a problémákban, hogy ha nincsenek problémák, akkor azt letudjuk, és rögtön a következő probléma felé fordulunk. Igazából ilyenkor megállhatnánk egy pillanatra, és örülhetnénk annak, hogy minden rendben ment.

Esetleg büszkék lehetnénk rá, hogy elértünk valamit. Mert akármennyire is sulykolja az egyetemi vezetés, hogy minden publikációt össze kell gyűjteni egy Excel táblázatba és villogni vele, hogy 300 D1-es cikk született egy évben, azért tudatosítani kellene azt is, hogy emögött a szám mögött 300 plusz információ van, amiről eddig kevesebbet tudtunk.

Vegyük például ezt a cikket. Leukémiás gyerekek mintáit vizsgáltuk. A szomatikus mutációk nem mutatnak nagy meglepetést, NRAS, KRAS gének romlottak el elsődlegesen. Viszont sikerült kifejleszteni egy olyan diagnosztikai panelt, ami a DNS és RNS adatokat összevetve képes lehet segítséget nyújtani a beteg gyerekek kezeléséhez.

Nyilván ez még nem egy kész eljárás, de egy lépéssel közelebb vihet hozzá. Ennek is lehet örülni, nem csak egy kész, díjnyertes kutatásnak. A pici sikereket is meg kell becsülni.

Megjelent egy újabb publikációnk. Csoda, hogy megjelent. Nem is tudom szavakba önteni, mennyi minden hátráltatta az adatgyűjtést, a vizsgálatokat és a megjelenést, ezért csak egy videóval összegezném a szenvedést, amit átéltünk:

Az egész egy nyúlbetegséggel indult, amiből GWAS-t akartunk csinálni. Az első probléma az volt, hogy nem lehetett pontosan megmondani, melyik állat beteg, mert a tünetek átfedtek egy csomó más betegséggel. Néha a boncolás után derült ki, hogy másban pusztult el az állat, és nem a vizsgálni kívánt betegségben. A nyilvántartás hibás volt, mert a nyúlketrecnél dolgozók nem vették komolyan az állatok jelölését. Olyan is volt, hogy a genom elemzése közben vettem észre, hogy apu nyuszi inkább anyu nyuszi, csak elírták az Excel táblában.

Apropó Excel tábla. A sok adatot mind egyetlen Excelbe vitték fel, ami végül akkorára duzzadt, hogy a legtöbb laptop memóriájában el sem fért. Vagy betöltötte egy részét, és nem tudta rendesen elmenteni, aminek az lett a vége, hogy az adatok egy része eltűnt.

Gyűjtöttünk genomokat, metagenomoka, RNASeq-et, mindent. Majd kiderült, hogy egy részét nem publikálhatjuk, mert valami különleges nyúlfajtából származnak, és a genom közzétételéhez a tenyésztő nem adta áldását. Később egyre inkább az volt az érzésünk, hogy az ipari partnert nem is érdekli az eredmény, ők inkább a termékenységhez köthető vizsgálatokat részesítik előnybe. Az, hogy néhány nyúl megdöglik egy betegségben, az nem számít (persze a pályázatból származó pénzre nem mondtak neme, de miután megkapták, látványosan lecsökkent a segítség, amit nyújtottak).

Az idő csak telt, és lassan kiderült, hogy az összegyűjtött adatokból nem lehet statisztiai módszerekkel meghatározni, hogy milyen genetikai elváltozásokkal asszociál a betegség, mert nincs elég minta.

Közben személyes problémák is felléptek. A megbeszélések személyeskedő hangvételre váltottak, ami szintén nem tett jót a további kooperációnak. A csoportunkból is mentek el a projekten dolgozó emberek, így egyre inkább úgy tűnt, hogy a több évnyi munka mind megy a kukába.

Egyetlen halvány reménysugárnak az tűnt, hogy elfelejtjük az egész betegséget, és azokból a szekvencia adatokból, amelyeket megoszthatunk a tudományos közösséggel, populációgenetikát csinálunk. Mivel a mintagyűjtésnél ez nem volt cél, a különböző nyúl fajták eltérő számban voltak reprezentálva, amit a bírálók teljesen jogosan szóvá is tettek, ezért további fajtákat szórtunk ki a vizsgálatból.

Végül a kézirat döcögősen, de megjelent. A csoportot elhagyó kollégák egy csomót szenvedtek, hogy az új munkahely elvárásai mellett ezzel a kézirattal is haladjanak. Valahogy megoldották. Valahogy sikerült. A pezsgőbontás mégis elmaradt, inkább olyan érzésem van, mintha levethetném a vizes göncöt egy esőbe fulladt kirándulás után. Senkinek nem kívánok ilyen projektet.

Még az egyetem alatt az ökológia tanszéknek segítettem adatfeldolgozó programokat írni, amikor egyik alkalommal átnéztük a tanszék korábbi vezetőjének hátrahagyott vackait. A profról annyit kell tudni, hogy szeretett a kutatásaihoz eszközöket vásárolni, de végül ezeket soha nem használta fel. Bekerültek egy szobába, és többet rájuk sem nézett.

Az új tanszékvezető szerette volna a saját kutatásait hatékonyabbá tenni az eszközökkel. A kacatok között találtunk egy Psion Organiser 2 XP-t. Nagyon megtetszett a bumfordi kis szerkezet, és elhatároztuk, hogy a terepen a befogott állatok viselkedését fogjuk monitorozni vele.

Írtam rá egy kis programot, de végül egy-két próba után feladtuk a terveket, mert annyi paramétert kellett volna rögzíteni, hogy lehetetlen volt emlékezni az összes billentyű kombinációra, ezért visszatértek a spirálfüzethet.

A szerkezet mély nyomokat hagyott bennem. Napokig jártam-keltem a géppel, amíg fejlesztettem rá a programot, és mindig találtam valami ürügyet, hogy a gombokat nyomkodjam. Évekkel később szereztem egy saját példányt, egy LZ 64-t, és most újra elővettem, mert nagy terveim vannak vele.

Először is ez a példány már négy soros kijelzővel rendelkezik. A belső memóriája 64k méretű, ami elég impresszív egy '80-as évekből származó kézi kütyütől. Teljes billentyűzete van, áramforrásként meg egy 9V-os elem szolgál. Saját BASIC-szerű programozási nyelve van, a tetején meg egy 16 tüskés csatlakozó, amivel különböző perifériákat csatlakoztathatunk. Még a 2010-es években is láttam olyan boltot, ahol Psion volt a pénztárgép egy vonalkód olvasóval.

Azóta sok idő telt el. Általában megpróbálok a régi eszközöknek funkciót találni a mai világban, de a Psionnál kudarcot vallottam. Az egész eszöz karakter központú, a bépített billentyűzet használata lassú. Bár sok hasznosnak tűnő program van alapból is a gépen, ezek használatát nagyon megnehezíti, hogy gombokkal kell váltani közöttük. A négy soros, húsz karakter széles képernyő pedig nem kedvez a hosszabb szövegeknek. Ahogy a fenti példa is mutatta, sajnos a készülék legnagyobb ellenfele a papír alapú határidőnapló.

Azokat, akik még manapság is a gép bűvöletében élnek, nem érdekli a funkcionalitás. Néhány ember továbbra is támogatja a gépet, aminek hála sok dokumentáció és programok is elérhetőek hozzá.

Bár többen mondták, hogy az elveszett adatot meg lehet próbálni helyreállítani, az nagyon költséges, és nem hoz 100% sikert, kifizettek valami irdatlan mennyiségű pénzt egy holland cégnek, amelyik azt állította, hogy vissza tudják nyerni az adatokat.

A diszkeket kiszerelték és elpostázták a cégnek, akik vissza is küldték az adatokat néhány USB-s NTFS fájlrendszert tartalmazó adattárolón.

Azt gondolhatnánk, hogy innen már minden csupa napfény és zene, a bioinformatikusok örülhetnek, hogy megmenekültek a kis fájlok. Hehehe, akkor miről írnék bejegyzést?

Szóval az első probléma, hogy a szerveren nincs USB. A második, hogy én távolról menedzselem a rendszert, de ha helyileg ott is lennék, akkor sem léphetek be a szent szerverterembe.

Úgyhogy volt egy nagy megbeszélés, ahol ott volt az informatikai igazgató, a rendszer adminisztrátor, mindenki. Elkezdődött a diskurzus, de jobbnak láttam, ha nem szólok, mert mindjárt az elején olyan vita alakult ki, hogy egyáltalán a kérdéses RAID tömb az most storage, vagy tárhely. A vita végén látthatta az informatikai igazgató, hogy csupa kutyaütő veszi körül, ezért határozottan azt mondta, hogy ezt a problémát nekik kell megoldani, a többiek nem is asszisztálhatnak hozzá.

Gondoltam, most jó kezekben lesz minden. De az akadémiai szférában nagy luxus ez a fajta elbizakodottság.

Eltelt két hónap, és egyre sürgetőbb emaileket kaptam, hogy mikor lesz hozzáférhető az adat. Egy ideig ellenálltam, hogy megkérdezzem az illetékeseket, mert egyrészt USB-n kell visszamásolni terabájtokat, másrészt az informatikai titkárság csak három emberből áll. Rettenetesen le vannak terhelve. Egy idő után viszont kénytelen voltam megkérdezni, hogyan áll a projekt.

Kiderült: sehogy. Még el sem kezdték. Az email után újabb egy héttel kiosztották a feladatot egy külső cég emberének, akivel már dolgoztam együtt. Végül mi ketten (illetve többségében ő) visszamásoltuk az adatokat. Egyébként a folyamatos egyeztetések során hasznos tippeket kaptam, hogy miként lehetne a szervert kicsit tuningolni, mert kiderült, hogy néhány beállításom nem volt éppen a legoptimálisabb. Ezeket nagyon hasznosnak találtam, ez határozottan egy pozitív hozadéka volt az eseményeknek.

Akkor jöhet a pezsgő és a happy end? Nem, mert ez a gyarló világ. Elkezdtem felhaszálni néhány nagyobb FASTQ fájlt a visszaállított adatokból, és az elemző programok rendre elszálltak rajtuk. Olyan hibaüzeneteket kaptam, hogy a szekvencia hosszabb, mint a quality, vagy a szekvencia és a quality nem + jellel van elválasztva.

Rövid nézegetés után kiderült, hogy bár a fájlok neve és mérete pontos, a tartalmuk sok esetben csak nyomokban emlékeztet az eredetire. A fájl eleje még jó, majd egyszer csak bináris szutyokká válik az egész.

Visszagondoltam az elmúlt egy évre, elmerengtem az élet értelmén. Érdekes módon nem érzek dühöt, vagy haragot. Kárörvendést sem. Csak sóhajtottam egyet, és letöröltem mindent, ami használhatatlanná vált.

Ez egy nagyon megkavart CTF volt, sok csapdával és kerülő utakkal. Először a szokásos felderítést végeztem. Első lépésként csak egy gyors keresés, hogy legyen min gondolkodni, amíg a teljes keresés lefut.

nmap -Pn --top-ports 100 $IP
nmap -Pn -p- $IP

Mindkét keresés ugyan azt az eredményt adta.

21/tcp open ftp
22/tcp open ssh
53/tcp open domain
1337/tcp open waste
1883/tcp open mqtt

Mi a fene az a waste? Újabb keresés, hogy részletesebb képet kapjak.

nmap -Sv -A -p 21,22,53,1337,1883 $IP

Oké, a waste egy átverés, Apache fut rajta. Az FTP-be be lehet lépni anoním módon, de nem tartalmaz semmit. A verziószám alapján nincs ismert sebezhetősége. Az 53-as porton Bind fut. Próbálkoztam zone transferrel, de nem volt sikeres. A dig paranccsal játszottam, hátha jön valami információ, de nem kaptam semmi használhatót. Próbálgattam a mosquitto-t, de az is átverésnek tűnt. Marad a webszerver.

Először a könyvtárakat néztem át.

gobuster dir -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -u http://$IP:1337/

Két ígéretes könyvtárat kaptam: /admin és /phpmyadmin. Az admin oldalt felkeresve rögtön egy segítséget találtam: "Biztos, hogy jó admin-t nézel?". Rövid próbálgatás után biztos voltam, hogy rossz admint nézek :-) Tehát a phpmyadmin lesz a befutó. A verziószám szerint 4.9.5-ös verzió fut. Habár van egy SQL injection sebezhetőség ebben a verzióban, az a keresésnél használható, nem a bejelentkezésnél. Kézzel próbálgattam default jelszavakat, de egyik sem vezetett eredményre.

Elkezdtem mindent előről, de csak ugyan azokat a megoldási útvonalakat néztem meg sokadszor is. Elakadtam.

Kénytelen voltam megnézni egy leírást. A gobuster-t kellett volna máshogy futtatni. Egy nagyobb fájllal. Ez eszembe juthatott volna.

gobuster dir -u http://$IP:1337/ -w /usr/share/wordlists/dirb/big.txt

Így mindjárt meglett az /admin_101 könyvtár is. Ha BurpSuit-al megnézzük, mit ad vissza a szerver, láthatjuk, hogy a hibaüzenet mellett egy sql lekérdezés részletét is megkapjuk. Valószínűleg SQL Injection-t kell használni. A phpmyadmin-ból pedig tudjuk, hogy MySQL az adatbázis. Nézzük meg, milyen adatbázisok vannak:

sqlmap -r request.txt --level 5 --risk 3 --dbms mysql --dbs

Az egyik nagyon érdekes, mert expose a neve.

sqlmap -r request.txt --level 5 --risk 3 --dbms mysql -D expose --dump

A request.txt a BurpSuit segítségével elmentett fájl. Tartalmazza a POST paramétereket, cookie-kat, mindent. Az adatbázis tartalmaz két URL-t, egy hash-t, és az admin felhasználó jelszavát. A jelszóval nem megyünk semmire, mert az admin oldal csak statikus szöveget tartalmaz némi JavaScript-el megbolondítva.

A második URL-hez (/upload-cv00101011/index.php) nincs az adatbázisban hash, csak egy megjegyzés, hogy a z-vel kezdődő felhasználó nevével érhetjük el. Hmm, ezt majd később tudjuk használni. Az első URL tartalmaz egy MD5 hash-t, amit a hashes.com-on azonnal törhetünk. A jelszó beírása után egy limitált webshell-t kapunk. Szerencsére a HTML forrásállománya tartalmaz némi segítséget. Nevezetesen nézzük meg a file vagy read paramétereket. Rögtön kiderül, hogy fájlokat tudunk megnézni. Nézzük meg az /etc/passwd-t! Rögtön megvan a z-vel kezdődő felhasználó neve!

Mehetünk a második URL-hez. A felhasználói név beírása után egy képfeltöltéshez jutunk, ami PNG-t vag JPG-t tud feltölteni. Igen ám, de az ellenőrzés csak a böngészőben fut. Ez kikerülhető!

BurpSuit segítségével át kell írni a JavaScript-et, hogy mindig fogadja el a feltöltést, kiterjesztéstől függetlenül, majd feltöltöttem egy php reverz shellt. A HTML-be rejtett módon ott van, hol találjuk a feltöltött fájlokat. Indítsuk el a reverz shellt, és máris limitált módon ugyan, de hozzáférünk a géphez.

A z betűs felhasználó könyvtárában csak egyetlen fájlt tudunk elolvasni, ami a beszédes ssh_creds.txt nevet viseli. Nem is kell többet bajlódni a revers shell-el, mert be tudunk lépni ssh-val. Azért ez mégis csak kényelmesebb, ráadásul el tudjuk olvasni a felhasználó flag.txt-jét.

Sajnos a felhasználó nem tud sudo-zni, crontab nem tartalmaz extra bejegyzést. Viszont a nano suid bit be van állítva. Ezzel meg lehet nyitni a /root/root.txt-t. Győzelem!

Az interneten fellelhető adatok egy része könnyen letölthető. Ezek HTML-be vannak ágyazva, esetleg már eleve valami könnyen emészthető fájlként ülnek a szerveren és egy link mutat rájuk. Ebben az esetben a wget vagy curl segítségével simán megszerezhetjük a nekünk kellő információt. Csakhogy egyes tartalmakat a tulajdonosai nem szeretik, ha letöltik. Ilyenkor különböző trükköket vetnek be, hogy a wget kuradcot valljon.

Jó kérdés, hogy amihez jogom van, hogy megnézzem, letölthetem-e? Mert mi van, ha csak ideiglenes hozzáférésem van az adathoz? Akkor ha letöltöm, akkor is tudom nézni, ha már lejárt a hozzáférésem, nem igaz? Az érem másik oldala, hogy nincs mindig net. Milyen jó lenne, ha valamit offline is nézhetnék, amikor jogom van hozzá. Aztán ha lejárt a láthatási idő, szépen becsülettel letörölném, mert én olyan vagyok.

Ezért amit most leírok, azt mindenki becsülettel használja, és ne warezolásra. Ahogy mondani szokás, amit leírok, azt csak "edukációs céllal teszem". Sőt, ahol tudom, azt is leírom, hogyan lehet megvédeni az adatokat.

Az első védelmi vonal, hogy különböző cookie-kkal ellenőrzik, hogy a felhasználó jogosult-e a tartalom letöltésére (például bejelentkezett-e). Habár a wget-nek is beállíthatunk cookie-kat, azok beállítása körülményes. Szerencsére a böngészők segítenek. Ha megvan a vágyott link, amit szeretnénk letölteni, de lusták vagyunk a cookie-kat beállítani, akkor a Developers módban a Network fülön az adott elemre ha jobb egégombbal kattintunk, akkor van egy "copy as cURL" (Windows-osoknak copy as Powershell), és kimásolja nekünk az egész linket parancssorral együtt. Az élet szép.

A második védelmi vonal, hogy igyekeznek elrejteni az adatot. Az adatok csak ritkán vannak szépen HTML tag-ek közé téve. A legtöbbször JavaScripttel vannak megbolondítva, vagyis a JavaScript módosítja a DOM-ot. Ha csak ész nélkül letöltjük az oldalt, kapunk egy obfuszkált kódot, de adatot nem.

Itt is a böngésző Developers módjának a segítségére vagyunk utalva. Az Inspector fülön láthatjuk a HTML melyik része felelős az adott struktúra megjelenítéséért. Szépen odanavigálunk, ami nekünk kell, jobb egérgomb, és a menüből a Screenshot node-al képként elmenthetjük a weboldal azon, és csak azon részét. Reklámok és idegesítő bannerek nélkül csak a lényeget kapjuk.

Ez ellen úgy lehet védekezni, hogy a tartalmat több darabra vágjuk, és a felhasználó interakciójától függően mindig csak egy részét mutatjuk. A manuális munka dögunalom, az emberek el fogják unni a developers-ben a munkát és feladják.

Az eddig bemutatott módszerek nem működnek például videomegosztó oldalakon. Ott előszeretettel használnak iframe-et is a JavaScript mellett. Egyrészt a videó beágyazható a segítségével más oldalra, másrészt nehezebb letölteni. De a Develper Tools még ebben az esetben is segítségünkre lehet. A videó ugyanis több darabban van, folyamatosan kell töltögetni az egyes részleteket. Ezt kell kihasználni!

A Network fülön láthatjuk, milyen kommunikáció zajlik a böngésző és a szerver között. A videoadat pedig folyamatosan töltődik. Itt egy hibát lehet elkövetni: az egyes részeket megszámozzák, méghozzá az adatok sorrendjében. Ha az URL-ek egy logikus sorrend szerint következnek, akkor lehet rá írni egy for ciklust és wget-el máris letölthetjük az egészet. Például:

for i in `seq 0 200`
do
  wget https://server/34342-werwer-32r423/chunk_$i.mp4
done

Utána meg ffmpeg-el összefűzzük a darabokat.

Ezt úgy lehet megakadályozni, hogy minden egyes darab egyedi, a többi darab alapján megjósolhatatlan azonosítót kap. Nincs stabil URL, hanem minden egyes bejelentkezésnél egyedi URL-t generálnak szerver oldalon. A nagyobb tartalomszolgáltatók így is csinálják.

Úgy tűnik, a kézi módszer az egyetlen, amivel megszerezhetjük a JavaScript bástyákkal körbevett adatot? Semmi esély rá, hogy automatizáljuk a letöltést? Hiszen úgy tűnik, a böngésző az egyetlen platform, ami képes megjeleníteni a tartalmakat, miután iframe és JavaScript hegyeken kell átverekedni magunkat.

Igen, a böngésző az egyetlen, ami képes erre, ezért a böngészőt kell programozni. Azért nem kell megijedni, nincs szükség, hogy a semmiből írjunk egy új böngészőt. A Firefox és a Chrome is futtatható headless módban, ami annyit jelent, hogy nem klikkeléssel vezéreljük, hanem szkriptből.

Több módszer is van a böngészők vezérlésére, én most a Firefox/Selenium szimbiózist fogom bemutatni. A szkript és a böngésző közé kell egy driver, ami megteremti a kapcsolatot a két egység között. Linux alatt például a Gecko driver szükséges. Python oldalról pedig a Selenium modul. Ha minden megvan, kezdődhet a móka.

from selenium import webdriver
from selenium.webdriver.common.keys import Keys
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC
import time

driver = webdriver.Firefox()

Ennek hatására elindul a böngésző. Fontos tudni, hogy az AJAX-nak és az iframe-eknek idő kell, hogy betöltődjenek, ezért célszerű várakozási időt beépíteni. A legegyszerűbb az implicit várakozási idő beállítása.

driver.implicitly_wait(5)
driver.get("http://xxxxxx.com/")

Ha betöltődött az oldal, ki kell választani az elemet, amit szeretnénk letölteni. Ehhez a find_element metódust használhatjuk. Elemeket számtalan módon azonosíthatunk (név, osztály, tag alapján), a By osztály használatával.

div = driver.get_element(By.TAG_NAME, "div")
div2 = driver.get_element(By.ID, "first")

Ha megvan az elem, akkor kinyerhetjük az általa tárolt adatot a text metódussal. Ha végeztünk a feldolgozással, zárjuk le a kapcsolatot.

driver.close()

A Selenium sokkal többre is képes, mint amit itt bemutattam. Emulálhatunk benne klikkelést, vagy egyéb felhasználói tevékenységet, hogy teljesen elhitessük az oldallal, hogy nem programmal kommunikál. Ez ellen CAPTCHA-val lehet védekezni.

Annak idején, ha az ember meg akart tanulni hekkelni, különböző warez oldalakat, underground fórumokat, és hasonlókat bújt (vagy feltette a nagy kérdést a prog.hu-n). Manapság pedig egész ipar épül rá. Ha van elég pénzed, megtanulhatod azt, ami régen tiltott, de ingyenes volt. Érdekes, hogyan változik a világ.

Sok plusz munkát bevállaltam, amitől szert tettem egy kis mellékesre. Nem tudtam, mit kezdjek a hirtelen kapott pénzzel, ezért úgy döntöttem tudásba fektetem. Ezek egy részét hasznosnak találtam, mint például a TryHackMe előfizetést, de egy másikkal nagyon megjártam. Ez pedig a EC-Council Ethical Hacker kurzus/vizsga.

Azért esett a választásom erre a kurzusra, mert agyon van hype-olva, én meg bedőltem neki. Úton-útfélen az jött az arcomba, hogy emberek mennyire örülnek, hogy megcsinálták, milyen hasznos volt. Igen, kicsit drága, de megéri. Én meg bezabáltam az egész maszlagot, mint kacsa a nokedlit.

Hol is kezdjem? Először is, nem kicsit drága, hanem keservesen drága. Még a legolcsóbb opció is. Ha az ember nem figyel, könnyen egy milla fölé ugrik az ár. Mivel én elfoglalt vagyok, olyan opciót kerestem, ahol a magam idejét tudom beosztani és a saját tempómban haladhatok az anyaggal. Ez természetesen a legolcsóbb lehetőség is egyben. Hozzád vágják a tananyagot, majd a végén vizsgázhatsz. Ha már valami pluszt is akarsz, akkor az ár emelkedik, mint a fapados repülőjáratokon. Van például egy elit előfizetés is, ahol négyszer próbálkozhatsz a vizsgával. És persze van olyan opció is dupla áron, ahol öt nap alatt egy ember az egész anyagot előadja.

Mivel én már öreg vagyok, hogy reggel 9-től délután ötig egy padban üljek, ez számomra nem volt opció. Már egyetemen sem tudtam koncentrálni délután három után. (A mostani tanítványaim sem). Szóval ezt nem akartam.

A jelentkezés után az első meglepetés, hogy nincsenek fix árak. Először emailt kell váltani egy hölggyel, aki ajánlatokat ad. Hogy-hogynem az elit előfizetés éppen akkor pont annyiba került, mint az alap készlet. De ehhez az első levelem feladása előtt három nappal kellett volna jelentkeznem, mert az volt a határidő. Mikor ezt szóvátettem, a hölgy gond nélkül visszadátumozta, mint az akadémiai szférában a szerződés hosszabbítást.

Utána annak rendje és módja szerint elkezdtek jönni a spam-ek az email címemre, hogy más méregdrága tanfolyamokat is végezzek el, sőt kombiáljam őket. Kösz, nem.

A tananyag

Az ember azt gondolná, hogy ennyi pénzért valami jó kis tananyagot kapunk. Hát nem. Először is van videó tananyag. Ezt egy ember mondja a kamerába, ha pedig olyan részhez ér, amiről nem akar beszélni, akkor elmondja, hogy ő csak a lényeget emeli ki, a többit nézzük meg a könyvben.

Egyébként a fickó számomra teljesen hiteltelen. A bemutatkozásban felsorolt egy rakás bizonyítványt, szigorúan három-négy betűs rövidítésekben, hogy ne lehessen tudni, miről is van szó. Arról is beszél, hogy 12 éves kora óta szétszedi a számítógépeket, és a tanítás a mindene. Ennek ellenére néha azért nem mutatott meg programokat, mert nem tudott elindítani, mert rosszul volt konfigurálva a rendszere. Ha ez egy tanteremben, élőben fordul elő, azt mondom peches. Nekem is voltak olyan pillanataim, amikor beégtem a hallgatóság előtt. De ez egy videó! Már egy harmadosztályú Tik-Tokker is tudja, hogyan vegye fel újra a balul sikerült részt. Úgyhogy három epizód után beszüntettem a videók nézését, mert csak az idő megy vele, és a könyv elolvasásást úgysem úszom meg.

A könyv első látásra rémisztő, mert vagy háromezer oldal. Szerencsére elég szellős, sok kép van benne, és aki egy egyetemi szigorlatot túlélt, az meg tud vele bírkózni. A felépítése viszonylag jó. Először egy rövid fél, vagy egy oldalas összefoglaló van, majd utána részletesen is kifejtik a témát. Néha ez abból áll, hogy megismétlik a rövid összefoglalót, csak töltelékmondatokkal felpuffasztva, néha még magyaráznak is. A magyarázat mennyisége változó, néha nagyon szájbarágós, néha nagyon felületes. Nekem az az érzésem, hogy ha valaki ebből akarja megtanulni a hekkelést, az nem fog menni. Inkább arra jó, ha valakinek van egy átfogó ismerete, akkor a hézagokat ezzel a tananyaggal ki tudja tölteni.

Márpedig előzetes ismeretek nagyon kellenek, mert a könyv tele van hibákkal. Én érzésre azt mondanám, 10 oldalanként találtam egy hibát, pedig nem vagyok szakértő. Egy részük nyilvánvaló elgépelés. Kihagyják a szóközt a parancs és a paraméter között, elfelejtik kitenni a kötőjelet. Van, hogy rosszul írják a parancsot. De olyan szinten, hogy a mellé berakott képernyőfotón más van!

Ezek elég zavaróak, de a tárgyi tévedéseket nehezebb megbocsátani. Például volt a könyvben egy Google kereső kifejezés, amivel állítólag ki lehet listázni a jelszavakat. Gondoltam magamban, ez talán a 2000-es évek elején még működött, de manapság már biztosan nem. Azért kipróbáltam, mert biztosra akartam menni. Jelszót egyet sem kaptam, de találatnak feljöttek a könyv illegális kópiái! Ebből is látszik, hogy ez a hülyeség csak ebben a könyvben létezik, a valóságban nem.

Mintha a könyv készítőinek az lenne a célja, hogy duzzasszák az ismeretanyagot, ezért csak hozzátesznek, el nem vesznek belőle. A tananyagot, ha aktualizáljuk, az nem azt jelenti, hogy benne hagyjuk a Windows XP-t, meg a régi szép időket, hanem eltávolítjuk az irreleváns részeket és újakkal helyettesítjük. A könyv úgy tárgyalja a Flash és ActiveX vezérlők adta veszélyt, mintha még léteznének ezek az entitások. Még olyat is leírtak, hogy a szervert úgy védhetjük meg, ha nem telepítünk rájuk DivX kodeket.

Természetesen belekerült a tananyagba az AI is, mert hogyan lehetne "naprakész" valami, ha nem teszünk bele AI-t. De teljesen feleslegesen van benne, semmi kapcsolata a kibervédelemmel. Csak benen van, mert az trendi, és ezzel is lehet emelni az oldalszámot.

Külön van benne fejezet weboldalak töréséről, és külön webszolgáltatások töréséről. De a két fejezet szinte teljesen megegyezik. Nem is csoda, mert két szorosan kapcsolódó téma. Ezt miért nem lehetett egybe gyúrni? Háromszáz oldalt spóroltak volna.

Minden fejezet vége egy hosszú lista van weboldalakról, programokról, amelyek az adott fejezet támadásait lehet végrehajtani, vagy kivédeni. Egyet kiemelnek, amelyről van esetleg egy képernyőfotó, de a legtöbbnek csak a neve szerepel, hogy legyen mit memorizálni. És igen, van belőlük kérdés.

Azért fél év alatt sikerült elolvasnom, és utána két hónapot szántam az ismétlésre, ahol már csak az összefoglalókat néztem át. Az ember azt gondolná, hogy akkor mindent tud, amit a vizsgán kérdezhetnek. Nem. A vizsgán lehetnek olyan kérdések, amelyek nincsenek benne a könyvben! Bumm. Gondolom, ez amolyan "előzzük meg a pereskedést" című kitétel, de akkor is, nem növeli a bizalmat.

Ami viszont nagyon tetszett, és amit tényleg jól megcsináltak, az a labor, ahol ki lehet próbálni a különböző technikákat. Fejezettől függően 2-3 virtuális gép fut párhuzamosan és mutatnak programot mind Windows-ra, mind Linuxra. Néha olyan is volt, hogy Linuxról kellett támadni, és Windows-on nézni az eredményt. Ezt a részét nagyon hasznosnak éreztem. Azért itt is akadtak gondok, mert egyes weboldalak már nem úgy működtek, ahogy a gyakorlaton használni kellett volna. De ez nem meglepő, a web gyorsan változik.

A vizsga

A vizsga tesztkérdésekből áll. Nem tudom, mostanában hogyan megy a nyelvvizsga, de középiskolás koromban volt a "Rigó utcai" vizsga, ahol szintén volt teszt. Olyan pletykák is terjedtek az én időmben, hogy még az angol anyanyelvűek sem tudják 100%-ra megcsinálni, mert amit ott kérdeznek, annak kevés köze van a beszélt nyelvhez. Nos, pont ezt éreztem ennél a tesztnél is. Attól senki nem lesz hekker, hogy kitölt egy tesztet és fejből tudja az nmap Maimon szkennelés kapcsolóját.

Hány százaléktól fogadják el a tesztet? Ez is vicces, mert 60-80% van megadva, a "vizsga nehézségétől függően". Mi van? Ha én egy ilyen követelményrendszert támasztanék a hallgatóimmal szembe, akkor ők - teljesen jogosan - bepanaszolnának. Ki dönti el, hogy nehéz, vagy könnyű a vizsga?

Természetesen aki eléggé elbizonytalanodik magában, annak is van segítség. Plusz pénzért vizsga felkészítést is vállalnak, ahol valószínűleg újra elmondják az egész anyagot, és akkor már nagyon fogja tudni az egyszeri ember, mit kell válaszolni.

A vizsgára egyébként úgy kell jelentkezni, hogy kapunk egy kupon kódot. Kupont úgy kapunk, ha értékeljük a kurzust oktató személyt. Akkor is értékelni kell ezt a személyt, ha mi nem is vettünk részt kurzuson. Én is értékeltem egy kitalált embert, jól le is pontoztam. A kapott kuponnal online lehet vizsgázni, ahol egy ember a vizsga teljes ideje alatt a webkamerán kukkol, hogy nem csalok-e. Lehet teremben is vizsgázni. Magyarországon több oktatási központ is van, ahol elvégezhetjük a tesztet. Ehhez viszont nem jó a korábban kapott kupon. Ezért upgrade-elni kell a kupont. Igen, plusz pénzért. Ha később downgrade-elni akarom a kupont, mert meggondoltam maga, azt is meg lehet tenni, és az ingyenes. Vissza nem térítenek semmit.

Féltem, hogy esetleg nem lesz elég stabil az otthoni net, meg pont akkor jön a villanyóra leolvasó, úgyhogy inkább a termes vizsgázást választottam. Ehhez el kell küldeni emailen a kupont, hogy emailen visszaküldjenek egy másik kupont. Természetesen csak azután, hogy a webshopban megvettem az upgrade opciót. A kuponnal együtt küldtek egy 17 oldalas PDF-t is, hogyan tudom használni azt. Kínai webshopok nem tarolnák le a világot, ha ilyen nyakatekert módon lehetne csak vásárolni náluk.

Utána regisztrálhattam Pearson Vue-ra, ahol a PDF-t követve sikerült elakadnom. Ugyanis a vizsgára való jelentkezés után kérte a kupon kódot. Megadtam. Aztán kérte a promóciós kódot. A PDF szerint itt is kupon kódot kell megadni, de azt nem fogadta el. Végül rájöttem, hogy amit az email "Eligibility Code"-nak hívnak, a PDF-ben voucher kódnak jelölnek, azt kell megadni a promotion szövegmezőben. Egyértelmű, nem?

A termes vizsgánál ki kell tölteni egy csomó papírt, hogy nem viszek be telefont, órát, vizet, kaját, 1 cm-nél szélesebb hajtűt és lőfegyvert. Nem vicc, tényleg nem lehet vizet és lőfegyvert bevinni. Szerencsére a robbanóanyagra nincs korlátozás.

Utána egy gép elé ültettek és megkezdődött a négy órás vizsga. Habár a szabályok szerint nem hagyhattam volna el a termet, azért a gyakorlatban megengedték, hogy a mosdót meglátogassam, és vizet is vihettem be.

A legtöbb kérdés könnyű volt, de azért akadtak kemény diók is. Nekem például nehézséget okozott megjegyezni absztrakt folyamatok lépéseit, meg olyan eszközök nevét, amit soha nem használtam, azokban téveszthettem a legtöbbet.

Az összes kérdés megválaszolása után meg kiírta az ítéletet: Pass. Hazudnék, ha azt mondtanám, hogy nem örültem neki. A nap hátralévő részében csak vigyorogtam.

A vizsga után

De most, hogy megvan a vizsga, már hátra lehet dőlni nem? Nem. A papír csak három évre érvényes. Utána folyamatosan bizonyítani kell, hogy "napra kész" vagy. Sőt, 2024 novemberétől még éves díjat is fizetned kell, hogy megtarthasd a minősítést. Bizonyára azért találták ki, mert már senki nem akar jelentkezni erre a hülyeségre, de a pénz meg kellene.

Ha a nyelvvizsgás hasonlatnál maradunk, akkor ahogy a teszt sem bizonyítja, hogy beszéljük a nyelvet, úgy ez a vizsga sem jelenti azt, hogy belőlem hekker lett. Nem érzem magam annak, még akkor sem, ha fel tudom sorolni a különböző támadásfajtákat, amiket a könyv tartalmazott. Mert tudom, mi a neve, de nem tudom végrehajtani, mert arról nem mond semmit a könyv! Mintha lenne egy leírás az ételek csoportosításáról, kalóriatartalomról, csak éppen a receptek hiányoznának belőle. Szakács lesz ezek alapján bárki is?

Összességében én úgy látom, hogy nem éri meg. Rettenetesen drága, igazi ismeretet nem ad, és lehúzásra megy az egész. A TryHackMe sokkal jobb, mert mindenben az ellenkezője.

Gyakran ismételt kérdések

- Megéri elvégezni?
- Nem.

- Egy cuki kutyus fejéhez pisztolyt nyomnak. Azt mondják meghúzzák a ravaszt, ha nem jelentkezem a kurzusra.
- Vesszen a kutya.

- Egy nagyon fontos rokonom fejéhez nyomnak pisztolyt, úgy követelik, hogy jelentkezzem.
- Mond a rokonodnak, hogy nagyon szereted, és rendezz neki szép temetést. Nos, ebben az esetben megfontolandó a kurzus elvégzése.

Legutóbb azon voltam kiakadva, hogy már az adathalász levelek sem a régiek. Csupa primitív, hátulgombolós módszerrel van tele az egyetemi levelezésem. Nem tudom, van-e összefüggés a poszttal (remélem nincs), de most kaptam pár valamire való phising emailt. Nézzük is meg, mire képesek.

Serverless módszer

Első emailem már megjelenésében is más.

Először is, csak egy címzett van, én. Más emailek általában olyan címekre mennek, amit minden dolgozó megkap, tehát az informatikusok is, korábban megkezdhetik az ellenlépéseket. Ebben nem. A levélben van CSS, formázás. Igaz, árulkodó, hogy hiányzik a címzett neve, a megszólítás is az email cím, tehát nem személyre szabott. Természetesen egy linket is tartalmaz, és a dolgok itt kezdenek érdekesek lenni.

A link ugyanis nem egy szerverre mutat , hanem egy Google Firebase alkalmazásra. Nincs dedikált szerver, nincs IP cím. Az alkalmazás egy kódolt JavaScriptet ad vissza.

Szerencsére nem bonyolult a kódolás, ezért még én is boldogultam vele a KiberSzakács segítségével. Az eredmény egy nagyon szofisztikált kód. Szépen kommentelt, profi kódnak tűnik. Az eredményeket Telegram-ra küldi.

Annyira szofisztikált a kód, hogy megkockáztatom, nem a támadó írta, hanem valaki más. A támadó csupán a saját igényeire szabta. A kód jellegzetességeire keresve van is találat itt. A telegram token más, ami azt valószínűsíti, hogy mások is használják a kódbázist a saját céljaikra. A Firebase alapú phising pedig másoknak is eszébe jutott.

Önnek új hangüzenete van

Második játékosunk hangüzenet értesítésnek álcázva küldte el az adathalász levelet. Már a szolgáltatás is elég nevetségesnek tűnik így 2025-ben. Hangüzenetről email-t küldeni? Amikor minden app-ba van ágyazva és folyamatosan pittyeg, hogy ne maradjunk le róla? Mindegy. Életemben nem hallottam a szólgáltatásról, és nem jött meg a kedvem a használatához.

A link (hxxps[://]www[.]travelzoo[.]com/newsflash/gtt/106533631-2877830_619/?ru=hxxps[://]dswwindsor[.]uk/3AfBLNZQT7?S=user@universitymail.hu) egy oldalra mutat, ahol valószínűleg RFI (remote file inclusion) sérülékenységet használtak ki. A lényege, hogy ha a weboldal úgy épül fel, hogy elemeket vesz át más fájlokból, és be tudunk szúrni más szerverekről tartalmakat, akkor a weboldal kinézetét, működését meg tudjuk változtatni.

Kicsit ront az összképen, hogy a link tartalmazza az eredeti URL-t is, tehát nagyon nem sikerült elrejteni a nyomokat, de talán az egyetem IP alapú szűrésén ezért tudott átmenni.

Összességében elmondható, hogy azért akadnak komolyabb játékosok is.

Psszt! Nem követtek? Át kell, hogy kutassalak, nem vagy-e bedrótozva. Egy telefon? Össze kell törnöm ezzel a kővel, mert lenyomozhatnak vele! Oké, most már tiszta vagy. Illetve majdnem. Ezt tedd a fejedre. Igen, aluminium fóliából van, de így rejtve maradnak a gondolataink. Azt mondod túlzott biztonság? Ilyen nem létezik. Biztos megfeledkeztem még tucatnyi dologról. Például ott az a mókus, és minket néz. Bakker, még mindig bámul. Rágcsálja azt a magot, vagy mifenét, és minket néz! Oké, elfutott. Tudni akarod, miért találkozunk az erdő közepén? Ezt hoztam.

Próbálok minél messzebb kerülni a Gyíkemberektől, de nem megy. Néha kénytelen vagyok számítógépet és internetet használni. De megtaláltam a tökéletes megoldást. Mindjárt elmondom, mi az, csak már megint néz a mókus.

Szóval a megoldás, hogy nem használok számítógépet. Mármint nem használok saját számítógépet. A Tails Linux-al minden számítógép az én számítógépem. Legalábbis ha be tudom bootolni. Ez az operációs rendszer ugyanis egy USB tárolón van. Amikor számítógépet kell használnom, keresek egy gépet, bedugom a pendrive-ot, és elintézem, amit el kell, majd kikapcsolom. A nyomok nem hozzám, hanem a géphez vezetnek. Nem nagyszerű?

Be lehet állítani, hogy semmit ne tároljon az USB meghajtón. Hiába használom a gépeket, nem marad nyoma a pendrive-on. Ennek persze megvan a maga hátránya. Ha egy wifi hálózatot többször is használnék (amúgy ilyet nem csinálok), akkor újból be kellene írni a jelszót. Ha beállítjuk, hogy legyen állandó partíció, akkor tárolhatjuk rajta az információkat. Telepítésnél pontosan beállíthatjuk, mely programok menthetnek erre a partícióra és melyek nem. Mi van, ha elhagyom a pendrive-ot? Nos, ez a partíció titkosítva van alapból. De én fejben tárolok mindent. Az aluminium fóli pedig véd attól, hogy onnan bármit kiolvassanak. Igen, nagyon gyorsan mosok hajat, köszönöm, hogy megkérdezted.

Nem csak a partíció titkosított. Tails-en az internet forgalom Tor-on keresztül megy. Az internet szolgáltató nem fogja látni, mit nézel. Azt persze látni fogja, hogy Tor-t használok, de erre is van megoldás! Lehet konfigurálni Tor Bridge-et, amivel nem közvetlenül kapcsolódunk a Tor hálózathoz. Nekem természetesen ilyenem is van. Kettő is. Na jó, három, csak nem akartam a mókusok előtt mondani. Soha nem lehet tudni, kiknek adják tovább.

Akik mindig mozgásban vannak, azoknak nagy segítség egy ilyen rendszer. Mi a véleményed? Hogyan? Te egy Gyíkember vagy? És a mókusok? Ja, azok csak a figyelemelterelés volt!

Elkészült a kód első változata. Röviden menjünk végig rajta!

void setup() {
  pinMode(ECHO_PIN, INPUT);
  pinMode(TRIG_PIN, OUTPUT);
  pinMode(BUZZ_PIN, OUTPUT);
  motor.attach(SERVO_PIN);
  digitalWrite(TRIG_PIN, LOW);
  digitalWrite(BUZZ_PIN, LOW);
  Serial.begin(9600);
  motor.write(90); // set to middle position
  prevangleindex = 1;
  prefetch(); // waiting ~5 sec to leave the area
  initialize_distances(); // collecting initial distances
}

Inicializálom a pineket, hogy melyiken fogadom, illetve küldöm az adatokat. A motort középre állítom. A prefetch() csak egy időhúzó lépés, hogy az eszköz telepítése után legyen idő elhagyni a védendő területet. Ez idő alatt másodpercenként annyit csipog, amennyi másodperc eltelt a bekapcsolás után. Öt után elhalgat, a rendszer megkezdi a működését.

Az initialize_distances függyvényben ezután jobbra fordul a riasztó, 20-szor távolságot mér, majd kiszámolja a t-próba konfidencia intervallumait. A műveletet megismétli a középső és a bal oldalra való fordulás után. Ezt a függvényt collect_baseline-nak neveztem el, háromszor hívom meg az initialize_distances-en belül.

void collect_baseline(int orientation){
  float avg;
  float sd;
  collect_dists();
  avg = calc_avg();
  sd = calc_sd(avg);
  base[orientation].low = avg - T * (sd / sqrt(20.0));
  base[orientation].high = avg + T * (sd / sqrt(20.0));
}

A T a kritikus érték 19-es szabadsági fokra, mert 20 mintánk van, és 99.5% konfidencia intervallumra. (Először 95%-ra állítottam be, de az nem volt jó, később részletezem, miért.) Az érték a statisztikai könyvekben és a Wikipédián is megtalálható.

A kód loop része a következő:

void loop() {
  actualangleindex = random(3);
  smooth_step(angles[prevangleindex], angles[actualangleindex]);
  if(is_extreme_dist(actualangleindex) == true){
    tone(BUZZ_PIN, 300);
  } else {
    noTone(BUZZ_PIN);
  }
  prevangleindex = actualangleindex;
}

Választunk véletlenszerűen egy irányt, a motort szép lassan odaforgatjuk, végzünk újabb 20 mérést, majd egy t-próbával megnézzük, hogy eltér-e az átlag attól, amit a collect_baseline esetén rögzítettünk. (Beleesik-e a konfidencia intervallumba) Ha eltér, veszettül riasztunk. Ha nem tér el, kikapcsoljuk a hangot.

Nos, a próbák során elég gyatrán teljesít a riasztó. Bármit is csináltam, kb 2-3 perc működési idő után elkezdett folyamatosan sípolni. A hiba oka nagyon meglepett. A riasztó a motor folyamatos mozgásának hatására szép lassan vándorolni kezdett a sima felületű asztalon, ezért egy idő után úgy érzékelte, hogy minden megváltozott körülötte.

Ekkor kivettem a szervó mozgatását a kódból. A fals riasztások mégsem szűntek meg. Elkezdtem kiíratni milyen értékeket mér a szerkezet, illetve milyen átlagokat rögzített. A konfidencia intervallumok közelében jöttek a találatok. Igaz is, a 95% azt jelenti, hogy a mért értékek legfeljebb 95%-a ebbe a tartományba esik. De nem minden. Ekkor tértem át a 99,5%-ra. A fals találatok száma valóban lecsökkent, de nem szűnt meg!

A felület, amire a riasztót irányítottam, merőleges volt a szenzorra, és kb. 1,4 méterre volt. Valami ismeretlen okból viszont néha a húsz mérés átlaga 90 cm lett. Tehát hiába állt mozdulatlanuk a szerkezet, akkor is beriasztott. Több helyen is írták, hogy a levegő hőmérséklete befolyásolja a szenzor mérési pontosságát, illetve felléphet interferencia is. Jelen pillanatban egyikre sincs ötletem, hogyan küszöbölhetném ki.

Ha ez még nem lenne elég néha ki tudtam cselezni a készüléket. Az irányváltások között, amikor forgatja a motort, akkor nem rögzíti a távolságokat. Tehát ha ebben a pillanatban gyorsan átugrottam a riasztó előtt, akkor nem adott hangjelzést.

A fejlesztés következő lépése, hogy kipróbálom több mérési pont alkalmazását, illetve beiktatok még egy kis szünetet a mérések között, hátha csökken az interferencia. Valamint kellene némi csúszásgátló a riasztó talpa alá. Hihetetlen, hogy egy egyszerű projekt során mennyi probléma előjön!

Ez egy elég nehezen induló CTF volt. A leírás szerint John IoT eszközöket tesztel, amikor valami szokatlanra lesz figyelmes a hálózati kommunikációban. A nagy meglepetés akkor jött, amikor a szokásos nmap keresésekkel egyetlen nyitott portot sem találtam. Elég reménytelennek tűnt, hogy meg tudom oldani a feladatot, ha semmihez nem tudok kapcsolódni.

Akkor arra gondoltam, talán fordítva kellene megközelíteni a dolgot. Ahelyett, hogy agyba-főbe szkennelnék, ismeretlen szolgáltatások után kutatva, talán pont azokat a portokat kellene csak nézni, ahol IoT eszközök szoktak kommunikálni.

nmap -sV -Pn -T4 -p 1883,8883,5683,5684 $IP

Rögtön meg is találtam az 1883-as nyitott portot, ami a Mosquitto bróker dedikált portja. Erről azt kell tudni, hogy összegyűjti az összes eszköz üzeneteit. Minden eszköz egy úgynevezett topic-ot kap, amin keresztül az eszköz elküldi saját állapotát, illetve utasításokat küldhetünk. Két paranccsot kell ismerni: mosquitto_sub, illetve a mosquitto_pub. Először az összes topic üzenetét megnézzük:

mosquitto_sub -h $IP -t "#" -v

Ilyen üzeneteket fogunk kapni:

storage/thermostat {"id":16399166308056728698,"temperature":23.84387}
frontdeck/camera {"id":10197626378469785711,"yaxis":-52.378067,"xaxis":169.65857,"zoom":4.9340644,"movement":false}
kitchen/toaster {"id":11240011071394374848,"in_use":true,"temperature":145.64915,"toast_time":182}
patio/lights {"id":10737355647360197010,"color":"WHITE","status":"OFF"}
livingroom/speaker {"id":17707635654923183114,"gain":55}
storage/thermostat {"id":9129473732134212486,"temperature":23.747482}

Az első oszlop a topic, a második az üzenet maga. Mint látható, a termosztát, a kenyérpirító és a fények rendben működnek. Aztán kapunk valami ilyesmit:

yR3gPp0r8Y/AGlaMxmHJe/qV66JF5qmH/config eyJpZCI6ImNkZDFiMWMwLTFjNDAtNGIwZi04ZTIyLTYxYjM1NzU0OGI3ZCIsInJlZ2lzdGVyZWRfY29tbWFuZHMiOlsiSEVMUCIsIkNNRCIsIlNZUyJdLCJwdWJfdG9waWMiOiJVNHZ5cU5sUXRmLzB2b3ptYVp5TFQvMTVIOVRGNkNIZy9wdWIiLCJzdWJfdG9waWMiOiJYRDJyZlI5QmV6L0dxTXBSU0VvYmgvVHZMUWVoTWcwRS9zdWIifQ==

Ez már érdekes, kezdünk közelebb jutni a megoldáshoz. Base64 kódolású. Dekódolás után ezt kapjuk:

{"id":"cdd1b1c0-1c40-4b0f-8e22-61b357548b7d","registered_commands":["HELP","CMD","SYS"],"pub_topic":"U4vyqNlQtf/0vozmaZyLT/15H9TF6CHg/pub","sub_topic":"XD2rfR9Bez/GqMpRSEobh/TvLQehMg0E/sub"}

Két újabb topic. A név alapján az egyiken üzeneteket küldhetünk, a másikon üzeneteket fogadhatunk. Legalábbis ezt feltételeztem. Már csak azt kell kitalálni, hogy milyen formában, és hova kell elküldeni az üzenetete. Itt próba-szerencse alapon küldtem ki az üzeneteket és néztem, mit válaszol a rendszer. A sub_topic-ra kell küldeni és a választ a pub_topic-ba kapjuk. Pont ellentétesen, mint ahogy feltételeztem. Ezért csak azt a topic-ot figyeltem ezután, amelyikre a válaszok érkeztek:

mosquitto_sub -h $IP -t "U4vyqNlQtf/0vozmaZyLT/15H9TF6CHg/pub"

A leírás szerint mindent base64-el kell kódolni, ezért elbohóckodtam pár percet azzal, hogy pipe-oljam a mosquitto-t a base64-el, de a bufferelés miatt nem jártam sikerrel. Próbáltam az unbuffer-t is, de valami miatt azzal sem ment. Kénytelen voltam a cyberchef segítségét kérni. Kicsit kényelmetlen volt. Valószínűleg egy Python szkripttel meggyorsítható a folyamat, de sejtettem, hogy már közel a vége.

Először egy HELP kérést küldtem.

mosquitto_pub -h $IP -t XD2rfR9Bez/GqMpRSEobh/TvLQehMg0E/sub -m 'eyJpZCI6ImNkZDFiMWMwLTFjNDAtNGIwZi04ZTIyLTYxYjM1NzU0OGI3ZCIsICJjbWQiOiJIRUxQIiwgImFyZyI6IiJ9'

A válasz részletesen leírta a használandó szintaktikát. Utána már bármilyen shell parancsot tudunk küldeni. Kiírathatjuk a flag.txt tartalmát:

mosquitto_pub -h $IP -t XD2rfR9Bez/GqMpRSEobh/TvLQehMg0E/sub -m 'eyJpZCI6ImNkZDFiMWMwLTFjNDAtNGIwZi04ZTIyLTYxYjM1NzU0OGI3ZCIsICJjbWQiOiJDTUQiLCAiYXJnIjoiY2F0IGZsYWcudHh0In0='

Anya, aki talált egy augmented reality appot:
- Nézd, lefotóztam neked a Mikulást! Ott áll a szobádban.
Nyolc éves gyerek fél szemmel a képernyőre sandít:
- Anya, ez Photoshop!
- Milyen shop? Nem shop-oltam! Nem lehet ilyen képet venni.

Nagymama:
- Nézd, kaptál egy madaras ágyneműt!
- Mama, ez a SpongyaBob!
- Akkor nem madár, hanem egy sajt?

Nagymama telefonhívást kap:
- Fogtok kimenni a teraszra?
- Nem, miért?
- Oda fogom rejteni az ajándékokat.
Nagypapa közbeszól:
- Mama, a telefonod ki van hangosítva!

Anya és Apa a webshopról rendelt ajándékokat rendszerezi:
- Ezt rendeltük Anettnak?
- Nem rémlik.
- Nem is úgy néz ki, mint a képen.
- Nagyon más.
- Szerinted örülni fog, ha ezt kapja?
- Hát persze.

- Az ikerk közül ki kapja a gyöngyfűzőt, és ki a karkötő készítőt?
- Dobj fel egy pénzérmét.

Gyerekeket beterelik egy szobába egy felnőttel, hogy Jézuskának legyen ideje a fa alá pakolni:
Egy perc múlva:
Első gyerek: - Pisilnem kell.
- Várj egy picit.
Második gyerek: - Szomjas vagyok!
- Most nem lehet kimenni.
Harmadik gyerek: - Melegem van!
- Mindjárt kimehettek.
- De nagyon kell...szomjan halok...meggyulladok!
Megszólal az ajándékozást jelző csengő. A gyerekek kirohannak és a dobozokra vetik magukat.
- Nem akartok előbb egy kicsit inni, pisilni, hűsölni?

Gondoltam építek egy ultrahang szenzoros riasztót. A cél az volt, hogy minél nehezebben lehessen kicselezni, bárhova telepíthető legyen, könnyen lehessen szállítani, és a mérete kicsi legyen.

Így esett a választás az egyik műanyag ételdobozra, ami a sok mikrózás miatt már étel tárolására nem alkalmas. Kivágtam két lyukat rajta és beleragasztottam az ultrahang szenzort.

Rékötöttem egy AVRDuino-t, és elkezdtem tesztelni. A kód első verziója a neten is fellelhető tutorialokat utánozta. Arra voltam kíváncsi, mennyire hatékony a szenzor, ezért csak a távolság adatokat írattam ki a soros portra.

A tapasztalatok a következők voltak: 4m méter után semmit nem érzékel a szerkezet. Puha anyagoknál megnő a mért jel szórása. Ha a tárgy felszíne nem merőleges szenzorra, gyengébb jelet kapok, illetve a szórás itt is nagyobb lesz.

Az eredményeket összegezve arra jutottam, hogy a cuccnak a következő módon kell működnie: bekapcsolom, a szerkezet vár, hogy elhagyjam a védendő területet. Feltérképezi a teret, megjegyzi az alap távolságot. Aktiválja magát, és ha a mért távolság eltér attól, amit korábban érzékelt, akkor jelez.

Ezzel csak egy probléma van, könnyű kikerülni, ha mindig egy irányba néz. Azt találtam ki, hogy egy szervó motorral fogom forgatni a dobozt, mintha egy kacsalábon forgó palota lenne. Szerencsére a doboz henger alakú. Ez az ötlet nagyon megtetszett. A doboz teteje lehetne a talpa is egyben.

Először kifúrtam a doboz közepét, és oda rogzítettem a szervő motort. Az új design-al az volt a gond, hogy jól ki kellett egyensúlyozni. Az irányító szerepet játszó AVRDuino ezért a motor fölött volt. Találtam néhány távtartót, ami elég magas volt, hogy a motor fölé emelje a mikrokontrollert.

Szükség volt még egy kis hangszóróra, hogy jelezze a risztást, illetve azt is, mikortól aktiválja magát a rendszer.

A doboz tetejére kellett a szervó karját szerelni. Nem bíztam a ragasztókba, ezért egy vékony dróttal rögzítettem azt. Aggódtam, hogy esetleg nem tudok olyan apró lyukakat fúrni a doboz tetejébe, de az aggodalmam alaptalan volt. Egy vastagabb varrótű simán megtette, még melegíteni sem kellett.

Először egy próbapanelen kötöttem össze az egységeket, és írtam egy próbakódot. Ebben a verzióban csak akkor jelezett a riasztó, ha 1,5 méternél közelebb érzékelt valamit. A motor három pozícióba állítja be a dobozt: 45 fok, 90 fok, 135 fok. Azért, hogy még nehezebb legyen kicselezni, a pozíciók véletlenszerűen váltják egymást, így a forgás elég kiszámíthatatlan.

A tesztelés jó játék volt a lányommal, megpróbáltuk kicselezni a készüléket. Akinél jelzett, az veszített. Ő nyert, mert elfért azon a kis résen, ami a fal és szenzor mérési határa között volt.

A prototípus elég jól működött, ezért készítettem egy kis próbapanelt, amire ráforrasztottam az alkatrészeket. A forrasztás még mindig nem megy valami jól, mint az látható a képeken. Többször ellenőriztem is multiméterrel, nehogy az áram nemkívánt irányba menjen. Szerencsére minden rendben volt, a próbapanel jól vizsgázott. Még a tetejét is rá lehet tenni a könnyű szállítás végett.

Tapasztalatok a jelenlegi működés alapján: A szervó túl gyors, a forgási tengely túl kicsi, kellene valami, ami plusz támasztékot biztosít (hasonló megoldás kellene, mint ami a mikróhullámú sütő tányérja alatt is van). Meg kell oldani a tápellátást is. A hardveren viszont nem tervezek nagyobb változtatást. A következő részben a kódot fogom bemutatni.

Naponta tucatjával jönnek az egyetemi levelezőrendszerre az adathalász levelek. De olyan szinten primitív módszereket használnak, hogy az már fáj. (Néha arra gondolok valójában ezek az IT részleg felmérései, hogy milyen a felhasználók tudatossága.)

A legbénább módszer, amikor az adatokat egy közönséges gmail címre kérik. Még arra sem veszik a fáradságot, hogy egy honlapot összedobjanak. Bár az is lehet, hogy csak nem értenek hozzá.

Egy fokkal igényesebb, ha egy ingyenes tárhely szolgáltató felületén létrehoznak egy annyira primitív oldalt, hogy még képet, CSS-t, semmit nem raknak bele. Rövid szöveg, két beviteli mező, meg egy gomb, hogy elküldjék az adatokat. Most épp a glitch.me a menő, arra irányít át a legtöbb szemét. A form feldolgozását pedig a Formspark-ra bízzák. Ez egyrészt védettséget biztosít a támadónak, mert névtelen, de cserébe könnyű keresztbe tenni nekik.

Alapvetően nem szabad ismeretlen linkre kattintani, de aki szeretné kivenni a részét a védekezésből, és egy átlagos felhasználónál többet tud a számítógépekről, annak leírom, mit tehet.

Először is a linket kimásoljuk a levélből. Linux alatt wget-el letöltjük az oldalt, és megnézzük, mit tartalmaz. Ha csak sima HTML-ből áll, akkor rendben van, folytathatjuk a munkát, ha semmit nem értünk abból, amit látunk, akkor töröljük a levelet is, a letöltött weboldalt is. Nem éri meg a rizikót.

Sima HTML esetén könnyű kiszúrni, hova is küldi az adatot. Ez a Formspark esetén egy submit-form.com lesz, GET-es paraméterben pedig egy egyedi azonosító. Ez kell nekünk! Ez alapján tudunk riportot küldeni ide.

Ha véletlenül mégis böngészőből kattintottunk rá, és elküldtük az adatainkat, akkor sincs minden veszve. A form elküldése után is megjelenik egy report abuse link. Itt is jelenthetjük a dolgot, de akkor minden esetben meg kell változtatni a levelező rendszerben az emailt. Lehetőleg gyorsabban, minthogy a támadó tenné meg :-)

Miért nem akadályozza meg a Formspark, hogy elkészüljön egy ilyen oldal? Nos, ők próbálkoznak, feltételezem van egy tiltott szavak listája, ami ha szerepel a weboldalon, akkor nem engedik rá a nagyvilágra. Ha viszont megnézzük, hogyan épül fel a weboldal, akkor sehol nem szerepel például a "password" szó. Az input mező is "anyword" névvel van ellátva. Egyedül magyarul szerepel, ez pedig feltételezem nincs benne a tiltott szavak listájában. Ezért mikor jelentettem a dolgot, fel is hívtam rá a figyelmet.

Egyébként a támadó egyetemekre szakosodhatott, mert az email aláírásában a Semmelweis szerepelt, nem az én munkahelyem. Szóval a támadó még arra sem vette a fáradságot, hogy különböző egyetemeknek más szöveggel küldjön emailt.

A harmadik szint már egy fokkal jobb. Ők a türelmesek. Ők is primitív módszerekkel dolgoznak, de nem puffogtatják el a muníciójukat azonnal. Várnak a megfelelő alkalomra.

Egyszer például jött egy valódi email az IT részlegről, hogy nagy átállás lesz, kiesik az internet, nem lesz email egy ideig, stb. A karbantartás befejeződése után három különböző spam jött amiben arról írtak, hogy a rendszerfrissítés után nem sikerült visszaállítani az emailemet! Ami egy paradoxon, mert akkor hogy kaptam meg a spam-et? Ráadásul annak ellenére, hogy vannak nagy nyelvi modellek, a levelek mégsem tudtak rendesen magyarul.

Ami megrémített, az az időzítés pontossága volt. Ha még csak egy levélről lett volna szó, azt gondoltam volna, hogy szerencséjük volt az időzítéssel. De három? Legjobb esetben az IT tesztelt minket, felhasználókat, legrosszabb esetben pedig van egy belsős. Egy vakond...

Már csak egy kérdés van hátra: miért ilyen primitívek ezek az adathalász levelek? Hol vannak azok a levelek, ahol a rendőrség fejlécét használják, hogy minél élethűbb legyen a csalás? Hol vannak azok az ál-oldalak, ahol a bejegyzett URL csak egy karakterben tér el attól, amit utánoz?

Minél többet gondolkodok rajta, a válasz annál ijesztőbb. Egy Asimov novella arról elmélkedett, hogy a szuperhős megjelenése magával hozza a szupergonosz megjelenését is, mert csak ők képesek hatákonyan bűnözni. Ezt a logikát a mi esetünkre is átültethetjük. A támadók nyilván a legkevesebb energiát akarják beleölni egy támadásba. A legkevesebbet, amivel azért eredményt tudnak elérni. Ha nulla eredményt érnének el, akkor vagy nem próbálkoznának többször, vagy több energiát tennének bele. Ahogy a fenti példa is mutatja, nem tesznek bele több energiát. Vagyis ennyi munkával eredményt lehet elérni.

A másik lehetőség, hogy ennyi munkával nem lehet eredményt elérni, ezért feladják a próbálkozást, de mivel mindig újabb és újabb scriptkidek lépnek a helyükre, folyamatos a fenyegetettség.

A magyarul viccesen hangzó kockatérképet (cubemap) elsősorban tükröződő felületek elkészítésére lehet használni. Olyan, mintha egy 360 fokos kamerával fényképeznénk. A tér minden irányába készítünk egy felvételt, és mindegyik oldalról elmentjük a képet egy textúrába. A neten fellelhető statikus példák helyett most egy dinamikus módszert mutatok be. Github-on is van egy csomó program, de némelyik látható hibáktól hemzseg. Ezért is döntöttem ennek bejegyzésnek a megírásáról.

A módszer hasonlít a textúrába renderelésre, ezért először egy framebuffert hozunk létre.

glGenFramebuffers(1, &fbo);
glBindFramebuffer(GL_FRAMEBUFFER, fbo);

A második lépés már egy kicsit különbözik, ugyanis létre kell hozni egy textúrát, de típusnak cubemap-et kell beállítani.

glGenTextures(1, &cubemap);
glBindTexture(GL_TEXTURE_CUBE_MAP, cubemap);

Most már elhagyjuk a biztonságos zónát. Hat textúrát kell beállítanunk, mindegyik dimenziónak kettőt. Mindegyik textúrának ugyan olyan típusúnak kell lennie. Habár a textúrák tetszőleges méretűek lehetnek OpenGL-ben, a kockatérképnél ez nem igaz. Itt kötelező a négyzet alak. (Habár ez így logikusnak tűnik, én egy napot kerestem a hibát a kódomban, mire rájöttem, hogy a méret inicializálással szúrtam el.)

glTexImage2D(GL_TEXTURE_CUBE_MAP_POSITIVE_X, 0, GL_RGBA, size, size, 0, GL_RGBA, GL_UNSIGNED_INT, 0);
glTexImage2D(GL_TEXTURE_CUBE_MAP_NEGATIVE_X, 0, GL_RGBA, size, size, 0, GL_RGBA, GL_UNSIGNED_INT, 0);
glTexImage2D(GL_TEXTURE_CUBE_MAP_POSITIVE_Y, 0, GL_RGBA, size, size, 0, GL_RGBA, GL_UNSIGNED_INT, 0);
glTexImage2D(GL_TEXTURE_CUBE_MAP_NEGATIVE_Y, 0, GL_RGBA, size, size, 0, GL_RGBA, GL_UNSIGNED_INT, 0);
glTexImage2D(GL_TEXTURE_CUBE_MAP_POSITIVE_Z, 0, GL_RGBA, size, size, 0, GL_RGBA, GL_UNSIGNED_INT, 0);
glTexImage2D(GL_TEXTURE_CUBE_MAP_NEGATIVE_Z, 0, GL_RGBA, size, size, 0, GL_RGBA, GL_UNSIGNED_INT, 0);

Ez a sok repetitív kód kicsit lehangoló lehet, ezért elárulom, hogy a függvény első paramétere egymást követő egész számok, ezért ciklusba szervezhetőek. Most csak a szemléltetés miatt vannak így leírva.

Ahogy lenni szokott, jönnek a textúra paraméterei. Fontos megjegyezni, hogy nem szeretnénk, ha a kocka éleinél ne legyen ronda csík, akkor GL_CLAMP_TO_EDGE opciót érdemes bekapcsolni.

De ez még nem elég. Kell egy renderbuffer, és a legtöbb esetben egy mélységi puffer is, hogy a renderelés során a takarások szépen jelenjenek meg. Természetesen a mérete akkora kell, hogy legyen, mint a fenti textúráknak.

glGenRenderbuffers(1, &render);
glBindRenderbuffer(GL_RENDERBUFFER, render);
glRenderbufferStorage(GL_RENDERBUFFER, GL_DEPTH_COMPONENT, size, size);

A legvégén mindig érdemes ellenőrizni a framebufferünket a glCheckFramebufferStatus-al, majd a framebuffer és a textúra állapotát nullára állítani.

if(glCheckFramebufferStatus(GL_FRAMEBUFFER) != GL_FRAMEBUFFER_COMPLETE){
   printf("no framebuffer\n");
}
glBindFramebuffer(GL_FRAMEBUFFER, 0);
glBindTexture(GL_TEXTURE_CUBE_MAP, 0);

Amikor eljön a renderelés ideje, akkor a jelenetet hatszor kell előállítani és a kamerát a megfelelő irányba állítani, hogy a kép a kocka megfelelő oldalára kerüljön. Tegyük fel, hogy a jelenetünket a geometry() nevű függvényben foglaltuk össze, aminek egy 4x4-es kamera mátrix a paramétere. Nem szabad elfelejteni, hogy ennek a függvénynek tartalmaznia kell a glClear() függvényt is.

glBindFramebuffer(GL_FRAMEBUFFER, fbo);
glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_CUBE_MAP_POSITIVE_X, cubemap, 0);
camera.lookAt(pos, target1, up1);
geometry(camera);
glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_CUBE_MAP_NEGATIVE_X, cubemap, 0);
camera.lookAt(pos, target2, up2);
geometry(camera);
glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_CUBE_MAP_POSITIVE_Y, cubemap, 0);
camera.lookAt(pos, target3, up3);
geometry(camera);
glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_CUBE_MAP_NEGATIVE_Y, cubemap, 0);
camera.lookAt(pos, target4, up4);
geometry(camera);
glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_CUBE_MAP_POSITIVE_Z, cubemap, 0);
camera.lookAt(pos, target5, up5);
geometry(camera);
glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_CUBE_MAP_NEGATIVE_Z, cubemap, 0);
camera.lookAt(pos, target6, up6);
geometry(camera);

Az kamera "up" paramétere redundáns, nincs szükség 6 különböző értékre. Természetesen kreatív kódolással ezt is ciklusba lehet szervezni, amit az olvasóra bízok.

Ezután jön egy újabb renderelés, ahol felhasználjuk a generált kockatérképet. Először csatoljuk a textúrát, ahogy bármelyik 2D textúrával is tennénk. A loc változó a glGetUniformLocation visszatérési értéke.

glActiveTexture(GL_TEXTURE0);
glBindTexture(GL_TEXTURE_CUBE_MAP, cubemap);
glUniform1i(loc, 0);

A shaderen belül a következő módon hivatkozunk a cubemap-re:

uniform samplerCube image;

Ez esetben "image" a változó neve, de természetesen bármi lehet, a lényeg, a típus. A képet ezután a shaderben felhasználhatjuk.

Mivel összesen hét renderelést hajtunk végre, célszerű a cubemap fázisoknál egyszerűsítéseket végezni, hogy csökkentsük a felhasználni kívánt erőforrásokat. Például ha tükröződő felületeket akarunk készíteni (jellemzően egy játékban például az autóra), akkor az autót, ami a legnagyobb poligonszámú, nem rajzoljuk ki, csak a környezetet. A távolságot is kisebbre vehetjük. De ha az autós példánál maradunk, akkor "lefelé" nem muszáj renderelni, mert az alváz nem sok krómot tartalmaz :-). Minden az adott felhasználástól függ.

Elmentem az idei Experience-re. Több blokkban demókat vetítettek, a végén pedig egy mini compó is volt. Az első blokkban külföldi PC demókat és intrókat vetítettek. A legtöbb már ismerős volt számomra, de így is akadt olyan, ami valami miatt elkerülte a figyelmemet. Mivel győztes alkotásokról volt szó, ezért nem okozott gondot többedszer is megnézni őket.

A második blokkban magyar scenerek mutatták be, hogyan készítik produkcióikat. Tifeco 4k intrót épített fel. Jó volt látni, hogy egyszerű effektek kombinálásából milyen látványos eredményt lehet elérni. Nyaki eszköze egy CSG alapú modellező. A módszert használva jégkrémet készített, majd a paraméterek változtatásával elolvasztotta azt. Végül Jimmi mutatta be a Bitangot, ami a shader változókat grafikus csúszkaként jeleníti meg és lehetőség van animálni is ezeket a paramétereket. BoyC betegség miatt nem tudott megjelenni.

Rövid szünet után Visage mutatott négy C64 demót, majd Charlie négy másik platformra készített alkotást. Mivel a retro gépek esetén nem vagyok annyira napra kész, ezért a legtöbb entry az újdonság erejével hatott. A The Demo Coder pedig akár egy új mantrával is felé. Talán igazságtalanság a többi releas-el szemben, de ezt ide is belinkelem. Mert demó kóder vagyok.

Ezután jött a verseny. Kaszi és elnyűhetetlen Hilbert görgéi voltak az egyetlen oldskool indulók. Tomcat 512 byte intróval jelentkezett. Több elméletem is van, hogy miről is akart szólni, de egyikben sem vagyok biztos.

Feryx QBParty invitáció-szerűséget készített. Azért csak szerűség, mert azon kívül, hogy szeptemberben lesz, igazából semmilyen információt nem tudunk meg. A zene gyanúsan AI csengést mutatott, amit Feryx meg is erősített. Elmondása szerint macskák után takarított, amikor kipattant a demó ötlete a fejéből, és hatalmas megkönnyebbülést okozott neki, hogy a gusztustalan munka után elkészíthette demóját. Nos, tényleg könnyebben elfogadható alkotás volt, mint a tavalyi.

Kaptunk a Transistor core-tól egy saját engine fejlesztéséből is egy techdemót, aminek találóan a neve is Techdemo volt. Végezetül a parti győztes Netro egy jókedélyű, kicsit vicces felütéssel kezdte demóját, csak hogy a végére az öngyilkosság témáját hozza fel. Party utáni beszélgetés során tudtam meg, hoy a demót személyes tragédia inspirálta, és egyfajta válaszkeresésként született, hogy mi vezethet egy ilyen döntéshez. De akkor is mondtam, hogy racionális módon nem lehet megérteni egy irracionális döntést. Ettől függetlenül remek demó, mert túlmutat önmagán.

Az idei bioinformatikai konferencia számomra olyan volt, mint egy érettségi találkozó. A volt kollégáim 70%-a jelen volt. Külföldről, nyugdíjból jöttek el, hogy itt lehessenek. A másik jó dolog az volt, hogy többségében PhD hallgatók adtak elő, így nem éreztem azt, hogy haldoklik a bioinformatika. A szervezés a magyar konferenciáknál megszokott "batyús bál" mintát követte. Ismerve a Magyar Bioinformatikai Társaság éves bevételét, azt kell mondjam, hogy csoda, hogy volt kávé. Szóval a szervezők tényleg a maximumot hozták ki a lehetőségekből.

De a sok kesergés helyett lássuk inkább az előadásokat, amik tényleg nagyon színvonalasak és változatosak voltak. Az utóbbi évek konferenciáin az előadók, mintha mind ugyan azt csinálták volna. Mikor Covid volt, mindenki vírusokkal foglalkozott. Mikor berobbant az AlphaFold, mindenki azt szapulta, mert nem találja meg a rendezetlen fehérjéket. Tavaly pedig mindenki MI szakértő volt. Úgy tűnik végre nincs több divathullám és valódi problémákra lehetett koncentrálni. Az előadásokról további információ itt érhető el.

Gerber Dániel: Bioinformatikai alkalmazások és kihívások az archeogenomikában

Az archeogenomikában több ezer éves DNS mintákkal dolgoznak. Jellemző, hogy ezek a minták töredezettek és kémiailag módosultak. Elsősorban populációgenetikai vizsgálatok dominálnak. Mivel az adatok hiányosak, ezért imputálásra támaszkodnak.

Bálint Balázs: Annotált genomok szennyeződéseinek érzékeny kimutatása és eltávolítása a ContScout programmal

A feltöltött genomok nagy része szennyeződés, ami befolyásolja az elemzést. Az eddigi programok alapvetően adatbázisokat használnak, de a ContScout fehérje alapon működik. A tesztek alapján horizontális géntranszfer esetén rosszabb eredményt ad.

Ari Eszter: mulea - egy többféle ontológiát és empirikus FDR-t alkalmazó dúsulást vizsgáló R csomag

Ontológiai elemzéseknél a többszörös tesztkorrekció ellenére is sok fals eredmény van, mert az ismert statisztikai módszerek függetlennek tételezik fel a teszteket. Egy fa struktúrába rendezett ontológia elemei viszont nem függetlenek. A mulea empirikus FDR-t használ, új mintavételezést végez, ezért számításigényes a futtatása.

Hegedűs Dániel és Juhász Márk Hunor: Filogenetikai fák metszése

Filogenetikai elemzéseknél a fel nem ismert hibák hosszú ágakat eredményezhetnek a törzsfákban. Az utólagos metszéssel jó eredményeket kaphatunk. Az eddigi programok nem végeznek jó munkát, és nehezen használhatóak, a csoport ezért egy új programot fejlesztett, ami nagyjából kör alakúra vágja a fákat. Jelen pillanatban az outgroup-ot még nem kezeli jól.

Juhász Judit: Nukleotid szekvenciák kontextusának vizsgálata pángenom és assembly gráfokban valószínűség alapú módszerekkel

Egy gráf jobban leírja a genomot, mint egy fasta fájl. Keresni viszont nagyon nehéz benne. A csoport egy hash alapú módszert dolgozott ki, ami egy minimizer alapú algoritmussal keres. Sokkal gyorsabb, mint a most létező megoldások, de még nincs teljesen kész.

Krizsán Dániel: Génexpresszió előrejelzése Escherichia coli baktériumban genomikai nyelvmodellek segítségével

A prokBERT nyelvi modellt használták, amit korábban mutattak be. Most expressziós adatokkal finomhangolták, hogy előrejelezzék az egyes gének kifejeződését. Sajnos még elég kis korrelációt mutat valódi expressziós adatokkal.

Nagy Ádám: Agyhullámok és Mentális Zavarok: A Legkorábbi Jelek Feltárása

Skizotípia és bipolaritás agyi képének elkülönítésére akartak tanulóalgoritmust trenírozni. Egyetemistákat használtak, akiket kérdőívek alapján egyik vagy másik csoportba soroltak. Ezután EEG-t, szemmozgást és más jeleket rögzítettek, hogy biomarkereket azonosíthassanak és modell magyarázó metrikákat számoltak.

Pogány Domonkos: Metabolit-betegség asszociációk becslése hiperbolikus terekben

A hiperbolikus terek jellemzője, hogy sok párhuzamos egyenes mehet át egy ponton, a térfogat pedig exponenciálisan növekszik. Emiatt skálafüggetlen hálózatok beágyazására alkalmasak. A csoport MDA hálózatok sekély beágyazását végezték hiberbolikus térbe, mert itt kisebb dimenzió is elég a kapcsolatok leírására. Az előadás legérdekesebb része mégis az volt, mikor az előadó azon filozofált, hogy miért látjuk a metabolit hálózatokat skálafüggetlennek? Azért, mert ilyen a hálózatok jellege, vagy azért, mert a kutatók az eredményeiket már ismert metabolitokhoz kapcsolják?

Stippinger Marcell: Jellemzők terének szűrése utranagy dimenziójú többosztályos adatokon

A bonyolultnak tűnő cím abból a kutatásból eredt, hogy egy cég felkérésére az aláírások hitelességét akarták meghatározni, amit egy idősoros adatként kezeltek. A probléma ott kezdődött, hogy nem tudták, milyen jellemzők lehetnek fontosak, például egy tanítási algoritmusnak. Ezért a meglévő adatok alapján jellemzőket generáltak számítógéppel. A gond az, hogy egyes jellemzők nem triviális korrelációkat tartalmazhatnak, ami egy elemzésnél elkerülheti a kutató figyelmét. A generált adatokat megpróbálták szűrni, amihez véletlen erdőket használtak. Az eredmének jók lettek.

Zsichla Levente: Nyílt forráskódú vírusgenom-összeszerelő pipeline-ok összehasonlító elemzése

Azt vizsgálták, hogy az egyes genom összeszerelő pipeline-ok mennyire jók HIV vírus esetén. Az összeszerelés minőségét Sanger-szekvenálással, gold standard genomokkal és in silico szimulációkkal mérték. A Shiver és a Smalt Align volt a legjobb.

Csendes Gerold: Poszt-perturbációs génexpressziót prediktáló gépi tanulási modellek kiértékelése

Ha a gépi tanulásban jó értékeket kapunk, még nem jelenti azt, hogy biológiailag is hasznos, amit az algoritmus megtanult. Különböző torzító tényezők miatt félremehet a tanulási folyamat. A baseline-ok megléte ezért nagyon fontos. Az előadás végén mégis arról beszélt az előadó, hogy ha nem jó egy modell, még nem használhatatlan.

Weber Áron: Hogyan fedez fel egy sejtszimuláció új fehérjekomplexeket?

A fehérjekomplexek azonosításában több stratégia létezik. A struktúra alapú módszernél azt vizsgálják, hogy a fehérjék képesek-e összeállni. Hálózat alapú módszeren alapul az MCL és a huMAP. Végül van a Cytocast Digital Twin Cell, ami egy szimuláció alapú megközelítést használ. Az előadás ezt mutatta be. A program proteomikai méréseken alapul. A kötési információkból gráfot képez, ahol a Google PageRank algoritmusát használják, hogy megállapítsák, melyik él a fontos.

Bruncsis Bence: Új szimulációs keretrendszer multivalens fehérjék és membránfehérjék közötti kötődés vizsgálatára

Egyes fehérjék kapcsolódásánál nem két, hanem több tag is részt vesz. Az ilyen, multivalens fehérjék esetén nem működnek a két tagra kihegyezett módszerek, ezért új kötési kinetikát és differenciál egyenleteket kell használni, hogy sikeresen leírják ezeket a rendszereket.

Kálmán Zsófia: Kölcsönhatások elemzése a PSD-ben: a GKAP-LC8 példája

A posztszinaptikus denzitás (PSD) fontos az olyan idegrendszeri megbetegedésekben, mint amilyen az Alzheimer is. A legfontosabb PSD-k bináris kölcsönhatását vizsgálták. Ezek közül az egyik az GKAP-LC8. Ez egy hexamer kapcsolat 4:2 stöchiometriával. Flexibilis kapcsolatot jön létre közöttük, amiben az LC8 kötőrégió hossza konzervált. Habár a komplex tagjai Drosophilában is megtalálhatóak, ott nincs közöttük kötés.

Tóth Adrienn Gréta: Klinikai megfontolások az antimikrobiális rezisztenciapotenciálhoz

Az antimikrobiális rezisztencia egy égető probléma. Sajnos a klinikumban, amikor antibiotikum használata mellett döntenek, akkor egy táptalajon felnövesztett törzsek telepmorfológiáját veszik alapul, ahol az antibiotikum kiválasztásánál szubjektív tényezők is szerepet kapnak. Ezzel a módszerrel sok információ elveszik. A csoport egy szekvenáláson alapuló módszert javasol, ahol genotípus alapján, metagenomikai módszerekkel rezisztencia géneket azonosítanának, és ez lenne az antibiotikum kezelés alapja.

Nagy Sára: Metagenomikai bepillantás egy gabonamúmiába

Emberi múmiákról mindenki hallott. De gabonákat is eltettek az Egyiptomiak. Egy ilyen gabonából vettek DNS-t, és azt vizsgálták. Találtak ember, selyemlepke, búza, prokarióta, nyárfa DNS-t. Sok szennyeződés volt a mintában, mert például fekete nyár nagyon ritka Egyiptomban, a selyemlepkére pedig kiviteli tilalom volt ebben az időben. Az emberi DNS viszont szubszaharai, valószínű, hogy hisztorikus.

Stirling Tamás: Genomi monitoring és fágterápia összekapcsolása az antibiotikum-rezisztens kórokozók elleni küzdelemben

A fágterápia hasznos lehet az antibiotikumok kiváltására, hátrányuk, hogy szűk hatásspektrumúak és gyorsabban adaptálódnak ellene a baktériumok, mint az antibiotikum ellen. A csoport adatbázisokból, környezeti mintákból rengeteg fágszekvenciát gyűjtött és azt nézték, miként változik a fágok genomja. Azt találták, hogy a fágok helyben terjednek, 6 éves távban nem mozdulnak, ezért hatékonyak lehetnek baktériumok ellen. A vizsgálatok alapján négy fágból álló koktél hatákonyan veszi fel a küzdelmet.

Buza Krisztián: Továbbfejlesztett ROCKET algoritmus tónusos-klónusos epilepsziás rohamok felismerésére

Az epilepsziás rohamokat idősoros gyorsulásmérő adatok alapján szerették volna előre jelezni. A fejlesztés során dinamikus konvolúciót építettek az algoritmusba. Először 10 ezer random konvolúciós mátrixot használtak, amit kétféle pooling alapján összegeztek. Az így kapott 20 ezer feature készletet logisztikus regresszióval vagy ridge regresszióval vizsgálták. Azt találták, hogy a nearest neighbour klaszterezéssel kapták a legjobb adatokat. Az algoritmus itt található.

Szatmári Zita Eszter: A sport hatása a biológiai életkor változására

Hetvenöt 50 és 70 év közötti ember öregedési óráját vizsgálták egy hosszabb edzés időszak előtt és után. Vérből izolált markereket használtak, többféle öregedési órát is néztek. Egyes órák esetben voltak szignifikáns különbségek, más esetben nem. Az előadó szerint az öregedés lassult edzés hatására. Nők esetén nem láttak olyan sok szignifikáns eredményt, mint férfiak esetén.

Kerepesi Csaba: A legújabb öregedés órák és érdekes alkalmazásaik

Az előadás a csoport eddigi publikációinak bemutatása volt. Tömören ezek a következők voltak: Fénykép alapján is meg tudták saccolni, milyen sebességű a biológiai órája valakinek. A sportolók tovább élnek, az olimpikonok meg még tovább (bár itt a hallgatóságból megjegyezték, hogy csak az élő sportolókat/olimpikonokat vizsgálták, tehát nem lehet általánosan kijelenteni, hogy a versenysport mindenkinek jó). Az akadémikusok pedig hamarabb halnak. Akinek magas a testzsír százaléka, az szintén gyorsabban öregszik. A gyulladást indukáló baktériumok jelenléte is a hosszú élet ellen dolgozik. Végezetül az egyes szervek nem ugyan olyan mértékben öregednek.

Nagy Gergely: A makrofág promóterek összetételének vizsgálata

A transzkripciós faktorok határozzák meg a sejttípust, de van olyan transzkripciós faktor is, ami egy egész sejtvonalat meghatározhat. Az elérhető nyilvános adatokból egy aggregált cisztront hoztak létre, amin belül az ETS és bZIP családokat néztek. A promótereket kategóriákba helyezték, így volt csak proximális elemeket tartalmazó csoport, csak disztális elemeket gyűjtő csoport, végül egy vegyes. Ez utóbbi csoportba tartozó promóterekhez rendelhető gének mutatták a legmagasabb expressziót. A promóterek CG tartalma meghatározza a cisz szabályozó elemek állapotát.

A BSides után nem volt kétséges, hogy a Haktivity-re is elmegyek. Ez egy nagyobb szabású rendezvény volt, négy teremben folytak párhuzamosan a szemináriumok és workshop-ok. Egy külön teremben pedig valami hackerspace is volt.

A kiállítók között nem volt olyan, aki most érdekelt volna. Egyedül az ISACA-hoz mentem oda. Ők kurzusokat hirdettek, azt hittem lesz közöttük olyan, ami számomra érdekes lehet. Hamar kiderült viszont, hogy inkább vezetőket képeznek, nem technikai szakembereket. Például van auditor képzésük is, de mikor megkérdeztem, mit is csinál egy auditor napi szinten, csak annyit válaszoltak, hogy kérdezzem meg e-mailben. Túl sok hasznos információt nem kaptam, de elhoztam egy prospektust az aktuális piaci körképről. Rögtön találtam is benne egy hibás statisztikai elemzést :-).

Az előadások, amire beültem, elég gyengék voltak. Mármint nem a szinvonal, hanem az előadói képességek hiánya miatt. Például érdekelt volna az autó hackelés, de az előadó beszélt a Pythonról, Scratch-ről, egy kicsit a CAN Bus-ról, de hogy ezek hogyan kapcsolódnak, arra már nem jutott idő. A háromnegyed órás előadás során csak egy dián voltak autók! Gondoltam, majd a workshop-on, amit szintén tartott, majd ezekre a hiányosságokra fog fókuszálni. Ott újra levetítette az előadást. Ennél a lépésnél feladtam. Egyébként sem vittem laptopot, a gyakorlatot nem tudtam volna végigvinni, úgyhogy kimentem.

Apropó workshopok. Elméletileg csak úgy lehetett bemenni a workshopokra, ha előzetesen arra regisztráltak. De az többeknek (köztük nekem is) nem volt tiszta, mégis hol? Ott állt egy csomó tanácstalan ember, akiket érdekelt volna egy téma, csak nem tudták, mit tegyenek. Szerencsére az oktatók elég rugalmasak voltak, és nem néztek jelenléti ívet.

Meghallgattam még egy érdekes előadást, ahol a Spanyolország egyik városában a választások előtt utalványokat osztogattak. Ehhez gyorsan összedobtak egy weboldalt, ahol igényelni lehetett ezt. Sajnos a biztonságra már nem ügyeltek, ezért bárki nevében ki lehetett tölteni az űrlapot és le lehetett tölteni az utalványokat. Az előadó vért izzadt a hivatalos úttal, ahol jelentette a hibákat. Végül a rendszert nem javították, csak annyit tettek, hogy a kuponok beváltásához személyit is kértek. Csak azért írtam le ezt, hogy lássuk, máshol sem fenékig tejfel az élet.

Megnéztem a hackerspace-t is. Egy rakás zár, lakat volt szétdobálva, azokat lehetett nyitogatni. Elkezdtem próbálgatni őket, de egyiket sem tudtam kinyitni. Némelyik láthatóan sérült volt, egyes zárakat például kettéfűrészeltek, talán, hogy könnyebben lehessen kinyitni. Aztán választottam egy számzáras lakatot, ahol egy kis papíron még a kombináció is rajta volt. Azt sem tudtam kinyitni. Ekkora antitálentum vagyok.

Szakmailag jobb volt, mint a BSides, de számomra sokkal unalmasabb volt. Egyrészt a gyakorlatlan előadók miatt, másrészt az én készületlenségem miatt.

A CTF-eket VPN-en keresztül szoktam megoldani, de egyik napról a másikra történt valami, amitől TLS hibára hivatkozva nem jött létre a kapcsolat. Első körben kértem új tanúsítványt, de azzal sem ment. Mivel már régóta nem frissítettem a Kali Linuxomat, gondoltam hátha az a probléma, hogy az OpenVPN elvault. Ha már frissítünk, frissítsünk komolyan, ezért az egész disztribúciót update-eltem.

A frissítés után eltűnt a hátterem, az ablakok dekorációja, a panelre nem lehetett klikkelni. A grafikus felület használhatatlanná vált. A neten találtam egy leírást, hogy indítsam el a fvwm4 --replace-t, és minden jó lesz.

Megtettem. Megjelent a háttér, az ikonok, de nem volt panel. Jobb egérgombra megjelent valami menü, amivel egy terminált azért tudtam indítani. Egy másik megoldás az volt, hogy töröljem a .local-t, a .cache-t és a .config-ot és indítsam újra. Ezt is megtettem. Újraindítás után minden megjelent, ami kellett.

Hurrá! Örültem. Munka után kikapcsoltam a gépet, másnap pedig indítás után jött a meglepetés. Az ablak dekorációk megint eltűntek. Ismét töröltem a kérdéses könyvtárakat, újraindítás után megint volt minden. De a következő újraindítás után kezdhettem elölről a folyamatot.

Pár nap után kezdtem megelégelni a dolgot. Különösen, hogy az OpenVPN továbbra sem működött, de most legalább a grafikus felület is rendetlenkedett. Úgy döntöttem, itt az ideje fixálni.

Elsőre az jutott az eszembe, hogy áttérhetnék Gnome-ra az fvwm helyett. A apt install kali-desktop-gnome azt hittem segíteni fog, de képtelen volt települni, mert nem tudta installálni a qt5ct-t. Megvontam a vállam, és kiadtam a végzetes sudo apt install qt5ct parancsot.

Annak ellenére, hogy ez egy telepítési parancs volt, valami ismeretlen okból 6Gb adatot törölt a gépemről, mondván, hogy arra már nincs szükség. A programok között volt a Metasploit, a Jupyter Notebook, millió Python csomag, de még az OpenOffice is. Utána viszont települt a Gnome.

Csak nem indult el. Elég jól álltam: nem ment a VPN, nem működött a Gnome, az fvwm, és még az eszközök nagy része is eltűnt. Oké, a Gnome nem megoldás. Eltávolítottam, de a grafikus környezet beállításai között továbbra is a Gnome volt az alapértelmezett, ezért grafikus felület megint nem indult el.

Kimentem parancssorba, majd a sudo update-alternatives --config x-session-manager paranccsal beállítottam, hogy ne az eltávolított Gnome-ot akarja betölteni. Visszakaptam a hibás fvwm rendszeremet. Ebben az állapotban már ennek is örültem.

Hanem észrevettem egy másik anomáliát is. A YouTube videók akadozva mentek. Lehet, hogy nincs hardveres gyorsítás? Egyre inkább úgy tűnt, hogy a netes megoldások nem segítenek, ezért azt tettem, amit először is tennem kellett volna: túrni kezdtem a logokat.

Az első hasznos nyom az .xsession-errors fájlban volt. Csak egy apró figyelmeztetés formájában, hogy nem tudja betölteni a Mesa GLX drivert. Még csak nem is hiba volt, de arra gondoltam, egy driver hiánya azért elég komoly dolognak kellene lennie.

Elkezdtem listázni a Mesa csomagokat, amikor is feltűnt, hogy a libglapi-mesa csomagból nem a legfrissebb van fent. Az apt update ezt valami miatt nem frissítette. Feltettem a csomagot, és működött a grafikus felület. Megvoltak a dekorációk, a háttérkép és a panel is. Még újraindítás után is megmaradt.

Oké, visszakaptam a rendszeremet, de a TryHackMe VPN még mindig nem megy. A böngészős AttackBox működött, de azt nem szeretem. Összesen 4 EU-s szerverük van, úgyhogy elkezdtem minden szerverre kulcsot kérni. A harmadiknál már csatlakozni is tudtam. Működött minden. Csak a letörölt csomagokat kell pótolni...

A futásban már stabilan megy a 10km, úgyhogy elkezdett érdekelni, mégis mennyire vagyok jó. Ha az ember egyedül rója a köröket egy szántóföldön, egy órával, ami elcsalja a métereket, nem sok visszajelzése van, hogy mégis mire képes.

Úgyhogy jelentkeztem a Budapest Marathonra, ahol a sok táv között volt 10km-es is. Meg kellett adni egy szintidőt is, ami az eddigi méréseim alapján 1 óra 10 perc volt. Be is soroltak az utolsó turnusba, ahol a leglassabb futókat indítják. Ez kicsit letörte a lelkesedésemet, de egyuttal minden elvárást is kiölt belőlem. Azt is írták, hogy akit utólér egy busz, annak a verseny véget ér. Így már nem is versenynek nézett ki számomra az esemény, hanem egy menekülésnek. Menekülésnek a söprögető busz elől. Az edzések során ezért igyekeztem a gyorsaságot növelni, hogy nehogy a végén a buszon végződjön a kaland.

A rajtszámot egy nappal előbb vettem fel. Mint kiderült, kellett volna vinnem a visszaigazoló emailt is, amit én természetesen elmulasztottam. Jól le is szúrtak miatta, de azért néhány ellenőrző kérdés után megkaptam mindent, mert az összes részletre emlékeztem.

A rajtszámon egy RFID chip is volt, de a Flipper nem tudta olvasni, mert nem 125KHz-en működött.

Korán lefeküdtem aludni, hogy legyen elég energiám és mivel nem volt semmi veszteni valóm, jól is aludtam. Annyira jól, hogy elaludtam. Rögtön eszembe jutott egy régi filmparódia, ahol a főszereplő vadászpilóta felkel, kinéz az ablakon, majd megjegyzi: Lekéstem a bevetést!

Rohantam a vonatra, az átszállásokra. Persze a vonat is késett, ha nem is sokat. Húsz perccel a rajt előtt megérkezdtem. Mekkora tömeg volt! Mindenki futóiskolázott, bemelegített, én meg nem tudtam hol kell gatyát cserélni. Bementem az ELTE egyik épületébe, ahol a kiírás szerint lehetett öltözni. Az épületen belül nem volt semmi jelzés, hogy ott mégis merre kell menni. Járkáltak ott össze-vissza. Megkérdeztem egy embert, hol lehet átöltözni, aki a csarnok közepére mutatott, hogy ott.

A mosdók előtt kilóméteres sorok álltak. Szerencsére már jártam itt még TDK-s koromban, úgyhogy tudtam hol találok még WC-t, amit kevesen nem használtak. Már csak 10 perc volt rajtig. Rohantam, hogy még le tudjam rakni a ruhatárba a csomagomat, persze azt sem találtam. Szerencsére információ volt minden stratégiai fontosságú ponton. Természetesen az értékmegőrzőt is eltévesztettem, mert abból is több fajta volt, de a szervezők is látták, hogy közel a rajt, úgyhogy megkönyörültek rajtam és átvették a csomagot. Még bedobtam két szőlőcukrot, majd két perccel a rajt előtt beálltam a futók közé. Majd futás közben bemelegedek.

A turnusokat késleltetve indították, úgyhogy számomra a rajt után még legalább 10 percig nem történt semmi, csak araszoltunk a rajt felé. Aztán elindultunk. Akkor már láttam, hogy nem jó csoportban vagyok. Az első három kilóméter azzal telt, hogy kerülgettem az embereket. Megelőztem Szuper Máriót és Luigit, egy csigának öltözött nőt és céges futócsapatokat.

Amin meglepődtem, hogy mennyien szurkoltak vad idegen embereknek. Kijöttek és mást sem csináltak, csak buzdítottak minden futót. Volt, aki kolomppal, kereplővel segített. Egyes helyeken pedig zenekarok játszottak.

Három és fél kilóméternél jött az első frissítőállomás. Hamar rájöttem, hogy futás közben nem tudok inni, ha megállok, akkor meg időt veszítek. Végül is edzés közben sem szoktam inni, nagy meleg sem volt, ezért a többi frissítőt kihagytam. Legyen jó eredményünk.

Nagyjából az ötödik kilóméternél voltam a tempómnak megfelelő szakaszban. Addigra már lehagytam a turnus iramfutóit is. Ez már kényelmes volt, tudtam tartani a tempómat. Nem kellett kerülgetni az embereket, senkit nem tartottam fel. Viszont kezdett fogyni a levegőm is.

Másoknak nem voltak ilyen problémáik. Még arra is volt energiájuk, hogy szelfizzenek. Egy pár is futott, ahol a nő még kis hátizsákot is cipelt, amiből a fickó menet közben kis is vett valamit. Anyukák babakocsival futottak. Sőt, láttam egy háromgyerekes családot is, ahol az apa egy gyereket tolt, az anya meg az ikreket. (Miért mindig a nők futottak nagyobb teherrel?) Én meg majd megdöglöttem.

Az órám mindig fél kilóméterrel korábban jelzett, mint a táblák, ezért nem is adtam sokat az óra információira, csak az időt néztem. Úgy tűnt hat percen belül teszek meg egy kilómétert. Akkor lesz rekord!

Az utolsó kilómétert megnyomtam. Lihegtem, fújtattam, mint egy gőzgép. A mozgásom is kezdett szétesni, de akkor már nem érdekelt. Próbáltam hosszúakat lépni és amennyire lehet, egyenletesen lélegezni. A célt 1 óra 5 perc után értem el, de az ugye az első turnus indulásától számított idő. Az időm végül 56:43 perc volt, ami király. Nem gondoltam volna, hogy egy órán belül leszek. Aztán már terelték is ki az embereket. Adtak egy kis reklámcsomagot, banánt, amit azonnal befaltam.

Kerestem egy viszonylag üres területet, majd lenyújtottam. Utána már a pulzusom is helyre állt. Kicsit még körbenéztem. Rengeteg kiállító volt, akik mindenféle futással kapcsolatos dolgot árultak, talpat mértek (szigorúan számítogéppel. Kíváncsi vagyok mikor lesz AI talpvizsgálat). Zsibvásári hangulat volt, amit hamar meguntam.

Az eredmény értékelése csak ez után következett. Először is meg kellett szerezni az adatokat. Ennek majd szentelek egy teljes bejegyzést, most csak legyen elég annyi, hogy JSON-ban az összes futó adata letölthető, ha az ember tud szkripteket írni.

A JSON adatokat összefűztem, CSV-be konvertáltam, majd beolvastam R-be. Az idő adatokat percbe konvertáltam, majd készítettem egy denzitás görbét, nőkre és férfiakra. A szaggatott vonallal bejelöltem a saját időeredményemet.

Anélkül, hogy komolyabb statisztikai elemzést végeznék, ránézésre azt mondhatjuk, hogy ez egy teljesen átlagos férfi eredmény.

Ez most egy kriptográfiai kihívás volt. Kriptográfiában nem vagyok jártas, de ezt a feladatot meg tudtam csinálni. Először kapunk egy forráskódot. Ez egy szerver, ami az egyik változójában tartalmaz egy flag-et (a forráskód nem tartalmazza az éles szerver flag-jét, azt majd nekünk kell kitalálni), előállít egy véletlen sztringet, XOR-al titkosítja a flag-et, majd kiírja a titkosított üzenetet.

Ezután megkérdezi, hogy mi volt a titkosítási kulcs. Ha eltaláljuk, kapunk egy második flag-et is. A szervert el is indíthatjuk, ami minden indításnál kiírja a titkosított üzenetet, majd kéri a kulcsot. Ha rosszat adunk meg, kilép.

Tehát első látásra lehetetlen a feladat, mert nem ismerjük sem a kulcsot, sem a nyers szöveget, csak a titkosított üzenetet. Nyers erővel sem törhetünk, mert csak egy lehetőségünk van, hogy a választ beírjuk. Kénytelenek leszünk gondolkodni.

Az XOR titkosításnak van egy érdekes tulajdonsága. Ha a titkosított szöveget ismét titkosítjuk ugyan azzal a kulccsal, akkor visszakapjuk a nyers szöveget. Ha viszont a titkosított szöveget az eredeti, nyers üzenettel titkosítjuk újra, akkor pedig a kulcsot kapjuk meg.

Milyen jó lenne ismerni az eredeti üzenetet! Igaz, az eredeti üzenetet nem ismerjük, de bizonyos tulajdonságairól van némi információnk. Például mindig "THM{"-el kezdődik. A forráskódból még az is tudjuk, hogy a kulcs 5 karakter hosszú.

Úgyhogy írtam egy programot, ami végigpróbálta milyen karakter állhat a "THM{" után. Titkosítottam vele a titkosított üzenetet, ezzel kaptam egy lehetséges kulcsot. A kulccsal ismét titkosítottam a titkosított üzenetet és reménykedtem, hogy felismerem majd, melyik lehet a jó megoldás (ugyanis a legtöbb flag nem random, hanem valami üzenet hacker stílusban). Íme a kód:

import string

def decode(hexinput, key):
   strinput = bytes.fromhex(hexinput).decode()
   xored = ""
   for i in range(0, len(strinput)):
      xored += chr(ord(strinput[i]) ^ ord(key[i%len(key)]))
   return xored

def doit():
   hex_encoded = input().strip()
   print("This XOR encoded text has flag 1: " + hex_encoded + "\n")

   for i in string.ascii_letters + string.digits:
      test = decode(hex_encoded, "THM{" + i)[0:5]
      out = decode(hex_encoded, test)
      if out[-1] == '}':
         print("Here is the result with the test", test, out)

doit()

Ahogy böngésztem az eredményeket, feltűnt valami. A jó megoldásnak az üzenet végét "}"-el kell lezárnia. Úgyhogy azt is beleírtam a programba, mint ellenőrzést. Elindítottam a szervert, ami kiírta a titkosított üzenetet. Azt kimásoltam, betettem a programomba, ami kiírta a kulcsot és az első flag-et. A kulcsot visszaírtam a szervernek, mire jutalmul megkaptam a második flag-et is.

Átnéztem, mások hogyan oldották meg, és akinek matematikus vénája van, az hamar rájött, hogy a titkos kulcs ötödik eleme mindig a záró kapcsos zárójelet fogja kódolni, mert a flag hossza 5 többszöröse. Tehát mindig csak egy jó megoldás lehet. Ez nekem nem esett le, de CTF-nek nagyon jó volt.

Kicsit megállt ez a sorozat, de nekem is fel kellett hoznom magam, hogy folytatni tudjam. A mostani részben megismerkedünk a számolással, elvégre a számítógép egy számító gép. (Pocsék poén achivement unlocked)

Kétféle módon számolhatunk. Az egyik módszerrel csak alapműveleteket végezhetünk egész számokon, a másikkal viszont a megnyílik előttünk a lebegőpontos számítás és a teljes matematikai függvénytár is. Jól hangzik nem? Kíváncsi vagyok, hogy a végére is ezt mondjátok-e.

Kezdjük az egyszerű módszerrel. Az egyszerű módszernél használhatjuk az általános célú regisztereket. Számolhatunk velük, de csak egész értékekkel dolgozhatunk. Összeadás:

mov ax, 3
add ax, 4

Az ax regiszterben az ax (3) és a 4 összege kerül, tehát hét. Olyan, mint a magasabb szintű programozási nyelvekben az x = x + 4. Szorzás:

mov bx, 4
mul bx

Az ax regisztert megszorozza egy másik regiszterrel. Közvetlen értékadás nem lehetséges, mint az add esetén. Az eredményt mindig ax-ben fogja tárolni. A div, ami az osztást végzi, kicsit másképp működik, ugyanis az eredménnyel két regisztert fog megtölteni. Az ax-t és a dx-t.  Az ax-be kerül a hányados, a dx-be a maradék. Emiatt van egy ökölszabály, hogy a dx regisztert az osztás előtt nullázzuk. Ha nem így teszünk, a programunk fagyni fog.

mov dx, 0
mov ax, 10
mov bx, 2
div bx

Még egy fontos dolgot kell megemlíteni az osztással kapcsolatban. Nem lehet neki közvetlenül értéket adni, mint az összeadásnál. Ezért használom a bx regisztert közvetítőnek.

Egyszerűen hangzik, nem? Nos, van néhány probléma. Először is, az eredmények nagyobbak lehetnek, mint ami a regiszterben elfér. Másodszor, a negatív számokat máshogy tárolják. Ezért külön utasítások vannak az előjeles számokra szorzás és osztás esetén. Ezek az imul és az idiv. Ezekkel most nem foglalkozom, de tudjatok róla, hogy ilyenek is vannak. Most csak az egyszerű esetekkel foglalkozom, aztán ha már lesz rutin, visszatérünk rájuk.

A hibakezeléssel sem foglalkozunk, mert az intrók nem nagyon kezelik a hibákat, mert azzal értékes helyet pazarolnak. Honnan tudjuk, hogy a művelet hibás? A processzor segít nekünk, ahogy tud. Fogja magát és újabb regisztereket fog beállítani. A következő részben csak debug lesz, ott visszatérek erre.

A bonyolult módszer a matematikai segédprocesszor, az FPU használatán alapul (ami csak régen volt külön processzor, most már egybe van építve a CPU-val, de hát a kompatibilitás miatt így maradt meg a köztudatban). Itt újabb regisztereket kapunk, amit ST-vel és egy számmal jelzünk. Tehát az első regiszter az ST0. Újabb regiszter kezelő utasításokat kell megismerni. Ezek a regisztereket nem érhetjük el szabadon, hanem egy verem szerű képződményen keresztül. Azért hívom verem-szerűnek, mert nem tud megtelni. Ha nyolcnál több értéket pakolsz bele, a régieket egyszerűen elfelejti. Bármilyen hibaüzenet nélkül. Jó, mi?

Hogyan tudunk adatokat másolni ezekbe a regiszterekbe? Csakis memóriából. De azért ne örüljetek annyira! Ezek a regiszterek 80 bitesek. A lefoglalt memórai tehát vagy kisebb, vagy nagyobb lesz, mint a regiszter, soha nem akkora. Ez majd jusson eszetekbe, ha nem értitek, miért változott meg a szám, amit az FPU-ba töltöttetek.

Először jelezzük a kódban, hogy mostantól FPU-t is akarunk használni:

finit

Most pedig másoljunk értékeket a regiszterekbe. Hiszen értékek nélkül nem tudunk számolni. Mivel eddig egész számokkal dolgoztunk, most is egész számokat fogunk használni.

fild [memóriacím]

Ezzel a memóriacímről az értéket az ST0 regiszterbe másoljuk. A kapcsos zárójel nélkül a memóriacímet másolja át, nem az ott tárolt értéket. Ha még egyszer kiadjuk a parancsot, akkor az ST0 értéke ST1-be kerül, az új érték meg ST0-ba. Újabb parancsok tovább tolják a régi értékeket a verem mélye felé.

Ha ki szeretnénk nyerni az értékeket, akkor azt a következő módon tehetitek meg:

fist [memóriacím]

Az ST0 érték a memóriacímre kerül, ST1 pedig ST0-ba. Ha az értékek az FPU regisztereiben vannak, akkor kezdődhet a számolás.

Összeadás fadd, szorzás fmul. Az eredmény szinte minden esetben az ST0-ba kerül, hasonlóan ahhoz, ahogy az ax-be helyezik az eredményt az egyszerű módszernél. Az alapműveletek mellett használhatjuk a szögfüggvényeket is. Ennek örömére készítettem egy egyszerű programot, ami egy kört rajzol, és rengeteg FPU műveletet érint.

Sokféle módon lehet kört rajzolni, ez a módszer végigmegy 0-tól 360 fokig az összes szögön, és mindegyik szöghöz kiszámít egy X és Y koordinátát. Ha elég kis lépéssel haladunk végig a szögeken, akkor folytonos lesz a kör. Ez nem a legoptimálisabb módszer, mert egy pontra többször is rajzol, de sok számítás kell hozzá, könnyen érthető és látványos az eredmény. Demonstrációs célra tökéletes.

org 100h
section .text
start:
       mov ax, 13h
       int 10h
       mov ax, 0A000h
       mov es, ax
       mov cx, 628
cyc:
       mov word [r], cx
       finit
       fild word [r]
       fmul dword [step]
       fsincos
       fmul dword [radius]
       fadd dword [centery]
       frndint
       fimul dword [width]
       fistp dword [y]
       fmul dword [radius]
       fadd dword [centerx]
       frndint
       fiadd dword [y]
       fistp word [y]

       mov di, [y]
       mov ax, 2
       mov [es:di], al

       loop cyc
waitsec:
       in al, 60h
       dec al
       jnz waitsec

       mov ax, 03h
       int 10h
       ret

section .data
       radius:  dd 70.0
       centerx: dd 160.0
       centery: dd 100.0
       step:    dd 0.01
       width:   dd 320
section .bss
       y: resd 1
       r: resw 1

Kezdjük a végén, mert új elemek vannak a programban. Mint említettem, az FPU-nak memóriacímek kellenek. Ezeket definiáljuk a section .data és section .bss részeknél. Előbbi statikus adat, nem módosíthatjuk. Definiáljuk a kör sugarát (70), a kör középpontját (160 és 100), egy lépésközt, valamint a képernyő szélességét (320). Meg kell adni a felhasználni kívánt memória méretét is. A dd a double word, vagyis 32 bit méretű. Ez a legegyszerűbb adattípus, amivel számokat cserélhetünk az FPU regisztereivel.

Ha módosítani is szeretnénk az adott memóriaterületet, akkor a section .bss-ben definiálhatunk változókat. Ebben a programban két változót fogunk használni, az y-t és az r-t. A dd helyett itt resd-vel adjuk meg a 32 bites típust. A resw egy word méretű memóriarész, tehát csak 16 bites. A legvégén a szám azt jelenti, mennyi elemet akarunk az adott adattípusból. Tehát ha egy tömbre lenne szükségünk, akkor ennek a tömbnek az elemeinek a számát adhatjuk meg- Az adattípusokról most elég ennyit megjegyezni, de tudjunk róla, ennél sokkal több van. Ami a lényeg jelen pillanatban, hogy d-vel definiáljuk, ami konstans, res-el ami változhat.

Oké, a program nagy része ismerős lehet. Ami új, az a finit-el kezdődik, és az utolsó fistp-vel végződik. Koncentráljunk erre a részre. Ahogy említettem, a finit inicializálja az FPU-t, innentől használhatjuk a szuper utasításokat.

fild word [r]

Az r változó értéke ezzel az ST0-ba kerül. A [r] az r változó memóriacíme, ebből még nem lehet tudni, hogy mekkora az adott változó. Ezért kell explicite megmondani a word kulcsszóval, hogy mennyi bájtot is akarunk beolvasni.

fmul dword [step]

Az ST0-t és a step értékét összeszorozzuk. Mivel ST0 az r változó, ezért az ST0 mostantól a r * step szorzat eredményét tartalmazza. A step változó már dupla szó, ezért dword-el jelezzük, hogy a számot nagyobb memóriáról kell beolvasni.

fsincos

Egy lépésben kiszámoljuk az ST0 szinusz és koszinusz értékét. Az ST0-ba kerül a szinusz, ST1-be a koszinusz kerül. Beteg mi? Szerencsére a kör pontjainak kiszámításához pont erre a két szögfüggvényre van szükségünk.

fmul dword [radius]

A ST0, vagyis a szinusz eredményt megszorozzuk a kör sugarával, tehát megkapjuk a kör adott szögéhez tartozó pont Y koordinátáját, ha a kör középpontja a 0 pontban lenne. De nem ott van, ezért szükség lesz a következő utasításra is:

fadd dword [centery]

Vagyis hozzáadjuk a kör középpontjának Y koordinátáját, ami szintén dupla szó (dword). Van egy lebegőpontos Y koordinátánk az ST0 regiszterben. Ezt képernyő pixelnek kell megfeleltetni. Bizonyára emlékszünk, hogy ebben a felbontásban, amiben dolgozunk, a pixelek folyamatosan mennek balról jobbra, ha a képernyő szélére érnek, ugranak egy sort. Ezért az Y * WIDTH + X képlettel kiszámoljuk, melyik pixelről van szó. A számításoknak még nincs vége!

Először is a lebegőpontos számokat egésszé konvertáljuk, mert a képernyő pozíció egész szám.

frndint

Az utasítás az ST0 regiszter tartalmát egész számmá konvertálja. Több módon is egésszé konvertálhatunk egy tizedestörtet, ez az utasítás a legközelebbi egész számra kerekít. Mivel az egész számokat máshogy tárolja a gép, ezért nekünk kell tisztába lenni, hogy milyen típusú adatokon hajtjuk végre a műveleteket, és a típusnak megfelelő üzenetet kell használni.

fimul dword [width]

A fimul a szorzás, de egész számokkal. Az Y koordinátánk már egész szám, ezért így szorozzuk.

fistp dword [y]

Az ST0 regiszter értékét az y változóba helyezzük. Az X koordináta eddig az ST1-ben volt, az most az ST0-ba kerül. Megismételhetjük az egész procedurát, hogy megkapjuk a másik koordinátát.

fmul dword [radius]
fadd dword [centerx]
frndint
fiadd dword [y]

Az utolsó lépésnél az X koordinátát, ami az ST0 regiszterben van, hozzáadjuk az Y * WIDTH részhez, amit korábban elhelyeztünk az Y változóban. Igen, itt kicsit félrevezető a változó neve, mert nem a tiszta Y koordinátát tartalmazza. Sőt, továbbmegyünk! Kimentjük az értéket az utolsó fistp utasítással az Y változóba, ami immár a pixel sorszámát tartalmazza a memóriában. De 256 byte intróknál spórolni kell a változókkal, mert sok helyet foglalnak.

Aki idáig eljutott, és begépelte, lefordította a programot, csalódni fog. Teljes kör helyett csak egy félkört fog rajzolni! A program hibát tartalmaz. A következő részben sajnos uncsi memória méretekkel és még uncsibb debuggolással fogunk megismerkedni. Megtaláljuk a hibát, és kijavítjuk.