Re: Dynamically loading binaries in Kernel mode.

You can reach me at LuisMiguelHuapaya@xxxxxxxxxxxx

"Carl Woodward" wrote:

Luis,

I have written something very similar in the past and have a couple of ideas
for you. Unfortunately, most of these ideas represent quite an investment to
my employers so I can't really post them into the public domain. I have
tried e-mailing you but the e-mail address you specified is invalid. If you
post an alternate way to contact you then perhaps we can discuss them.

Hope no one in the group minds me doing this, I am certainly not touting for
business, just protecting our IP; I am fairly sure I'd be out of a job if I
didn't!

Carl

"Luis Miguel Huapaya" <LuisMiguelHuapaya@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message news:049028A3-7171-4ABB-8462-6C7552B91421@xxxxxxxxxxxxxxxx
Well, we've considered the "separate driver" solution, but it will not do
the
trick for the goals we have in mind. So without too many details here is
what
we need to achieve:

1) Allocate kernel level memory (system memory) that is big enough to
receive the binary image (and related static data) of the dynamic code
that
we want to run.
2) Load the code into memory. I won't get into details, but we can't have
the kernel level code reading it from disk.
3) Do whatever address fixups, etc.. required before "executing" the code.
4) Execute the code.

Our dynamically linked code would publish a GetProcAddress() type function
capable of reporting back on the entry points of every other function in
the
dynamic code. The GetProcAddress() function would undoubdetly be at a
fixed
offset in the binary code. We would have to figure a mechanism to report
back
on other functions in the binaries based on the load address.

The dynamic code must be loadable/unloadable on demand.

I can't think of any other way to achieve our intended goal. It sucks
because I prefer simple solutions, but in this particular case, I don't
think
there is any other choice.

cheers,
Luis Miguel Huapaya

"Don Burn" wrote:

Actually, the group will answer the question without going into the
details
of you project. What we are looking for are the goals of you need to
load
binaries. There are a number of solutions including do not do that, but
without understanding the reasoning behind the need a lot of us find we
are
helping people shoot the system in the foot.

For instance in you situation, there are multiple methods you can use,
kernel mode DLL's, a seperate driver with an interface handled in many
ways,
etc. The problem is that many people come to us with "I want to do X,
how
can I accomplish it", when if they stepped back one level the answer is
"Use
standard mechanism A".

A common example of this are people asking many different ways to have
the
driver communicate with the application. Once we understand that the
question "how do I map a user space code section into the kernel?" is
really
"how do I call up to an application with an action to do?" the answer
becomes obvious.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply


"Luis Miguel Huapaya" <LuisMiguelHuapaya@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote
in
message news:52930D30-4618-4C8B-BDEF-6BE5FDE193C5@xxxxxxxxxxxxxxxx
Hi again,

I understand where you are coming from. Unfortunately there are legal
reasons pertaining to ongoing patent work that would prevent me from
disclosing the reasons why we (I) need to dynamically load code at the
kernel
level. It's unfortunately one of those situations where telling anyone
about
our master plan basically screws us :-)

So it sounds to me like I need to take this offline with a consultant,
get
an NDA signed and proceed with some technical questions since for the
most
part, the participants on this forum feel ill at ease with answering my
questions without prior full disclosure (which won't happen anytime
soon).

cheers,
Luis Miguel Huapaya







.

Relevant Pages

  • Re: Dynamically loading binaries in Kernel mode.
    ... Allocate kernel level memory that is big enough to ... receive the binary image of the dynamic code ... Load the code into memory. ...
    (microsoft.public.development.device.drivers)
  • Re: Dynamically loading binaries in Kernel mode.
    ... standard filesystem and unless you load it using standard export driver ... Allocate kernel level memory that is big enough to ... receive the binary image of the dynamic code ...
    (microsoft.public.development.device.drivers)
  • Re: Dynamically loading binaries in Kernel mode.
    ... standard filesystem and unless you load it using standard export driver ... Allocate kernel level memory that is big enough to ... receive the binary image of the dynamic code ...
    (microsoft.public.development.device.drivers)
  • Re: Dynamically loading binaries in Kernel mode.
    ... Anyway, unless the place you're going to load it from is reachable via a standard filesystem and unless you load it using standard export driver mechanisms and interfaces, you're going to end up having to rewrite the entire DLL loader by yourself. ... Allocate kernel level memory that is big enough to receive the binary image of the dynamic code that we want to run. ...
    (microsoft.public.development.device.drivers)
  • Re: [fw-wiz] RE: Firewall Utilization
    ... these are usually load averages for user space processes. ... All major firewall implementations work at kernel level, ...
    (Firewall-Wizards)