[C++] Dekompilacja programu...

Witam.
Piszę program który wykorzystuje połączenie z bazą danych MySQL na moim zdalnym serwerze. Adres serwera, Hasło i użytkownik bazy danych jest zapisany w programie.
No i moje pytanie brzmi... Czy jest możliwość uzyskania tych poufnych danych poprzez dekompilację programu (bo chyba tak sie to nazywa => zamiana kodu maszynowego na kod źródłowy)? A może jeszcze w jakiś inny sposób (np. poprzez przechwytywanie informacji wysyłanych do sieci Internet)?

No a jeśli jest to możliwe to najważniejsza kwestia jak się przed tym ustrzec?

Na kod źródłowy programu nie przerobisz. Nie ma dekompilatorów do C++, są tylko do assemblera. Ale jeżeli znasz asma, to możesz spróbować rozpracować program. Może lepiej pobawić się snifferem, albo założyć hak na funkcję systemową odpowiedzialną za wysyłanie danych.
Pozdrawiam,
Afish

tak. jesli nie uzywasz szyfrowanego polaczenia z baza - wystarczy podsluchac pakiety. a i dokladnie tak - dekompilacja rowniez pozwoli z programu wyciagnac haslo, login i wszystko inne co ciekawe. tylko zwaz, ze C++ bardzo trudno sie 'decompile'. zwykle wchodzi w gre jedynie 'dissassemble'.. jednak, jesli trzymasz takie dane niezabezpieczone nijak, to Ci je licealista wyczyta wprost z exeka windowsowym notatnikiem..

Ok więc załóżmy że będę korzystał z połączenia SSL z MySQL. Jednak jak najlepiej zabezpieczyć hasło do bazy danych w kodzie programu (które ma być wspólne dla wszystkich użytkowników)?

jeśli hasło jest wbudowane na stałe w program to jest prosty sposób na jego "zakodowanie"

jako pierwszy stopień rozbijasz ciąg na znaki
potem zamieniasz je na kod znaku
następnie z tej liczby wyciągasz:
-liczbę setek
-liczbę dziesiątek
-liczbę jednostek

i wszystko zapisujesz w osobnych stałych
i żaden licealista notatnikiem ci raczej nie podpatrzy =)

oczywiście do wysłania hasło potrzebne jest jego złożenie w całość więc po prostu rób to chwilowo, i po użyciu czyść zmienną gdzie będzie siedzieć całe hasło =)

coder() napisał(a)

Witam.
Piszę program który wykorzystuje połączenie z bazą danych MySQL na moim zdalnym serwerze. Adres serwera, Hasło i użytkownik bazy danych jest zapisany w programie.
No i moje pytanie brzmi... Czy jest możliwość uzyskania tych poufnych danych poprzez dekompilację programu (bo chyba tak sie to nazywa => zamiana kodu maszynowego na kod źródłowy)? A może jeszcze w jakiś inny sposób (np. poprzez przechwytywanie informacji wysyłanych do sieci Internet)?

No a jeśli jest to możliwe to najważniejsza kwestia jak się przed tym ustrzec?

do C są

http://boomerang.sourceforge.net/

jednak jeśli ktoś zna assemblera to bez problemu (albo chociażby przy większych staraniach) mógłby to rozpracować prawda?

Na moje oko wystarczyłby prosty algorytm kodowania...
Taki algorytm z kodu Assemblera wyczyta może dwóch ludzi na świecie...

wiecej, duzo wiecej :) poza tym, KOD ani ALGORYTM malo kogo obchodzi. wystarczy wylapac chwile w ktorej haslo bedzie juz skompletowane, jawne i po prostu je sobie spisac.. od czego sa debuggery?

ale tak na serio, nie wiem jak bardzo 'wazny' program tworzysz, w zasadzie wystarczy Ci jakiekolwiek najprostsze zaszyfrowanie hasla, do serwera tez wysylaj zaszyfrowane. proste i skuteczne jest np. wysylanie daty+tekstu zaszyfrownego w oparciu o te date. serv sprawdza czy data = 'teraz'+-5 minut (jesli nie, to znaczy ze ktos probuje np. wyslac kopie starego pakietu) oraz czy odszyfrowane (na podstawie zalaczonej daty) haslo jest poprawne

