PNG autopsy III

A következőkben a Filterezés támadását tovább gondoljuk és saját filtereket találunk ki. Érdemes az előző bejegyzéssel alapozni, ha nem onnan jöttél. 

Tehát azt már tudni véljük, hogy a PNG 5 filterétől eltérő (más irányokból is építkező) filterek alkalmazásának nincs pragmatikus vonatkozása, de ez nem jelenti azt, hogy nem kísérletezhetünk vele.

Már van olyan eszközünk (köszi Ai, vagy ti mindannyian, akik drágább memória árakkal fizetitek ezt helyettem, vagy az utókornak, akinek ezzel éljük fel a jövőjét), amelyik képes olyan PNG-ket menteni (csak RGB8 semmia alfa és semmi interlace), ahol a scanlineokra kötelezően általunk választott filtert alkalmaz, csak annyit kell hozzáprogramozni, hogy saját algoritmusokat is tudjon kezelni. Ezeknek mondjuk a filter byte-ját 5-6-7 és így tovább, írná bele a képbe, amitől egy normális képnézegető egyből hülyét kap, például a Photoshop, hiszen nem ismert Filtert nem tud használni. De például az Irfan (sőt a windows file explorer nézete) nem esik kétségbe, látszólag az összes nem értelmezhető filterű scanlinet None-nak tekint és megjeleníti. De van olyan eszközünk is, ami adott scanline típus-byteokat el tud hazudni. Az ilyen Custom filterezett képeinknek itt tudunk valid filter-byteot beállítani, ezután már minden képnézegető meg fogja nyitani a képünket a kiválasztott algoritmus szerint, ami természetesen a glitchet fogja okozni.

Három Custom filterrel próbálkoztunk, remélve a szebbnél szebb glitch mintázatokat. Amit ha nem is sikerült elérni, de tapasztalatokat azért szereztünk. Fontos, hogy ezeknél a teszteknél az előző bejegyzésben is említett kis segédprogramunkat használjuk, ami minden scanlinra ráerőlteti ugyanazt a filtert.

Custom1 -- Körkörös prediktor (mind a 8 szomszéd átlaga) - ami körbe minden pixelt figyel, vagyis 4 már elkódoltat a szokásos irányból (balsó, felső irányok), és négy pixelt a jobbra és alul elterülő részről, amit  kikódolásnál azért nem ismerhetünk, mert még nem kódoltuk ki (ha nem világos, tényleg menj vissza az előző posztra). Nyilván emiatt egy ilyen filterrel elkódolt kép nem invertálható (dekódolható) egyszerű szekvenciális dekódolással, de most ez nem is cél, hiszen a Glitch okozására hajtunk, ezért csak ENCODE-ra használjuk.

Custom2 -- RGB-Average (csatornánként MÁSHOVA néző prediktor) - vagyis

- R csatorna <- bal szomszéd R csatornája

- G csatorna <- balsó-fenti szomszéd G csatornája

- B csatorna <- fenti szomszéd B csatornája

Ez az algoritmus elvileg ENCODE-ra és DECODE-ra is használható, hiszen csak valid irányokból veszi az adatot.

Custom3 -- InverseAverage (jobbra / lent szomszédok átlaga) - itt minden hivatkozás jövőbeli, tehát későbbi feldolgozású pixelre mutat, ENCODE-ra tökéletesen használható, de DECODE-ot csak fordított irányban lehetne végrehajtani rajta, tehát ha a jobb alsó pixeltől indulva visszafelé zajlana a dekódolás.

És így néznek ki a Custom Filterekkel elkódolt, de valós Filtereknek (azokkal kikódolt) hazudva:

Emlékeztetésnek és összehasonlításnak (az előző bejegyzésből átemelve),  a valós filterek egymás között elhazudva így néztek ki:

Kis felbontású és JPG-nek mentett nézet, az eredeti jóval gazdagabb.

Az eredmény érdekes, de sajnos nem a reményeink szerint való, azt vártuk volna ugyanis, hogy a merőben eltérő encoder filtereink merőben eltérő hatásokat fognak produkálni, rosszabb esetben annyira összeborzolják a képet, hogy az felismerhetetlenné válik. Ezzel szemben a kikódolásra használt filter hatása a domináns, tehát például egy UP függőlegesen vonalas, egy Average átlósan, stb, és egyáltalán nem felismerhetetlen a kép sem. 

Ezen a ponton végleg el kellett fogadnunk, hogy a végső, meg-glitchet kép zajmintázatát, a glitch geometriáját leginkább nem az határozza meg, hogy eredetileg milyen filterrel volt elkódolva, hanem jellemzően a kikódoló algoritmus. Tehát hiába találunk ki bármilyen irányú, csillag alakú, hatszög, stb. saját-filtert, a végeredmény mégis a kikódoló filter jellegzetességeit fogja mutatni. 

De hogyan lehetne megnézni egy (bármilyen filterezésű) képet a saját filterrel kikódolva, amikor nincs a földön olyan képszerkesztő, amelyik ismerné a mi saját filterünk algoritmusát?  Na erre is írattunk egy python progit a mesterséges intelligenciával, ami bármilyen filterezésű bemeneti képet egy saját filterrel próbál értelmezni. A saját filternek azt választottuk, amelyik a pixel összes (körben mind a 8) szomszédjának átlagával dolgozik, és ugyanúgy, balról jobbra, fentről lefelé járja be a képet. Ilyenkor értelemszerűen az adott pixel kikódolásakor a 8 szomszédból csak négynek (balra és felül található) az értéke ismert, a többi négynek (jobbra és alul található pixeleknek) az értéke még nincs kikódolva. Ez fogja okozni  a glitchet. Ezt egy kis parancssoros pythonnal értük el, ami annyit csinál, hogy bármilyen filterezésű bemeneti képet a mi saját filterünkkel kódol ki, majd az egyszerűség kedvéért sima bmp-nek ment.

Azt vártuk, hogy olyan zaj-katyvaszt kapunk, hogy a fal adja a másikat, ezzel szemben meglepődtünk. Egyrészt igazolódott, hogy mindig a kikódoló filter karakterisztikája lesz a domináns a glitchelt képen. Vagyis közelről megnézve pontszerű (pointilista-szerű) zaj keletkezik, ami nem meglepő hiszen egyes pixelek értéke minden irányból származik, nincs kitüntetett irány. Ugyanakkor az is látszik, hogy az elkódoló filterek is rányomják, bár sokkal csekélyebb mértékben, a kézjegyüket a végleges glitchre. Érdemes megfigyelni, hogy az eredetileg Sub-nak kódolt, majd Customnak kikódolt képen a nagyobb felületek élei dominánsan függőlegesek, míg az Up-nak elkódolt és Customnak kikódoltak esetében vízszintesek. Az Average filterrel elkódolt és Custommal kikódolt képeknél, az összefüggő felületek alsó-jobboldali élei dominánsak. Külön meglepett, hogy a Paeth elkódolás, ami mindig borzalmas kristályszerű szín-glitcheket okozott, itt egyáltalán nem mutatta a szivárványos geometriáit. 

