Jak sprawdzić i udowodnić, że plik STL nie był zmieniony

Druk trójwymiarowy stał się w ostatnich latach nieodłącznym elementem inżynierii, medycyny, produkcji i badań naukowych, a wraz z tym rozwojem pojawiło się pytanie, które zadają sobie inżynierowie, rzeczoznawcy i prawnicy — jak udowodnić, że plik STL nie był modyfikowany od momentu jego utworzenia lub przekazania? Pliki STL, będące standardem dla szybkiego prototypowania, opisują jedynie powierzchnię siatki trójkątów, ale ich pozorna strukturalna prostota nie oznacza, że są odporne na ingerencje. Wystarczy otworzyć model w dowolnym edytorze CAD, przesunąć wierzchołek o ułamek milimetra, wyeksportować ponownie plik i gotowe — wizualnie model wygląda identycznie, natomiast jego cyfrowa struktura jest już inna. Właśnie dlatego intuicja i porównanie wizualne nie wystarczą, a rzetelne udokumentowanie stanu pliku wymaga narzędzi opartych na kryptografii i analizie metadanych, które potrafią obiektywnie porównać dwa zestawy danych bajt po bajcie.

Należy wyraźnie odróżnić techniczne udokumentowanie pliku od wyciągania wniosków prawnych. Kiedy mówimy o udowodnieniu, że plik nie był modyfikowany, w rzeczywistości mówimy o udowodnieniu, że jego cyfrowa zawartość jest bitowo identyczna z wcześniejszą wersją zarejestrowaną w określonym czasie. Zmiana nawet jednego znaku w nagłówku pliku, modyfikacja struktury siatki trójkątów czy po prostu ponowne zapisanie pliku przez inny program zmienia jego sumę kontrolną. Nie oznacza to automatycznie celowego sabotażu — czasem programy CAD dodają własne metadane podczas eksportu lub zmieniają sposób zaokrąglania wartości zmiennoprzecinkowych. Niemniej jednak, z punktu widzenia dowodu technicznego, plik nie jest już w stanie pierwotnym. Aby takiego dowodu dostarczyć, trzeba móc wykazać, w jaki sposób obliczano kryptograficzne odciski palców, jakie metadane wyciągnięto z pliku i kto, kiedy oraz w jakim środowisku te informacje zebrał. Do takich zadań stworzono platformę FilesAudit, która po wgraniu pliku wyciąga jego techniczne metadane, oblicza odpowiednie funkcje skrótu i generuje profesjonalne raporty w formacie PDF, które służą jako obiektywna dokumentacja.

Podstawą każdej weryfikacji integralności pliku STL jest kryptografia, a dokładniej funkcje skrótu takie jak SHA-256, MD5 czy CRC32. Funkcja skrótu to jednostronne przekształcenie dowolnej ilości danych wejściowych na ciąg o stałej długości, który jest unikalny dla danego zestawu danych — w teorii zmiana jednego bitu w pliku STL powoduje całkowitą zmianę wynikowego hasza. Jeśli więc masz oryginalny plik STL z zarejestrowaną sumą SHA-256, a po miesiącu lub roku ktoś kwestionuje jego autentyczność, wystarczy obliczyć sumę kontrolną dla aktualnego pliku i porównać ją z tą zarejestrowaną wcześniej. Jeśli sumy są identyczne, masz techniczny dowód, że plik nie zmienił się ani o jeden bajt. Jeśli sumy się różnią, masz techniczny dowód, że plik uległ modyfikacji. Warto jednak pamiętać, że sam hasz nie mówi nic o tym, co dokładnie zostało zmienione — może to być przesunięcie wierzchołka siatki, zmiana nazwy autora w metadanych nagłówka, dodanie komentarza w pliku binarnym STL, a nawet niewidoczna dla użytkownika zmiana kodowania znaków. Kiedy ktoś pyta, jak sprawdzić czy plik EXE został zmieniony – hash, stosuje się identyczną zasadę — hasz jest dowodem tożsamości lub różnicy, ale nie jest narzędziem do analizy różnic wewnątrz pliku. W przypadku modeli trójwymiarowych najczęściej generuje się sumy kontrolne tuż po eksporcie z systemu CAD, a następnie po każdej istotnej operacji, takiej jak konwersja formatu, naprawa siatki czy uproszczenie geometrii. W ten sposób powstaje łańcuch dowodowy, w którym każdy krok jest udokumentowany i weryfikowalny.

Oprócz samej sumy kontrolnej kluczowa jest analiza metadanych, które mogą dostarczyć cennych wskazówek na temat historii pliku i jego potencjalnych modyfikacji. Pliki STL występują w dwóch podstawowych wariantach: tekstowym (ASCII) i binarnym. W wariancie ASCII można otworzyć plik w edytorze tekstu i przejrzeć jego zawartość linia po linii, gdzie nagłówek zawiera tekst opisowy, a poniżej znajdują się współrzędne wierzchołków każdego trójkąta. W wariancie binarnym nagłówek to 80 bajtów opisu, po których następuje liczba trójkątów i skompresowane dane geometryczne. Choć format STL jest znany z tego, że jest bardzo ubogi w metadane w porównaniu z formatami takimi jak OBJ czy 3MF, to nawet w nim można znaleźć ślady modyfikacji. Na przykład nagłówek pliku binarnego STL często zawiera nazwę programu, w którym plik został utworzony — jeśli nagłówek mówi „SolidWorks” lub „Blender”, a plik rzekomo pochodzi bezpośrednio z programu CATIA, to jest to techniczna przesłanka, że plik mógł być przetworzony lub przekonwertowany. Co więcej, niektóre programy CAD zapisują w nagłówku informacje o dacie i autorze, choć jest to rzadkie i zależy od implementacji eksportu w konkretnym systemie. W przypadku formatu ASCII dodatkowo można sprawdzić spójność formatowania — różne programy mają różne style zapisu współrzędnych, różne liczby miejsc po przecinku, różne białe znaki i komentarze. Jeśli w jednym pliku widać dwa różne style formatowania, może to sugerować, że plik był edytowany ręcznie lub łączony z innych źródeł. Dla szczegółowego przewodnika po tym, jakie informacje można wyciągnąć z tych specyficznych plików, warto zajrzeć na stronę STL metadata, która opisuje dokładną strukturę i potencjalne pola analizy.

W praktyce inżynierskiej i sądowej sama analiza pojedynczego pliku często nie wystarcza — trzeba porównać go z plikiem referencyjnym, który uważa się za oryginał lub wzorzec. Ta potrzeba pojawia się na przykład w sporach o własność intelektualną, gdzie strona pozwana twierdzi, że model STL przesłany do produkcji jest identyczny z modelem zarejestrowanym w bazie danych projektowej, a powód twierdzi, że model został zmieniony, by ukryć kopiowanie geometrii. W takich sytuacjach generuje się sumy kontrolne dla obu plików i porównuje je — jeśli są identyczne, sprawa jest prosta. Jeśli sumy się różnią, należy przejść do analizy strukturalnej. Narzędzia takie jak FilesAudit pozwalają wygenerować raporty dla obu plików, w których zawarte są sumy kontrolne, podstawowe metadane, rozmiar pliku, liczba trójkątów, skrajne wierzchołki siatki i inne techniczne właściwości. Porównanie tych dwóch raportów pozwala stwierdzić, czy różnice są istotne technicznie — na przykład czy liczba trójkątów jest inna, czy środek masy modelu się przesunął, czy bounding box ma inne wymiary. Taka analiza nie odpowie na pytanie, kto zmienił plik i kiedy, ale dostarczy obiektywnych danych na temat tego, co technicznie różni dwa pliki. W niektórych przypadkach można nawet zrekonstruować, jakie operacje zostały wykonane — zmiana liczby trójkątów wskazuje na ponowne przekątkowaniu (remeshing) siatki, zmiana nagłówka bez zmiany geometrii wskazuje na ponowny zapis w innym programie, a zmiana współrzędnych bez zmiany topologii wskazuje na transformację przestrzenną, taką jak przesunięcie, obrót czy skalowanie. Wszystkie te wnioski muszą być jednak formułowane ostrożnie, jako techniczne obserwacje, a nie kategoryczne oskarżenia.

Do rozważań na temat kompleksowej weryfikacji plików przestrzennych warto dołączyć szerszy kontekst analizy dowodów cyfrowych w innych formatach, gdzie ślady modyfikacji mogą być znacznie bogatsze i łatwiejsze do wykrycia. Przykładowo, formaty obrazów rastrowych często zawierają bogate metadane EXIF, GPS czy XMP, które mogą zdradzać datę, godzinę, urządzenie i oprogramowanie użyte do zapisu lub modyfikacji pliku, co pozwala na jak udowodnić, że zdjęcie nie było retuszowane w sposób znacznie bardziej szczegółowy niż w przypadku ubogich w metadane plików STL. Podobnie w przypadku dokumentów tekstowych, analizując metadane plików DOCX, można często wyciągnąć nazwę użytkownika, historię rewizji, daty modyfikacji i inne informacje, które w pliku STL po prostu nie istnieją. Ta różnica wynika z samej natury formatu — STL został stworzony w 1987 roku dla stereolitografii i nigdy nie był projektowany jako format archiwizacyjny bogaty w metadane. Jego jedynym celem było opisanie powierzchni trójwymiarowej dla maszyn druku 3D. Dlatego w weryfikacji plików STL szczególnie ważna