Reverse engineering oprogramowania a prawo — czy korzystanie z REA jest legalne?

Narzędzia wykorzystujące sztuczną inteligencję coraz mocniej zmieniają sposób, w jaki programiści analizują cudze oprogramowanie. Jeszcze kilka lat temu reverse engineering wymagał znajomości deassemblerów, debuggerów, analizy binarnej oraz narzędzi takich jak IDA, Ghidra czy Hopper. Obecnie pojawiają się rozwiązania, które łączą klasyczne narzędzia inżynierii odwrotnej z agentami AI i pozwalają użytkownikowi zadawać pytania dotyczące działania aplikacji niemal w naturalnym języku. Jednym z takich projektów jest REA, czyli Reverse Engineer Anything, rozwijany jako otwartoźródłowa platforma umożliwiająca agentom analizowanie aplikacji, plików binarnych, kodu JavaScript, aplikacji Electron, bibliotek .NET czy zachowania programu w czasie jego działania. Sam projekt reklamowany jest między innymi możliwością zbadania funkcji występującej w aplikacji bez dostępu do jej kodu źródłowego, wyjaśnienia sposobu jej działania i wykorzystania zdobytej wiedzy przy budowie własnego rozwiązania. (GitHub)

Taka możliwość niemal automatycznie prowadzi do pytania, czy korzystanie z podobnego narzędzia jest legalne. Odpowiedź nie brzmi ani „tak”, ani „nie”. Reverse engineering jako taki nie jest w polskim i unijnym prawie zakazany, a w określonych sytuacjach ustawodawca wprost zezwala na analizowanie sposobu działania programu komputerowego, a nawet na jego dekompilację. Granica legalności zależy jednak od tego, kto dokonuje analizy, czy posiada legalny dostęp do programu, jakie czynności techniczne wykonuje, po co pozyskuje informacje oraz w jaki sposób później je wykorzystuje. Zupełnie inaczej należy ocenić analizę własnej aplikacji albo programu klienta w ramach zleconego audytu bezpieczeństwa, inaczej badanie konkurencyjnego programu w celu zapewnienia interoperacyjności, a jeszcze inaczej próbę obejścia mechanizmu licencyjnego, systemu anti-cheat albo zabezpieczeń chroniących niedostępne publicznie API.

Sam fakt, że program taki jak REA można pobrać z GitHub, nie oznacza więc ani że każde jego użycie jest dozwolone, ani że samo posiadanie narzędzia jest nielegalne. W przypadku REA autorzy zresztą wyraźnie deklarują, że projekt przeznaczony jest do zgodnej z prawem analizy, security research, badania malware, analizy incydentów, zapewniania interoperacyjności, edukacji, CTF, ochrony oprogramowania oraz badania systemów, których użytkownik jest właścicielem albo do których analizy został upoważniony. Jednocześnie dokumentacja projektu wprost odcina się od obchodzenia DRM, zabezpieczeń licencyjnych, anti-cheatów, zabezpieczeń dostępu i uwierzytelniania, tworzenia cheatów oraz kopiowania chronionego oprogramowania. (GitHub)

Czym właściwie jest reverse engineering?

Reverse engineering, czyli inżynieria odwrotna, oznacza analizowanie gotowego produktu w celu ustalenia sposobu jego działania, konstrukcji albo zasad, na których został oparty. W przypadku oprogramowania może przyjmować bardzo różne formy. Czasami będzie to zwykłe obserwowanie reakcji aplikacji na określone działania użytkownika, czasami analiza komunikacji sieciowej, struktury plików albo formatów danych, a w bardziej zaawansowanych przypadkach deasemblacja lub dekompilacja kodu wykonywalnego i analiza działania programu w pamięci.

Z prawnego punktu widzenia te czynności nie powinny być wrzucane do jednego worka. Samo uruchomienie legalnie posiadanej aplikacji i obserwowanie, w jaki sposób reaguje ona na konkretne dane wejściowe, znajduje się w zupełnie innym miejscu niż przełamanie zabezpieczenia serwera w celu uzyskania informacji, do których użytkownik normalnie nie miałby dostępu. Również dekompilacja programu nie jest automatycznie nielegalna, ale ustawodawca w określonych przypadkach uzależnia jej dopuszczalność od spełnienia konkretnych warunków.

Dlatego oceniając narzędzie takie jak REA nie należy pytać wyłącznie „czy REA jest legalne?”. Właściwe pytanie brzmi: „czy konkretna czynność wykonana za pomocą REA jest legalna w określonym stanie faktycznym?”.

Samo narzędzie REA nie jest nielegalne