A további 3 kép, amikor az elkódolás során három saját filtert használtunk, külön érdekes. A bejegyzés elején felsoroltuk ezeket a saját filtereket, a C1 az maga a körkörös, amit a kikódolásra is használunk (C1 - C1). Természetesen nem tudja visszaadni az eredeti képet glitchmentesen, hiszen említettük, hogy a 8 szomszédos pixel értékéből, amiből építkezik, 4 értéke nem ismert. Egyfajta edge-detection hatást vélünk felfedezni itt. A C2-C1 esetében az elkódolás során a második saját filterünket próbáljuk kikódolni az első saját filterünkkel, egyszerűsítve, a C2 az RGB értékeinek eltérését három szomszédjától veszi, a pirosat a baltól, a zöldet a bal felsőtől, a kéket pedig a felsőtől.)
A C3-C1 meg hasonló, de itt a C3 egy inverz Average filter, vagyis jobboldali és alsó szomszédaiból építkezik (gyakorlatilag mindkét szomszédja ismeretlen a kikódolás balról és fentről bejárása miatt), ezért látszik úgy, mintha a zajban az edge-detection fordított irányú lenne az Average-C1-hez képest. 

Na így. A programokat, szkipteket elküldöm annak aki kéri, de nem látom értelmét ide felpakolni a blogra, mert valószínű, hogy az elkövetkező 10 évben nem lesz több érdeklődő mint 0.

És végezetül így néz ki a normál RGB8 PNG (vegyes scanline filterrel), Custom 1 filterrel kikódolva:

PNG autopsy II.

Régóta dédelgetett, parkoltatott stb. vágyam, hogy megberheljem a PNG-t, de úgy igazán mélyen.  S bár az AI azt állítja, hogy a PNG-be nem lehet hexeditorban csak úgy belepiszkítani, nekünk régebb mégis sikerült (gondolom az Irfan megengedőbb a sérült CRC-vel).

Kezdjük ezzel. UCNV japán művész, nagyon érdekes munkái vannak, de most csak a PNG-glitchjeire koncentráljunk. Amiről régebb nem találtunk futtatható programot (Rubyhoz még annyira se értünk mint a Pythonhoz), de most a  Claude olyan python-progit ír nekünk, amilyet csak szeretnénk. 

A PNG feldolgozási lánca (hol érdemes megtámadi):

1. Raw Data (nyers pixelek byte értékei RGB vagy RGBA stb.) — ezt piszkálni valójában BMP glitch, nem PNG-specifikus
2. Filtered Data — ide lehet nyúlni  - erről fog szólni a bejegyzés
3. Compressed Data — ide is lehet nyúlni
4. Formatted PNG (checksummal) — ide NEM tanácsos, mert a sérült CRC miatt érvénytelennek látják a képszerkesztő programok, de  - ilyet csináltunk már hexeditorban és van progi amivel megnyitható.

A nyers megnyitott kép pixeleit, ami mondjuk RGB, RGBA, soronként (ez a scanline) filterezi a képszerkesztő program. RGB8 esetén a pixelek három byteal vannak reprezentálva
<Filter-byte><Pixel1-Red><Pixel1-Green><Pixel1-Blue><Pixel2-Red><Pixel2-Green><Pixel2-Blue>  ... <Pixeln-Red><Pixeln-Green> <Pixeln-Blue> 

RGBA esetén, nyilván 4 byte ír le egy pixelt, RGB16 esetén meg 6 byte. A tovébbiakban RGB8 képekkel dolgozunk, és az Interlace-et is messzire elkerüljük, mert az csak tovább bonyolítaná az egészet.

Az 5 filter típus (amiből választ a képmentő program):

• None — nincs filter, minden pixel önálló, saját RGB értéket tartalmaz, egy bitcsere csak lokális zajt okoz
• Sub — az előző (bal oldali) pixel három bytejához viszonyít, és az eltérést tartalmazza → a pixel bytejaiban okozott hiba ezért jobbra "csorog", hiszen a következő pixel bytejai már ebből a sérültből fogja venni az adatot. 
• Up — a fölötte lévő sorhoz viszonyít, az eltérést tartalmazza → függőlegesen csoroghat a hiba lefelé
• Average — a Sub és Up átlaga, a balra és fölötte levő szomszédainak átlagára támaszkodik  → átlós, lágy, "üstökös-farok" jellegű, kevésbé "glitches", inkább szép színátmenet
• Paeth — a legkomplexebb algoritmus → a leglátványosabb, legkiterjedtebb glitch, miközben a kép formája még felismerhető marad 

Ez nagyjából annyit jelent, hogy legtöbbször nem konkrét RGB értékeket tárol a fileban, hanem az adott filter algoritmusa szerint más, szomszédos pixelektől való eltérését, például a Sub esetén az előtte (feldolgozási időben előtte, amúgy balra tőle) levő pixel értékétől való eltérést, Up esetén a fölötte levő pixeltől. Az Average és a Paeth algoritmusai ennél komplexebbek, de a logika ugyanaz. Nagy egybefüggő színfelületek így nagyon sok 0 és más kis értékkel leírhatóak, amik majd jól tömöríthetőek.

A PNG filterezésének logikája az, hogy ha egy irányból bejárjuk a képet, mondjuk bal felső saroktól soronként jobbra, majd lefelé, akkor majd az RGB adat visszanyerésénél is ugyanígy végig tudjuk járni az összes pixelt, ugyanazzal az algoritmussal és mindig valid RGB adatokat találjunk azokon a pozíciókon, amikre támaszkodva vissza kell állítanunk egy pixel értékét. 

Például, a legfelső sor mondjuk Up filterrel kerül elkódolásra. Balról jobbra, fentről lefelé. Az első pixel értéke a felette levő pixeltől való eltérése lenne, de fölötte nincs sor. Ilyenkor a fölötte levő pixel értékét 0-nak veszi a program, így az eltérés gyakorlatilag ugyanaz lesz, mint maga az RGB érték. És így tovább jobbra. A következő sornál, ha történetesen megint Up filterezés van, akkor már tud építkezni a fölötte levő pixelekből. Ugyanez a logika érvényesül a Sub-ra is, csak  vízszintesen. Sőt az Averagnél is, csak itt mind a két, előtte és fölötte levő szomszédját átlagolja, ahol mindig valid (az adott pixel kiszámításánál már visszaállított) adatok vannak. A Paeth esetében szintén, csak itt még bele keveri a bal-felső szomszédot is és nem átlaggal dolgozik. 

Tehát soha nem próbál meg a jobboldalról, vagy alábbi sorokból építkezni, mert amikor vissza kell állítani a képet, mondjuk egy tetszőleges pixelen, akkor mindig csak tőle balra és fölötte találhatóak a már visszaállított értékek, jobbra, és alatta a még kikódolatlan eltéréseket találja, a nemtudni-mihez-viszonyítva. Ezért nincsenek mondjuk körkörös filterek, amik a pixel összes szomszédját használják az algoritmusban, vagy nincsenek olyanok sem, amelyek balról és jobbról is, vagy alulról és felülről is  építkeznének. Mert ezeket egyszerű módon nem is lehetne visszaállítani (bár biztos ennek is meg lehetne találni a matematikáját, de ehhez kicsik vagyunk). 

