🚀 go-pugleaf

ZB wrote:

> Grzebiąc w archiwach comp.lang.tcl znalazłem coś takiego:
> 
> #v+
>   Starpack do not offer encryption. Anyway, I think tclbytecode is much
>   better than encryption. So it doesn't really matter much.
> #v-
> 
> Ani w Wiki nie znalazłem nic "dając searcha" na to hasło, ani Google jakoś
> nic o tym nie wie. Czy chodzi o jakiś rodzaj kompilatora dla TCL?

Jest takie coś jak procomp, czy też tclcompiler, nie wiem jak to poprawnie
nazwać. W każdym bądź razie znaleźć to można w TclPro - stare, ale jak się
uprzeć to działa, tylko gorzej sobie radzi z Tcl 8.5. Z 8.4 działa całkiem
nieźle, choć TclPro zaprzestano rozwijać gdzies w okolicach Tcl 8.3.

Obecnie jest TclDevKit - komercyjny. Zawiera w sobie tclcompiler, który jest
kontynuacją tego z TclPro, tyle że za kasę :/

Chcąc skompilować niewyszukany kod Tcl 8.4 można zadowolić się kompilatorem
z TclPro. Do bardziej zaawansowanych zastosowań pozostaje TclDevKit.

Kod skompilowany tym programem _TEORETYCZNIE_ jest nie do odtworzenia.
Oczywiście wszystko da się zrobić, ale odtworzenie tego kodu jest niezwykle
trudne. Póki co nie ma narzędzi które by na to pozwalały.

Tak skompilowany kod niestety nie uruchamia się "po prostu". Użytkownik
docelowy musi mieć rozszerzenie tbcload (tbc to rozszerzenie skompilowanych
plików). tcbload można mieć za free, jest w pakiecie ActiveTcl, jest też
starsza wersja w TclPro.


Jeśli chcesz zobaczyć jak to wygląda w praktyce to możesz sobie ściągnąć
SQLiteStudio (tak, autoreklama ;) ), użyłem tam kompilatora do ukrycia kodu
odpowiedzialnego za licencję. Jednocześnie tbcload dostarczam razem z
paczką binarną, więc tak na prawdę można używać kompilatora i nie nękać
end-usera o jakieś dodatkowe rozszerzenia.

-- 
Pozdrawiam! (Regards!)
Googie

Dnia 25.01.2008 Googie <no@spam.0rg> napisał/a:

> Chcąc skompilować niewyszukany kod Tcl 8.4 można zadowolić się kompilatorem
> z TclPro. Do bardziej zaawansowanych zastosowań pozostaje TclDevKit.

Ano właśnie. Muszę to przebadać...

> Kod skompilowany tym programem _TEORETYCZNIE_ jest nie do odtworzenia.
> Oczywiście wszystko da się zrobić, ale odtworzenie tego kodu jest niezwykle
> trudne. Póki co nie ma narzędzi które by na to pozwalały.

A to szkoda, że Ruskich o tym nikt nie poinformował wcześniej. Może by
dali sobie spokój...?   ;)

http://tinyurl.com/ywq8e2

Ja bym za to nawet zapłacił - ale za kasę wymagałbym jednak czegoś lepiej
chroniącego kod.
-- 
ZB

ZB wrote:

> A to szkoda, że Ruskich o tym nikt nie poinformował wcześniej. Może by
> dali sobie spokój...?   ;)
> 
> http://tinyurl.com/ywq8e2
> 

Nie znam rosyjskiego - czy oni twierdzą że im się udało zdekompilować tak
skompilowany kod Tcl?

> Ja bym za to nawet zapłacił - ale za kasę wymagałbym jednak czegoś lepiej
> chroniącego kod.

Można kombinować łącząc kompilowanie kodu z RSA i AES. To też nie daje 100%
pewności (bo przecież nic nie daje), ale na pewno nie ułatwi sprawy.

-- 
Pozdrawiam! (Regards!)
Googie

Dnia 29.01.2008 Googie <no@spam.0rg> napisał/a:

> Nie znam rosyjskiego - czy oni twierdzą że im się udało zdekompilować tak
> skompilowany kod Tcl?

Podają dość prosty przepis na to. Taki "domowej roboty". :D  Skontaktowałem
się zresztą z AS w tej sprawie, bo przymierza(łe)m się do kupna TDK - i
nieco wymijającej odpowiedzi mi udzielili.

>> Ja bym za to nawet zapłacił - ale za kasę wymagałbym jednak czegoś lepiej
>> chroniącego kod.
>
> Można kombinować łącząc kompilowanie kodu z RSA i AES. To też nie daje 100%
> pewności (bo przecież nic nie daje), ale na pewno nie ułatwi sprawy.

No zastanawiam się... ale wobec tak prostej recepty, czy warto płacić za
TDK, jeśli - jak wygląda z tych fragmentarycznych informacji - nawet to
FreeWrap-owe zip-kodowanie wygląda na większą przeszkodę dla ciekawskiego?

Też nie 100% pewną - ale jednak bardziej zniechęcającą, bo do jej
przełamania trzeba większego nakładu pracy. No, tak mi to jakoś wygląda na
dzień dzisiejszy.
-- 
ZB

ZB wrote:

> No zastanawiam się... ale wobec tak prostej recepty, czy warto płacić za
> TDK, jeśli - jak wygląda z tych fragmentarycznych informacji - nawet to
> FreeWrap-owe zip-kodowanie wygląda na większą przeszkodę dla ciekawskiego?

Przyjrzałem się metodzie kompilowania przez TDK i mam 2 wnioski, 1
pozytywny, 1 negatywny.

1 netgatywny dotyczy tego, że sposób opisany przez ruskich jest wynikiem
poważnego błędu w kompilatorze. Mianowicie kod skompilowany nie powinien
wpisywać do pliku stringa skompilowanego, tylko takiego, jaki był przed
kompilacją. Ten błąd może powodować problemy z działaniem nawet
najprostszych aplikacji po skompilowaniu...

1 pozytywny dotyczy faktu, że stringi nie są do końca "kompilowane", a
jedynie kodowane, już nie pamiętam za pomocą czego, ale metodologia jest
podobna do base64. Z jednej strony pozwala to na odkodowanie dowolnego
stringu, pod warunkiem że wiemy gdzie się zaczyna a gdzie kończy, ale z
drugiej strony - nawet wpisanie do pliku tak skompilowanego stringu nie
powoduje narażenia bezpieczeństwa reszty kodu, który jest prawdziwie
skompilowany do bytecodu. Innymi słowy to co osiągnęły ruskie nie daje im
jeszcze możliwości poznania samej struktury bytecodu. Tak na prawdę to w
ogóle nie wiele im to daje.


-- 
Pozdrawiam! (Regards!)
Googie

Dnia 31.01.2008 Googie <no@spam.0rg> napisał/a:

> z drugiej strony - nawet wpisanie do pliku tak skompilowanego stringu nie
> powoduje narażenia bezpieczeństwa reszty kodu, który jest prawdziwie
> skompilowany do bytecodu. Innymi słowy to co osiągnęły ruskie nie daje im
> jeszcze możliwości poznania samej struktury bytecodu. Tak na prawdę to w
> ogóle nie wiele im to daje.

Muszę w końcu pobrać demo-pakiet TDK - i sprawdzić to na jakimś "żywym
przykładzie".
-- 
ZB

A gdyby przyszło co do czego: czy warto zdecydować się na "Pro Studio"?
Zasadniczo sam TDK wydawałby się chyba wystarczający...
-- 
ZB

ZB wrote:

> A gdyby przyszło co do czego: czy warto zdecydować się na "Pro Studio"?
> Zasadniczo sam TDK wydawałby się chyba wystarczający...

Nie używałem. W ogóle z płatnych narzędzi wypróbowałem TDK i Komodo, jako
osobne programy. TDK fajne, fajne...
Komodo też niezłe, ale prędkością działania przypomina Eclipse, albo jeszcze
gorzej. Mało pracowałem z Komodo, ale wydaje mi się, że stosunek możliwości
do prędkości działania i ceny jest niekorzystny.

-- 
Pozdrawiam! (Regards!)
Googie

Dnia 25.01.2008 Googie <no@spam.0rg> napisał/a:

> Jeśli chcesz zobaczyć jak to wygląda w praktyce to możesz sobie ściągnąć
> SQLiteStudio (tak, autoreklama ;) ), użyłem tam kompilatora do ukrycia kodu
> odpowiedzialnego za licencję. Jednocześnie tbcload dostarczam razem z
> paczką binarną, więc tak na prawdę można używać kompilatora i nie nękać
> end-usera o jakieś dodatkowe rozszerzenia.

To znaczy: w tej kombinacji z "tbcload-em" tak naprawdę chodzi o zbudowanie
"Starpacka", który będzie zawierał skrypt - że tak powiem - "bytecoded"?

Bo chodzi mi o możliwość przekazania programu komuś, kto w ogóle nie ma
środowiska TCL/Tk zainstalowanego, ani nie chce nawet wiedzieć, co to
jest... on chce, żeby było "klikam - i działa".
-- 
ZB

ZB wrote:

> Dnia 25.01.2008 Googie <no@spam.0rg> napisał/a:
> 
>> Jeśli chcesz zobaczyć jak to wygląda w praktyce to możesz sobie ściągnąć
>> SQLiteStudio (tak, autoreklama ;) ), użyłem tam kompilatora do ukrycia
>> kodu odpowiedzialnego za licencję. Jednocześnie tbcload dostarczam razem
>> z paczką binarną, więc tak na prawdę można używać kompilatora i nie nękać
>> end-usera o jakieś dodatkowe rozszerzenia.
> 
> To znaczy: w tej kombinacji z "tbcload-em" tak naprawdę chodzi o
> zbudowanie "Starpacka", który będzie zawierał skrypt - że tak powiem -
> "bytecoded"?
> 
> Bo chodzi mi o możliwość przekazania programu komuś, kto w ogóle nie ma
> środowiska TCL/Tk zainstalowanego, ani nie chce nawet wiedzieć, co to
> jest... on chce, żeby było "klikam - i działa".

Więc starkit (starpack with tclkit included) jest dla Ciebie.
Starpack = plik.kit uruchamiany przez tclkit.exe.
Starkit = plik.exe z tclkit.exe wbudowanym.

Klikasz i działa.

-- 
Pozdrawiam! (Regards!)
Googie