nwpirx >> A mógłbyś podać jakiś przykład? Albo i jakiś trudniejszy :D

Ja osobiście wymyśliłem coś takiego... Jest sobie jakieś tam słowo... (zakodowane tak jak napisał Potwoor_). Następnie jest ono kodowane metodą MD5.
Z otrzymanego wyniku są usuwane litery parzyste... I to jest gotowe hasło do serwera MySQL które wcześniej ustawiłem :P

Było by to w miarę bezpieczne w połączeniu z SSL ??

PS.
Chodzi o to ze baza danych będzie zawierała całe mnóstwo poufnych informacji, które użytkownicy powinni mieć możliwość jedynie dodawać. Żadna edycja i usuwanie ich nie wchodziło by w grę. Jeśli hasło do bazy danych dostało by się w niepowołane ręce to w bardzo prosty sposób zdalnie gość mógłby mi wyczyścić całą bazę robiąc dla siebie kopie :-/ od tego najbardziej chcę się ustrzec.

nwpirx, chyba śnisz, jak tak to ja jastem jednym z nich... tylko kto jest tym drugim?
A poważnie to na tym forum znam ze 20 osób zdolnych do tego. Reverse engineering wcale taki trudny nie jest - średnia znajomość assemblera, trochę myślenia analitycznego i można spokojnie algorytmy wywlekać, odwracać czy tłumaczyć na języki wyższego poziomu. Tego nawet na niektórych uczelniach uczą... Spójrz może na wątki o crackme.

Potwoor_, na kij tyle kombinowania jak do ochrony przed cywilem xor starczy?

bądź wredny
dodaj parę fałszywych haseł
i zrób dla nich konta na serverku i wsadź tam jakieś śmieci

ktoś otworzy w notatniku czy HexEditku jakimś, wyczyta fałszywe hasło i login
dobierze się do tych śmieci i będzie próbował coś z nimi zrobić podczas gdy dane prawdziwe będą bezpieczne =)

coder() napisał(a)

Chodzi o to ze baza danych będzie zawierała całe mnóstwo poufnych informacji, które użytkownicy powinni mieć możliwość jedynie dodawać. Żadna edycja i usuwanie ich nie wchodziło by w grę. Jeśli hasło do bazy danych dostało by się w niepowołane ręce to w bardzo prosty sposób zdalnie gość mógłby mi wyczyścić całą bazę robiąc dla siebie kopie :-/ od tego najbardziej chcę się ustrzec.

A nie da się tego osiągnąć ustawiając w bazie odpowiednio uprawnienia tego użytkownika, którego login/hasło masz w programie? Jeśli te uprawnienia będą OK to nawet jeśli posiadacz programu wydobędzie zeń login/hasło, to i tak i tak nie będzie mógł „ręcznie” zrobić nic innego, niż dodawanie...

deus napisał:

do ochrony przed cywilem xor starczy
No nie wiem.... zależy kogo nazywasz cywilem i na jakim poziomie będzie ten xor.

for (int i=0; i<haslo_dlugosc; i++)haslo[i]=haslo_zaszyfrowane[i] ^ 123;

Dla niektórych coś takiego to już jest piekne "zabzpieczenie" z wykorzystaniem xor'a ;-). Chyba kazdy newbie zrobi to w minute....

nwpirx napisał:

Taki algorytm z kodu Assemblera wyczyta może dwóch ludzi na świecie...
deus pierwszy... a ja drugi... Zdolnych hakierów mamy w Polsce [rotfl]

//edit:
Pomysł cooby jest chyba najlepszy ze wszystkich, które pojawiły się w tym wątku.