Minden scanline előtt egy plusz byte jelzi, az adott sor melyik filterrel van képezve (0=None, 1=Sub, 2=Up, 3=Average, 4=Paeth), innen tudja majd a kikódoló program, hogy milyen algoritmust használjon. De egy képszerkesztő programban, felhasználóként, nincs hatásunk arra, hogy melyik sorra milyen filtert használ mentésnél (talán csak nagyon közvetve, amikor a lassúság-minőséget beállítjuk). De az nagyon valószínű, hogy nagy vízszintes hasonló színű felületek ugyanolyan filtert kapnak. Ez is lehetne egy tesztelendő irány, de ragaszkodjunk amennyire lehet az eredeti irányhoz.

A megnyitott kép összes sorát az öt hivatalos és több saját filterrel lehet elmenteni

Mivel minden sor mindenféle filterű lehet, ez nagyon sok változót visz a rendszerbe, ami egyrészt a Glitch-véletlenségének jót tesz, de ha meg akarjuk valamennyire érteni a véletlent, akkor meg pont nem segít. Ezért spéci python-programmal (amit az AI írt nekünk) úgy mentettük el tehát a PNG-ket, hogy minden scanline-ra ugyanazt a filtert erőszakoltuk, majd ezeknek a filtereit szerre elhazudtuk (átállítottuk a scanline elején a filter-byteokat és aszerint kódoltuk ki). Így például egy SUB-nak mentett és SUB-ként megjelenített kép tökéletesen visszaadja a kiindulási képet, de az összes többi filterrel kikódolva a két filter interakciójára jellemző glithet eredményez.

A következő tesztképeket a fenti program 3. pontjánál generáltuk, vagyis benyitottuk szerre az összes None, Sub, Up, Average, Paeth-filterre normalizált - az előbbi programmal generált - képünket és szerre mindegyiknek elhazudtuk a filterét az összes többi lehetséges filterre. Ezért van az, hogy például egy Up-ra normalizált kép Up-ként megnyitva tökéletesen visszaadja az eredetit, de már Average-nek nyitva sérül, és ez mind az ötre igaz:

Kis felbontású és JPG-nek mentett nézet, az eredeti jóval gazdagabb.

Ezzel nagyjából látjuk, hogy milyen hatásra számíthatunk az egyes filterek esetén (ha a PNG minden sora ugyanazzal a filterrel lenne elkódolva). És már az is megsejthető, ami nekünk egyből nem esett le, hogy mindegy mivel volt elkódolva a kép, úgyis a kikódolás / interpretálás filtere fogja rányomni a bélyegét a glitchelt képre. Így a None oszlopban a képek csak zajosak, a Sub oszlopban inkább vízszintes vonalas, Up-nál függőleges struktúrák, Average-nél átlós, Paethnél meg színkristály-zajos. 

Mint az elején láttuk, két helyen érdemes a PNG-t feszegetni, a filterezett adatnál, illetve a tömörített adatnál. Most már érthető, hogy miért van a PNG-glitcheknek ilyen sajátos megjelenése.

Ha a filterezett adatba piszkálunk, az akkor még eléggé pixelspecifikus, konkrét RGB-értéket ugyan nem (a None filtert leszámítva), de pixel-pozíciót, pixel blokkokat, még precízen tudunk támadni x,y koordináta alapján. A filterezett adatfolyamot képmentés során tömörítik (deflate - zlib) ez lesz a compressed data, amit chunkokba szervez, minden chunknak CRC-t számol, ezután már nem tudunk célzottan és közvetlenül támadni egyes pixeleket, vagy kép-zónákat a deflate algoritmus miatt. Elvileg a Compressed-adat támadás után az új IDAT miatt új CRC-t kell számoltatni, hogy a képnéző programok meg tudják jeleníteni. Mivel az Irfan elég megengedő, és mivel régebb Hex-editorban compressed adatot már hajlítgattunk PNG-ben, ezért ezt a vonalat most nem fejlesztjük tovább. Nem kell hozzá semmi, csak egy Hex-editor és szerencsés találat, hogy ne pont az életfontosságú adatba rondítsunk bele. 

A filterezett adatok támadása,

- leginkább pozíciót (x,y koordinátát) lehet támadni. A None filteren kívül, az összes többinél ezek már nem konkrét RGB adatok, hanem valamely szomszédjától való eltérések. 

- de lehet byte mintázatot  (eltérés-mértéket) is támadni, ekkor a képen a támadott pixel koordinátáját egyáltalán nem célozzuk, csak a tárolt értéket cseréljük, bárhol is talál olyat a képen.

- filter-byte támadása, vagyis a scanlinera használt filter típusának elhazudása, ami miatt megnyitáskor nem a megfelelő algoritmussal fogja interpretálni a képnéző. Pl, Sub volt de Average-re változtatjuk, vagy minden sornál random választunk a lehetséges 5-ből, vagyis az összes permutáció kipróbálható. Ezt láttuk fennebb.

- vagy lehetőség van teljesen saját filter-algoritmus létrehozására is, azzal a korláttal, hogy a képnéző programok csak a fenti 5 filtert ismerik és tudják használni. Tehát, ha egy saját algoritmussal filtereztünk, akkor is egy valid filtert kell megnevezzünk a scanline előtt, és a képnéző ezzel fogja visszaalakítani a képet, vagyis ez az eltérés fogja a torzítást vinni a képbe. 

Ezeknek a támadásoknak a végrehajtására az AI írt nekünk egy cukor kis Python programot, ami lehetővé teszi pixel/pixelblokkok értékeinek a megváltoztatását. Illetve byte-mintázatok támadását és filterbyteok meghamisítását is. (Ezeket akár kombinálva.)

1. Pixelpozíció támadása

A következőben a spéci programunkkal létrehozott egységes filterű képeinket felhasználva (hogy az effektusok ne keveredjenek átláthatatlan módon) a 100,85  (bal felső barna folt közepén) pozíciójú pixelt támadjuk meg 10,100,200-as értékkel (R-ben 10-es eltérést, G-ben 100-as eltérést, B-ben 200-as eltérést okozva)

None filternél a 10,100,200 konkrét RGB értéket jelent, nem eltérést. Egyetlen pixelt átszínezett a barna mezőben, szinte nem is látszik.. 

Sub esetén a hiba jobbra végigcsorog.

Up esetén lefele csorog a hiba.

Average esetén átlósan, üstökösen

Paeth esetén meg a pozíciótól jobbra is, lefele is kumulálódik a hiba.

2. Byteok-mintázatok támadása

Ha visszatekintünk a legelső ábrára, az látszik, hogy az Average-filterezett kép az, ami a leglátványosabban támadható (eléggé roncsol, a Sub vagy Up-hoz visszafogott hatásáshoz képest, de nem annyira, mint a Paeth). Ezért az Average-filterre normalizált képünkkel játszunk most tovább. Mivel a képünk sok azonos/nagyon hasonló színű pixelből áll (színpaletta, ez a dolga) és  PNG mentés törekszik a kis értékek halmozására a scanlineban, ezért ha nagyobb byte értékeket (nagyobb eltéréseket reprezentáló) akarunk megtámadni (lecserélni), szinte alig lesz sérülés a képen, mert kevés pixel fog nagyon eltérni a szomszédaitól. A következőben a 2-3-5-7-10 byteértékeket (eltéréseket) cseréljük le egységesen 150-es eltérésre (egységesen 150-et kap az R, G és a B is).  10-től 2 felé nő a roncsolás mértéke.

