Mam pytanie apropto ukrywania kodu php. Czy jest taka możliwość?

Chodzi oto iż posiadam własny algorytm szyfrowania pewnych danych zarazem z deszyfrowaniem ich i nie chciałbym by ktoś wszedł w jego posiadanie z wiadomych względów ...
Posiadam programy, które z kodu robią małą zamieszkę np. usuwają wszystkie komentarze, nowe linie (kod php jest w jednej linii), zmieniają nazwy funkcji przeze mnie zdeklarowanych, zmieniają nazwy zmiennych i stwarzają kod php o wiele mniej czytelny lecz zarazem szybciej dzialajacy na serwerze ... jednak to nie rozwiazuje problemu gdyz kod dalej jest do odczytania ...

czy jest jakies oprogramowanie, ktore na serwerze linuksowym za pomoca pewnego algorytmu odczytuje "skompilowny lub inaczej zakodowany" kod php i generuje poprawny kod php?

wszystko by bylo ok gdyby kod php, ktory pisze byl widoczny tylko dla mnie ale niestety niektore skrypty udostepniam na innych serwerach a wtedy wiadomo dzieje sie co sie dzieje ...

wiem, ze wyjsciem jest java, ktora moze wykonywac algorytm kodujacy i dekodujacy ale ... tego chcialbym uzyc w ostatecznosci gdyby nie dalo sie kodu php zataic

http://www.turcksoft.com/en/e_products.htm

Polecam: Turck MMCache for php

czesto sie stosuje kodowanie base64 w takiej sytuacji ale zakodowany w sposob nastepujacy kod: base64_encode($kod); aje sie rownie latwo odkodowac poprzez base64_decode($kod_b64); wiec jest to tylko skuteczne na poczatkijacych

kris_ << wszystko fajnie tylko jak czyta sie dokumentacje tego programu to od razu widac, ze wymagane jest wnikanie w konfiguracje serwera ... a kod, ktory udostepniam ma byc gietki a nie wymagajacy pewnych ustawien ... z reszta kazdemu z nas zalezy by wszedzie ruszyl bez problemu a nie wymagal specjalnych ustawien/bibliotek/systemow

squid << odpowiedziales sam na problem ...

Nie słyszałem o metodzie na użycie w jakikolwiek sposób skompilowanego kodu php na serwerze nie wyposażonym w odpowiednie mechanizmy dekodujące. Bibliotek obsługujących zaszyfrowany kod php (darmowa alternatywa dla Zend Encoder) jest kilka, ale z tego co mi wiadomo każda z nich wymaga ingerencji w serwer php.

skoro inaczej sie nie da to przepisz twoj kod na c i udostepni jako cgi

To są tak zwane obfuscatory, ale to tylko utrudnia, a nie uniemożliwia odczytanie oryginalnego kodu. Pamiętaj, że musisz tam gdzieś zapisać procedurę, która to odtwarza przed uruchomieniem, więc de facto zawierasz cały klucz do odzyskania tekstu oryginalnego razem z kodem. Nawet jak zrobisz ten dekoder w C jako rozszerzenie Zenda to i tak stosunkowo łatwo to obejść. Kiedyś ,,łamałem'' kod zabezpieczony czymś co się nazywało Source Guardian, czy jakoś tak (produkt jak najbardziej komercyjny) i zajęło mi to kilkanaście minut, nie polecam więc tego typu ,,bajerów''.

Kiedyś przy podobnym problemie wykorzystałem darmowego php Acceleratora. To narzędzie kompiluje pliki źródłowe php do natywnego bytecode'u Zenda i trzyma w takiej postaci na dysku aby przyspieszyć proces uruchamiania. Podczas uruchamiania skryptu PHPA porównywał czasy modyfikacji pliku oryginalnego i skompilowanego, żeby zadecydować czy wziąć skompilowany czy przekompilować oryginał. Wystarczyło umieścić puste (o długości 0) pliki źródłowe o dacie modyfikacji sprzed daty modyfikacji wersji skompilowanej i PHPA ich nie dotykał. Całośc kodu wtedy jest w kodzie Zendowym, a puste pliki źródłowe są tylko zaślepką.

Mylisz dwie rzeczy. Skompilowanie do php-owego bytecode'u jest znacznie trudniejsze do disasemblacji niż rozkodowanie takiego obfuscatora.

Chodzi Ci o servlety? Bo inaczej to sobie tego nie wyobrażam. Chociaż w przypadku servletów to też ma mały sens.

Tak chodzi mi o servlety. Wiem, ze sa dekompilatory ... to tez problem ... ale coz ... nie widze by ktos tu mial jakies sensowne wyjscie ... ;[

Hej
Istnieje mechanizm ktory to umozliwia: http://www.rssoftlab.com/phpenc.php

Pozdrawiam

A swoja opinie opierasz na marketingbleble z ich strony czy z wlasnych doswiadczen ? Bo ja zdziwiony poogladalem ten wyznalazek i on _wymaga_ grzebania w instalacji serwera. Niby maja tez opcje kodowania php-ow do plikow samodekodujacych, ale to guzik prawda. Po prostu do zakodowanej postaci dodaja kawalek kodu ktory dynamicznie wciaga biblioteke i wywoluje jej funkcje - czyli skrypt jednak nie jest samowystarczalny i jak nie mozesz wciagnac wlasnej biblioteki to to rozwiazanie nadaje sie ino jako podporka do stolu.

Tak jak to powiedzial ktos wczesniej: Samodekodujace sie skrypty sa w zasadzie rownowazne skryptow niezakodowanym: wystarczy uruchomic je na papierze...

Hejdoswiadczeniachjedna z trzech drog do uzycia nie wymaga "grzebania". sam to przyznajesz nizej. masz racje jesli zaklada sie ze serwer nieumozliwia wsparcia dla rozszerzen oraz funkcji dl(). To cos zupelnie innego.To wpierw mala dygresja dla wiedzacych jak dziala phtml encoder - "guzik prawda" wyglada nastepnujaco: [php:1:a1da22441e]dl("phtmlenc4.X.Y.so");[/php:1:a1da22441e]gdzie X i Y to numery wersji php, a pliki .so dolaczone sa do programu.

Wracajac do mister uboottd: Twierdzisz: "i jak nie mozesz wciagnac wlasnej biblioteki" - super. tylko poki co jeszcze nie natrafilem na klienta, ktory by uniemozliwial zarowno wywolywania dl() oraz dodanie extension.

eins) dodawaj prosze przy tego typu wypowidziach informacje ".. jesli nie mamy dostepu ani do lodowania biblotek poprzez dl() ani do dodawania rozszerzen (extension) lub zend_extensions. twierdzac kategorycznie ze nijak nie mozna zakodowac skryptow mowisz czesc prawdy - sa mechanizmy ktore polaczone z php zabezpieczaja kod na poziomie niemozliwosci odczytania zrodel a jedynie (i tutaj juz zaleznie od narzedzia) udostepniajace kod binarny badz zakodowany (w tym w jedna strone).
zwei) kod chroni nie encoder/obfuskator ale umowa lub dobrze skonfigurowany serwer - jesli zalezy tobie na niedostepnosci zrodel przed przystapieniem do pracy upewnij sie ze masz obie rzeczy udostepnione - a nie narzekaj. mozesz tez zmienic platforme lub jezyk programowania.


Pozdrawiam

Jeśli wykluczasz umieszczenie rozszerzenia w serwerze to raczej zapomnij o takim czymś.

Znaczy nie spotkales klienta, ktory ma wlaczone safe_mode ? Bo to wystarcza, zeby te ich "samodekodujace sie" (pomijajac juz szczegol ze skrypt odwolujacy sie do specjalnej biblioteki zeby go zdekodowala juz nie jest samodekodujacy sie...) skrypty nie dzialaly. A jesli serwer jest Twoj i mozesz cos do niego dolozyc to w ogole nie ma o czym dystkutowac. Jednak jakos wydaje mi sie ze ciezko bedzie Ci znalezc kogos kto hostuje strony www i daje ludziom swobode w dokladaniu bibliotek. A jak znam zycie to treewoodowi wlasnie chodzi o taka sytuacje.

Kompilator to calkiem inna historia - mowiac o skryptach mam na mysli postac zrodlowa, binarka to juz dla mnie cos innego, i tu juz sa wieksze mozliwosci, aczkolwiek tez wymagaja wsparcia ze strony serwera, a tym to akurat nie wiem jak jest u providerow, a podejrzewam ze gorzej niz wylaczonym safe_modem.

Zreszta, dopoki nie wykupisz wersji PRO i nie pozmieniasz kluczy to kazdy moze se sciagnac ichniejsza wersje darmowa i zdekodowac ten badziew...

Ale faktycznie najlepszym zabezpieczeniem powinna byc dobra umowa i zaufanie do admina serwera.

HejJesli dobrze pamietam Safe mode nie wyklucza dodania extension.

Jesli jednak doda sie extension beda dzialaly. Wiec po sprawie.

Nie do konca - moze mam farta ale poki co jakos zyje - albo trafiam na dedykowane serwery albo na zyciowych adminow.
Pozwolmy sie wiec jemu wypowiedziec. Zwracam tez uwage na inny szczegol: ja wcale nie odpowiadalem treewoodowi a dragossaniemu ;)


wersja pro to 120$. jesli komus zalezy na ochornie kodu to jest to bardzo maly koszt.


Pozdrawiam

extension nie, ale dl tak, i albo admin Ci sam to doda albo do widzenia. A to juz ingerencja w konfig.

ja dodam tylko od siebie tyle
co mowi samo przez się że bez dodatkowych bibliotek zakodowanie kodu php jest nie możliwe.

Zgadzam się z przedmówcą, a od siebie dodam tylko że jest jeszcze jeden soft który pozwala zakodować strony - mmcache
http://turck-mmcache.sourceforge.net/. Jest on domyślnie instalowany na serwerach home.pl, działa jako akcelerator i encoder.
Jeśli chodzi o ładowania bibliotek, etc.. to może nie warto kombinować na 1000 sposobów - tylko lepiej pogadać z adminem. Zwykły czynnik ludzki w zupełności wystarczy Dodam jeszcze że mmcache fajnie współpracuje ze smarty - engine jest zaszyty w "kompilowanych" plikach, a template można swobodnie edytować - piękna sprawa.

HejTak, wiemy o nim dobrze ;) tutaj raczej chodzilo o samo dekodujace sie skrypty. mmcache dziala stricte jako zianstalowany modul wiec wg mnie nie podpada.
Nie jest to prawda. Jest podany na liscie serwerow na ktorych jest zainstalowany mmcache. To cos innego ;)Tak, tylko trzeba uwazac jesli mamy baardzo duzo plikow .html a provider nieopatrznie wlaczyl parsowanie rowniez plikow .html. Wowczas moze sie okazac, ze mmcache musi "pilnowac" baardzo duzej liczby plikow - i wowczas jego wydajnosc silnie spada. Poza tym, rzeczywiscie bardzo mile oprogramowanie :)


Pozdrawiam

Jest instalowany: http://home.pl/support/phpinfo.php


Dlatego warto pilnować tego w .htaccess, i tak jak już pisałem zawsze można dogadać się z adminem, a jak się nie da to trzeba zmienić providera

HeTak, teraz jest zainstlowany. Ale home od dawno gdera przy mmcache'u zmieniajac go. Obecna wersja jak przyznaje home na usenetcie jest raczej tymczasowa. Tez mialym nadzieje ze by sie utrzymala ale gwarancji niestety raczej nie ma.

Pozdrawiam

Wpadlem na calkiem fajny sposb kodowania kodu bez potrzeby instalowania dodatkowych modulow.
1) Musimy posiadac skrypt kodujacy/dekodujacy tekst po podaniu hasla.
2) Wszystkie skrypty kodujemy za pomoca hasla.
3) Zostawiamy jedynie skrypt odpowiedzialny za logowanie do systemu. W bazie przechowujemy hash naszego hasla.
4) Podczas wchdozenia do systemu podajemy haslo i jezeli jest ono poprawne dekodujemy tym haslem skrypty.
5) Musimy stworzyc wlasna funckcje include, ktora bedzie dekodowala potrzbny skrypt i wrzucala go do evala.

Plusy takiego rozwianziania:
+ Mozemy cos takiego uzyc do tworzenia prezentacji systemow (aplikacji) gdzie nie chcemy lub nie mozemy udostniac kodu.
+ Brak dodatkowych bibliotek
+ Wieksze bezpieczenstwo skryptu
+ Latwosc implementacji
+ Mozliwosci zaimplemenetowania algorytmu dwoch kluczy (priv/public) i udostepnianie czesci "publicznej" kodu dla pewnej grupy ludzi - np podstawowe zarzadzanie systeme, a administracja byla by zakodowana prywatnym kluczem.

Minusy:
- Mala wydajnosc
- Pewna ucizliwoscia moze byc to, ze trzeba podawac haslo

Minusy: duzy naklad pracy przy minimalnych zyskach:
- nieadekwatne dla serowsow dostepnych publicznie
- przed osoba i tak nie majaca dostepu nie trzeba w ogole tego stosowac
- uprawniony uzytkownik ma haslo wiec ma dostep, musi tylko chwile pomyslec
- admin servera i tak moze miec do tego dostep, 10minut pracy wiecej czyli jak mu zalezy to i tak dostanie sie do zrodel.

Nie. Jezeli jego uprawnienia sa tylko do czesci skryptu. Reszta nie jest dekodowana.

Poza tym glowne pliki dekodujace strone mogly b sie znajdowac na innym serverze, a zakodowane na tym "mneij bezpiecznym". Wtedy nie bylo by mowy o podejzeniu zrodel.

To który serwer by to wykonywał ?
W końcu php to język interpretowany i w pewnym momencie musi dostać czystą postać tekstową kodu - i tam ZAWSZE będzie można go przechwycić, kwestia pracy

No dobra moze to rpzekombinowalem

Jednak mysle, ze cos podobnego mozna bylo by opracowac.