REA jest projektem open source, a kod tworzony w ramach projektu został udostępniony na licencji MIT. Oznacza to możliwość korzystania, modyfikowania i rozpowszechniania samego kodu REA zgodnie z warunkami tej licencji. Nie oznacza to jednak uzyskania jakichkolwiek praw do programów analizowanych przy jego wykorzystaniu. Autorzy projektu wyraźnie zwracają na to uwagę, wskazując między innymi, że użytkownik musi posiadać odpowiednie licencje na komercyjne narzędzia wykorzystywane przez REA, takie jak IDA Pro, Hex-Rays, Hopper czy JEB, a samo REA nie zapewnia licencji ani prawa do korzystania z zewnętrznych produktów. (GitHub)

Jest to rozróżnienie mające znaczenie również poza REA. Legalność programu służącego do analizy oprogramowania oraz legalność konkretnej analizy są dwiema odrębnymi kwestiami. Debugger może być wykorzystywany przez programistę do naprawienia własnej aplikacji, przez badacza bezpieczeństwa do analizy malware albo przez inną osobę do obejścia zabezpieczeń komercyjnego programu. To samo narzędzie techniczne może zatem uczestniczyć zarówno w całkowicie legalnej działalności, jak i w działaniu naruszającym prawo.

Polskie prawo wprost pozwala badać działanie programu

Najważniejszym przepisem z punktu widzenia reverse engineeringu jest art. 75 ustawy o prawie autorskim i prawach pokrewnych. Zgodnie z nim osoba posiadająca prawo do korzystania z egzemplarza programu komputerowego może bez zgody uprawnionego obserwować, badać i testować funkcjonowanie programu w celu poznania idei i zasad, na których opiera się jego działanie, o ile dokonuje tego podczas takich czynności jak wprowadzanie, wyświetlanie, stosowanie, przekazywanie lub przechowywanie programu, do których jest uprawniona. (Ustawa prawo autorskie i prawa pokrewne)

Jest to bardzo istotna regulacja. Oznacza bowiem, że prawo autorskie chroniące program komputerowy nie daje jego producentowi absolutnego monopolu na wiedzę dotyczącą sposobu działania aplikacji. Legalny użytkownik może program uruchamiać, obserwować jego zachowanie, przeprowadzać testy i na tej podstawie ustalać idee oraz zasady leżące u podstaw poszczególnych mechanizmów.

W praktyce właśnie w tym miejscu może mieścić się znaczna część zastosowań narzędzi takich jak REA. Jeżeli przedsiębiorca legalnie korzysta z programu i chce ustalić na przykład sposób komunikowania się aplikacji z plikami, strukturę danych, zachowanie określonej funkcji albo zasadę działania mechanizmu potrzebną do stworzenia interoperacyjnego rozwiązania, samo użycie automatycznego narzędzia wspomagającego analizę nie przesądza o naruszeniu prawa autorskiego.

Co szczególnie ważne, art. 76 ustawy stanowi, że postanowienia umów sprzeczne między innymi z art. 75 ust. 2 i 3 są nieważne. Producent programu nie może zatem poprzez zwykły zapis w licencji całkowicie odebrać użytkownikowi tych uprawnień, które ustawodawca nadał mu w sposób bezwzględnie obowiązujący.

Czy regulamin programu może zabronić reverse engineeringu?

W licencjach oprogramowania bardzo często można znaleźć postanowienia zabraniające reverse engineeringu, dekompilacji lub deasemblacji. Samo występowanie takiego postanowienia nie oznacza jednak, że w każdych okolicznościach będzie ono skuteczne.

Polskie prawo wprost uznaje za nieważne postanowienia umów sprzeczne z określonymi wyjątkami przewidzianymi w art. 75 ustawy o prawie autorskim. Jeżeli więc użytkownik wykonuje czynności mieszczące się w ustawowym prawie do obserwowania, badania i testowania programu albo w dozwolonej dekompilacji na potrzeby interoperacyjności, zapis umowny nie może po prostu wyłączyć tych ustawowych praw.

Nie oznacza to jednak, że regulamin nie ma żadnego znaczenia. Po pierwsze, art. 75 ust. 1 dotyczący czynności koniecznych do korzystania z programu zgodnie z jego przeznaczeniem, w tym poprawiania błędów, został skonstruowany z zastrzeżeniem „jeżeli umowa nie stanowi inaczej”. Po drugie, umowa może regulować dostęp do określonych serwerów, danych, interfejsów, środowisk i informacji poufnych. Po trzecie, określone ograniczenia mogą mieć znaczenie z punktu widzenia tajemnicy przedsiębiorstwa lub odpowiedzialności kontraktowej nawet w sytuacji, w której samo badanie funkcji programu nie narusza prawa autorskiego.

Nie można więc stosować prostej zasady, zgodnie z którą każde postanowienie „no reverse engineering” jest automatycznie nieważne. Trzeba najpierw ustalić, jakiej czynności dotyczy oraz czy konkretna czynność mieści się w bezwzględnie chronionym wyjątku ustawowym.

Obserwowanie programu to nie to samo co dekompilacja

Istotne jest również rozróżnienie zwykłej analizy zachowania programu od dekompilacji. Ustawodawca znacznie szerzej pozwala legalnemu użytkownikowi obserwować, badać i testować program niż zwielokrotniać kod oraz tłumaczyć jego formę.

Dekompilacja jest dopuszczalna bez zezwolenia uprawnionego wtedy, gdy jest niezbędna do uzyskania informacji koniecznych do osiągnięcia współdziałania niezależnie stworzonego programu z innymi programami. Ustawa wymaga dodatkowo, aby działała osoba uprawniona do korzystania z programu albo osoba działająca na jej rzecz, aby potrzebne informacje nie były wcześniej łatwo dostępne oraz aby analiza obejmowała wyłącznie te części oryginalnego programu, które są konieczne do osiągnięcia interoperacyjności.

Informacje pozyskane w ten sposób nie mogą następnie zostać wykorzystane w dowolnym celu. Ustawa zabrania wykorzystywania ich do innych celów niż osiągnięcie współdziałania, przekazywania ich innym osobom poza sytuacją, gdy jest to potrzebne do interoperacyjności, oraz wykorzystywania ich do tworzenia i wprowadzania do obrotu programu o istotnie podobnej formie wyrażenia albo podejmowania innych działań naruszających prawa autorskie.

To właśnie dlatego użycie REA do ustalenia, jak skomunikować własną aplikację z legalnie używanym programem, może być oceniane zupełnie inaczej niż wykorzystanie narzędzia do odtworzenia jak największej części kodu konkurencyjnego produktu.

Czy można skopiować funkcję z konkurencyjnego programu?

To jedno z najciekawszych zagadnień w kontekście REA, ponieważ projekt przedstawia możliwość zbadania interesującej funkcji aplikacji, zrozumienia jej działania i zbudowania podobnego rozwiązania we własnym produkcie.

Samo odtworzenie funkcjonalności programu nie musi oznaczać naruszenia prawa autorskiego. Trybunał Sprawiedliwości Unii Europejskiej w głośnej sprawie SAS Institute przeciwko World Programming wskazał, że funkcjonalność programu komputerowego, język programowania oraz format plików danych wykorzystywany przez program nie stanowią same przez się formy wyrażenia programu chronionej szczególnym reżimem prawa autorskiego dotyczącym oprogramowania. W sprawie tej konkurencyjna firma stworzyła program realizujący podobne funkcje bez dostępu do kodu źródłowego pierwotnego produktu, a Trybunał wyraźnie odróżnił niechronione idee i funkcjonalności od chronionej formy ich wyrażenia. (Wyrok SAS Institute Inc. przeciwko World Programming Ltd.)

Nie oznacza to prawa do kopiowania wszystkiego, co uda się zobaczyć podczas analizy. Chroniony może być konkretny kod źródłowy lub wynikowy, teksty, grafiki, dokumentacja, oryginalne elementy interfejsu oraz inne twórcze elementy. TSUE wskazywał również, że graficzny interfejs użytkownika wprawdzie nie jest chroniony jako forma wyrażenia programu komputerowego, ale może korzystać ze zwykłej ochrony prawa autorskiego, jeżeli stanowi własną twórczość intelektualną autora.

Granica przebiega więc pomiędzy odtworzeniem pomysłu lub funkcjonalności a kopiowaniem chronionej formy ich realizacji. Można stworzyć własną aplikację posiadającą funkcję importu dokumentów działającą podobnie jak rozwiązanie konkurenta. Nie oznacza to jednak automatycznie prawa do skopiowania jego kodu, ikon, grafik, tekstów, charakterystycznego interfejsu czy innych twórczych elementów produktu.

Clean room reverse engineering jako sposób ograniczenia ryzyka

W bardziej wrażliwych projektach warto rozważyć model określany jako clean room reverse engineering. Polega on na oddzieleniu procesu analizy konkurencyjnego rozwiązania od procesu tworzenia własnego kodu. Jeden zespół bada legalnie dostępny program i przygotowuje dokumentację opisującą jego funkcje, zachowanie, protokół lub wymagania interoperacyjności. Drugi zespół, który nie ma kontaktu z kodem ani chronionymi elementami analizowanego programu, tworzy własną implementację wyłącznie na podstawie takiej specyfikacji.

Takie podejście nie daje automatycznego „certyfikatu legalności”, ale może znacząco ograniczyć ryzyko zarzutu, że nowy produkt jest kopią chronionego kodu. Ma to szczególne znaczenie wtedy, gdy firma chce stworzyć kompatybilny produkt konkurencyjny albo odtworzyć określoną funkcję istniejącego rozwiązania.

Narzędzia AI dodatkowo komplikują ten problem, ponieważ jeden agent może jednocześnie analizować oryginalny program i generować kod implementujący podobne rozwiązanie. Jeżeli przedsiębiorca chce ograniczyć ryzyko, warto rozdzielić te etapy również technicznie oraz zachować dokumentację pokazującą, jakie informacje zostały uzyskane podczas analizy i na podstawie czego powstała nowa implementacja.

Reverse engineering a tajemnica przedsiębiorstwa

Drugim bardzo istotnym obszarem jest ochrona tajemnicy przedsiębiorstwa. Co ciekawe, również w tym przypadku ustawodawca nie zakazuje automatycznie reverse engineeringu.

Art. 11 ustawy o zwalczaniu nieuczciwej konkurencji przewiduje, że pozyskanie informacji stanowiących tajemnicę przedsiębiorstwa nie jest czynem nieuczciwej konkurencji, jeżeli nastąpiło wskutek niezależnego odkrycia lub wytworzenia albo obserwacji, badania, rozłożenia na części lub testowania przedmiotu dostępnego publicznie lub posiadanego zgodnie z prawem, pod warunkiem że uprawnienie osoby pozyskującej informacje nie było w chwili ich pozyskania ograniczone. (Ustawa o zwalczaniu nieuczciwej konkurencji)

To bardzo ważna regulacja z perspektywy klasycznego reverse engineeringu produktu. Jeżeli przedsiębiorca legalnie kupił urządzenie albo legalnie posiada produkt i nie wiąże go skuteczne ograniczenie dotyczące pozyskania takich informacji, samo rozłożenie produktu na części i ustalenie jego konstrukcji może nie naruszać przepisów dotyczących tajemnicy przedsiębiorstwa.

Tutaj jednak widać istotną różnicę względem przepisów o programach komputerowych. W przypadku tajemnicy przedsiębiorstwa znaczenie ma to, czy uprawnienie do pozyskania informacji było ograniczone. Dlatego NDA, warunki licencji, umowa wdrożeniowa albo inna umowa zawarta z właścicielem technologii mogą mieć bardzo duże znaczenie.

Posiadanie programu nie oznacza prawa do wszystkiego

Autorzy REA trafnie zwracają uwagę, że publiczna dostępność aplikacji, posiadanie jej pliku albo dostęp do endpointu debugującego nie oznaczają same przez się uprawnienia do wykonania każdej możliwej operacji.

To rozróżnienie jest szczególnie istotne w przypadku nowoczesnych aplikacji internetowych. Użytkownik może być uprawniony do korzystania z frontendu aplikacji oraz własnego konta, ale nie oznacza to automatycznie prawa do uzyskiwania dostępu do administracyjnej części systemu, zasobów innych klientów, wewnętrznych API albo endpointów zabezpieczonych mechanizmem autoryzacji.

Jeżeli analiza polega na obserwowaniu ruchu generowanego przez własną aplikację i własne konto, ryzyko prawne może być stosunkowo ograniczone. Jeżeli jednak użytkownik zaczyna modyfikować tokeny, omijać kontrolę uprawnień albo wykorzystywać błąd w celu dotarcia do danych, których normalnie nie powinien widzieć, problem przestaje dotyczyć wyłącznie prawa autorskiego.

Reverse engineering może wejść w obszar prawa karnego

Najpoważniejsza granica pojawia się wtedy, gdy analiza przechodzi w nieuprawniony dostęp do systemu lub informacji. Art. 267 Kodeksu karnego penalizuje między innymi uzyskanie bez uprawnienia dostępu do informacji poprzez przełamanie lub ominięcie zabezpieczenia, uzyskanie bez uprawnienia dostępu do całości albo części systemu informatycznego oraz posługiwanie się oprogramowaniem w celu uzyskania informacji, do której dana osoba nie jest uprawniona.

Z tego powodu korzystanie z REA do analizy własnego lokalnego programu różni się zasadniczo od używania go do badania niedostępnej części infrastruktury usługodawcy. Narzędzie może pomóc zidentyfikować endpoint albo mechanizm autoryzacyjny, ale samo odkrycie jego istnienia nie oznacza prawa do ominięcia zabezpieczeń.