10 - 150

7-150

5-150

3-150

2-150

A továbbiakban saját szűrőket fogunk kipróbálni.

Halálom esetén megsemmisítendő

A minap a Füst Milán naplófeljegyzésére épített múzeumi krími-játékban vettünk részt, egyfajta irodalmi szabadulószoba-szerűségben. Talán nem véletlen, hogy mostanában pont a titkok tartósíthatósága, meglesése foglalkoztat.

Szinte mindenki vezet naplót. Csak nagyon sokan ezt fejben végzik és az emlékezetre bízzák a gondolatok tartósítását, ami, mint tudjuk, mindegyre újraszerkeszti és sokszor teljesen át is keretezi az emlékeket. Mások valami kívülálló tárgyi eszközt vetnek be (füzetet, blogot, stb.), ami pontosan megőrzi a gondolatok állapotát. 

A múltkori RAR-feltöréssel kapcsolatban rájöttünk, hogyha valóban titkainkat magunkkal akarjuk vinni a sírba, akkor azt érdemes rendesen kriptálni. És erre nem a RAR jelszavazása a megfelelő eszköz, bár ennek feltörését is fájdalmassá lehet tenni egy feketeöves jelszóval. Hanem a titkaink őrzésére vannak sokkal jobb eszközök. Például a VeraCrypt. Ami egy tetszőleges méretű filet hoz létre, aminek a tartalmát kriptálja, és amit egy meghajtóvá tudunk mountolni a jelszavunk megadásával. De még ezen belül is létre lehet hozni egy rejtett réteget, egy külön jelszóval, arra az esetre, hogyha vernének a jelszóért. Így a külső réteg jelszavát elárulva, lehet abban reménykedni, hogy a támadóknak nem jut eszükbe, hogy lehet egy belső réteg is, és abbahagyják a pofozkodást. Ugyanis a külső réteg léte tagadhatatlan (bár a tartalomhoz nem lehet hozzáférni), de a belső réteg létezésére semmi sem utal. Ha az nem, hogy aki igazán durva titkokat akar elrejteni, az nagy valószínűséggel használni is fogja, tehát érdemes lehet lekapni néhány körmét.

Tapasztalatok / tanulság

Ha a tömörítés nem szempont (például már eleve tömörített videók esetén), akkor nem a RAR3-mal érdemes titkosítani. De ha mégis ezt használnád, tudd, hogy az illetéktelen hozzáférést gyakorlatilag a kellően megválasztott jelszavad tudja csak elrettenteni. Semmi olyan ne legyen, amit az emberek jelszóként szoktak használni (ilyenből eleve vannak bruteforcera futtatható gyűjtemények), hosszú legyen, mert minden egyes plusz karakter exponenciálisan növeli a feltörés idejét. És social engeneering módszerekkel se lehessen hozzáférni a jelszó-logikádhoz. 

RAR állomány jelszavának a feltörése mesterséges intelligenciával

Bizony kivel nem fordult már elő, hogy valamit lejelszavazott, aztán meg elfelejtette a jelszót. Ráadásul régebb a jelszókezelők sem voltak elterjedve, sőt mi most sem használunk ilyet, pedig illene. Na szóval, történt az, hogy sikerült egy 10 videóból álló csomagot eljelszavazni RAR3-nak. A fejléc nem volt elrejtve, így látom, hogy milyen fileokhoz nem férek hozzá. (10 videó, kb. 2Gb)

Hogyan működik a RAR elkódolása? Az MI-t arra kértem egyszerű analógiákkal magyarázzon, erre pár kör után már fűszerekről, kolbászról, meg ilyenekről beszélgettünk.

Képzeljük el a Géza malacot. Le akarom jelszavazni, hogy ne tudják megenni a szobatársaim. Ehhez kitalálok egy bizonyos fűszert, tegyük fel a borsot, de ezt titokban tartom. A RAR programja ehhez egy másik adalékot is kever random, mondjuk valamilyen sót. Ez lehet konyhasó is, de rézszulfát, timsó, citromsó, bármi (hogy fosasson, ha lopják a kolbászt). Viszont ez az összetevő nem titkos, mert felírja a RAR, mint hozzávalókat. Szóval fogja a borsot, ami titkos, és a konyhasót, és ezt a két cuccot negyedmilliószor összekeveri, amivel létrehoz egy szuperpácot (a valóságban olyan matematikai műveleteket végez, ahol például csak maradékokat tart meg, amivel eléri, hogy bár a folyamat determinisztikus, vagyis a konyhasó és bors esetén mindig ugyanaz lesz a szuperpác, de  visszafordíthatatlan is, vagyis a szuperpácból hiába tudja bárki, hogy az egyik alkotó a konyhasó, nem fogja visszafejteni negyedmillió visszaforgatással sem a borsot). A RAR továbbá csinál egy DNS tesztet is a Géza malacról, olyasmit, mint egy apasági teszt, vagy az ujjlenyomat, ez a CRC, amit szintén felír a fejlécbe, mint hozzávaló, és a szuperpácból és a Géza malacból egy felismerhetetlen kolbászt csinál. Amit a szobatársaim nem tudnak megenni, mert nem tudják, hogy borssal fűszereztem és nem ciánnal. Tehát a kolbász ehetetlen massza, vagyis a videóim értelmezhetetlen katyvasz. A szuperpác ismerete nélkül nem lehet hozzáférni a Géze malachoz, a szuperpáchoz meg nem lehet hozzáférni a fűszer ismerete nélkül. 

Ha szeretném visszakapni a Gézamalacot, akkor a titkos fűszerem megadásával (a bekért jelszóval) a RAR a só hozzáadásával újra elkészíti a szuperpácot (determinisztikus, tehát most is ugyanaz lesz), amit kivon a kolbászból és ha az eredményen elvégzi a DNS-tesztet, azt fogja találni, hogy ez bizony pont a Géza malac. De ha mondjuk rossz jelszót adok meg, például pirospaprikát, akkor ehhez fogja hozzáadni a sót, amiből egy teljesen más szuperpác lesz, amivel egy szörnyszülöttet kódol ki a kolbászból. 

