Reading //./Device/PhysicalMemory

So what I am doing is, I am reading data from //./Device/PhysicalMemory and I am dumping it to disk. I want to find and read data from the EPROCESS, PEB, TEB etc… struct from the data. So my question, is Would I have to find this by pattern or does Windows delegate certain pages to these structures? I am really confused on this. If it does delegate certain pages to these structures does the format change? If it does by how much?

Hi,

I guess you can use the symbols to find some lists, then traverse them,
parse the structures properly, deal with the states of all of them…

Have you consider using Volatility?

Hope it helps,

Julian

El El mié, 9 may 2018 a las 4:57, xxxxx@students.mhusd.org <
xxxxx@lists.osr.com> escribió:

So what I am doing is, I am reading data from //./Device/PhysicalMemory
and I am dumping it to disk. I want to find and read data from the
EPROCESS, PEB, TEB etc… struct from the data. So my question, is Would I
have to find this by pattern or does Windows delegate certain pages to
these structures? I am really confused on this. If it does delegate certain
pages to these structures does the format change? If it does by how much?


NTDEV is sponsored by OSR

Visit the list online at: <
http://www.osronline.com/showlists.cfm?list=ntdev\>

MONTHLY seminars on crash dump analysis, WDF, Windows internals and
software drivers!
Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:>

xxxxx@students.mhusd.org wrote:

So what I am doing is, I am reading data from //./Device/PhysicalMemory and I am dumping it to disk. I want to find and read data from the EPROCESS, PEB, TEB etc… struct from the data. So my question, is Would I have to find this by pattern or does Windows delegate certain pages to these structures? I am really confused on this. If it does delegate certain pages to these structures does the format change? If it does by how much?

What this shows is that you do not understand what you’re doing. 
Physical addresses are essentially random.  The system doesn’t dedicate
any physical addresses at all, and machine language code never deals
with physical addresses.  Even if you could find the EPROCESS in virtual
memory, that doesn’t tell you anything about its physical memory
location.  You’d need to page tables to do that mapping.   Plus, a
single table can be spread across multiple pages that are have wildly
different physical addresses.

If you are reading from //./Device/PhysicalMemory, then you must already
be running kernel code.  In that case, you can simply read the kernel
memory using virtual addresses, where things make a lot more sense and
buffers are contiguous.  The kernel debugger can show you the EPROCESS,
PEB, and TEB tables, and whatever the kernel debugger can find, so can you.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Sorry I forgot to state what I wanted to do. I wanted to make something to analyze memory dumps. I have achieved this by pool-tag scanning. I already know how to access EPROCESS from kernel mode, via PsLookupProcessByProcessId and PEB/TEB via ZwQueryInformationProcess. Thank you though for clearing up my confusion on physical addresses.

My driver is only dumping the memory to a file where my service will open it. I have a FileSystem MinFilter so I only allow my process to access the dump.

Also yea I did consider volatility but, I need to reinvent the wheel :.

xxxxx@students.mhusd.org wrote:

Sorry I forgot to state what I wanted to do. I wanted to make something to analyze memory dumps.

Forgive my snark, but there’s already a very competent tool for doing
that.  It’s called “windbg”.

I have achieved this by pool-tag scanning. I already know how to access EPROCESS from kernel mode, via PsLookupProcessByProcessId and PEB/TEB via ZwQueryInformationProcess. …

My driver is only dumping the memory to a file where my service will open it. I have a FileSystem MinFilter so I only allow my process to access the dump.

Both of my comments still apply.  Why go to the trouble of copying
physical memory to a file, and then going to the EXTREME trouble of
parsing that file to extract the information you want, when you already
had live access to the memory?  Why not just pull the information you
want directly using the addresses you mention above?

Short of that, why copy physical memory?   Why not just copy the virtual
memory, where your addresses are meaningful?


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Hi Guys !
Im new here and i have some news for you today !

-Apparently www.osronline.com is unaccessible due to unknown reasons

-MS Visual Studio professional Update 5.7.1 is available :
-I downloaded/Installed it successfully
-After finishing installation process, i opened one of my ‘WDM’
projects, and i found <wdm.h> went missing
-Fix : I reinstalled WDM and the problem was solved

Valar Morghulis !

On Wed, May 9, 2018 at 7:13 PM, xxxxx@probo.com wrote:

> xxxxx@students.mhusd.org wrote:
> > So what I am doing is, I am reading data from //./Device/PhysicalMemory
> and I am dumping it to disk. I want to find and read data from the
> EPROCESS, PEB, TEB etc… struct from the data. So my question, is Would I
> have to find this by pattern or does Windows delegate certain pages to
> these structures? I am really confused on this. If it does delegate certain
> pages to these structures does the format change? If it does by how much?
>
> What this shows is that you do not understand what you’re doing.
> Physical addresses are essentially random. The system doesn’t dedicate
> any physical addresses at all, and machine language code never deals
> with physical addresses. Even if you could find the EPROCESS in virtual
> memory, that doesn’t tell you anything about its physical memory
> location. You’d need to page tables to do that mapping. Plus, a
> single table can be spread across multiple pages that are have wildly
> different physical addresses.
>
> If you are reading from //./Device/PhysicalMemory, then you must already
> be running kernel code. In that case, you can simply read the kernel
> memory using virtual addresses, where things make a lot more sense and
> buffers are contiguous. The kernel debugger can show you the EPROCESS,
> PEB, and TEB tables, and whatever the kernel debugger can find, so can you.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:></http:></wdm.h>