W przypadku testów bezpieczeństwa zdecydowanie najbezpieczniejszą sytuacją jest uzyskanie wyraźnego upoważnienia właściciela systemu. Powinno ono określać zakres testów, systemy objęte zgodą, dopuszczalne techniki, okres wykonywania testu oraz zasady postępowania z uzyskanymi danymi. Pozwala to uniknąć późniejszego sporu dotyczącego tego, czy tester miał prawo przeprowadzić konkretną czynność.

Czy polskie prawo chroni ethical hacking?

Kodeks karny przewiduje szczególną regulację dotyczącą działań podejmowanych w celu zabezpieczania systemów. Art. 269c wskazuje, że nie podlega karze za określone przestępstwa osoba, która działa wyłącznie w celu zabezpieczenia systemu informatycznego, systemu teleinformatycznego lub sieci albo opracowania metody takiego zabezpieczenia, niezwłocznie zawiadamia dysponenta o ujawnionych zagrożeniach, a jej działanie nie narusza interesu publicznego lub prywatnego i nie wyrządza szkody.

Nie jest to jednak ogólny immunitet dla każdego badacza bezpieczeństwa. Przepis odnosi się tylko do określonych typów czynów, a warunki jego zastosowania są ścisłe. Sam argument „robiłem security research” nie daje automatycznie prawa do dowolnego penetrowania cudzej infrastruktury.

Z punktu widzenia przedsiębiorcy lub profesjonalnego pentestera znacznie bezpieczniejszą podstawą działania pozostaje zgoda właściciela systemu albo jasno określony program bug bounty.

REA a łamanie DRM, licencji i anti-cheatów

Szczególnie wysokie ryzyko powstaje, gdy reverse engineering służy obchodzeniu zabezpieczeń programu. Ustawa o prawie autorskim pozwala uprawnionemu żądać od użytkownika programu zniszczenia posiadanych środków technicznych, w tym programów komputerowych, których jedynym przeznaczeniem jest ułatwianie niedozwolonego usuwania lub obchodzenia technicznych zabezpieczeń programu.

W praktyce analiza zmierzająca do poznania mechanizmu licencyjnego w celach edukacyjnych może wymagać zupełnie innej oceny niż stworzenie patcha wyłączającego weryfikację licencji i rozpowszechnianie go w internecie. Podobnie jest z systemami anti-cheat. Badanie ich działania na potrzeby bezpieczeństwa własnego produktu może być legalne, podczas gdy stworzenie narzędzia umożliwiającego oszukiwanie w grze online może naruszać zarówno umowę z operatorem, jak i inne przepisy.

Autorzy REA sami wprost wskazują, że projekt nie wspiera obchodzenia DRM, mechanizmów licencyjnych, anti-cheatów ani zabezpieczeń dostępu.

Analiza aplikacji internetowej jest bardziej ryzykowna niż lokalnego pliku

REA pozwala analizować nie tylko natywne pliki binarne, lecz również JavaScript, aplikacje Electron i strony internetowe. Z prawnego punktu widzenia ma to znaczenie, ponieważ analiza lokalnie posiadanego pliku często ogranicza się do działań wykonywanych na własnym urządzeniu, podczas gdy analiza aplikacji webowej może powodować interakcję z cudzym systemem.

Przeglądanie kodu JavaScript przesłanego przez serwer do przeglądarki nie jest tym samym co próba wywoływania ukrytych endpointów administracyjnych. Odczytanie publicznej struktury requestu nie jest tym samym co wykorzystanie jej do pobrania danych innych użytkowników. Podobnie znalezienie w kodzie frontendu adresu API nie oznacza automatycznie, że użytkownik posiada uprawnienie do wykonywania wszystkich możliwych zapytań.

Im bardziej analiza wychodzi poza własny egzemplarz programu i zaczyna ingerować w działający system zewnętrzny, tym większego znaczenia nabierają przepisy prawa karnego, regulamin usługi i zakres faktycznego uprawnienia użytkownika.

A co z kopiowaniem konkurencyjnego produktu?

REA może być atrakcyjne dla przedsiębiorcy, który widzi interesującą funkcję w konkurencyjnym produkcie i chciałby dowiedzieć się, w jaki sposób działa. Nie oznacza to, że każdy taki przypadek jest zakazany.

Prawo autorskie chroni konkretny sposób wyrażenia programu, ale nie daje monopolu na sam pomysł biznesowy lub funkcję. Jeżeli jedna aplikacja posiada mechanizm automatycznej organizacji dokumentów, inny przedsiębiorca może stworzyć własne rozwiązanie realizujące tę samą funkcję. Problem pojawia się wtedy, gdy zamiast niezależnej implementacji następuje kopiowanie chronionego kodu albo innych twórczych elementów.

Granica może być szczególnie trudna do ustalenia w przypadku wykorzystania AI. Agent może po przeanalizowaniu programu wygenerować kod bardzo podobny do rozwiązania pierwotnego. Z perspektywy firmy wykorzystującej takie narzędzie rozsądnym rozwiązaniem jest dokumentowanie procesu tworzenia własnej implementacji i unikanie poleceń zmierzających do możliwie dokładnego odtworzenia kodu źródłowego konkurenta.

Im bardziej rezultat jest niezależnym rozwiązaniem tej samej funkcji, tym mniejsze ryzyko. Im bardziej przypomina rekonstrukcję konkretnej formy programu, tym bardziej ryzyko rośnie.

Czy można analizować aplikację mobilną konkurenta?

Sam fakt pobrania legalnej aplikacji z App Store lub Google Play nie powoduje, że jej użytkownik otrzymuje prawo do dowolnego kopiowania kodu. Jednocześnie legalny użytkownik może korzystać z ustawowych uprawnień do obserwowania i badania programu w granicach art. 75 prawa autorskiego.

Można więc wyobrazić sobie legalną analizę zachowania aplikacji mobilnej w celu ustalenia, jak działa określona funkcja albo jak aplikacja komunikuje się z kompatybilnym urządzeniem. Zupełnie inaczej należy oceniać obejście autoryzacji i uzyskanie dostępu do danych innych użytkowników.

W przypadku aplikacji mobilnych dodatkowo znaczenie mogą mieć warunki App Store, Google Play oraz warunki licencyjne samego producenta programu. Nie każda sankcja za ich naruszenie będzie wynikała z prawa autorskiego. Czasami konsekwencją może być rozwiązanie umowy, blokada konta albo roszczenie kontraktowe.

Czy można reverse engineerować własne oprogramowanie?

To najmniej problematyczna sytuacja. Jeżeli przedsiębiorca posiada autorskie prawa majątkowe do programu oraz kontroluje analizowane środowisko, może korzystać z REA między innymi do audytu bezpieczeństwa, dokumentowania starego systemu, migracji legacy software, ustalania działania nieudokumentowanych komponentów albo analizy aplikacji stworzonej wiele lat wcześniej.

Trzeba jednak pamiętać, że nawet we własnym produkcie mogą występować elementy należące do osób trzecich. Biblioteki komercyjne, SDK, komponenty OEM, sterowniki i inne zależności mogą być objęte odrębnymi licencjami. Fakt, że przedsiębiorca jest właścicielem własnego kodu, nie daje automatycznie prawa do dowolnego reverse engineeringu wszystkich dołączonych komponentów.

Podobna ostrożność jest potrzebna, gdy software house analizuje system klienta. Umowa powinna jednoznacznie określać zakres upoważnienia, szczególnie jeżeli system zawiera elementy dostarczone przez inne firmy.

Audyt bezpieczeństwa na zlecenie klienta

REA może być bardzo przydatnym narzędziem w profesjonalnym security research i audytach bezpieczeństwa. W tym przypadku kluczowym zabezpieczeniem prawnym powinien być jednak zakres upoważnienia.

Nie wystarczy ogólne stwierdzenie, że wykonawca ma „sprawdzić bezpieczeństwo aplikacji”. Jeżeli test wymaga dekompilacji aplikacji, analizy API, testowania mechanizmu autoryzacji, uzyskiwania dostępu do środowiska produkcyjnego albo wykonywania prób mogących wpłynąć na dostępność systemu, warto wskazać to wyraźnie w umowie lub Rules of Engagement.

Szczególnie istotne jest ustalenie, czy można testować produkcję, czy wolno wykorzystywać konta innych niż utworzone na potrzeby testu, czy można pobierać dane, w jaki sposób należy je zabezpieczyć oraz kiedy mają zostać usunięte.

W profesjonalnym audycie odpowiednia dokumentacja upoważnienia jest równie ważna jak samo narzędzie techniczne.

Odkrycie podatności nie daje prawa do jej wykorzystania

Podczas reverse engineeringu można przypadkowo znaleźć lukę bezpieczeństwa. Samo odkrycie podatności nie oznacza jednak prawa do jej dalszego wykorzystywania.

Jeżeli podczas analizy legalnie posiadanej aplikacji użytkownik zauważy, że odpowiednia modyfikacja requestu pozwala uzyskać cudze dane, powinien bardzo ostrożnie podchodzić do prób potwierdzania problemu. Przeprowadzenie jednej operacji na własnych danych może wyglądać zupełnie inaczej prawnie niż masowe pobieranie informacji należących do innych klientów.

Właśnie dlatego programy bug bounty określają zakres dopuszczalnych testów i zasady responsible disclosure. Jeżeli producent nie prowadzi programu bug bounty, warto ograniczać zakres działań do minimum potrzebnego do udokumentowania problemu i możliwie szybko poinformować dysponenta systemu.

Licencja MIT REA nie legalizuje analizy innych programów

Fakt, że REA jest rozpowszechniane na licencji MIT, bywa łatwy do błędnego zinterpretowania. Licencja dotyczy samego kodu REA. Nie rozciąga się na analizowany program, dane, kod wynikowy otrzymany z dekompilatora ani komercyjne narzędzia podłączone do platformy.

Jeżeli REA współpracuje z IDA Pro, Hopperem albo JEB, użytkownik nadal musi posiadać prawo do korzystania z tych produktów. Autorzy projektu wyraźnie zastrzegają, że REA nie daje żadnej dodatkowej licencji do komercyjnych narzędzi, a korzystanie z nielegalnych kopii, cudzych kluczy czy obchodzenie ograniczeń licencyjnych nie jest autoryzowane.

Podobnie wynik dekompilacji nie staje się „open source” tylko dlatego, że został wygenerowany przez otwartoźródłowy program.

Wynik wygenerowany przez AI nie jest automatycznie bezpieczny prawnie

Automatyzacja reverse engineeringu powoduje jeszcze jeden problem. Użytkownik może nie wiedzieć dokładnie, jakie czynności wykonał agent.

Jeżeli tradycyjny analityk ręcznie uruchamia kolejne polecenia debuggera, łatwiej kontroluje zakres analizy. Agent AI może natomiast autonomicznie wykonywać serię działań prowadzących do celu. Z prawnego punktu widzenia użytkownik nadal powinien kontrolować, czy agent nie przekracza zakresu posiadanego upoważnienia.

Samo stwierdzenie „AI zrobiła to automatycznie” nie powinno być traktowane jako skuteczne przeniesienie odpowiedzialności. Autorzy REA również wskazują, że użytkownik odpowiada za polecenia, konfiguracje, skrypty i działania, które zleca agentowi.

Przedsiębiorstwa wykorzystujące podobne narzędzia powinny więc traktować agentów reverse engineering nie jako neutralny „podgląd kodu”, lecz jako narzędzia posiadające potencjalnie daleko idące możliwości techniczne.

Jak bezpiecznie korzystać z REA w firmie?

Najbezpieczniejszy model polega na wcześniejszym ustaleniu podstawy prawnej do analizy. Jeżeli analizowane jest własne oprogramowanie, należy sprawdzić prawa do komponentów zewnętrznych. Jeżeli badany jest produkt klienta, warto uzyskać pisemne upoważnienie. Jeżeli analizowany jest program konkurencyjny, należy ustalić, czy posiadany egzemplarz jest legalny, które czynności mieszczą się w art. 75 prawa autorskiego, czy potrzebna jest dekompilacja oraz do czego mają zostać wykorzystane pozyskane informacje.

W projektach interoperacyjności należy ograniczyć zakres analizy do informacji rzeczywiście potrzebnych do osiągnięcia współdziałania. Przy tworzeniu konkurencyjnego rozwiązania warto oddzielić analizę od implementacji, aby móc wykazać niezależne stworzenie kodu. W security research trzeba natomiast bardzo dokładnie ustalić zakres zgody i nie wychodzić poza objęte nią systemy.

Szczególnie ostrożnie należy traktować omijanie zabezpieczeń technicznych, mechanizmów licencyjnych, uwierzytelniania i kontroli dostępu. W tych sytuacjach potencjalny problem może już wykraczać poza odpowiedzialność cywilną i wejść w obszar prawa karnego.

Czy przedsiębiorca powinien stworzyć politykę reverse engineeringu i security research?

W firmach technologicznych może mieć to coraz większy sens. Programiści korzystają z Ghidry, debuggerów, narzędzi AI i agentów kodujących często bez udziału działu prawnego. Tymczasem jedno polecenie może prowadzić od legalnej analizy własnej biblioteki do czynności dotyczących zewnętrznego systemu.

Wewnętrzna polityka może określać, jakie programy wolno analizować, kiedy potrzebna jest zgoda przełożonego lub klienta, jak dokumentować podstawę prawną, jakie informacje mogą być przechowywane oraz kiedy analiza powinna zostać przerwana.

Szczególnie przydatne może być wymaganie utworzenia krótkiego „scope document” przed rozpoczęciem projektu. Powinien on wskazywać właściciela analizowanego systemu, podstawę dostępu, cel analizy, dopuszczalne narzędzia i zakres wykorzystania wyników. Taka dokumentacja może później mieć bardzo duże znaczenie w przypadku sporu.

Gdzie przebiega praktyczna granica legalności?