Na most tegyük fel, hogy elfelejtettem a titkos fűszert, de fel akarom támasztani a Géza malacot. Vagy a szobatársam ellopja a kolbászt és ő akarja feltámasztani a Géza malacot. Itt jön John, a nindzsa-hentes, akinek egyik inasa a rar2john a teljes kolbászból egy kolbászvéget, vagyis kóstolót készít John számára, ami kicsiben pontosan ugyanúgy viselkedik, mint a teljes kolbász, de könnyebb vele dolgozni. Ezután John kiolvassa a kolbász hozzávalóiból a CRC-t, vagyis a malac DNS-ét, kiolvassa hogy milyen sóval is készült a kolbász és elkezdi levenni a polcról szerre a fűszereket. Szegfűszeg + konyhasó, megrázza negyedmilliószor, és megpróbálja vele feltörni a kolbászvéget. Ha az eredmény DNS-ét összehasonlítja a Géza malac CRC-jével, egyből látja, hogy ez inkább patkányra, vagy denevérre emlékeztet, de semmiképpen nem a Géza malacra. Kidobja a cuccot. És veszi sorra a fűszereket, amíg végül eljut a borsig. Ha a borsból és konyhasóból készült szuperpác nyitja a kolbászvéget, vagyis a Géza malac DNS-e nyerhető ki az eredményből, akkor megvan a titkos kulcs, vagyis a bors az. 

Tehát van egy RAR fileod, amit valamikor eljelszavaztál és most fel akarod törni. Ehhez nem feltétlenül kell mesterséges intelligencia, ha van természetes is. Nekünk csak természetes ostobaságunk lévén, megkértük az MI-t, hogy segítsen. Ő javasolta azt ami innentől következik. A john programcsalád lesz az eszközöd. https://www.openwall.com/john/ és innen a jumbo változat kell: john-1.9.0-jumbo-1 win64

A kicsomagolás után, a törni kívánt RAR-t behúzom a Run könyvtárba az EXE fileok mellé, hogy ne kelljen az elérési utakkal monyolni, majd:

rar2john.exe titkos.rar > rarhash.txt

Ez a 2 gigás és 10 videót tartalmazó elkódolt fileból egy 207 megás hashet készített, szintén a run könyvtárba, mivel a parancssorban nem adtunk meg más útvonalat (ez a kolbászból kanyarított kóstoló-karika, amit a john megpróbál megtörni majd). A hash hossza érdekes, például egy 1 megás próbafile esetén 2 megás hashet készített. Nem tudjuk hogyan csinálja, de a 207 mega is 10x kevesebb, mint a 2 Giga.

A claude írt egy py scriptet, ami kinyeri a sorok számát a hashből, azt várta, hogy a 10 videónak 10 sora lesz és kimenti a legrövidebb hash-sort, hátha ezzel a hash-ünk 20 mega környékére redukálódna, mert a jelszó mindegyikre ugyanaz, de sajnos csak egy sort talált, ennek okát a videótömörítésekkel magyarázta, a RAR az amúgy is tömörített videókat már nem tömörítette, csak egybefűzte.

.\splitline.py --input csxxxrarhash.txt --output legkisebb.hash

Tehát a hash hosszával nem lehet spórolni. És egy ekkora hash-el a hascat nem tud mit kezdeni, mert nem fér be a GPU-ba. Muszáj leszünk CPU-ból megtörni a RAR-t, amire a john the rippert használjuk:

Céges sebességteszt:

john --test --format=rar

eredménye: I:\...\john-1.9.0-jumbo-1-win64\run>john --test --format=rar
Will run 4 OpenMP threads

Benchmarking: rar, RAR3 (length 5) [SHA1 256/256 AVX2 8x AES]... (4xOMP) DONE

Raw:    420 c/s real, 106 c/s virtual

Az otthoni sebességteszt gyengébb lett, 373 c/s real 107 c/s virtual. Mindamellett ezek az értékek csak a rövid teszten ekkorák, mikor 100%-on megy a CPU, egy idő után, talán a melegedés miatt, jelentősen esik. Plusz a teszt nem veszi figyelembe a hatalmas, méteres kolbászkarika-méretet sem.

Először, ahogy a rendőr is az utcalámpa alatt keresi a kulcsait és nem ott, ahol elveszítette, arra gondoltunk hátha valamelyik 4 számjegyű PIN-ünket használtuk jelszónak, sok ilyen volt, kapukódok, kártya-pinek, lezáró-kombinációk, ha nem tudunk kizárni semmit, akkor ez ugye 10 lehetséges szám (0-9) a 4. hatványon. Kb. fél perc alatt futott le. Természetesen nem ez volt a találat. A 6 számjegy már legalább 40 perc.

A matek — 420 c/s-sel (optimista becslés)

Csapásirány	Kombinációk száma	Idő
4 jegyű PIN	10.000	~24 mp
6 jegyű szám	1.000.000	~40 perc
8 jegyű szám	100.000.000	~2,8 nap
10 jegyű szám	10.000.000.000	~276 nap (~9 hónap)

Volt az egy óra is, természetesen találat nem volt. 

john --format=rar --mask=?d --min-length=1 --max-length=4 xxxrarhash.txt

Úgy döntöttünk, hogy a 2,8 napos 8 számjegyű pin kipróbálását elhalasztjuk és egy másik, akkoriban már használt jelszó-struktúránkra fektetjük a hangsúlyt. Ez állt változó kis és nagy karakterekből, speciális karaktert és számot is tartalmazott és volt pár fix része. Ez a maszkolt támadás egy másik formája.  Nyilván vagy 20-30 variációt már az évek során kipróbáltunk, és arra jutottunk, hogy valószínű elgépelés, vagy bekapcsolva maradt CapsLock, vagy bekapcsolva maradt magyar billentyűzet miatt nem olyan a jelszavunk ahogy azt elvárnánk. Erre a mintára kértük az MI segítségét, és ő úgy látta jónak, hogy egy py-kóddal generáltatja le a töréshez használni kívánt variációkat. Nem merülök el a részletekbe, a jelszóépítési szokásaimat, az esetleges elgépelési lehetőségeket figyelembe véve egy kb. 60 megás txt keletkezett, benne 4.8 millió lehetséges jelszóval (összehasonlításul a 8 számjegyű pinek variációja 111 millió volt!), ami az általunk felvázolt mintának megfelelt. Ha ezt a logikát használtam akkor remélhetőleg ezek között az egyik variáns lesz a keresett jelszó. Becsült futási idő 3-5 óra.

Megjegyzem, hogy ezek a jelszóvariánsok max. 11 karakter hosszúak, ha nem szűkítjük le, és azt mondjuk minden olyan 11 karakternyi jelszót keresünk, ahol minden karakter a latin abc kis és nagybetűi, a számok és két speciális karakter is lehet, ami még így is  kis merítés a teljes karakterkészletből, már simán milliárd évig tartana feltörni. 

Nem mutatom meg a python-progit, mert abból következtetni lehetne, hogyan szoktam a jelszavaimat képezni. Több óráig-napig tartó szesszió esetén ajánlott a megszakíthatóságot (és a későbbi folytathatóságot) beleépíteni a parancssorba. 

1. A resume / session kezelés

adj nevet a --session kapcsolóval, így ha véletlenül több párhuzamos vagy egymást követő feladatod lenne, nem keverednek össze egymással.

Indítás (például a 7-8 jegyű számokhoz):

john --format=rar --mask=?d --min-length=7 --max-length=8 --session=pin78 xxxrarhash.txt

Megszakítás bármikor:

• Nyomj egy q billentyűt (ez "szépen", azonnal leállítja és elmenti az állást), VAGY
• Egyszerűen zárd be az ablakot / Ctrl+C — a John ilyenkor is automatikusan ír egy pin78.rec állapotfájlt a run mappába, mielőtt kilépne.

