Reputation: 81
I tried to write a peloader. I first load the executable image and all it's dependent dlls(include kernel32.dll and ntdll.dll) into memory, process all import address table, rewrite all data which need relocation.
Then I call all image's EntryPoint in order. I get the return code 0 from ntdll.dll's EntryPoint, but kernel32.dll returns 0xC0000000. When I tried to call the executable image's EntryPoint, the program crashed.
I know the windows system already load ntdll.dll and kernel32.dll into process memory when the process is created. My question is how can I load another copy of ntdll.dll and kernel32.dll into memory, and link my module to the copy ones.
I make an experiment: 1. copy ntdll.dll -> a.dll
Is it possible to make a.exe run correctly?
It's my first question on stack overflow, sorry for my poor english. Thanks.
Upvotes: 8
Views: 4032
Reputation: 295
If you wish to use your own version of ntdll.dll (a.dll) in your code then you can read the dll using Readfile() and parse the PE structures to use in your code. for eg: you may parse the Export Name Table, Export ordinal table and Export address table to find pointers to the exported functions and use the same in your executable.
Upvotes: 0
Reputation:
In visual studio put in the project properties linker->input->Ignore All default libraries
to yes. Then in c++->Code Generation->Basic Runtime Check
to default (to avoid linking in __RTC_*
. Then in linker->Advanced->Entry Point
you specify an function in your project you want to be called when the program is started.
Build everything and you should have a program that isn't linked to any library, including the c-runtime.
Upvotes: 0
Reputation: 98358
I don't think you can do this. The kernel32.dll and ntdll.dll, AFAIK are not relocatable. That is, MS removed the relocation information from them, because, as they are already loaded in every process, their assigned addresses are always available, by design.
So, if you try to load them into a different address, well, they'll crash. You could theoretically try to rebuild the relocation information for them... but I wouldn't bet on it.
My question in turn is: why cannot you use the preloaded kernel32/ntdll? Why do you feel that you need private copies? As I see it, you should consider them the system API, and so leave them alone.
Upvotes: 4