eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingmój obfuskator - problem projektowy › Re: mój obfuskator - problem projektowy
  • Path: news-archive.icm.edu.pl!news.icm.edu.pl!newsfeed.pionier.net.pl!2.eu.feeder.erj
    e.net!3.eu.feeder.erje.net!feeder.erje.net!newsreader4.netcologne.de!news.netco
    logne.de!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.ams4!peer.am4.hi
    ghwinds-media.com!news.highwinds-media.com!newsfeed.neostrada.pl!unt-exc-02.new
    s.neostrada.pl!unt-spo-b-01.news.neostrada.pl!news.neostrada.pl.POSTED!not-for-
    mail
    Date: Tue, 25 Oct 2022 20:35:08 +0200
    MIME-Version: 1.0
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
    Thunderbird/102.4.0
    Subject: Re: mój obfuskator - problem projektowy
    Newsgroups: pl.comp.programming
    References: <tj64ne$36qsg$3@portraits.wsisiz.edu.pl>
    Content-Language: pl
    From: J-23 <B...@p...fm>
    In-Reply-To: <tj64ne$36qsg$3@portraits.wsisiz.edu.pl>
    Content-Type: text/plain; charset=UTF-8; format=flowed
    Content-Transfer-Encoding: 8bit
    Lines: 31
    Message-ID: <63582c4f$0$463$65785112@news.neostrada.pl>
    Organization: Telekomunikacja Polska
    NNTP-Posting-Host: 178.213.140.164
    X-Trace: 1666722895 unt-rea-a-02.news.neostrada.pl 463 178.213.140.164:56470
    X-Complaints-To: a...@n...neostrada.pl
    X-Received-Bytes: 2712
    Xref: news-archive.icm.edu.pl pl.comp.programming:215863
    [ ukryj nagłówki ]

    W dniu 24.10.2022 o 15:42, Jivanmukta pisze:
    > Piszę tutaj bo na pl.como.lang.php nie dostałem odpowiedzi.
    >
    > Napisałem w C++ obfuskator PHP 5/7/8. Obfuskator umożliwia m.in.
    > zaciemnienie projektu wykorzystującego Composera, tzn. katalog vendor.
    > Ponieważ obfuskuję samą aplikację a nie frameworki i biblioteki z
    > katalogu vendor potrzebuję zrobić żeby identifikatory z vendor nie były
    > zastępowane losowymi. W tym celu analizuję kod frameworków i bibliotek z
    > katalogu vendor w poszukiwaniu identyfikatorów (zmiennych, funkcji,
    > metod, właściwości itd.). Problem w tym że jeśli katalog vendor jest
    > duży, tzn. liczy wiele podkatalogów, proces analizy trwa długo, nawet
    > kilka godzin. Żeby nie analizować katalogu vendor wielokrotnie (przy
    > każdej obfuskacji projektu) zapamiętuje znalezione w vendor
    > identyfikatory w cache'u (pliku xml-owym). Modyfikacja katalogu vendor
    > (np. dodanie Composerem nowej biblioteki lub update) nie powoduje u mnie
    > ponownego parsowania całego vendor bo zapamiętuję w cache'u timestampy
    > podkatalogów vendor.
    >
    > Czy takie rozwiązanie jest do przyjęcia, tzn. że pierwsza obfuskacja
    > może trwać nawet kilka godzin, ale późniejsze już w minutach?

    Wnioskuje po zapytaniu ze próbujesz zrobić narzędzie które będziesz
    sprzedawał/dystrybuował na szerszą skale. Pytanie to nie powinno być na
    grupę a do pierwszej partii klientów którzy ten produkt otrzymają.
    Sposobów przyspieszenia tego jest dużo, ale tez nie będzie to proste w
    implementacji. Musisz przeanalizować sobie gdzie jest dla Ciebie punkt
    który zadowoli Ciebie lub Twoich klientów.

    Pozdrawiam


Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: