Sorry for the previous “emtpy” mail that I sent. TMFOKS.
The problem with this is that if the space you want to use isn’t available
to YOU, you need to use “hacking” methods to get access to it. It gets
worse, because you don’t know who else is wanting to access the memory, and
what happens to it later.
Let’s say that you have an interesting address 0x80001234. Now, that
happens to be “not allocated” at the moment, so it’s easy to just trap the
access to it in a DLL that catches memory accesses that are out of bound.
But now, some application in your system (say your e-mail software) causes
the file-system driver to allocate some memory, and for the reasons of this
discussion, the memory manager decides to allocate the address
0x80001000-0x80001FFF to use for a buffer. So what are you going to do now?
You can lock down pages that YOU own, but you can’t prevent some other
system component from using pages that you don’t own. And there’s no way to
tell the system “I want to own the page at 0x80001000”.
Also, you probably didn’t understand my comment on (unsigned char
*)(0xFF00FF00) += 3;
The problem is that the compiler will quite possibly generate:
add byte ptr 0xff00ff00, 3
Which will trap on the access of 0xFF00FF00, but there’s no way that you
can continue that instruction, you’ll have to emulate THE whole operation.
Ok, so you could change the address of the operation, but then you have to
consider:
- You need to change it back again before the next time it executes.
- You could have code that isn’t as obvious:
mov esi, 0xff00ff00
add byte ptr [esi], 3
or more complex:
mov esi, 0xff00000
add byte ptr [esi+0xff00], 3
Do consider that the load of esi may not be immediately before the
operation, but rather a thousand instructions earlier.
With regard to bit operations, they are no different from any other
operation, because they still make a READ/MODIFY/WRITE operation, either as
a single operation, or a set of operations. The set of operations is easy
to handle as you get a trap for each operation. it’s the same thing as
above, but a different operator. You’ll have to support all manner of
operations, so they make little difference.
With regards to memory allocation and embedded systems, I’d say that a very
limited amount of embedded systems I’ve worked with didn’t have a function
similar to malloc. One of the ones that I’ve spent considerable time
working on has a fundamental principle of using messages as
InterProcessCommunicaiton, and messages get allocated and freed frequently.
But my concern about memory allocation is more to do with other pocesses in
the windows system allocating memory. Try this: Hook up a WinDBG to an
idle windows machine, and type:
ba e 1 KeAllocatePoolWithTag
g; g; g; g; g; g; g; g; copy’n’paste>
bc *
Each time it says “Breakpoint X hit” it shows that some memory was
allocated in the kernel.
And it will do that QUITE A LOT.
So you can’t really rely on the system not changing the memory allocation
VERY OFTEN.
And that is the base of the problem. There is no interface for YOUR DRIVER
to decide what gets allocated, where, when and how. Simply, because it’s a
very specialized area, and there’s little need for anything to use this
(unless you’re trying to emulate hardware that doesn’t exist, but Windows
isn’t really designed to do that).
–
Mats
xxxxx@lists.osr.com wrote on 11/26/2004 11:29:18 AM:
>
>
> The solution I would like is to have a driver or a dll which filters all
> memory accesses. This driver or dll should give to an application the
> possibility to supervise specific memory addresses from its (the
> application) virtual memory space (32bits: 0 -FFFFFFFFH). When a memory
> operation, initiated by a thread from that application, tries to access
one
> of the registered addresses, a notification mechanism should be trigger
and
> the memory access should be suspended.
>
> Now, the application (notified by the driver) will:
>
> - get the type of operation: read/write and some supplementary parameters
> depending of the operation type.
>
> - do some specific treatment
>
> - resume the operation access. For a read operation this will set the
value
> that should be seen by that thread which reads
>
>
>
> The not unary accesses like (unsigned char *)(0xFF00FF00) += 3; will be
seen
> as so many reads and writes as necessary, but this is not a problem.
There
> are also operations which can change only a bit by using a cast to a
> specific structure like struct { bit0 char:1; …bit7 char:1} but I think
> that is the same case.
>
> The addresses the application should supervise are known. Their number
> should be something like 100 addresses. The embedded software never does
> memory allocations: no new, malloc, etc
>
>
>
>
> “Mats PETERSSON” wrote in message
> news:xxxxx@ntdev…
> >
> >
> >
> >
> >
> > If I understand you correctly, your hardware access address may well be
> > ANYWHERE in the 0-4GB address range. This makes the whole situation
pretty
> > hopeless, because there are certainly some addresses that you will not
be
> > able to “hook” without a major hacking in the kernel (what happens if
the
> > graphics card happens to be allocated to your hardware address? Or a
SCSI
> > adapter’s PCI region is at the address you want to use… Etc, etc…).
As
> > far as I’m aware, there is no API for telling the OS that “Virtual
address
> > XXXXXXXX is mine, and you can’t use it”. There is an API to map
physical
> > addresses to a virtual address, but once the address is virtual, it’s
> > beyond your control what address is being used and what is not.
> >
> > Then comes the problem that 0-2G happens to be used for user-space and
> > 2G-4G is used for kernel space (except in /3GB configuration, where
0-3G
> > is
> > user mode, and 3G-4G is kernel space, but let’s ignore that for the
next
> > bit). If your DLL is running in user mode, there is no way you’ll ever
be
> > able to access 2G-4G. If you’re in kernel mode, you’ve got access to
> > everything, but you still haven’t got a way to “own” memory at any
> > particular address. Also, the memory manager will unmap and re-map
things
> > according to what it thinks is good at any given time, so for instance,
> > the
> > region you want to use may well be mapped in at the moment, and then
> > suddently get unmapped. Unless you hack around in the actualy
management
> > of
> > the memory, you will not have any control over what memory addresses it
> > uses, and what happens to them in the future.
> >
> > Of course, if you want to do a emulator in user mode, you could USE the
> > fact that > 2G is kernel mode (but beware of the /3GB switch) and have
an
> > access violation caused by the access to >2G trap into a exception
> > handler,
> > which takes care of the HW access. This will also work for
non-allocated
> > memory in user mode, but there’s no way that you can know which areas
of
> > memory are being allocated and not in user-mode, as the memory
management
> > (again) is allocating memory “at random”. And you’ll still have to
figure
> > out what the operation is (not just read/write, but also the size of
the
> > operation). Also, what do you do with:
> >
> > (unsigned char *)(0xFF00FF00) += 3;
> >
> > You’ll get one trap for the memory access being invalid when the
processor
> > tries to read 0xFF00FF00, but you’ll have to actually emulate both the
> > read
> > and the write operation and then modify the return address to the next
> > location after the add operation (but that’s not guaranteed, the
operation
> > may also be split into three different steps, a read, add and write
> > operation, depending on what the compiler fancies doing with it).
> >
> > I still think the best idea would be to add a macro to the original
source
> > code to encapsulate the hardware access. Something like this (obviously
> > needs a bit more work to give full flexibility of sizes):
> >
> > #if EMULATING
> > #define HWACCESS_READ(x, y) y = DoHwAccessRead(x)
> > #define HWACCESS_WRITE(x, y) DoHwAccessWrite(x, y)
> > #else
> > #define HWACCESS_READ(x, y) y = *x
> > #define HWACCESS_WRITE(x, y) *x = y
> > #endif
> >
> > Best of luck.
> >
> > –
> > Mats
> >
> >>
> >> the address 0xFF00FF00 is only an example. the addresses can be in
both
> >> zones 0-2G; 2G-4G.
> >> should i reserve those from 0-2G?
> >>
> >>
> >> “Prokash Sinha” wrote in message
news:xxxxx@ntdev…
> >> > Wow !
> >> >
> >> > First, definitly U know the access violation is due to kernel memory
(
> >> > 0x80000000 - 0xffffffff, simple 2gb case ) being accessed from user,
if
> >
> >> > your
> >> > dll is Luser mode. I like this (L)user word recently coined by Mark
> > Roddy
> >> > !
> >> >
> >> > Now if could correlate the hardware register to krnl mode mapped
> > address (
> >> > i/o space, memory space etc - pci resouce enumeration !!! you have a
> >> > chance
> >> > of using Max, Mat and Marc ideas, otherwise I would recommend to
look
> > at
> >> > virtual dos driver, and other places where a driver can initiate the
> > path
> >> > for user mode to call IN(S) OUT(S).
> >> >
> >> > I suspect you could get some lead if you look at those sites to
start
> >> > with,
> >> > lots of interesting junks and hacks but pls be wary about main
stream
> >> > products. IT IS A BIG NO, NO.
> >> >
> >> > I dont know how soon I would be looking at my problem, but have the
> >> > feeling
> >> > fairly soon !
> >> >
> >> > -pro
> >> >
> >> >
> >> > ----- Original Message -----
> >> > From: “Razvan Marcus”
> >> > To: “Windows System Software Devs Interest List”
> >> > Sent: Thursday, November 25, 2004 1:08 PM
> >> > Subject: [ntdev] memory access hook
> >> >
> >> >
> >> >>
> >> >> The address 0xFF00FF00 could be for example the latch
> >> >> for a flash memory or the UART control register. In
> >> >> the windows PC (emulator) this address has no meaning.
> >> >> An access attempt to this address will get an
> >> >> AccessViolation
> >> >>
> >> >> >You might also want to look at two sites -
> >> >> >
> >> >> >www.rootkit.com 'n www.pharak.com
> >> >> >
> >> >> >BTW, when you said 0xff00ff00 on a specific machine,
> >> >> >is it virtual
> >> >> >address
> >> >> >you talking about or physical ( straight w/o any
> >> >> >translation ) …
> >> >>
> >> >> >I might be dealing with something very similar, but
> >> >> >not right now. It
> >> >> >is to
> >> >> >capture system state at krnl level / perterb arg
> >> >> >data, and replay …
> >> >> >It has
> >> >> >to do with something like -
> >> >>
> >> >> >jg, and ja
> >> >>
> >> >> >-pro
> >> >> ----- Original Message -----
> >> >> From: “Razvan Marcus”
> >> >> To: “Windows System Software Devs Interest List”
> >> >>
> >> >> Sent: Thursday, November 25, 2004 7:31 AM
> >> >> Subject: [ntdev] memory access hook
> >> >>
> >> >>
> >> >> >
> >> >> > Hello,
> >> >> >
> >> >> > I’m working on an pseudo-emulator software. I have
> >> >> > to provide a box capable of loading and running a
> >> >> > binary code. This binary is a DLL compiled in VC++.
> >> >> > The same source code compiled for a specific
> >> >> processor
> >> >> > is used by the real machine. The source code cannot
> >> >> be
> >> >> > changed.
> >> >> > The code makes use of direct memory manipulations
> >> >> > like:
> >> >> > *(unsigned char *)(0xFF00FF00) = 0x80
> >> >> > or
> >> >> > unsigned char ch = *(unsigned char *)(0xFF00FF00);
> >> >> >
> >> >> > I am searching for a solution to intercept these
> >> >> > memory accesses. I need to know:
> >> >> > - the operation type: write or read
> >> >> > - the address
> >> >> > - the value (if write)
> >> >> >
> >> >> > It is important to intercept the read because some
> >> >> > devices need only a register read to switch to a
> >> >> > specific mode.
> >> >> >
> >> >> > Could someone give me some advices about how
> >> >> should
> >> >> > I implement this mechanism?
> >> >> > I am familiar with filter drivers but, in this
> >> >> case,
> >> >> > I don’t know which driver I have to filter.
> >> >> >
> >> >> > Thank you
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> __________________________________
> >> >> Do you Yahoo!?
> >> >> The all-new My Yahoo! - Get yours free!
> >> >> http://my.yahoo.com
> >> >>
> >> >>
> >> >>
> >> >> —
> >> >> Questions? First check the Kernel Driver FAQ at
> >> > http://www.osronline.com/article.cfm?id=256
> >> >>
> >> >> You are currently subscribed to ntdev as: xxxxx@garlic.com
> >> >> To unsubscribe send a blank email to
xxxxx@lists.osr.com
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >>
> >>
> >>
> >> —
> >> Questions? First check the Kernel Driver FAQ at http://www.
> >> osronline.com/article.cfm?id=256
> >>
> >> You are currently subscribed to ntdev as: xxxxx@3dlabs.com
> >> To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >> ForwardSourceID:NT0000804E
> >
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.
> osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@3dlabs.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
> ForwardSourceID:NT0000807E