bawilem sie wczoraj jeszcze troche wspominanym OllyDebug
i zaobserwowalem co nastepuje (o ile nie myli mnie pamiec co do
szczegolow adresow bo nie robilem notatek):

modul mojej aplikacji exe zostala wgrany pod adres 0x40000000
(albo 0x40001000 w kazdym razie tutaj byl punkt startowy)
- to sie zgadza z tym co czytalem ze domyslnie pod ten adres mapowane
sa exeki;

chyba od razu za tym (o ile pamietam) byla duza sekcja danych (glownie zera
wiec chyba tam byly zaalokowane malokiem i statycznie tablice)

pod adresami 0x7xxxxxxx w przestrzeni procesu znajdowalo sie
kilkanascie dllelek glownie systemowych jak kernel32.dll
(swoich wlasnych aplikacja nie uzywa) i pare tez mi nie znanych
ale chyba okolosystemowych, plus jedna ("hook.dll" o ile
pamietam ) pochodzaca z mojego slownika polsko angielskiego
firmy techland - ten slownik zaklada takie hooki bo ma opcje
kontekstowych tlumaczen tekstow odrazu z aplikacji

ciakawa wogole sprawa; jak to jest ze te dllki sa mapowane w
prywatnej przestrzeni procesu? zdawalo mi sie ze powinny byc one
w wyzszej polowce adresow systemowych; drugie pytanie czy da sie
wypatrzec wiecej ciekawego info jak powyzsze, debuggerem w przestzreni
prywatnej procesu? jak dokladnie z pol PE mozna orzec gdzie zostana
zmapowane sekcje i kore sekcje są 'minimalne'; czy da się zrobic
funkcjonalny program PE wylacznie z sekcja .text (plus ewentualnei
tablice importow i exportow) czy raczej jeszce jakies powinny byc?
borland 55 ktorego uzywam kompiluje o ile dobrze pamietam az osiem
sekcji z ktorego jednanazywa sie .tls - co to moze byc?

tia, slamazar

uzywam



--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry

W dniu 28.12.2010 09:46, slamazar pisze:
> bawilem sie wczoraj jeszcze troche wspominanym OllyDebug
> i zaobserwowalem co nastepuje (o ile nie myli mnie pamiec co do
> szczegolow adresow bo nie robilem notatek):
>
> modul mojej aplikacji exe zostala wgrany pod adres 0x40000000
> (albo 0x40001000 w kazdym razie tutaj byl punkt startowy)
> - to sie zgadza z tym co czytalem ze domyslnie pod ten adres mapowane
> sa exeki;
>
> chyba od razu za tym (o ile pamietam) byla duza sekcja danych (glownie zera
> wiec chyba tam byly zaalokowane malokiem i statycznie tablice)

Albo dopełnienie w celu wyrównania adresu kolejnej sekcji do granicy
4096 bajtów.

> pod adresami 0x7xxxxxxx w przestrzeni procesu znajdowalo sie
> kilkanascie dllelek glownie systemowych jak kernel32.dll
> (swoich wlasnych aplikacja nie uzywa) i pare tez mi nie znanych
> ale chyba okolosystemowych, plus jedna ("hook.dll" o ile
> pamietam ) pochodzaca z mojego slownika polsko angielskiego
> firmy techland - ten slownik zaklada takie hooki bo ma opcje
> kontekstowych tlumaczen tekstow odrazu z aplikacji
>
> ciakawa wogole sprawa; jak to jest ze te dllki sa mapowane w
> prywatnej przestrzeni procesu? zdawalo mi sie ze powinny byc one
> w wyzszej polowce adresow systemowych;

Może tam są, tylko w procesie wyglądają na zmapowane pod niższe
adresy. Ale może to być kwestia tego, że program jest uruchomiony pod
debugerem - on też korzysta z wywołań systemowych, może więc
"przechwytuje" je dla programu: wstawia swoje zaślepki pod adresami
0x7xxxxxxx (aby na przykład można było podejrzeć parametry
uruchamianych funkcji), po czym odwołuje się do tych właściwych już
pod innymi, "bardziej standardowymi" adresami.

> drugie pytanie czy da sie
> wypatrzec wiecej ciekawego info jak powyzsze, debuggerem w przestzreni
> prywatnej procesu?

Zależy, co Cię interesuje. Sekcje kodu i danych na pewno można
zobaczyć, pewnie też sekcję zasobów (.res, czy jakoś podobnie,
zawierającą m.in. identyfikatory elementów interfejsu graficznego).
Sekcja .bss to dane niezainicjalizowane (program mówi, ile potrzebuje,
a system mu daje w chwili uruchamiania). Gdzieś też (raczej pod
wyższymi adresami) powinien być stos.

> jak dokladnie z pol PE mozna orzec gdzie zostana
> zmapowane sekcje

Tego nie wiem. W zasadzie nie wiem nawet, czy w ogóle się da. Może
program ładujący ma w sobie zapisane te adresy. Ostatnie wynalazki w
stylu losowanie adresu przestrzeni danych mogłyby świadczyć, że w
nagłówku nie ma tych informacji (albo program ładujący je ignoruje).
Ale może poczekajmy, aż wypowie się ktoś bardziej kompetentny w
temacie formatu PE.

> i kore sekcje są 'minimalne'; czy da się zrobic
> funkcjonalny program PE wylacznie z sekcja .text (plus ewentualnei
> tablice importow i exportow) czy raczej jeszce jakies powinny byc?

Jeśli nie używasz żadnych zmiennych, to możliwe, że te wystarczą. Ale
głowy nie dam.

> borland 55 ktorego uzywam kompiluje o ile dobrze pamietam az osiem
> sekcji z ktorego jednanazywa sie .tls - co to moze byc?

Thread-local storage.

--
Pozdrawiam/Regards - Bogdan (GNU/Linux & FreeDOS)
Kurs asemblera x86 (DOS, GNU/Linux):http://rudy.mif.pg.gda.pl/~bogdro
Grupy dyskusyjne o asm: pl.comp.lang.asm alt.pl.asm alt.pl.asm.win32
www.Xiph.org www.TorProject.org Soft (EN): miniurl.pl/bogdro-soft

do góry

Dnia 28-12-2010 o 12:54:56 Bogdan (bogdro) <b...@p...gazeta.pl>
napisa?(a):

>> pod adresami 0x7xxxxxxx w przestrzeni procesu znajdowalo sie
>> kilkanascie dllelek glownie systemowych jak kernel32.dll
>> (swoich wlasnych aplikacja nie uzywa) i pare tez mi nie znanych
>> ale chyba okolosystemowych, plus jedna ("hook.dll" o ile
>> pamietam ) pochodzaca z mojego slownika polsko angielskiego
>> firmy techland - ten slownik zaklada takie hooki bo ma opcje
>> kontekstowych tlumaczen tekstow odrazu z aplikacji
>>
>> ciakawa wogole sprawa; jak to jest ze te dllki sa mapowane w
>> prywatnej przestrzeni procesu? zdawalo mi sie ze powinny byc one
>> w wyzszej polowce adresow systemowych;
>
> Może tam są, tylko w procesie wyglądają na zmapowane pod niższe
> adresy. Ale może to być kwestia tego, że program jest uruchomiony pod
> debugerem - on też korzysta z wywołań systemowych, może więc
> "przechwytuje" je dla programu: wstawia swoje zaślepki pod adresami
> 0x7xxxxxxx (aby na przykład można było podejrzeć parametry
> uruchamianych funkcji), po czym odwołuje się do tych właściwych już
> pod innymi, "bardziej standardowymi" adresami.

Bo właśnie od 0x7xxxxxxx system ładuje swoje biblioteki (nie wiem jak w
systemach 64 bitowych), bez względu na to, czy program jest uruchomiony
pod debuggerem, czy nie. Zresztą, debugger można podłączyć i odłączyć już
po wystartowaniu procesu. Poczytaj sobie może gdzieś o tym, jak działają
procesy, dllki i system, to nie będziesz błądził po omacku. Ja niestety
żadnych artykułów nie polecę, bo dawno temu to studiowałem.

--
Boguś

do góry

> Bo właśnie od 0x7xxxxxxx system ładuje swoje biblioteki (nie wiem jak w  
> systemach 64 bitowych), bez względu na to, czy program jest uruchomiony  
> pod debuggerem, czy nie. Zresztą, debugger można podłączyć i odłączyć już  
> po wystartowaniu procesu. Poczytaj sobie może gdzieś o tym, jak działają  
> procesy, dllki i system, to nie będziesz błądził po omacku. Ja niestety  
> żadnych artykułów nie polecę, bo dawno temu to studiowałem.
>

polecam wam wszystkim sciagniecie sobie ollydbg 1.1 (jest wersja 2 alpha
ale nie dokonczona i 1.1 ma o ile wiem wiecej funkcjonalnosci) odpalenie
go z jakims np wlasnym progsem - to moze was nauczyc w jeden wieczor
(o ile sa juz jakies zreby wiedzy) tyle ile ze dwa lata czytania

sam costam juz czytalem (i o pe i o mapowaniu w pamieci) i 'jakies' tam
wstepne pojecie mam - aczkolwiek przydalaby sie wieksza jasność

fir


--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry