Witam,

Chciałbym przedstawić następującą kwestię (proszę mnie poprawić gdy
się mylę):
1. Jak wiadomo, kod źródłowy kompilowany jest (przez ilasm.exe) do
kodu pośredniego (MSIL)*
2. Uruchomienie programu polega na wczytaniu tego MSIL przez tzw. JIT
(kompilator do kodu maszynowego działający w czasie uruchomienia).
Zatem w trakcie uruchomienia w pamięci znajduje się kod maszynowy
właściwy dla danej platformy (najczęściej jest to 32 bitowy Windows NT
czyli wszelkie 32 bitowe XP, 2003, Vista itp, itd).

O co chodzi?

Chodzi o ten kod maszynowy. Jeśli taki kod istnieje w pamięci to
równie dobrze można go wysłać do pliku i uruchamiać skompilowany do
kodu maszynowego gotowy program. (?)

Po co?

1. Nie muszę się martwić o przechwycenie moich rozwiązań przez
potencjalną konkurencję (dotfuscator kosztuje ok. 4500euro i jako
pojedynczego człowieka mnie na to nie stać).
2. Nie muszę instalować Frameworka.

Niestety będą też wady:
1. Wszytkie używane biblioteki .NET ten EXEk będzie musiał pewnie mieć
w sobie bo myślę, że twórcy .NET nie uwzględniają opisywanej tu opcji.
No i pewnie rozmiar pliku byłby spory (chyba że jakoś byłby zdolny
odwoływać się do jednak zainstalowanych bibliotek .NET).
2. Nie można będzie skorzystać z udogodnień .NET jak np. GC i pewnie w
ogóle będzie trzeba pisać kod niezarządzany? (unsafe).

-------------
* Jest to kod nieczytelny dla edytora (dlaczego? kodowanie?) i można
go zdekompilować do czytelnego pliku tekstowego za pomocą ildasm.exe
(nadal nie jest to kod języka wysokiego poziomu tylko, jak myślę,
czytelna postać MSIL).

do góry

> Chodzi o ten kod maszynowy. Jeśli taki kod istnieje w pamięci to
> równie dobrze można go wysłać do pliku i uruchamiać skompilowany do
> kodu maszynowego gotowy program. (?)

Salamander Native Compiler.

http://www.remotesoft.com/

od razu zastrzegam, że nie używałem nigdy tego narzędzia, przywołuję je
wyłącznie dla porządku, jako przykład, że już coś takiego jak sobie
wymyśliłeś ktoś zrobił i nawet to sprzedaje.
nie wiem czy są inne narzędzia tego typu, nigdy takich aktywnie nie
poszukiwałem.

Wiktor Zychla

do góry

Dzięki za informację.
Niestety wymieniony Salamander nie daje wersji próbnej a tylko
przykładowy obraz exe wykonany przez ten program.
Jest płatnym programem więc nie będę go brał pod uwagę (póki nie mam
pieniędzy z programowania).
Doczytalem, że wbudowany w .NET ngen.exe kompiluje do obrazu zależnego
od architektury lokalnej (native image) ale nie znalazłem opcji zapisu
tego obrazu do pliku - siedzi gdzieś w tzw. global assembly cache
(cokolwiek przez to rozumieć :).

Pozdrawiam

do góry

discharge pisze:
> Witam,
>
> Chciałbym przedstawić następującą kwestię (proszę mnie poprawić gdy
> się mylę):
> 1. Jak wiadomo, kod źródłowy kompilowany jest (przez ilasm.exe) do
> kodu pośredniego (MSIL)*
> 2. Uruchomienie programu polega na wczytaniu tego MSIL przez tzw. JIT
> (kompilator do kodu maszynowego działający w czasie uruchomienia).
> Zatem w trakcie uruchomienia w pamięci znajduje się kod maszynowy
> właściwy dla danej platformy (najczęściej jest to 32 bitowy Windows NT
> czyli wszelkie 32 bitowe XP, 2003, Vista itp, itd).
>
> O co chodzi?
>
> Chodzi o ten kod maszynowy. Jeśli taki kod istnieje w pamięci to
> równie dobrze można go wysłać do pliku i uruchamiać skompilowany do
> kodu maszynowego gotowy program. (?)
>
> Po co?
>
> 1. Nie muszę się martwić o przechwycenie moich rozwiązań przez
> potencjalną konkurencję (dotfuscator kosztuje ok. 4500euro i jako
> pojedynczego człowieka mnie na to nie stać).
> 2. Nie muszę instalować Frameworka.
>
> Niestety będą też wady:
> 1. Wszytkie używane biblioteki .NET ten EXEk będzie musiał pewnie mieć
> w sobie bo myślę, że twórcy .NET nie uwzględniają opisywanej tu opcji.
> No i pewnie rozmiar pliku byłby spory (chyba że jakoś byłby zdolny
> odwoływać się do jednak zainstalowanych bibliotek .NET).
> 2. Nie można będzie skorzystać z udogodnień .NET jak np. GC i pewnie w
> ogóle będzie trzeba pisać kod niezarządzany? (unsafe).

Mono w ostatnim wydaniu dodało możliwość tworzenia natywnej binarki.
Jest to zrobione głównie dla iPhone (ograniczenia licencyjne Apple App
Store wykluczają aplikacje z kodem pośrednim), więc nie wiem jak się
zachowa na i86.

Adam Kłobukowski

do góry

> od architektury lokalnej (native image) ale nie znalazłem opcji zapisu
> tego obrazu do pliku - siedzi gdzieś w tzw. global assembly cache

