Hi All,
I am interested to findout the system MAC Address using the physical memory....Any body have an idea whether the MACAddress will reside in physical memory.

Thanks

Physical memory?

Tell us what your platform is, what you mean by 'using the physical memory' and why Google hasn't been able to answer your question then we'll be happy to help. And for the record, the system doesn't necessarily have a unique MAC address - this is a property of a network device, so a typical machine will have several, and many will have none.

Hi Admiral, Thanks for your response. My question is regarding windows platform. you are right....MAC address belongs to Network device.. My doubt is whether this information can be found using any of the systerm data structures....
I have already searched google and i didnt find the proper results....

When you say 'system data structures', does that allow the use of system APIs? If so, this should have been one of Google's first hits: http://dn.codegear.com/article/26040
If not, you'll have to explain why you have such a strange restriction

Admiral,
Suppose if you take TEB strctue, we can get the structure pointer using any system API or using FS segemnt register..

In the same way i want to know if there is any system register that will allow us to find out the MAC Address.

Thanks

@rijnahts: From what I undestand, MAC address is stored in the registry, not in RAM. The hardware Burned, Physical MAC address is written in the network card ROM, but is read by the network card driver early during system boot, using ring 0 code then copied to the registry, where all other OS functions will access it. I doubt you will find The MAC address written at a specific location somewhere in the memory address space.
The real question is: why do you need it? you could read it and change it at the registry using Windows ADVAPI.dll APIs.

You would have to either parse internal NDIS or AFD structures or parse the registry hive structure. The former would probably be a little bit easier implementation-wise, although it would require you to do a little bit more of your own reversing (because those structures are entirely undocumented, whereas the in-memory registry structure is documented - somewhat, anyway).

Thanks for your responses... Why did i have asked this is ....... Eventhough the registry will in part of ce.reg file finally it will be mapped into the physical memory....I was thinking whether we have any option to find out the MACAddress directly using some of the kernel data structures....

I propose an experiment:
Figure out the MAC address(es) of your computer network interfaces: 6 bytes, using ipconfig/all for instance.
Using a ring 0 debugger, windbg for instance, syser or SoftIce if you have it installed, search the whole memory space for the 6 byte pattern. Also search for the NN:NN:NN:NN:NN:NN pattern.
You may find a few false positives but you can figure out who owns the memory that contains the potential hit(s). Some of the registry hives are directly mapped in memory so one possible hit would be the registry key. You may reverse engineer the structure that contains the MAC address, if such structure indeed exists.

I'm not sure if this is a communication breakdown or a misunderstanding on whoever's part, but your question makes no sense

In many situations, the MAC address of whichever device will indeed find its way into a process's address-space, but only through one of the many APIs already discussed. The TEB, FS register and everything else you have discussed are user-mode, process-specific concepts that relate in no way to hardware enumeration. Moreover, a typical ring3 process will have absolutely no use for any system MAC addresses to be mapped into one of its internal structures automatically by the OS, so you won't find it like that.

<sarcasm>
If you were to parse the PEB to locate the list of modules mapped in the process, iterate through them until kernel32 was found, use its PE header to find the export table; locate LoadLibraryA and GetProcAddress, then you could import CoCreateGuid from ole32.dll, create a GUID and extract your primary MAC from that.
</sarcasm>

That fits your criteria, but you'd be insane to do it. Far better would be to use one of the other methods already given. In other words, what are you trying to do and why can't you do it the normal way? If you give us some insight into the underlying problem, maybe we can suggest an altogether more elegant way of dealing with things

http://www.google.com/search?hl=en&sa=X&oi=spell&resnum=0&ct=result&cd=1&q=%22mac+address+in+physical+memory%22&spell=1

The results are lame at best BUT, considering the question at hand,
Well, I still dont understand the question.



Woodmann

troll?

I can only think of two reasons one would want to obtain the MAC addr without using an API. One is as a protection mechanism (hardware id style) and the other is malicious.

Forensic analysis of physical memory is also a potential reason. I've actually written code to do exactly what he is describing, but it's for my work on a physical memory forensics product, so I can't post the code here or go into much more detail than I already described in my previous post in this thread about how to do it.