Najprostszy sposób oceny polega na zadaniu kilku kolejnych pytań. Czy posiadam legalny dostęp do programu? Czy analizuję działania, które normalnie jestem uprawniony wykonywać? Czy omijam zabezpieczenia albo próbuję uzyskać dostęp do danych lub funkcji, do których nie jestem uprawniony? Czy dekompilacja jest rzeczywiście potrzebna do interoperacyjności albo innego dopuszczalnego celu? Czy kopiuję kod i inne chronione elementy, czy jedynie poznaję funkcjonalność? Czy wiąże mnie NDA albo skuteczne ograniczenie dotyczące tajemnicy przedsiębiorstwa? Czy analiza dotyczy lokalnego egzemplarza programu, czy prowadzi do interakcji z cudzym systemem?

Im więcej odpowiedzi przesuwa się w stronę nieuprawnionego dostępu, obchodzenia zabezpieczeń i kopiowania konkretnego rozwiązania, tym większe ryzyko prawne. Im bardziej analiza dotyczy legalnie posiadanego programu, interoperacyjności, własnego bezpieczeństwa, niezależnego stworzenia nowego rozwiązania albo audytu wykonywanego za zgodą właściciela, tym mocniejsza jest podstawa do uznania działań za zgodne z prawem.

REA pokazuje, że reverse engineering stanie się znacznie bardziej dostępny

Najciekawszym aspektem takich projektów jak REA nie jest samo pojawienie się kolejnego dekompilatora. Narzędzia używane przez REA istniały od lat. Zmiana polega na tym, że agent AI może je łączyć, interpretować wyniki i prowadzić użytkownika przez analizę, która wcześniej wymagała specjalistycznej wiedzy.

To może spowodować gwałtowny wzrost wykorzystania reverse engineeringu w zwykłym developmentcie. Programista chcący zrozumieć działanie nieudokumentowanej aplikacji nie będzie musiał samodzielnie uczyć się asemblera i obsługi kilku specjalistycznych programów. Wystarczy agent, któremu wskaże cel.

Z prawnego punktu widzenia oznacza to jednak, że zagadnienia dotychczas kojarzone głównie z ekspertami bezpieczeństwa zaczną dotyczyć zwykłych software house’ów i zespołów developerskich. Firmy będą musiały określić, kiedy ich programiści mogą analizować cudze aplikacje i w jakim zakresie mogą wykorzystywać pozyskane informacje.

Podsumowanie

Korzystanie z REA lub podobnego narzędzia nie jest samo w sobie nielegalne. Polski i unijny system prawa wprost dopuszczają określone formy reverse engineeringu, w tym obserwowanie, badanie i testowanie programu przez osobę posiadającą prawo do korzystania z jego egzemplarza. W szczególnych warunkach dopuszczalna jest również dekompilacja potrzebna do osiągnięcia interoperacyjności.

Legalność kończy się jednak tam, gdzie użytkownik przestaje analizować legalnie dostępny program, a zaczyna uzyskiwać bez uprawnienia dostęp do cudzych systemów lub informacji, obchodzić zabezpieczenia, kopiować chroniony kod albo wykorzystywać pozyskane informacje w sposób wykraczający poza ustawowe wyjątki. Odrębną warstwę stanowią zobowiązania wynikające z licencji, NDA oraz ochrony tajemnicy przedsiębiorstwa.

Szczególnie istotne jest rozróżnienie funkcjonalności programu od konkretnej formy jej realizacji. Prawo autorskie nie pozwala jednemu przedsiębiorcy zmonopolizować samego pomysłu na działanie aplikacji, dlatego niezależne stworzenie programu posiadającego podobną funkcję może być legalne. Nie oznacza to jednak prawa do kopiowania kodu, grafik, dokumentacji czy twórczych elementów interfejsu.

REA jest więc dobrym przykładem technologii, której legalność zależy przede wszystkim od użytkownika. To samo narzędzie może zostać wykorzystane do całkowicie legalnego audytu własnego programu, zapewnienia interoperacyjności albo analizy malware, ale może również zostać użyte do czynności naruszających prawa autorskie, tajemnicę przedsiębiorstwa, warunki umowy czy nawet przepisy karne dotyczące nieuprawnionego dostępu do systemu.

Wraz z rozwojem agentów AI różnica pomiędzy analizą programu a jego automatyczną rekonstrukcją będzie coraz mniej wyraźna. Dlatego przedsiębiorstwa wykorzystujące narzędzia do reverse engineeringu powinny nie tylko interesować się ich możliwościami technicznymi, ale również wdrożyć zasady określające, jakie systemy mogą być analizowane, na jakiej podstawie oraz w jakim zakresie można wykorzystywać uzyskane wyniki.