No tak najlepszy... Lecz aby tego dokonać należy posiadać dostęp do bazy danych o nazwie "mysql". Ja niestety nie posiadam do niej dostępu ponieważ jest to wirtualny hosting (w nazwa.pl) i mam dostęp tylko do baz danych które sobie sam stworzę. :(

a masz w nazwa.pl PHP? to niech skrypty PHP łączą się z bazą danych przez tajne hasło. A program, żeby już nie komplikować, niech pobiera dane przez API:

www.mojastrona.pl/pobierz.php?co=dane&sid=43465644334r221
www.mojastrona.pl/ustaw.php?co=dane&sid=43465644334r221

Co to jest sid? sesja. na podstawie SID serwer określa, czy masz prawa pobrać, zmienić, zapisać, usunąć... Taki SID niech będzie przydzielany tymczasowo. Twój program nie wie, co jest w SID, po prostu go używa.

Twój program niech nie trzyma żadnych haseł "współdzielonych", które "mogą wszystko", a jedynie prywatne hasło i login każdego użytkownika oddzielnie. Ba, program podczas startu o hasło i login może pytać. O SIDa niech prosi, na przykład tak:

www.mojastrona.pl/pobierz_sid.php?user=blabla&password=blabla

skrypt dostał hasło i login, sprawdza w tabeli userów uprawnienia. Tworzy w tabeli "sesje" nową pozycję, zapisuje w niej czas utworzenia, IP, użytkownika i tak dalej, wszystko co potrzebne. programowi zwraca numer tej pozycji i tyle.

od czasu do czasu niech skrypt przejedzie po tabeli, żeby usunąć stare sesje (np starsze niż 10 minut)

skrypty ustaw.php i pobierz.php dostają żądanie oraz SID. Sprawdzają, czy dany SID pozwala na daną czynność. Jeśli SID w ogóle nie istnieje, ładują błędem "0:zła sesja". Jeśli SID nie pozwala na daną rzecz, to masz błąd "1:brak praw".

Z twojej strony jest to bezpieczne, nikt ci danych nie zabierze, nikt nie zrobi nic złego. Z punktu widzenia użytkowników bezpiecznie nie jest, bo dane logowania lecą przez GET i to gołe i wesołe.

Możesz to zmienić oczywiście, tworząc połączenie https, słać dane w POST, dać skrót hasła, a nie hasło itd. Metodę z GET podałem, bo może być bardzo prosto zrobiona za pomocą skryptów PHP plujących danymi za pomocą echo, oraz funkcji URLDownloadToFile w programie, która po prostu pobiera treść strony www. A tobie, jako udostępniającemu zapewnia bezpieczeństwo. Po prostu użytkowników łatwo podsłuchać, ale ich to $#$ ;P

dopisane:
No i trzeba zrobić stronę rejestracji, to też możesz zrobić jako skrypt, jeśli robotów się nie boisz:

www.mojastrona.pl/rejestruj_goscia_ktory_nic_prawie_nie_moze.php?nowy_user=blabla&jego_password=blabla

albo porządniejszą, ładniejszą stronkę...

o to to cacy wygląda=)

a czy przypadkiem twój host ( nazwa.pl ) nie ma żadnych zabezpieczeń? może ich zapytaj jak bardzo dane są zabezpieczone

deus i co zxorujesz a ktoś odxoruje i ma hasło =) a jak posiekasz na skrawki to ni hu hu zanim rozgryzie które cyferki są od hasła żeby zacząć je sobie składać to obgryzie paznokcie az do łokci ze stresu =)

Potwoor_ napisał:

deus i co zxorujesz a ktoś odxoruje i ma hasło =) a jak posiekasz na skrawki to ni hu hu zanim rozgryzie które cyferki są od hasła żeby zacząć je sobie składać to obgryzie paznokcie az do łokci ze stresu =)

Litości!!.... Chyba nie sądzisz, że deus pisząc o xor'e miał na myśli to co ja później podałem jako przykład? Możesz mi wierzyć - na tym możliwości szyfrowania za pomocą xor'a sie nie kończą. (Z tego co wiem)Jakieś wielkie to one nie są, ale coś mie zdaje ze i takwieksze niz "posikanie na skrawki".... Chyba, że źle Cie zorzumiałem - opisz dokładniej co chcesz zrobić z hasłem najlepiej daj kawałek kodu albo gotowy program. A po co mam się zastanawiac, które cyferki są od czego? Jasne, żem ożna ale po co sie wysilac? Prześledze debugerem fragment kodu, który rozszyfruje to za mnie. I juz. Hop siup, mam haslo :) W teori wyglada pieknie, niestety nie zawsze tak jest :]

