🚀 go-pugleaf

> Czy w Windows mozna zaladowac funkcje z Kernel.dll za pomoca
> przerwania (BIOS) lub za pomoca odwolania sie do okreslonego miejsca
> w pamieci z poziomu ASM?
> Napewno fukcje z tego DLL musza byc gdzies w pamieci.

Ech, poczytaj o pisaniu w asmie pod Win32, i jak dostać się do funkcji z 
DLL.

Są dwa sposoby: linkowanie statyczne i linkowanie dynamiczne.

Pod NASM-em statyczne robisz tak:

EXTERN GetModuleHandleA
IMPORT GetModuleHandleA kernel32.dll

i już możesz wykonywać "call [GetModuleHandleA]".

Linkowanie dynamiczne: za pomocą linkowania statycznego uzyskujesz funkcje 
LoadLibrary i GetProcAddress. Wywołujesz LoadLibrary, żeby uzyskać uchwyt na 
żądaną bibliotekę dll, a następnie GetProcAddress zwraca ci wskaźniki na 
funkcje o podanych przez ciebie nazwach.


-- 
Azarien

Mialem na mysli programowanie za pomoca opcode.
Linkowanie za pomoca programu typu LINK.EXE jest proste.

-- 

> Mialem na mysli programowanie za pomoca opcode.
> Linkowanie za pomoca programu typu LINK.EXE jest proste.

Musisz spreparować odpowiednio EXE-ka, aby system podczas jego ładowania sam 
wypełnił te adresy (do wszystkich wywoływanych funkcji albo tylko do 
LoadLibrary/GetAddrProc). Normalnie robi to linker.

Co chcesz osiągnąć tak na prawdę, i w czym piszesz program?

-- 
Azarien

Użytkownik "Wiktor S." <azi@daleko.ANTISPAM.be> napisał w wiadomości 
news:ed10bc$j1f$1@news.onet.pl...
>> Mialem na mysli programowanie za pomoca opcode.
>> Linkowanie za pomoca programu typu LINK.EXE jest proste.
>
> Musisz spreparować odpowiednio EXE-ka, aby system podczas jego ładowania 
> sam wypełnił te adresy (do wszystkich wywoływanych funkcji albo tylko do 
> LoadLibrary/GetAddrProc). Normalnie robi to linker.
>
> Co chcesz osiągnąć tak na prawdę, i w czym piszesz program?
> -- 
> Azarien
W tym problem, ze chcialem napisac prosty program hexedytorem, czyli znac 
podstawy, ale te pliki dll sa pokrecone i zakodowane (moze skompresowane). 
Myslalem o tym zeby recznie skompilowac program. 

> Musisz spreparować odpowiednio EXE-ka, aby system podczas jego ładowania 
> sam
> wypełnił te adresy (do wszystkich wywoływanych funkcji albo tylko do 
> LoadLibrary/GetAddrProc). Normalnie robi to linker.
>
> Co chcesz osiągnąć tak na prawdę, i w czym piszesz program?
> -- 
> Azarien

Dziekuje za odpowiedz. Mialem nadzieje, ze ktos zna numer przerwania lub 
adres w pamieci mogacy rozwiazac problem. Myslalem wczesniej o zmianie 
danych w EXE, ale problem pojawia sie w identyfikatorach w DLLu i EXE. 
Disasemblowalem "manualnie" plik i doszedlem do wniosku, ze w DLLu nie ma 
hintow (lub idow) podanych w EXE. Wydaje sie to nielogicznie i bezsensowne. 
Problem pojawil sie w zwiazku, ze zla kompilacja mojego programu w C/C++.

--
PioM 

P.S. Intel skomplikowal assembler, mogl uzywac min bajtow do okreslenia 
rejestrow i operacji na nich, wtedy byloby wszystko bardziej czytelne. 
Kompresja kodu doprowadzila do utrudnienia jego rozumienia i praktycznie 
wyzerowania mozliwosci zapamietania. W dokumentacji wyglada to dobrze i 
niektore rzeczy sa nawet stablicowane, tylko niestety widac duza liczbe 
polecen, ktora powieksza chaos. Co bedzie w przyszlosci z tymi procesorami? 
Napewno wystarczyly by proste polecenia i mniejsza liczba, zeby wszystko 
dzialalo. Kompatyblinosc wstecz zbiera zniwo i kto wie jakie beda tego 
efekty. Utrudniono maksymalnie nauke na tej platformie i pewnie ograniczono 
w duzej mierze produktywnosc. Powinno przenoszenie z komorki pamieci do 
komporki pamieci - bezposrednie. Po co mieszac 32 bitowy i 16 bitowy kod?
Sytuacje ratuja kompilatory i linkery, jednak nie zawsze mozna na nich 
polegac.

--
PioM 

> P.S. Intel skomplikowal assembler, mogl uzywac min bajtow do
> okreslenia rejestrow i operacji na nich, wtedy byloby wszystko
> bardziej czytelne. Kompresja kodu doprowadzila do utrudnienia jego
> rozumienia i praktycznie wyzerowania mozliwosci zapamietania.
> W dokumentacji wyglada to dobrze i niektore rzeczy sa nawet
> stablicowane, tylko niestety widac duza liczbe polecen, ktora
> powieksza chaos.

Ty chcesz się uczyć na pamięć kodu maszynowego? Można zapytać... po co :-)

> Co bedzie w przyszlosci z tymi procesorami?

patrz AMD64. jeszcze większy bałagan, bo pousuwano mnóstwo elementów 
(rejestry ds i es całkowicie poleciały, deskryptory są okastrowane) i dodano 
nowe rejestry i operacje 64-bitowe. Wtedy spamiętaj, czy dany rejestr można 
wykorzystać w danej instrukcji, czy nie... (np. OIDP nie można mieszać 
rejestrów ah,bh itp, w jednej instrukcji z r8w,r9w itd. "bo tak")

> Napewno wystarczyly by proste polecenia i mniejsza liczba, zeby wszystko
> dzialalo. Kompatyblinosc wstecz zbiera zniwo i kto wie jakie beda
> tego efekty.

demonizujesz. kompatybilność x86 jest jednym z podstawowych założeń, i 
dzięki niemu ta rodzina się rozwija [patrz: ia64 (niezgodne wstecz) kontra 
amd64 (zgodne) - która platforma się upowszechniła?]

> utrudniono maksymalnie nauke na tej platformie i pewnie
> ograniczono w duzej mierze produktywnosc.

najniższy poziom, jakiego programista się tyka, to asembler. mnemoniki są 
jasne, poziom skomplikowania instrukcji w wewnętrznej reprezentacji nie 
powinien nikomu przeszkadzać.

> Po co mieszac 32 bitowy i 16 bitowy kod?

a i 8 i 64- również :-)

> Sytuacje ratuja kompilatory i linkery, jednak
> nie zawsze mozna na nich polegac.

to kiedy nie?

-- 
Azarien

>> Napewno wystarczyly by proste polecenia i mniejsza liczba, zeby wszystko
>> dzialalo. Kompatyblinosc wstecz zbiera zniwo i kto wie jakie beda
>> tego efekty.
>
> demonizujesz. kompatybilność x86 jest jednym z podstawowych założeń, i 
> dzięki niemu ta rodzina się rozwija [patrz: ia64 (niezgodne wstecz) kontra 
> amd64 (zgodne) - która platforma się upowszechniła?]

Powoduje duzy chaos i moze kiedys zniszczy platforme.
Nie mam obecnie dostepu do dokumentacji ia64.
Dokumentacja udostepniona programistom jest znacznie ograniczona.

>> utrudniono maksymalnie nauke na tej platformie i pewnie
>> ograniczono w duzej mierze produktywnosc.
>
> najniższy poziom, jakiego programista się tyka, to asembler. mnemoniki są 
> jasne, poziom skomplikowania instrukcji w wewnętrznej reprezentacji nie 
> powinien nikomu przeszkadzać.

Jezeli jest zbyt skomplikowany i niedoskonaly to mozna podejrzewac 
zlosliwosc.

>> Po co mieszac 32 bitowy i 16 bitowy kod?
>
> a i 8 i 64- również :-)
>
>> Sytuacje ratuja kompilatory i linkery, jednak
>> nie zawsze mozna na nich polegac.
>
> to kiedy nie?

Czasami sa probemy. Chociaz moze w tym byc troche zlosliwosci innych ludzi.