HadesMem v1.0.0 (SemVer)

[Cypher]

HadesMem v1.3.0

New Features

• Added new Injector APIs.
• Added new PeLib APIs.
  
  • ​DosHeader
  • ExportDir
  • ImportDir
  • NtHeaders
  • PeFile
  • Section
  • TlsDir
• Added experimental ManualMap API. Subject to change and availability, not for production use. Currently undocumented.
  
• Added experimental manual mapping example program.

Bug Fixes

• Added missing headers to Memory.hpp.
• Fixed Boost build scripts.
• MemoryMgr::ReadString, MemoryMgr::ReadList, MemoryMgr::WriteString, and MemoryMgr::WriteList now support custom allocators and traits classes (where appliciable) for the containers passed as template arguments.
  

Changes

• HadesMem is now licensed under the Boost Software License. This is a far more permissive license than the previous one (the GNU GPL v3). Please review the new license before use.
  
• Improved Module tests.
• Improved documentation.
• Updated Boost.
• Removed unnecessary template metaprogramming from MemoryMgr::ReadString, MemoryMgr::ReadList, MemoryMgr::WriteString, and MemoryMgr::WriteList. Now using static assertions instead.
  

[sitnspinlock]

hey, haven't looked over the newer stuff yet, but it's so clean I wish I had the time to do the same ;p

maybe I'm blind and didn't see this one but I wanted to suggest a PEB LDR manipulation wrapper for library cloaking and whatnot

but if its already included then obviously I didn't look hard enough.

anyways, nice work. its very clean and an excellent knowledge source

[Cypher]

hey, haven't looked over the newer stuff yet, but it's so clean I wish I had the time to do the same ;p

maybe I'm blind and didn't see this one but I wanted to suggest a PEB LDR manipulation wrapper for library cloaking and whatnot

but if its already included then obviously I didn't look hard enough.

anyways, nice work. its very clean and an excellent knowledge source

Unlinking yourself from the PEB is generally fairly pointless, as you can still recover the original module name by enumerating memory regions and calling NtQueryVirtualMemory with the MemorySectionName flag to recover the path of the underlying file mapping section object.

I've started working on a manual mapper though, which doesn't suffer from this problem (although it's much much harder to implement, and EH isn't working yet on targets with DEP enabled).

[sitnspinlock]

Unlinking yourself from the PEB is generally fairly pointless, as you can still recover the original module name by enumerating memory regions and calling NtQueryVirtualMemory with the MemorySectionName flag to recover the path of the underlying file mapping section object.

I've started working on a manual mapper though, which doesn't suffer from this problem (although it's much much harder to implement, and EH isn't working yet on targets with DEP enabled).

wow I never noticed the use of that mbi member... but hey, learned something ;p

[Cypher]

wow I never noticed the use of that mbi member... but hey, learned something ;p

By MBI do you mean the MEMORY_BASIC_INFORMATION structure?

That's not what I'm referring to. NtQueryVirtualMemory, unlike VirtualQuery(Ex), allows you to retrieve not only the MEMORY_BASIC_INFORMATION structure, but also a DIFFERENT structure which contains section object information (via the MemorySectionName information class).

I believe there is a Win32 API to do the same thing, but I forget its name...

[_Mike]

By MBI do you mean the MEMORY_BASIC_INFORMATION structure?

That's not what I'm referring to. NtQueryVirtualMemory, unlike VirtualQuery(Ex), allows you to retrieve not only the MEMORY_BASIC_INFORMATION structure, but also a DIFFERENT structure which contains section object information (via the MemorySectionName information class).

I believe there is a Win32 API to do the same thing, but I forget its name...

GetMappedFileName calls NtQueryVirtualMemory with info class 2 (MemorySectionName) internally.

[Cypher]

GetMappedFileName calls NtQueryVirtualMemory with info class 2 (MemorySectionName) internally.

Bingo! That's the one. I always forget its name. Thanks.

[SKU]

Fantastic work as usual. Loving the new license - what made you change it?

[Cypher]

Fantastic work as usual. Loving the new license - what made you change it?

Two reasons... Though mainly the second:
1. Dual licensing was proving to be more difficult than anticipated.
2. In this 'scene', the type of people who are usually cheat sellers are unlikely to obey the GPL anyway. So I figured that I'd rather give people the 'benefit of the doubt', and give legitimate users more freedoms, as the *******s are gonna do what they want without contributing back anyway.

[pyre]

Two reasons... Though mainly the second:
1. Dual licensing was proving to be more difficult than anticipated.
2. In this 'scene', the type of people who are usually cheat sellers are unlikely to obey the GPL anyway. So I figured that I'd rather give people the 'benefit of the doubt', and give legitimate users more freedoms, as the *******s are gonna do what they want without contributing back anyway.

This is why you own.

[sitnspinlock]

Oh, I just never had any prior knowledge of the GetMappedFileName api. That and I didnt see any extra info related to that for NtQueryVirtualMemory on ntinternals :P otherwise I would have traced it.. but yay for more info!

I guess im just an uneducated scrub

[adaephon]

Out of curiosity, what editor do you use? Given your library targets Windows, presumably you're editing on Windows, so I'd assume Visual Studio (or C++ Express). If so, is there any reason you don't include project/solution files in svn? Obviously you use the jam files for building, and thus the project files aren't required to build from your source. However, they would make it more convenient to quickly open / navigate / explore your source. If you don't use VS/VC++, is there some other editor you recommend?

[Cypher]

Out of curiosity, what editor do you use? Given your library targets Windows, presumably you're editing on Windows, so I'd assume Visual Studio (or C++ Express). If so, is there any reason you don't include project/solution files in svn? Obviously you use the jam files for building, and thus the project files aren't required to build from your source. However, they would make it more convenient to quickly open / navigate / explore your source. If you don't use VS/VC++, is there some other editor you recommend?

​I don't use Visual Studio for this project. Maintaining solution files is a pain when I'm not using them, maybe I'll do it in the future, but for now it's not something I want to waste time doing.

[flo8464]

​I don't use Visual Studio for this project. Maintaining solution files is a pain when I'm not using them, maybe I'll do it in the future, but for now it's not something I want to waste time doing.

Just curious, is Hadesmem in it's current state GCC compatible?

[Cypher]

Just curious, is Hadesmem in it's current state GCC compatible?

Yes it is. It compiles and passes tests with GCC 4.6.0 via MinGW-w64.

I want to support Clang too, but MinGW-w64 support for it is VERY early on and it's not yet ready for production use.