P.S.
Dobra rada - nie licz na to, że deus nie da rady - byly już takie przypadki(1 i 2 Właściwie to w obu przypadkach jeden i ten sam człowiek :] Jak chcesz to wrzuc tutaj swoje dzieło - chetnie poobgryzam paznokcie :P

* jak już dajesz linki do wątków z RE to dodam jeszcze jeden, nawet ciekawszy - Wyzywam cię na pojedynek! :> * deus

Ranides napisał(a)

a masz w nazwa.pl PHP? to niech skrypty PHP łączą się z bazą danych przez tajne hasło. A program, żeby już nie komplikować, niech pobiera dane przez API:

www.mojastrona.pl/pobierz.php?co=dane&sid=43465644334r221
www.mojastrona.pl/ustaw.php?co=dane&sid=43465644334r221

Co to jest sid? sesja. na podstawie SID serwer określa, czy masz prawa pobrać, zmienić, zapisać, usunąć... Taki SID niech będzie przydzielany tymczasowo. Twój program nie wie, co jest w SID, po prostu go używa.

Twój program niech nie trzyma żadnych haseł "współdzielonych", które "mogą wszystko", a jedynie prywatne hasło i login każdego użytkownika oddzielnie. Ba, program podczas startu o hasło i login może pytać. O SIDa niech prosi, na przykład tak:

www.mojastrona.pl/pobierz_sid.php?user=blabla&password=blabla

skrypt dostał hasło i login, sprawdza w tabeli userów uprawnienia. Tworzy w tabeli "sesje" nową pozycję, zapisuje w niej czas utworzenia, IP, użytkownika i tak dalej, wszystko co potrzebne. programowi zwraca numer tej pozycji i tyle.

od czasu do czasu niech skrypt przejedzie po tabeli, żeby usunąć stare sesje (np starsze niż 10 minut)

skrypty ustaw.php i pobierz.php dostają żądanie oraz SID. Sprawdzają, czy dany SID pozwala na daną czynność. Jeśli SID w ogóle nie istnieje, ładują błędem "0:zła sesja". Jeśli SID nie pozwala na daną rzecz, to masz błąd "1:brak praw".

Z twojej strony jest to bezpieczne, nikt ci danych nie zabierze, nikt nie zrobi nic złego. Z punktu widzenia użytkowników bezpiecznie nie jest, bo dane logowania lecą przez GET i to gołe i wesołe.

Możesz to zmienić oczywiście, tworząc połączenie https, słać dane w POST, dać skrót hasła, a nie hasło itd. Metodę z GET podałem, bo może być bardzo prosto zrobiona za pomocą skryptów PHP plujących danymi za pomocą echo, oraz funkcji URLDownloadToFile w programie, która po prostu pobiera treść strony www. A tobie, jako udostępniającemu zapewnia bezpieczeństwo. Po prostu użytkowników łatwo podsłuchać, ale ich to $#$ ;P

dopisane:
No i trzeba zrobić stronę rejestracji, to też możesz zrobić jako skrypt, jeśli robotów się nie boisz:

www.mojastrona.pl/rejestruj_goscia_ktory_nic_prawie_nie_moze.php?nowy_user=blabla&jego_password=blabla

albo porządniejszą, ładniejszą stronkę...

Muszę przyznać ze pomysł jest bardzo dobry i w miarę wygodny bo obsługa MySQL (a w szczególności wyświetlanie wyników) jest tam banalne... a do tego wszystkie dane wysyłał bym POST'em za pomocą cURL'a...

Myślałem sam nad takim rozwiązaniem tylko odstraszyło mnie to ze jak przyjdzie skryptowi wyświetlić załóżmy kilka tysięcy rekordów to czy nie będzie to za bardzo wstrzymywało działania aplikacji tej w C++ ??
Albo inny przypadek... użytkownik będzie chciał wyświetlić tylko jeden rekord to czy czas, który będzie potrzebował skrypt na wykonanie zapytania (sprawdzenie poprawności i terminu sesji, analiza typu zapytania - SELECT, DROP, INSERT, i porównanie tego z uprawnieniami użytkownika) nie będzie zbyt długi w porównaniu z połączeniem bezpośrednim prze aplikację C++ z MySQL?? Bo w moim programie przewiduję taką sytuację kiedy po kolei może być wysyłanych około tysiąc pojedynczych zapytań do bazy (na przemian pobieranie danych i wstawianie nowych) więc jak by tak za każdym razem miało to spowalniać aplikację to lepiej przenieść się na inny serwer gdzie będę miał dostęp do bazy danych o nazwie "mysql" gdzie ustawie odpowiednie uprawnienia dla jednego wspólnego usera...

oj Panie Zielonka, narzut to w tym jest jak cholera :D
pomijam koszty weryfikacji (jeden SELECT z tabeli indeksowanej, zwraca 2 liczby: czas i maskę bitową uprawnień). Ogromny narzut to samo PHP. Wszystkie dane z bazy lecą do wirtualnej maszyny Zend, ona je sobie miesza, i dopiero wypluwa na wyjście jako tekst, ty ten tekst pobierasz, musisz przeparsować z powrotem do jakiejś struktury danych...

tak na oko:
obciążenie samej bazy dużo mniej niż +100% (każde pytanie zamienia się w 2 pytania, ale "pytanie weryfikujące" jest proste)
obciążenie serwera: więcej niż +200% - koszt odebrania z bazy i koszt wysłania do HTML
obciążenie aplikacji: za cholerę nie wiem ile, ale tu wielokrotności będą. koszty parsowania tekstu są wysokie.

hosting pewnie wytrzyma, tego, że zarzynasz serwer może nawet nie zauważysz. Aplikacja może chodzić wolniej, dużo wolniej, jeśli będzie musiała odbierać dużo danych i zamieniać na tablice.

aha... hmm... w takim razie nie pozostaje mi chyba nic innego jak dogadać się z administracją nazwa.pl żeby oni ustawili mi odpowiednie uprawnienia dla kilku użytkowników :P :D

możesz też dodatkowo zaszyfrować dane, wpleść w nie śmiecia, dodać fałszywe konta, co pewien czas zmieniać szyfrowanie, nazw kont i sposób dostępu czy inne rzeczy,

ale nasuwa się pytanie czy komukolwiek tak zależy na tych danych że bęzie próbować się do bazy włamać?

Dla osób dla których przeznaczony ma być ten program dane z tej bazy danych są bardzo cenne :P :D

A dla innych? Jak długo dane musza pozostać niejawne? Jak poważne byłyby konsekwencje ich ujawnienia? Komu może zależeć na ich przejeciu i jakimi możliwościami może dysponować /tak, zgodnie z maksyma Shannona teoretycznie powinno się zakładać, że dysponuje wszystkimi dostępnymi/. To są podstawowe kryteria wyboru metody szyfrowania i ochrony danych.

Ranides napisał(a)

oj Panie Zielonka, narzut to w tym jest jak cholera :D
pomijam koszty weryfikacji (jeden SELECT z tabeli indeksowanej, zwraca 2 liczby: czas i maskę bitową uprawnień). Ogromny narzut to samo PHP. Wszystkie dane z bazy lecą do wirtualnej maszyny Zend, ona je sobie miesza, i dopiero wypluwa na wyjście jako tekst, ty ten tekst pobierasz, musisz przeparsować z powrotem do jakiejś struktury danych...

tak na oko:
obciążenie samej bazy dużo mniej niż +100% (każde pytanie zamienia się w 2 pytania, ale "pytanie weryfikujące" jest proste)
obciążenie serwera: więcej niż +200% - koszt odebrania z bazy i koszt wysłania do HTML
obciążenie aplikacji: za cholerę nie wiem ile, ale tu wielokrotności będą. koszty parsowania tekstu są wysokie.

hosting pewnie wytrzyma, tego, że zarzynasz serwer może nawet nie zauważysz. Aplikacja może chodzić wolniej, dużo wolniej, jeśli będzie musiała odbierać dużo danych i zamieniać na tablice.

Tak czy tak będzie musiała odebrać te dane bo wszystko będzie z bazy pobierane... Więc samo obciążenie bazy będzie w obu przypadkach identyczne... Chodziło mi tylko o samą różnice korzystania z PHP :P

A jest może jakiś sposób na to zeby odebrać cały blok danych, w takiej postaci jak odbiera ją aplikacja w C++, wprost do drugiej aplikacji w C++? (czyli coś jakby tablica)
Jednym sposobem było by pewnie napisanie aplikacji w exe na serwerze... ale czy jest jakiś sposób na to zeby program miał do niej dostęp, a hacker który by odnalazł ścieżkę dostępu do nie mógł jej pobrać?

EDIT:
Wymyśliłem coś takiego...
Aplikacja z komputera zwykłego wysyła zapytanie do aplikacji na serwerze (do której dostęp ma każdy: 777). Ta aplikacja z kolei wysyła je do trzeciej (do której uprawnienia ma tylko admin... czyli w tym wypadku aplikacja uruchomiona na serwerze 655 bodajże)... Ta 3 aplikacja wysyła zapytanie do MySQL odbiera wynik i w niezmienionej postaci wysyła go do 2 aplikacji... ta 2 aplikacja wysyła go z kolei do tej pierwszej (czyli do użytkownika) :D Wydaje sie być to dobre rozwiązanie ale czy możliwe w realizacji?? i czy dobre na tyle żeby zrezygnować z realizacji z PHP??

EDIT2:
deus => jeśli nie wiadomo o co chodzi to chodzi o kase :D właśnie w celach zarobkowych ktoś mógłby te dane przechwycić... Łatwo te dane opchnąć za niezłą kase :P Im więcej tych danych tym większa kasa :PP

@Edit - a co to da? Aplikacja działająca po stronie serwera to czarna skrzynka dla potencjalnego atakującego, o jej działaniu może dowiedzieć się jedynie eksperymentując i analizując komunicjację z klientem.
@EDIT2 - świat opiera się na zysku, ze względu na różnie pojęty zysk toczono wojny, nawet religijne. Tutaj trzeba mieć konkretne dane aby oszacować konieczny poziom zabezpieczeń, z armatą na muchę lepiej się nie wybierać, może to co najwyżej zbędnie obciążyć aplikację i docelowego klienta /tego w sensie kosztów uzyskania, utrzymania, szkolenia itd./. Z drugiej strony jeżeli dane są faktycznie krytyczne to każde zabezpieczenie jest na wagę złota. Metoda przedstawiona przez ranidesa jest może i wygodna ale daje ogromny narzut a jakiegoś nadmiernego bezpieczeństwa nie zapewnia. Co do niezłej kasy - albo piszesz coś ogromnego dla rządu\inszej poważnej instytucji albo kasa taka 'niezła' nie będzie.
Skłaniałbym się, jeżeli już stawiamy aplikację po stronie serwera, na własny protokól komunikacyjny, z bezpiecznym logowaniem, szyfrowany. Przy każdej operacji walidacja praw danej sesji po stronie serwera - wymaga to zapisania w bazie danych praw konkretnych użytkowników programu jak i grup.
Kolejna sprawa - potrzebne dane zapisane są w programie, tak? Użytkownik bazy danych jest współny czy też dla każdego klienta oddzielny, ew. zgodny z uprawnieniami?
Zakładamy, że osoby niepowołane będą mieć dostęp do działającej kopii programu, z odpowiednimi poświadczeniami? /tak by wypadało/.

