Poprzedni livestream był bardzo ciekawy (przynajmniej dla mnie ;>) - miałem okazję zaprezentować prostą implementacje rozproszonego raytracingu, oraz poprosić widzów, by Ci wsparli rendering mocą obliczeniową. Założeniem było, że coś pójdzie "nie tak", a to z uwagi na absolutny brak mechanizmów weryfikacji poprawności wyników (co jest tematem kolejnego streama - w czwartek o 20). I na szczęście się udało, tj. coś faktycznie poszło "nie tak" i wynikowe sceny wyglądały jak przysłowiowa sztuka nowoczesna. W tym krótkim poście chciałem wskazać kilka oddzielnych klas rzeczy, które wpłynęły na ostateczny wygląd renderingu (patrz obraz po prawej).
Założenie livestreamu było proste - rozdać binarki workera raytracera (w tym miejscu podziękowania dla KrzaQ za przygotowania binarki pod Linuxa) lub poprosić o skompilowanie jej we własnym zakresie (kod jest otwarty), a następnie zlecić na dostępnych workerach wyrenderowanie sceny (co zostało przez widzów humorystycznie określone jako "kopanie gyncoinów") przesyłając pozycję kamery, rozdzielczość całkowitą, oraz fragment do wyrenderowania; sama scena musiała być już obecna na dysku z powodów rożnych, o których za chwilę. A w trakcie renderingu poopowiadać o samym kodzie, jego konstrukcji, etc. Dodam, że w eksperymencie wzięły udział przynajmniej 24 workery od różnych osób (nie posiadam niestety kompletnych logów, więc mogło być odrobinę więcej), a wyrenderowaliśmy ostatecznie 3 obrazy bazując na tej samej scenie (ale z różnymi rozdzielczościami / pozycjami kamery).
Przechodząc do wynikłych problemów, zacznę od przedmiotu renderingu, który sam w sobie przyczynił się do jednego z problemów, czyli darmowej sceny autorstwa ufukufuka pobranej z cgtrader. Genezą problemu jest fakt, iż wiele edytorów 3D ma najwyraźniej problem z eksportem do OBJ+MTL, tj. definicje materiałów w pliku MTL są szczątkowe, niekompletne, i z jakiegoś powodu odzwierciedlają robocze kolory z edytora, a nie finalne materiały ze sceny. Początkowo (po kupieniu/ściągnięciu trzech scen) myślałem, że problemem jest sama metoda konwersji sceny na OBJ+MTL używana na cgtrader, ale po skontaktowaniu się z jednym z autorów scen okazało się, że nawet OBJ+MTL wyeksportowane w programie z którego korzystał nie zawiera prawidłowych definicji (co zresztą potwierdził znajomy grafik wykonując na moją prośbę prostą scenę testową w posiadanym edytorze, i eksportując ją do OBJ+MTL). Oczywiście, czego pewnie nie muszę dodawać, mój raytracer ma zaimplementowaną obsługę jedynie OBJ+MTL.
Z uwagi na powyższe, o czym wspominałem również podczas streamów, poświęciłem któryś wieczór i poprawiłem posiadane OBJ+MTL. Niestety, z uwagi na ograniczenia licencyjne darmowej sceny, nie mogłem udostępnić widzom zmodyfikowanej. W związku z czym byłem zmuszony poprosić widzów o założenie konta na cgtraderze i pobranie darmowej sceny, rozpakowanie jej (ale bez podmieniania dostarczonego przeze mnie pliku MTL) a następnie zaaplikowania patcha, który sprowadza ją do wersji używanej przeze mnie (patcher został przygotowany przez KrzaQ - podziękowania!).
I tu pojawił się pierwszy problem - część workerów nie miała zaaplikowanego patcha na scene (ale zaskakująco chyba wszystkie korzystały z mojego MTL), co objawiło się przełączeniem się niektórych workerów w domyślny tryb "kolory na podstawie iloczynu skalarnego wektora normalnego i promienia" - stąd rozpoznawalne szare fragmenty obrazu na poniższych screenshotach (widać również wielkość fragmentu zlecaną workerom), lub korzystały z innego materiału niż powinny dla danego obiektu (patrz ostatni obrazek, w którym poduszki są fragmentami z tego samego materiału co kanapy; problem dotyczy również przezroczystego stolika).
Drugi problem związany był z celową ingerencją w scene niektórych workerów, tj. w pierwszym renderingu ktoś z poczuciem humoru wpadł na pomysł, żeby podmienić oryginalny obraz Marka Spaina znajdujący się w centrum sceny na coś innego, co w kolejnych renderingach bardzo się spopularyzowało (naliczyłem 4 różne tekstury, pomijając oryginalny obraz):
Ostatni problem na 50% jest efektem buga w moim kodzie, ale równie dobrze mógł być celowym działaniem, więc i tu go opiszę. O ile oba powyższe problemy były de facto ograniczone przez moc obliczeniową problematycznych workerów, o tyle ostatni problem nie jest posiada tego ograniczenia. Konkretniej, raytracer master odpowiedzialny za przydzielanie pracy zlecał rendering jednego fragmentu (np. o rozdzielczości 100x100) danemu workerowi, a następnie czekał na wynik, i do momentu jego otrzymania dany worker nie mógł "zostać właścicielem" kolejnego fragmentu sceny - a więc jeżeli ktoś chciał wpłynąć np. na 50% sceny, to musiał posiadać ~50% mocy obliczeniowej. Ograniczenie to jednak się nie stosuje, jeśli dany worker by po prostu nie wykonywał żadnych zleconych obliczeń, tylko odsyłał od razu np. czarną klatkę. Efektem tego jest zapełnienie większości finalnego renderingu (poza fragmentami "zajętymi" przez inne workery z uwagi na algorytm FCFS) czarnymi fragmentami przy użyciu minimalnej ilości mocy obliczeniowej:
Przyznaję, że bardzo mi się podobało, że podczas odcinka udało się w tak obrazowy sposób pokazać problemy z obliczeniami rozproszonymi na niezaufanych węzłach :)
W kolejnym odcinku (standardowo w czwartek o 20) pokaże kilka metod zabezpieczenia obliczeń przed "złymi" workerami. Z kilkoma widzami już zresztą dyskutowałem o różnych pomysłach (m.in. dostałem kilka świetnych pomysłów od Karola Augustyniuka - kudos), więc w sumie i tu zapytam - czy i Wy macie jakieś pomysły lub przemyślenia jak można by zabezpieczyć rendering w niezaufanym środowisku? Zachęcam do dyskusji w komentarzach.
I tyle.
Sections
- lang: |
- RSS: |
- About me
- Tools
- → YT YouTube (EN)
- → D Discord
- → M Mastodon
- → T Twitter
- → GH GitHub
Links / Blogs
- → dragonsector.pl
- → vexillium.org
- Security/Hacking:
- Reverse Eng./Low-Level:
- Programming/Code:
Posts
- Debug Log: Internet doesn't work (it was the PSU),
- FAQ: The tragedy of low-level exploitation,
- Solving Hx8 Teaser 2 highlight videos!,
- Gynvael on SECURITYbreak podcast,
- Paged Out! #4 is out,
- I won't be able to attend CONFidence'24 after all :(,
- xz/liblzma: Bash-stage Obfuscation Explained,
- Two of my bookmarklets: image extraction and simple TTS,
- Paged Out! #3 is out,
- My howto script,
- → see all posts on main page
// copyright © Gynvael Coldwind
// design & art by Xa
// logo font (birdman regular) by utopiafonts / Dale Harris
/* the author and owner of this blog hereby allows anyone to test the security of this blog (on HTTP level only, the server is not mine, so let's leave it alone ;>), and try to break in (including successful breaks) without any consequences of any kind (DoS attacks are an exception here) ... I'll add that I planted in some places funny photos of some kittens, there are 7 of them right now, so have fun looking for them ;> let me know if You find them all, I'll add some congratz message or sth ;> */
Vulns found in blog:
* XSS (pers, user-inter) by ged_
* XSS (non-pers) by Anno & Tracerout
* XSS (pers) by Anno & Tracerout
* Blind SQLI by Sławomir Błażek
* XSS (pers) by Sławomir Błażek
// design & art by Xa
// logo font (birdman regular) by utopiafonts / Dale Harris
/* the author and owner of this blog hereby allows anyone to test the security of this blog (on HTTP level only, the server is not mine, so let's leave it alone ;>), and try to break in (including successful breaks) without any consequences of any kind (DoS attacks are an exception here) ... I'll add that I planted in some places funny photos of some kittens, there are 7 of them right now, so have fun looking for them ;> let me know if You find them all, I'll add some congratz message or sth ;> */
Vulns found in blog:
* XSS (pers, user-inter) by ged_
* XSS (non-pers) by Anno & Tracerout
* XSS (pers) by Anno & Tracerout
* Blind SQLI by Sławomir Błażek
* XSS (pers) by Sławomir Błażek
Comments:
Naturalnie nadal możliwe byłoby wstawianie obrazka wielkości np. 1% przydzielonej pracy w nadziei że akurat się żaden sprawdzony piksel tam nie znajdzie, ale przynajmniej nie byłoby takich wielkich połaci z zamienionym całym obrazem ;)
Inny pomysłem jest zapisywanie workerów, która wysyłają źle wyrenderowane fragmenty i ich ukaranie np. poprzez nieprzydzielanie pracy przez jakiś czas albo po prostu disconnect.
Niestety, powiadomienie jest prawidłowe - przez kilka najbliższych tygodni nie będę w stanie zrobić livestreamów (przerwa wakacyjna), więc kolejny stream dopiero we wrześniu.
@Lgeras
Nie no, bzdura - OBJ/MTL obsługuje wystarczająco dużo ficzerów, żeby scena wyglądała podobnie. Problemem nie jest format, tylko to, że eksportery są źle zrobione.
Add a comment: