Mam pytanie
Będę jednym exe-kem otwierał inny exe. Tylko jak uruchomię ten drugi exe-k samofzielnie to ma mi się nie otwierać. Tylko ma się uruchomić z programu, który wywołuje exe-k. Czy można cos takiego zrobić ? Przypominało by to postać programu i dll-ki.
0
0
program nadrzędny uruchamia program podrzędny z parametrem, a program podrzędny sprawdza, czy parametr jest i czy jest prawidłowy. Jeśli nie ma parametru lub jest zły to info, że można uruchomić tylk z programu głównego i koniec. Cały pic polega na tym aby parametr był jak najbardziej "zakręcony"
0
Parametr jest złym sposobem - rzut oka na wnętrzości programu i od razu wiadomo co dopisać.
Prędzej zainteresowałbym się informacją o procesie nadrzędnym, sprawdzeniu klasy, jakiejś sumy kontrolnej etc.
0
Marooned napisał(a)
Parametr jest złym sposobem - rzut oka na wnętrzości programu i od razu wiadomo co dopisać.
Prędzej zainteresowałbym się informacją o procesie nadrzędnym, sprawdzeniu klasy, jakiejś sumy kontrolnej etc.
Można też pozmieniac cos w hexedytorze i przed uruchomieniem programu to naprawiac, najlepiej jeżeli to exe po Windows to zmienić tak zawsze pokazywało się dosowe okienko, że program musi być uruchomiony na Windows (nie pamiętam dokładnie tresci tego komunikatu) albo po prostu nagłówek (Sygnaturę MZ) wtedy Windows stwierdzi, że to niepraidłowy exe i wyświetli stosowny kominikat.
Tylko wadą tego rozwiązania jest to że program pierwszy musi działać w tle i czekać na zakończenie drugiego po to aby wszystko zpowrotem pozmieniac. Drugą sprawą jest to że wrazie jak się Windows wykrzaczy to pozostanie na dysku exe który można będzie bez problemu uruchomić. Trzecia wadą jest to że jeżeli osoba która mogła by spróbować uruchomić program miała by jakieś pojęcie o budowie plików PE to sobie sama program w hexedytorze naprawi. :-/
EDIT// Tylko tego pierwszego chyba nie da się zrobić bez zawasnaowanego rewerseengineringu. Trzeba by sprawdzić ale nie mam czasu.
EDIT2//
A jednak wystarczy zmiana jednego bajtu i już jest piękne dosowe okienko (przynajmniej na Win98)
0
Marooned napisał(a)
Parametr jest złym sposobem - rzut oka na wnętrzości programu i od razu wiadomo co dopisać.
Prędzej zainteresowałbym się informacją o procesie nadrzędnym, sprawdzeniu klasy, jakiejś sumy kontrolnej etc.
a niby dlaczego? Wystarczy parametr przekazywać nie jawnie ale przez zmienną (chodzi mi o nie wpisanie np. ('moja_app.exe terazsiemozeszuruchomic') tylko ('moja_app.exe ' + param)) a parametr do zmiennej wpisywać w kilku miejscach po kawałku, np. wywołując kolejno pfunkcje
function dodajpar1: string
begin
result := 'jakasczescparametru';
end;
function dodajpar2: string
...
wszystko zależy od inwencji twórczej osoby, która to pisze
0
zgadzam się z Maroonedem co do linii poleceń - chyba, że większość execa jest zaszyfrowana, pod EP jest dekrypter a poprzez linię poleceń przekazywany jest klucz, którego forma zależy np. od aktualnego czasu. Klucz z linii poleceń dopiero po odpowiednim przeliczeniu używany jest do deszyfrowania - jeśli zły to execa mamy z głowy ;) ...tylko, że to już podchodzi pod exeprotektory a tu bez asma i świetnej znajomości PE wiele się nie zdziała... nie radzę zmieniać sygnatury MZ - takie rzeczy jak modyfikacja execa w celu blokady uruchomienia robi się poprzez debug api /a jeśli nie ma 'MZ' na początku pliku to sytem nie będzie chciał takiego obrazu zaladować - ogólnie nowsze windowsy są bardzo wrażliwe na grzebanie także w nagłówku PE/. Co do
Najlepiej jeżeli to exe to zmienic tak zawsze pokazywało się dosowe okienko, że program musi być uruchomiony na windows (nie pamiętam dokładnie tresci tego komunikatu)
jeśli dobrze rozumiem to chodzi o zrobienie tak, aby zamiast odpalić sie program pokazywało się info o potrzebie windy... to nie przejdzie - dosstub to zwykły program dosowy wpakowany na początek execa i w trybie 32bit pod win jest całkowicie ignorowany /swego czasu zrobiłem dzięki temu hybrydę execa i html/. Jeśli już chcecie modyfikować execa to polecam spisanie pierwszego bajtu z EP i zmianę na 0xc3 /retn/. Program nadrzędny tworzy proces z flagą DEBUG_PROCESS potem WaitForDebugEvent pobranie kontekstu i zapis właściwego bajtu pod eip /WriteProcessMemory/. Takie rozwiązanie ma swoje wady ale jest banalne w implementacji nawet dla osób nie znających aseblera i struktury plików formatu PE...'
tylko nadal zastanawiam się 'po kiego grzyba' loader?
0
Deus napisał(a)
Najlepiej jeżeli to exe to zmienic tak zawsze pokazywało się dosowe okienko, że program musi być uruchomiony na windows (nie pamiętam dokładnie tresci tego komunikatu)
jeśli dobrze rozumiem to chodzi o zrobienie tak, aby zamiast odpalić sie program pokazywało się info o potrzebie windy... to nie przejdzie - dosstub to zwykły program dosowy wpakowany na początek execa i w trybie 32bit pod win jest całkowicie ignorowany /swego czasu zrobiłem dzięki temu hybrydę execa i html/. Jeśli już chcecie modyfikować execa to polecam spisanie pierwszego bajtu z EP i zmianę na 0xc3 /retn/. Program nadrzędny tworzy proces z flagą DEBUG_PROCESS potem WaitForDebugEvent pobranie kontekstu i zapis właściwego bajtu pod eip /WriteProcessMemory/. Takie rozwiązanie ma swoje wady ale jest banalne w implementacji nawet dla osób nie znających aseblera i struktury plików formatu PE...'
tylko nadal zastanawiam się 'po kiego grzyba' loader?
A spróbuj zmienic bajt pod adresem 0x3C np. na cokolwiek np. 0xE9 i mamy piękne
"This program cannot be run in DOS mode." znaczy że jednak Windows (98, XP) coś tam jednak czyta. Sprawdzałem to na 3 programach napisanych w Delphi, Visual C++ i MASM32
A co do sygantury MZ to 4D5A zmieniłem na 0000 i na XP wchodzi tylko dosowe okienko (na 98 jeszcz3e nie sprawdziłem).
EDIT// Win 98 wyswietla MessageBox "Bład podczas wkonywania programu"
EDIT2// Co do twojego rozwiązania to można to zrobić bardziej elegancko w wiekszości programów jest trochę wplnego miejsca w sekcji z kodem (a jak nie ma to można dodać nową sekcję) więc można by sie pobawić np. w wyświetlenie MessageBoxa.
0
dobra, dobra, ale musiałbyś modyfikować plik na dysku aby go odpalić... co z tego, że zmodyfikujesz np. ptr do nagłówka PE jeśli program zostanie odpalony jako dosowy - musisz wtedy zmodyfikowac plik na dysku a co za tym idzie chociaż na chwilę go naprawić... Wystarczy tylko w odpowiednim momencie skopiowac plik i po twoim zabezpieczeniu... metoda z 0xc3 ma jeden niezaprzeczalny plus - program modyfkujesz na dysku tylko raz - w celu 'zabezpieczenia' - potem tylko wgrywasz 'co trzeba' do pamięci utworzonego procesu i idzesz na piwo... a swoją drogą to już lepiej byłoby zaszyfrować sekcję kodu chociażby xorem i deszyfrować poprzez proces nadrzędny...
// 'MZ' jest wymagany...
// i kolejny edit: wierz mi, znam się na tym... więc co proponujesz? /moim zdaniem deszyfrowanie poprzez np. 'wstrzykiwanie' unpackera to całkiem dobra metoda - pewniejsza niż zwykły unpack/
// obaczymy co Marooned na to powie /może coś prostego i zarazem skutecznego wymyśli/
0
Deus napisał(a)
dobra, dobra, ale musiałbyś modyfikować plik na dysku aby go odpalić... co z tego, że zmodyfikujesz np. ptr do nagłówka PE jeśli program zostanie odpalony jako dosowy - musisz wtedy zmodyfikowac plik na dysku a co za tym idzie chociaż na chwilę go naprawić... Wystarczy tylko w odpowiednim momencie skopiowac plik i po twoim zabezpieczeniu... metoda z 0xc3 ma jeden niezaprzeczalny plus - program modyfkujesz na dysku tylko raz - w celu 'zabezpieczenia' - potem tylko wgrywasz 'co trzeba' do pamięci utworzonego procesu i idzesz na piwo... a swoją drogą to już lepiej byłoby zaszyfrować sekcję kodu chociażby xorem i deszyfrować poprzez proces nadrzędny...
// 'MZ' jest wymagany...
Zgadza się, tylko jest to trochę trudniejsze w implementacji, jednak przy znajomości WinApi nie ma problemu. Gorzej jezeli program który ma być blokowany ma zabezpieczenie przed crakingiem (debugger ) ale jezeli nie to tak jak napisałem (wyedytowalem) poprzedniego posta można sie pobawić nawet w wyświetlenie stosownego MessageBox.
EDIT//
Samo zaszyfrowanie sekcji kodu jest troche bez sensu, program uruchomiony normalnie (bez loadera) najprowdopodobjiej wywali sie już po kilku pierwszych instrukcjach i może spowodować nie stabilnośc Windows
0
dobrze, to może teraz poskładaj wszystko - aby było jasne i czytelne... bo sie pogubiłem ;)
edit:
EDIT//
Samo zaszyfrowanie sekcji kodu jest troche bez sensu, program uruchomiony normalnie (bez loadera) najprowdopodobjiej wywali sie już po kilku pierwszych instrukcjach i może spowodować nie stabilnośc Windows
a co pisałem o 0xc3? xor ma to do siebie, że można wyliczyć maskę tak, aby zaszyfrowany pierwszy bajt miał postać właśnie 0xc3... /jak wiesz jest to powrót - w tym przypadku do loadera z kernela32/
0
Deus napisał(a)
dobrze, to może teraz poskładaj wszystko - aby było jasne i czytelne... bo sie pogubiłem ;)
No dobra, zgadzam się ze lepiej naprawiać program w pamięci. Tyle, że trudniej to zrobić. Ale jezeli ktoś wie o czym mowa to sobie poradzi. Więc najlepiej przerobić program tak aby uruchomiony bez loadera wyświetlił jakis tam MessageBox (chodzi mi o dodanie kodu), a jeżeli będzie załadowany przez loader to loader entrypoint na prawidłowy i (ew. odszyfruje program).
EDIT// Teraz kapuję pierwszy bajt na który wskarze EP ma mieć warośc 0xC3 po zaszyfrowaniu. :) No ok, ale lepiej z MessageBox aby poinformować użytkownika że nie może uruchomić tego programu.
Tylko po co loader do tego, czy nie można w Windows (chyba że to ma być uruchamiane na Windows 9x) ograniczyć praw użytkownikowi?
0
Marooned napisał:
Parametr jest złym sposobem - rzut oka na wnętrzości programu i od razu wiadomo co dopisać.
Całość spakowana byłaby UPX-em albo innym pakerem. ProcDump-em można by odpakować i sprawdzić. Kto jednak by zadał sobie taki trud.
KAzek napisał:
Można też pozmieniac cos w hexedytorze
Dobrym sposobem byłoby w HEX-sie pozamieniać znaki, ale program wraz z podprogramem będzie znajdował się na płycie CD-ROM. Trudno byłoby naprawić, chyba, że w pamięci.
Myślałem o czymś takim:
PROGRAM GŁÓWNY:
var
H : THandle;
begin
ShellExecute(Handle,open', 'CD_ROM\Poboczny.exe', nil, nil, SW_SHOWNORMAL);
H := FindWindow(nil, 'Form1');
SetWindowPos(H, HWND_TOP, 101, 101, 101, 101,SWP_SHOWWINDOW);
PROGRAM POBOCZNY:
Ustawiam tak:
BorderStyle -> bsSingle
BorderIcons -> biMinimize -> False
BorderIcons -> biMaximize -> False
if (Form1.Width = 100) and (Form1.Height = 100) and (Form1.Top = 100) and (Form1.Left = 100) then
FatalAppExit(0, 'Program może być uruchomiony'+#13+'tylko z pozycji programu głównego.');
Oczywiście w <ort>najprostrzy </ort>sposób.
0
Bruno(M) napisał(a)
Marooned napisał:
Parametr jest złym sposobem - rzut oka na wnętrzości programu i od razu wiadomo co dopisać.
nawet nie trzeba, gdzieś miałem program monitorujący z tej samej firmy co monitor rejestru, sieci i plików na dysku, że pokazywał co jest uruchamiane, kiedy i z jakimi parametrami
0
a co za problem odpalić debugger i postawić bpx'a na GetCommandLineA\W ?? Co do upx'a to 'Kto jednak by zadał sobie taki trud'? Mnie rozpakowanie aspacka czy upx'a /ręczne/ zajmuje na oko z pół minuty... Każdy kto potrafi jako-tako obsługiwać debugger sobie poradzi... Jak już zabezpieczać to zabezpieczać... ukrycie formy to niezbyt ciekawy pomysł. Może napisz w jakim celu konkretnie zabezpieczasz program, na jakich zasadach ma się to opierać a coś się wymyśli...
//Adamo - chodzi ci może o te toolsy? http://sysinternals.com/
0
Może napisz w jakim celu konkretnie zabezpieczasz program, na jakich zasadach ma się to opierać a coś się wymyśli...
Napisałem program multimedialny. W zamierzeniu myślałem tylko o nim, i że nic w między czasie nie dopiszę do niego. Żadnych dodatków. Jednak dopisywałem różne do niego programy, których nie tworzyłem w dll-kach. Okazało się, że jak znajomi go widzieli, to bardziej skupiali się na podprogramie, niż na programie głównym :/ Niechciałbym, aby program główny zszedł do lamusa, a program poboczny był skopiowany na pulpit i odpalany. Albo też przesłany netem do osób, których go nie powinny mieć. Całość (program główny) zawiera sporo mb, więc kolejne utrudnienie. Nie chodzi mi o zabezpieczenie typowe, dla osób, które lubią 'bawić' się w łamanie takich programów, tylko o zabezpieczenie z którym przeciętna osoba, niewiedząca co to HEX, procesy nie złamnie tego.
0
to mam taką propozycję: program 'potomny' za pomocą CreateToolhelp32Snapshot z Process32First pobiera info o sobie - a konkretnie o rodzicu.
Jak to zaimplementować? Chyba najprościej poprzez listę jednokierunkową /struktury PROCESSENTRY32/. Po pobraniu informacji o wszystkich procesach szukamy swojego/po nazwie execa - zwykle będzie ostatni/, jak znajdziemy to bierzemy th32ParentProcessID i szukamy procesu o takim th32ProcessID. Potem pozostaje tylko porównanie nazwy execa... z właściwą nazwą rodzica.
//do postu poniżej - trzeba już mieć utworzone okno... chociaż fakt faktem metoda prosta i dosyć skuteczna.
0
Możesz to zrobić za pomocą FindWindow oraz SetWindowLong() i GetWindowLong().
0
Deus Przyjrzę się temu.
http://www.pcconcrete.ro/phtml/10/r10467b.html
http://www.swissdelphicenter.ch/torry/showcode.php?id=616
Dziękuje Wam Wszystkim [soczek]
0
widzę jeszcze inne rozwiązanie - uruchamiany program otwiera sobie potok nazwany albo gniazdo tcp i nasłuchuje - nazwijmy go serwerem. jeśli w przeciągu krótkiego czasu od uruchomienia nie przyjdzie odpowiedni komunikat, serwer kończy swoje działanie. jeśli jakiś klient się zgłosi, to serwer wysyła mu jakieś dane - mogą być losowe, klient je szyfruje (rsa, des - cokolwiek, symetryczne czy asymetryczne), zwraca serwerowi, ten odszyfrowuje i porównuje z danymi wcześniej wygenerowanymi. jeśli nie otrzymuje odpowiedzi albo jest nieprawidłowa, no to wiadomo co zrobić...
oczywiście taki algorytm zabezpieczenia przed niepowołanym uruchomieniem każdy bardziej zaawansowany programista może złamać, ale to samo tyczy się i wszystkich innych zabezpieczeń.
0
W kodzie ze strony:
http://www.delphipraxis.net/topic26805,previous.html
zamiast w buttonie dodaję w oncreate formy oto taki kod (program poboczny):
if IsEXE_Running('Program_glowny.exe', False) and (FindWindow(nil,'Nazwa okna glownego') <> 0) then
else
FatalAppExit(0, 'Uruchom program z pozycji programu głównego');
Natomiast programem głównym wywołuję program poboczny, który szuka uruchomionego execa (Program_glowny) i nazwę okna (Nazwa okna glownego). Czy takie zabezpieczenie łatwo waszym zdaniem złamać w pamięci?