Wymyśliłem coś takiego...
Aplikacja z komputera zwykłego wysyła zapytanie do aplikacji na serwerze (do której dostęp ma każdy: 777). Ta aplikacja z kolei wysyła je do trzeciej (do której uprawnienia ma tylko admin... czyli w tym wypadku aplikacja uruchomiona na serwerze 655 bodajże)... Ta 3 aplikacja wysyła zapytanie do MySQL odbiera wynik i w niezmienionej postaci wysyła go do 2 aplikacji... ta 2 aplikacja wysyła go z kolei do tej pierwszej (czyli do użytkownika)

... i po miesiącu user dostaje infrormacje, że udalo mu się zalogować do systemu ;-P

* na tym cały vic polega aby mechanika była jak najbardziej przeźroczysta z punktu widzenia usera, jak najmniej dodatkowych 'widocznych' elementów wnosiła * deus

deus napisał(a)

@Edit - a co to da? Aplikacja działająca po stronie serwera to czarna skrzynka dla potencjalnego atakującego, o jej działaniu może dowiedzieć się jedynie eksperymentując i analizując komunicjację z klientem.
(...)
Skłaniałbym się, jeżeli już stawiamy aplikację po stronie serwera, na własny protokól komunikacyjny, z bezpiecznym logowaniem, szyfrowany. Przy każdej operacji walidacja praw danej sesji po stronie serwera - wymaga to zapisania w bazie danych praw konkretnych użytkowników programu jak i grup.
Kolejna sprawa - potrzebne dane zapisane są w programie, tak? Użytkownik bazy danych jest współny czy też dla każdego klienta oddzielny, ew. zgodny z uprawnieniami?
Zakładamy, że osoby niepowołane będą mieć dostęp do działającej kopii programu, z odpowiednimi poświadczeniami? /tak by wypadało/.

No a dało by to to że ta druga aplikacja sprawdzała by informacje które są wysyłane do serwera - czy nie jest to np. DROP (użytkownik co prawda mógłby ją ściągnac ale co by z nią zrobił jak nie miała by żadnych informacji o haśle do bazy danych ani niczego podobnego) Trzecia aplikacja łączyła by sie z bazą danych i pobierała potrzebne wyniki... Następnie by je zwracała do tej poprzedniej a ta do tej pierwszej która ją wywołała. (myślę że było by to szybsze niż C++ i PHP)
Pobranie aplikacji 3 (która zawierała by dane logowania i która wysyła zapytania bezpośrednio do MySQL) nie było by możliwe dzięki atrybutom pliku, a apache by odrzucał prośby o pobranie tej aplikacji. Aplikacja 2 miała by dostęp do tej 3 ponieważ znajdowała by sie w tej samej lokalizaji czyli na localhoscie.

Oto schemat blokowy jak bym coś niezrozumiale wytłumaczył:
http://img177.imageshack.us/my.php?image=beztytuuhx1.jpg

EDIT:
A co do kasy... Dla jednego "niezła kasa" jest naprawde niezła a dla drugiego marna... Patrząc z mojego punktu widzenia jest duza.

A co do własnego protokołu to dopiero weszło by w życie z drugą wersją projektu. na razie muszę sprawdzić czy by się to wszystko sprawdziło ;)

Słuchaj człowieku, czy pierwsza i jedyna aplikacja nie może filtrować zapytań? Nie mówię o 'programie' w rodzaju skryptu '/?get' czy '/?set'... Tutaj chodzi o aplikację serwerową, przyjmującą połączenia od klientów...

Hmm... chyba się nie rozumimy albo ja nie pojmuję Twojego pomysłu...

Chodzi o to ze jeżeli napiszę aplikację, która będzie łączyć się z MySQL, analizować zapytania i zwracać wyniki, oraz być po prostu pośrednikiem pomiędzy użytkownikiem, a bazą danych (wszystko dzieje sie poprzez sieć Internet) to ktoś kto zwyczajnie zdekompiluje sobie aplikacje (tą którą będę udostępniał wszystkim) będzie miał ścieżkę dostępu do tego pośrednika, którego wrzuciłem przez FTP na serwer wirtualny. Później zwyczajnie przez Http mógłby sobie go ściągnąć, zdekompilować i mieć wszystkie potrzebne dane.
Mam racje?