I came across BinarySharp today and its VERY impressive. It's like an all-in-one library for memory/process related operations and I'm amazed at how extensive it is.
I was interested in how the addresses of remote functions were being found and it seems that it attempts to call LoadLibrary on the target module instead of manually reading it remotely from the Portable Executable structure in memory. I did notice that you said that you were currently working on a "PE Format Analysis" feature which will probably allow this to happen without having to load the module but its just a suggestion if you didn't think of it.
I have written my own extensive portable executable class but I didn't add any abstraction for it to work with memory (only works with images on disk) so it'd be nice to see someone else's approach on it.
The following only applies when you decide to add both 32-bit and 64-bit support to your library (as far as I know it's 32-bit only right now).
Also, I've had a look at the ManagedTeb and ManagedPeb classes and it seems they're using Enums to obtain the field offsets. Due to the varying in sizes of the pointer type in 32-bit and 64-bit applications, wouldn't those offsets break? From looking at your enums, it seems like you've assumed that all pointer types are 4 bytes long. Also, in the TebStructure enum, you've called one of the fields "WoW64Reserved" when the correct name is actually "Wow32Reserved".
Another thing is that in WoW64 processes, there are actually 2 PEBs and 2 TEBs. One is the 32-bit version and the other one is the 64-bit version. The 64-bit TEB and PEB structure actually vary, that being the pointer sizes are different. Also, in the 64-bit PEB, the GdiHandleBuffer field only has 30 values as opposed to 34. If you require a detailed reference, you can look here.
Also, obtaining the PEB/TEB of another process is abit troublesome too. If you are a 64-bit process and wish to obtain the 32-bit PEB of a Wow64 process (which is the default one if you were that Wow64 process), you need to use ProcessWow64Information with NtQueryInformationProcess instead of ProcessBasicInformation otherwise it'll return the 64-bit PEB (use IsWow64Process along with a GetProcAddress check to determine if a process is running under WoW64). When using NtQueryInformationProcess with ProcessWow64Information, it takes a reference to a pointer-sized integer (aka, IntPtr) instead of a PROCESS_BASIC_INFORMATION structure and puts the address of the PEB in this pointer-sized integer.
[DllImport("ntdll.dll", SetLastError=true)]
public static extern int NtQueryInformationProcess(IntPtr hProcess, PROCESSINFOCLASS pic, ref IntPtr pbi, int cb, out int pSize);
If you are a 64-bit process and wish to obtain the 32-bit TEB of a Wow64 process, you use the same usual method of obtaining the TEB using NtQueryInformationThread (which in this case will return the 64-bit TEB) and then add 0x2000 because the 64-bit TEB always preceeds the 32-bit TEB by 2 pages (reference: here, check Side Notes, you can see the offset is hardcoded in Wow64cpu!CpuThreadInit).
Once you've made all the necessary fixes for 32-bit/64-bit TEB/PEB structures, you could easily add a feature that allows you to unlink/hide a module from the PEB. (example: here)
Another thing is the .NET Process suffers from a problem where if you are running as a 64-bit process and are trying to list the modules of a Wow64 process, it will only list the 64-bit modules (the target's main module, ntdll.dll, wow64.dll, wow64win.dll and wow64cpu.dll). The workaround is to use EnumProcessModulesEx with the LIST_MODULES_ALL filter flag (note that this function only exists in Vista and higher). Then you have you use the populated module handle array with the corresponding functions to obtain the module name, path, size, etc (GetModuleBaseName, GetModuleFileNameEx and GetModuleInformation respectively). The only problem with this is that you cannot create an instance of the ProcessModule class unless you use some hackery with Reflection and populate the internal ModuleInfo class and call the ProcessModule internal constructor.
Hope this helps. If you require me to explain me to explain anything, then let me know. 
Edited by master131, 22 September 2013 - 06:27 AM.