stan mojej wiedzy jest taki, że nie da się tego natywnego obrazu nijak
wyciągnąć i używać samodzielnie.

Wiktor Zychla

do góry

> stan mojej wiedzy jest taki, że nie da się tego natywnego obrazu nijak
> wyciągnąć i używać samodzielnie.

Chłopska logika podpowiada, że jeśli można to zrobić w locie (jit) to
dlaczego nie można zwyczajnie?
Poza tym sam napisałeś wyżej o Salamanderze.
Jednak zostawiam to na razie bo szkoda czasu. Punkt 1 z mojego postu
rozpoczynającego wątek osiągnąłem stosując zaciemniacz.

W każdym razie dziękuję za odzew.

PS. Znalazłem kiedyś ciekawą rzecz do ASP.NET polegającą na tym, że
jeśli chcesz ukryć kod źródłowy skryptów (C#, VB) dołączanych do
strony ASP.NET, można go sobie skompilować do biblioteki (kod
pośredni) i strona używa taki plik zamiast żywego skryptu. Pewnie
można go dodatkowo zaciemnić zaciemniaczem. Jednak ostatnio nie robię
nic dla WWW i na razie nie sprawdzę tego.

do góry

discharge pisze:
[...]
> PS. Znalazłem kiedyś ciekawą rzecz do ASP.NET polegającą na tym, że
> jeśli chcesz ukryć kod źródłowy skryptów (C#, VB) dołączanych do
> strony ASP.NET, można go sobie skompilować do biblioteki (kod
> pośredni) i strona używa taki plik zamiast żywego skryptu. Pewnie
> można go dodatkowo zaciemnić zaciemniaczem. Jednak ostatnio nie robię
> nic dla WWW i na razie nie sprawdzę tego.
Jeśli chodzi o ASP.NET to nie ma aż takiej potrzeby ukrywania tego kodu
(przynajmniej w aplikacjach napisanych warstwowo, gdzie logika dziedziny
siedzi gdzie indziej), gdyż:
1. Użytkownik przeglądarki i tak nie ma z tym kodem styczności.
2. Poznanie parunastu linijek podpiętych pod Click przycisku nie jest
ciekawe bo gołym okiem widać co tam się w GUI zmienia.

Pozdrawiam

--
Grzegorz Gruza
Odpowiadając usuń "spamerom_nie." z adresu!!!

do góry

>Jeśli chodzi o ASP.NET to nie ma aż takiej potrzeby ukrywania tego kodu
>(przynajmniej w aplikacjach napisanych warstwowo, gdzie logika dziedziny
>siedzi gdzie indziej), gdyż:
>1. Użytkownik przeglądarki i tak nie ma z tym kodem styczności.

Zakładając, że sam bedę administratorem tego WW. A co gdy
administratorem będzie wścibski i nielubiany (i viceversa)
programista? Miałem taką sytuację.

>2. Poznanie parunastu linijek podpiętych pod Click przycisku nie jest
>ciekawe bo gołym okiem widać co tam się w GUI zmienia.

Jeśli to będzie np. proste wyświetlenie napisiku czy okienka, zgadzam
się. Ale jeśli wynikiem kliknięcia będzie uruchomienie algorytmu, nad
którym pracowałem 1/2 roku to już się nie zgadzam.

PS. Jest taki mechanizm, który pozwala skompilować kod ASP.NET do
pliku binarnego. Testowałem to jakiś czas temu (nie sprawdziłem czy da
się zaciemnić ale pewnie tak). Był opisany w książce "C# receptury".

do góry

x...@o...pl pisze:
>> Jeśli chodzi o ASP.NET to nie ma aż takiej potrzeby ukrywania tego kodu
>> (przynajmniej w aplikacjach napisanych warstwowo, gdzie logika dziedziny
>> siedzi gdzie indziej), gdyż:
>> 1. Użytkownik przeglądarki i tak nie ma z tym kodem styczności.
>
> Zakładając, że sam bedę administratorem tego WW. A co gdy
> administratorem będzie wścibski i nielubiany (i viceversa)
> programista? Miałem taką sytuację.
>

Gratuluję podejścia zwiększania kosztów wytwarzania oprogramowania
dlatego, że jego przyszły admin jest wścibski i nielubiany :-)

>> 2. Poznanie parunastu linijek podpiętych pod Click przycisku nie jest
>> ciekawe bo gołym okiem widać co tam się w GUI zmienia.
>
> Jeśli to będzie np. proste wyświetlenie napisiku czy okienka, zgadzam
> się. Ale jeśli wynikiem kliknięcia będzie uruchomienie algorytmu, nad
> którym pracowałem 1/2 roku to już się nie zgadzam.
>

Pisałem o aplikacjach pisanych warstwowo, gdzie logika siedzi gdzie indziej.

> PS. Jest taki mechanizm, który pozwala skompilować kod ASP.NET do
> pliku binarnego. Testowałem to jakiś czas temu (nie sprawdziłem czy da
> się zaciemnić ale pewnie tak). Był opisany w książce "C# receptury".

Ustalmy o czym mówimy - chodzi o to pojęcie pliku binarnego. Ja mówię o
pliku binarnym jako dll ze skompilowanym kodem - to można disasemblować,
jeśli nie użyje się zaciemniacza. Jeśli masz na myśli coś innego, to
napisz co.

Pozdrawiam

--
Grzegorz Gruza
Odpowiadając usuń "spamerom_nie." z adresu!!!

do góry