The "madBasic" package contains several units, which implement a lot ofbasic functionality like standard type definitions (madTypes), string handling (madStrings), simplified message handling (madTools), compression(madZip) and crypting and encoding (madCrypt). Then the base interfaces for the other mad* packages are defined (unit madBasic). Finally some lists are implemented (madLists). As a bonus I've recently added a unit which can modify the resources of dlls/exes (unit madRes).
The package "madCodeHook" offers everything you need to hook code (mostly APIs). Usually such hooks show effect only in the current process. But madCodeHook also can inject a specified DLL into any desired 32bit process or even "system wide" (that is into all currently running and into all in the future created processes). So by putting your hooking stuff into a little DLL and injecting it "system wide", you can realize effective and easy to use system wide API hooking. Of course everything works just as fine under both OS families (9x/NT).
The package "madDisAsm" features a full x86 disassembler including MMX, 3dNow enhanced, SSE and SSE2 support. The isassembler can examine a single x86 instruction (see ParseCode) or a full function (see ParseFunction) and either return a short analysis or a full text disassembly. Register contents are watched/followed if possible, this improves the analyses for jump/call targets. Case/switch jump tables are automatically detected and handled correctly.
The package "madExcept" was exactly build for that purpose, namely to replace Delphi's standard exception handling with a new logic, which finds out the full callstack with as much details and infos as possible. The exact behaviour of madExcept's exception handling can be totally customized. You can choose whether you want to see an exception box or not, how the box should look like, which buttons it should have, how the buttons should be labeled and so on.
The package "madKernel" is about Kernel Objects for the biggest part. The most important object types are wrapped up in nice interfaces, utilizing all the specific kernel32 APIs and also utilizing a whole lot of undocumented stuff. You often won't notice the undocumented parts of madKernel, though, because all what you can do seems natural and logical. There are simply a lot of holes in the win32 API, which madKernel has to fill in order to make the interfaces complete. Just one example: The well known API "ShellExecuteEx" can give you a process handle of the newly created process. But what process ID does the process have? The win32 API *should* contain an API like "ProcessHandleToProcessID",but it doesn't. So madKernel uses undocumented stuff to fill the holes.
The package "madRemote" gives you the basic tools you need to get into foreign processes. You can allocate&free memory in a specified process (AllocMemEx/FreeMemEx), you can copy a function to the memory context of a specified process (CopyFunction) and you can even create a remote thread in any 32bit process (CreateRemoteThreadEx).
The "madSecurity" package makes it easily possible to handle Shares and other Security Objects like file security or registry security. To be able to do so, this package also features functionality around Accounts and ACEs and ACLs.
The package "madShell" implements often needed shell functionality, beginning with Special Folders like the "Windows" folder or the "Program Files" folder, continuing with Shell ID Lists, Shell Objects and Shell Events. Then you'll find functionality around ShortCuts/ShellLinks and finally everything about Display Modes.