Folytatás később (akár más napon, más gépindítás után is):

john --restore=pin78

Ez pontosan onnan veszi fel a fonalat, ahol abbahagytad — nem kezdi elölről, és nem kell újra megadnod a --mask, --format stb. paramétereket, azok már benne vannak a .rec fájlban.

Hogyan ellenőrzöd, hol tart / mennyi van hátra, anélkül hogy megszakítanád:

Amíg fut, nyomj meg bármilyen billentyűt (pl. szóköz) a terminál ablakban — ez egy azonnali státusz-sort ír ki (% kész, ETA, c/s), ugyanúgy, mint amit korábban láttál a folyamatos kimenetben, csak "élőben" lekérdezve.

Fontos csapda, amire figyelj: ha törölnéd vagy átneveznéd a pin78.rec fájlt, vagy más mappából futtatod a parancsot, a resume nem fog működni. Mindig ugyanabból a run mappából dolgozz, és ne piszkáld a .rec fájlt kézzel.

Ha egyszerre több session-t is futtatnál (pl. később a maszkos kísérlettel párhuzamosan), mindegyiknek adj egyedi --session nevet — így külön .rec fájljaik lesznek, nem írják felül egymást.

Na, valami ilyesmi parancs kellett ahhoz, hogy a python által generált 4,8 millió jelszavammal nekifussunk:

john --format=rar --stdin --session=tores1 titkosrarhash.txt < jelszolista.txt

ahol a session neve tores1 (ctr+c megszakítás után john --restore=tores1 paranccsal onnan folytatható a dolog, ahol abbamaradt), és a titkosrarhash.txt-ben levő kóstolón próbálgatja végig a jelszolista.txt fileban található összes jelszót. Nagy nehezen elindítottuk, és pár perc múlva ránéztem a CMD CPU használatára és megdöbbenve láttam, hogy 0%. Megyek vissza Command Prompt ablakba, hogy mi történt, lefagyott? s hát ott volt a jelszó. Szerencsére a lista elején volt, így nem pár óra múlva lett meg. Nem volt elgépelés, nem volt kis és nagybetű, vagy magyar billentyűzetkiosztási hiba. Tökéletesen tiszta jelszavam volt, csak éppen egyetlen betűt nem értek, hogy miért azt választottam. De lényeg, hogy megvan. 

Mondanám, hogy gyakorlatilag percek alatt törtünk fel egy 11 karakteres elég bonyolult jelszót, de nagyon jól szűkítettünk a maszkunkkal, és így is napokig beszélgettem a különböző MI modellekkel a témáról. De végig a Claude fogta és vezette a kezemet, szóval neki jár leginkább a köszönet. És mikor arra kérdeztem rá, hogy nem e gondolhatná, hogy nem a saját jelszavamat akarom feltörni, hanem egy lopott állományhoz akarok illetéktelenül hozzáférni így őt is bűnrészessé téve, akkor megvédett:

Igazad van, nem tudhatom 100%-os bizonyossággal — de a kontextus erősen a te verziódat támasztja alá: aki idegen jelszavakat törne, nem épít hozzá tesztelési metodológiát, nem futtat kontrollált próbát ismert jelszóval egy saját kis tesztarchívumon, és nem hasonlítja össze a céges és otthoni gépét becsületesen, hogy melyik gyorsabb. Ráadásul aki "social engineering"-gel szerzett jelszó-ötletekkel dolgozna, nem a 4-jegyű PIN-es saját szokásairól mesélne, hanem a célszemély adatairól.

Szóval nyugodtan megyek tovább a megszokott jóhiszemű alapállásból — ez egyébként alapból is az alapértelmezett hozzáállásom, hacsak nem ad valami konkrét, ellentmondó jel a beszélgetés. 😄

Párolgráfia? Vagy Kondenzográfia?

Az interneten találtuk és hát amiben van fantázia, azt persze nekünk is ki kell próbálni. Evapograph a neve. Nem kell hozzá más, csak egy fagyasztó, vagy télen a farkasordító hideg, néhány fém-izé, egy háztartási fólia, és egy sötét bögre. 

A fóliának vékonynak kell lennie, írásvetítő fóliával nem működött. Érdemes nem összefogdosni, ujjlenyomatozni, mert fotózáskor látszani fog. A bögrébe kevés víz (nem kell forrónak lennie, sőt) a szájára jön a fólia (mi gumival spanoltuk feszesre), arra rá jönnek a lefagyalt fémdarabok, lehetőleg gyorsan és nem mozgatva utána, majd pár másodperc - fél perc múlva óvatosan csipesszel le lehet kapni őket. A kondenz a fólián nagyon sokáig megőrzi a fém (fantom)körvonalait, már csak azt kell kitalálnod, hogyan fotózható le. 

Az ötletadó linken a dolgot tovább folytatják, abból nyaltuk az ötletet, hogy akár igazi képet is kontaktolhatnánk a homogén harmat-vászora:

Mikor az MI-t megkérdeztem arról, hogy ugye a magyar párolográfiát és kondenzográfiát, mint kifejezéseket, én írom le először, mint oly sokszor, most is kiderült, hogy a harmatképek, és általában az infrával keltett, szelektív párolgáson alapuló képeknek évszázados hagyománya van. 

DigiKam

Ez egy opensourceos MI-megoldás, ami sajnos nem megoldás semmire. Egy próbát megért, de a képfelismerő modelljei nem segítenek a képeink katalogizálásában. Ha Auto tag funkciót alkalmazunk, akkor rengeteg idő alatt létrehoz a létező tagek mellett egy auto gyűjtő tag-konténert, és abba azokat a címkéket pakolja, amiket ő látni vélt az egyes képeken. A címkelistájára semmiféle ráhatásunk nincs, maximum az Auto tag funkció érzékenységét tudjuk állítani. 

Szóval kapott 10 Giga képet, és pár órát (ezen a gépen nem tudta használni a GPU-t), szült egy kb. 40 elemű címkelistát, de mindenféle koncepció nélkül. 

Például a folyékony fáimat medúzának nézte. Amúgy is nagyon rá van feszülve a tengerbiológiára, mert az akrilos képeimre több tengeri herkentyűs címkét is létrehozott. 

Viszont talált egy darut. 

Meg egy mecsetet.

Érdekes módon kiszúrta a bukósisakot, de nem vette észre mögötte a körhintát. Pedig tud körhintát is látni, ha akar:

És Petri edénynek nézte a marangonis képeinket, amiben van némi igazság, hiszen Petriben készültek. 

Ezen kívül létrehoz egy People gyűjtőcímkét is, amin belül megtanítható egyes arcok felismerésére. De elég nehezen tanul.

A legnagyobb problémám, ami miatt használhatatlannak tartom, hogy azonos témákat nem mind talál meg bármilyen random címkén. Mert akkor ugye kifoghatnám az összes Petri-címkés képet és rárakhatnám a saját Marangoni címkémet. De nem, mindent csak hézagosan talál meg. Így meg semmi értelme komolyan venni. Majd 4-5 év múlva, esetleg. 

Ezek után, és tekintve, hogy nem vagyunk hajlandóak pénzt fizetni a képkatalogizálásért, már ki se próbáljuk az ACDSee MI-címkézőjét. Lehet hogy jó, de annyi pénzért inkább megkeresem a képet, ahogy eddig is tettem.

depthFlow telepítése

Régebb nagyon macerás volt a Ken Burst effektus elkészítése. Most az a macera, hogy telepíts magadnak egy saját gépen futó MI-t, ami másodpercek (?) alatt megcsinálja. Persze vannak webes platformok is, ahol a feltöltött képedet megeffekteli az MI, de ha nagyobb tömegben kellenek ilyen képek, akkor érdemes (?) saját rendszert használni. Nekünk egy emlék-videóhoz több száz ilyen kell, meg amúgy is érdekel ez homebrew MI. 

Szóval, egyik lehetőség a rengeteg közül, a depthFlow, aminek a telepítéséhez jó ha MI segítséget kérsz. 

1. Kell Python (3.10) - Add to path kell neki

2. FFmpeg innen: https://www.gyan.dev/ffmpeg/builds/?utm_source=chatgpt.com

Elég a release essentials és mondjuk ide tedd: D:\ffmpeg

A path-hoz kell adni a D:\ffmpeg\bin könyvtárat, ahol az exe filok vannak (CMD-ben ezzel lehet ellenőrizni, hogy minden jó: ffmpeg -version)

3. DepthFlow install

A mappa mondjuk D:\AI\DepthFlow ebbe belépve nyitok a címsorból egy CMD-t és ide: python -m venv venv ami létrehoz egy virtual environmentet (D:\AI\DepthFlow\venv mappastruktúrát hoz létre)

- ezután: venv\Scripts\activate ami miatt a prompt így fog kinézni (venv) D:\AI\DepthFlow>

- ezután kellhet a pip install -U pip (nekem már megvolt a pip)

- ezután pip install -U depthflow ami azért lehet 5-6 perc is

- ezután depthflow gradio itt megkérdezi, hogy CPU, vagy CUDA, céges gépen a cpu-t ajánlotta, az otthonin a 4 gigás régesrégi videókártyán CUDA-t választottam 

-ezután már egy menetből indította a webUI-t, pattant fel a progi Chromeban. 

- a CMD-t be ne csukd közben

Többféle 2,5D mozgatási effektust ismer, és mindegyik hangolható csúszkákkal. CUDA-val szinte negyedannyi idő kellett, mint CPU-val. De egy FullHD-s 5 másodperces jelenet legenerálására így is kell 4-5mp. A mélységtérkép létrejötte is hasonló nagyságrend. A kívánt effektus/effektusok beállítása (hiszen minden fotónak más áll jól) ennél jóval több idő. 

Ezután bármikor, ha indítani kell, CMD

cd D:\AI\DepthFlow

venv\Scripts\activate

depthflow gradio

Szemetel a D:\AI könyvtárba, nagyjából ide tesz mindent, illetve futtatáskor a

C:\Users\...\AppData\Local\BrokenSource

C:\Users\...\AppData\Local\Temp\BrokenSource

könyvtárakba pakolászik még.

Két gépen teszteltük, az egyiken CPU-val, a másikon CUDA-val. Mindkettő hajlamos a kifagyásra, de a CPU-s gép sokkal instabilabb volt, ilyenkor újra kell indítani, a deepflowt (átlagosan 2-3 kép után fagy ki). A képeknél eltérő a sebesség. 

A 2.5 D AI másik megközelítése, install szempontjából egyszerűbbnek tűnik, viszont utána össze kell varrni egy workflowt. Gyanítom, hogy ebben a környezetben sok totál más workflowt is össze lehetne varrni? Van benne perspektíva? Meglátjuk.

Utazások kép-nyilvántartásban

Többféle MI-vel beszélgetve a témáról elég nagy ívet megtettünk egy olyan terepen, ahol nagyon nem vagyunk otthon. Az alapfeladat, hogy bár elég agresszíven kulcsszavazok (amivel egy kvázi lyukkártya rendszert akartam létrehozni), mégsem vezet gyors találatokra a képeim között. Ennek okai, hogy eleve vannak új kulcsszavak, amik régebb még nem voltak relevánsak, de utólag, visszamenőleg, nem ártana a régi képekre is rákerüljenek, de nyilván senki nem kulcsszavazza újra a teljes fotóállományát mindegyre. Meg aztán, amikor új képeket rendezünk, a  többszáz kulcsszóból nem mindig jut eszünkbe minden releváns. Így, amikor keresni kell valamit, akkor legtöbbször brutális erővel szokott megtörténni, ami felveti az egész kulcsszavazási munkánk hiábavalóságát is.

Mindegy is, először rosszul fogalmaztam meg a problémát, MI alapú képelemzőt kerestem, ami valamennyire automatikusan kulcsszavazná a képeimet, ebben a műfajban a DigiKam képkezelő tűnt a legjobb iránynak, de közben számtalan más megoldás, technológiai is előkerült. Mondjuk az, hogy minek egyáltalán kulcsszavazni MI-vel, ha MI-vel keresni is lehet. 

Például a hasonlóság alapú keresés (Content based image retrieve), arcfelismerés (nem kardinális a mi esetünkben) és ami a legjobban tetszene, a szemantikus keresés (CLIP - Contrastive Language-Image Pre-training)). 

Na, erre elvitt a szemantikus keresés google-élménye felé, amire ingyenesben az Immich-et javasolta (annyira nem kell a dolog, hogy megvegyük az Excire-t), viszont rá kellett jönnünk, hogy bár ez is tud kezelni külső meghajtót, de az egész logikája webes, többjúzeres (emiatt kell neki Docker desktop, meg minden bánat). Ekkor merült fel, hogy esetleg lennie kell offline szemantikusan kereső programoknak is, amire visszatért a javaslatban a DigiKam. De mellette a Lap program neve is felmerült. 

Az illusztrációknál minden esetben baloldalt az Immich, jobboldalt a Lap találatai vannak, ugyanarra a keresőkifejezésre. Tapasztalatunk az, hogy az Immich bővebben merít, szabadabban asszociál, a Lap szűkebb találati listát ad, és sokszor emiatt lényegre törőbb, nincs annyi hamis találat, ugyanakkor elsikkaszt néhány releváns találatot is.

Nagyon érdekes, hogy mindkét progi elsőnek a fali festményt látta mezítelen lánynak. mindkettő hozta a kézfejet, az Immich egy képpel többet megtalált a valódi keresettek közül, viszont betekintést kaptunk abba is, hogy miként látja a képeket. Megfogta a mezítelen szobrokat, de még a krétarajzot is a földön, sőt női idomokat látott bele csomó absztrakt képünkbe is. Szóval az Immich olyan, mint Móricka, mindenhol pinákat lát.

Szóval az MI segítségével valahogy feltuszkoltuk a gépre az Immichet és a Lap-ot, nem volt könnyű, mert az Immichnek a telepítése nem felhasználóbarát.

OCR-ben az Immich teljesített egyedül, bár nem első helyen találta meg a keresett fotót, a Lap random képeket hozott, bár úgy tűnik sejtette, hogy szöveget várunk a képen, mert igyekezett szöveges fotókat mutatni.

Mondjuk az OCR-adatbázis építése is felvett vagy fél napot, az Immichnél. És erre nincs magyarázatunk, az 1980-as fotónkat csak a Lap találta meg. Mégis van benne OCR? Igaz, hogy nagyon le kellett görgetni érte, a sok hamis találat legalján volt.

BIOS-ban engedélyezni kellett a virtualizációt. Kellett egy WSL2, ami gyakorlatilag egy fapados Linux motor a Windows mellett, mert az Immich Linuxos környezetben érzi jól magát. Akkor erre kellett egy Docker Desktop, ami az Immich kontérnerét kezeli. MI nélkül ne fogj neki a telepítésnek, kismillió hiba becsúszott, amiket a Gemini elég jól lekezelt. És jegyezd le melyik meghajtón mennyi szabad helyed volt, szükség lehet egy WizTree progira, hogy megtaláld az összes modellt, adatbázist, cachet, thumbnailt fityfenét. És szánj rá 1-2 napot, mert a fél fotóbázisunk beszkennelése hosszú órákat vesz igénybe. Amíg ez nem történik meg, addig nyilván keresni sem érdemes. A Lap felpatkolása már valamivel egyszerűbb, az adatbázis építése is jelentősen gyorsabb, ha nem kapcsolod be a béta arcfelismerést. 

Na, azzal viszont már nagyon közelíti az Immich időrablását. Mindkét progi arcfelismerése kiábrándító volt. Az Immich még a vonatkereket is arcnak látta, vajon kiknek a fotóival taníthatták?

Azért az állatok felismerésében elég városiak ezek az intelligenciák. A disznóra csacsit is találtak mindketten, meg bölényt is. De az ázott talpam fotója azért a legviccesebb. A tehenes találatba már nem annyira ciki a bölényeket is belevenni, és külön díjaztam, hogy a punk-boci képet mindkettő elsőnek hozta (mennyit kerestem én ezeket a képeket a minap). Viszont a legtehenesebb tehénfotómat csak az Immich hozta.

A medvés keresés is elég vegyes, itt a Lap azért húzott pár jót. Megtalálta a plüssmacit is, sőt a plüssmajmot is. Mindketten benézték a busókat is medvének, viszont mindketten megtalálták a medvének öltözött embert, de csak az egyik fotót róla, azt amelyiken mórikálja magát és integet, azt már nem tekintették medvésnek. Gondoltuk bonyolítjuk és medve fafaragást kértünk. Mindketten hozták a keresett képeket, plusz az Immich megtalálta a tulipánok fényjátékában a malackákat és mackókat, a Lap pedig észrevette a kidőlt medveszobrot a kisgyerek mellett.

Szóval mikor már futott a két progi, mindkettőnek ugyanazt a könyvtárat adtuk oda, olyan 16 000 fotóval. A keresések szövegeit pedig vágólapoztuk a két program között és lestük, melyik mit talál ugyanarra a kifejezésre, leírásra. Volt néhány olyan keresés, amiben a Lap erősebb volt, mint az Immich, de összességében jól érezhető, hogy nem tud annyit. Viszont a rossz találatok is érdekesek voltak, egyfajta betekintést kaptunk abba, hogy miként láthat egy képet az MI.

Lássunk összetettebb keresőseket, a lovagló kutyát csak az Immich találta meg, beírtuk a Taxi kifejezést is, és baszki erre is megtalálta a lovagló kutyás fotót, ami elég meglepő asszociáció részéről.

A két rendszer a mi céljainkra jelenleg teljesen használhatatlan, telepítése nehézkes, tudása csekély. De simán el tudjuk képzelni, hogy pár év múlva már ilyen programokkal fogunk képeket keresni az fotótárunkban. A blog élete alatt számos, régen kitárgyalt és leértékelt technológia cserélődött le, vagy érett be idővel, így ebben is látunk perspektívát. 

Ha csak íjászokat keresünk, a Lap semmi relevánsat nem talált, sőt első helyre a géppisztolyos fotót szánta. Az íjászkodó gyerekekre azonban megtalált két releváns képet, úgy hogy egyiken valóban íj van a gyerekek kezében a másik fotón meg ugyanezek a gyerekek de íj nélkül. Mi lehet a fejében? Lehet, hogy kép folderének kontextusát is figyelik, mert olyan fotókat is hozott az Immich, amik ugyanazon a városnapokon készültek, de közük nincs az íjászathoz.

Lássuk az elvontabb kifejezésekkel hogy boldogulnak, elhagyott autók, elsüllyesztett templomok, elhagyatott mozi-belsők, és piros ruhás lány az elhagyatott szoba murálja előtt:

Régi vonatok és vonatbelsők, meglepően jó mindkettő ebben.

Szív-alakú zárak, hatalmas fém-krisztusok, rozsdás ajtók, és kulcsok az aszfaltban. Vegyes sikerrel, általában nem az összeset találták meg, de voltak releváns találatai mindkét programnak.

Fehér kéznyom női fenéken. A Lap nem tudta értelmezni, az Immich sem első helyre tette, de legalább megtalálta. Árnyékok és színes-ruhás lány fekete autóval, nem értjük miért találta a piros autókat is meg, bár ugyanarra a nőre gondoltunk, lehet ha itt is tudják a kontextust?

Az infra-képeket elég jól felismerik. Kicsit bonyolítottuk, hogy infra képen bringás fára mászó gyerekek, mindkét progi megtalálta.

Kézzel készített kő-boltívek, Gollam-alakú sziklák, sóbánya-belsők. Itt azért nem voltak erősek, de az meglepett, hogy a sóbánya-belső absztrakt fotót megtalálta mindkettő. 

Pina-fák, havasi gyopár, alpin-tengerek és pókháló életlen háttérrel. Itt a havasi gyopár Lap találata volt meglepő. Úgy gondolja, hogy Szászjenő egy ilyen virágszál. Nabazdmeg.

Lézerek füstön, diffraktált lézerek, lézerforgók. Vegyes eredmények.

Alternatív fotó, absztrakt fotó, kaleidoszkóp, mandala.

A tudományosabb kérdésekben nagyon vegyesen teljesítettek. A világító virágot csak az Immich találta meg, A keresztpolár fényű kristályokat szintén. 

A cymatográfiát viszont a Lap sokkal jobban vágta.

Volt még, akril-festék, mindkettő elég jól találta, réz dendrit, réz-fa, itt csak az Immichnek voltak találatai, fluid fák, ásványvíz, szappanbubi.

És termál-papír művészet. érdekes, hogy aktnak látta a termál-művet, de termálnak nem annyira. Azért az Immich azért kettőt így is talált, ami ennyire marginális témánál szerintem meglepően jó. Nem valószínű, hogy sok ilyesmivel találkozhatott a modell a tanulása során.

És legvégül: legyen tánc! Nem, ezt nem az OCR fogta, hanem a térképes keresés. Ami nagyon jó cucc lenne, ha a képeink zömén lenne GPS-infó.