Services wanted $$$

Nov 28, 2008 at 7:27 PM
I am a developer located in Milwaukee, Wisconsin, USA and will soon begin a rather large project for which I believe EasyHook may (that's MAY) be useful and beneficial.

Due to the overall scope of the project, I do not easily have the time to attack the EasyHook learning curve.  So... if there is anyone who can code the EasyHook portion for me, I will enter into some arrangement to compensate you for your assistance.  This may be in the form of a one-off payment,  ongoing "royalties" (generally 5% of each sale), or some combination thereof.

You may do your coding in any of the following languages (also, depending on compatibility with EasyHook):, Delphi (Win32 or Net), PowerBasic, or C#.

The goal of use of EasyHook is as follows:

I will create a system which, among other things, peforms integration between several other software systems (third party; no source code available).  It is critical that all of the related applications (including my own) access the desired ActiveX components where those components may or not be currently registered and/or preset in the host system.  Also at issue may be miscellaneous registry entries present for exclusive use of my application and the applications it integrates.  The goal may be summarized as creating a type of Virtual Registry wherein only those applications I designate are able to access the "registry" data, and NO OTHER APPLICATION should have access to those "registry" entries.  The virtual registry data itself will reside in an encrypted virtual disk which my application shall create, control, and maintain.

I presume EasyHook could hook the registry calls from the specified applications.  That is part of the work I need done.  I would then substitute (where necessary) the Virtual Registry data, and that data should be returned to the calling host program.  The return of the substituted data is also something I need developed by someone familiar with EasyHook.

Again, agreement for compensation is flexible.
Nov 30, 2008 at 9:30 AM
This sounds like a security application... Please keep in mind that user mode hooking is in general no suiteable for this task. The only way to realize this with user-mode hooking in a safe manner is to "simulate" the exitence of registry entries or their data content. That means such "protected" registry keys shouldn't exist in the real registry (or at least their data shouldn't exist there). The hooking application should "simulate" their existence and pass them as result for usual registry functions if the caller is permitted to access them. But of course here the question already is how you can "safely" determine the caller.

So think much about how you want to implement this idea before actually starting to code some wierd API hooking implementations which might cause huge security holes...

Nov 30, 2008 at 9:32 AM
If you know all this, EasyHook doesn't have a big learning curve... You can start with the FileMon demo which already implements most of the concepts required for your task...
Nov 30, 2008 at 1:59 PM
I appreciate your thoughtful comments, Chris.

The primary goals are to create an essentially zero-install package, to prevent any "DLL Hell" issues, and to prevent introduction of any registry entries which may be incompatible with other (or future) applications installed by the customer.  As such, it's not really a security application - but it is meant to be secure within itself, thus the fully-encrypted virtual drive.  For example, it may be that one of the applications involved in the integration relies on a specific --older-- version of a given DLL.  I would want to design the entire application around that version (of course).  There's always the chance the customer may install some other application which installs a newer version of that same DLL - which would caused my system to fail.  But this could be any registry entry, really.  So, yes, after hooking the registry calls, I would have to simulate a successful call, returning the protected/virtual registry key data (contained within my files) that I depend upon, passing those back to the caller as the legitimate result.   The real regististry would therefore not be impacted in any meaningful way (other than, for example, Explorer's recently opened list, etc).

As to safely determining the identity of the caller... that's an issue I have not yet addressed.  But  I suspect there may be several ways to skin that particular cat.  If need be, the customer could simply be instructed to run no other applications while running my application.  This would not be an unreasonable requirement.  Thus, if my application is launched, the hook will be installed, and all further requests may be assumed to come from authorized apps.  If my app is not running, then no hook.  Or my app itself could prevent launches of other apps while the hook is active. 

I have reviewed the FileMon demo as you suggested, and I do agree that much of the learning curve may be covered based on that demo.  But, as in the original post, there's a substantial amount of work to be done in many other areas - thus if someone already familiar with EasyHook would be interested in saving me that time in return for money, it may be that both parties benefit. 
Dec 1, 2008 at 11:40 AM
you simply want to simulate install success without actually installing the app in the registry or what???

That would be possible of course... But if you really want to manage a second registry in parallel to the windows registry you will run into serious issues...
Dec 1, 2008 at 1:23 PM
I appreciate your interest, Chris.

Let me try to present my goal in a slightly different fashion. 


Customer has selected third party APP_1 to manage its widgets production line.  APP_1 is closed source.  APP_1 requires activex comonent WidgetX_v_3_2.ocx (version 3.2) for proper functioning.  WidgetX_v_3_2.ocx  is NOT the current release (current release is v.8.7) and ONLY v3.2 is compatible with APP_1.  WidgetX is a VERY popular component used by EVERY software manufacturer in the world.

Customer has selected third party APP_2 to manage its order processing department.  APP_2 is closed source.  APP_2 requires activex comonent oProcessX_v_5_9.ocx (version 5.9) for proper functioning.  oProcessX_v_5_9.ocx  is NOT the current release (current release is v.6.1) and ONLY v5.9 is compatible with APP_2.  oProcessX is a VERY popular component used by EVERY software manufacturer in the world.

New laws require all data managed by APP_1 and APP_2 to be stored in encrypted form and inaccessible from unauthorized apps.  The individual manufacturers of APP_1 and APP_2 are unable or unwilling to meet these new legal requirements.

Customer will continue to select other software for their facility (ie: accounting software, backup software, etc), and all of these packages very may well use the latest versions of WidgetX and oProcessX components.

MyAPP is the program I have created to manage the data in a fully-encrypted virtual drive so that all data is encrypted.  MyAPP also controls which processes may access the data stored in the virtual drive and allows for APP_1 and APP_2 to work together.


Now, if we do the standard routine.... install APP_1, install APP_2, and MyAPP, everything will work fine.  **UNTIL** the customer installs a new application which overwrites/updates WidgetX or oProcessX, and which point both APP_1 and APP_2 will fail.  Such an installation will generally BOTH replace the component code file (the ocx) and update the registry.  Therefore APP_1 and APP_2 will have no access to the older compatible components.

My solution, then, is as follows:

Create a virtual drive.  Duplicate the file and directory structure created by installation of APP_1 and APP_2.  So, at this point, every single file that is necessary for APP_1 and APP_2 is present within my encrypted (and fully controlled) virtual drive.  This INCLUDES older oProcessX and WidgetX components.

The oProcessX and WidgetX components are now protected from overwrite by any future program installation.  HOWEVER, future installations of other programs will overwrite the REGISTRY entries related to the registration of the components.  Of course, APP_1 and APP_2 will be pointed to the updated (external to virtual drive) components during runtime and shall fail.

So, I need to hook registry calls from APP_1 and APP_2 and instead return suitable registry data to point them to the older components present within the virtual drive.

The result is essentially a zero-install application wherein all necessary files and registry entries are present in the protected virtual drive (and thus virtual registry), in that both apps are fully functional, but do not rely on external data or registry data.

I hope this sheds some light.  The situation is entirely fictional, but the general goal and challenge is hopefully clearer.

Dec 1, 2008 at 3:57 PM
Edited Dec 1, 2008 at 3:59 PM
without knowing any further details I would say that this is a pretty easy task (I mean the part where you have to hook the registry calls and "emulate" the old activeX controls). Also the indended security has nothing to do with these hooks, which is a good thing ;-). Your "insight" made the thing much clearer to me... And because you know about the apps you are going to hook things will get much more comfortable... Initially I thought you want to realize such a thing for ANY application...

How is your timeplan for this (I think the hooking part is completly standalone, so you could first develop the rest of the app and add the hook thing at the end)? Currently I am very busy (because I have my own project running and studying physics) but in late Februar maybe I could spend some time...
Dec 1, 2008 at 3:58 PM
Edited Dec 1, 2008 at 3:58 PM
not much time, but as I said if this is all you want to do in case of hooking, I should be able to do this in some days...
Dec 1, 2008 at 4:36 PM
Ah, good!  My lengthy explanation seems to have served its purpose.

Yes, all that is requested in the hooking mechanism (hook, identify details of call, provide "virtual registry" data for return to caller).  All other code is on my platter.

And you are absolutely correct - the entire project can be brought to a nearly completed stage, implementing hooking only at the end.

Timetable?  Completing one project this month.  I hope to begin design of this hooking-related project early January.
Dec 1, 2008 at 4:42 PM
Oh... where are you located, Chris?  Seems like I may have seen Germany as your home?
Would need to get payment issues resolved (for example, it's very difficult & expensive to send money to Russia).
Not quite sure how easy or reasonably-priced transfers are for Germany.
Dec 1, 2008 at 8:26 PM
Good ;-)... Yes I am in germany... 

If you know more about your specific requirements don't hesitate to contant me again. You may send me a private message for contact data exchange...
But I will definitely have no time in the first three februar weeks (testpaper time ;-) ) ... After this period I can provide you some code!

I think with PayPal there are no fees...

Dec 2, 2008 at 12:11 PM
Sounds good, Chris.

I will continue work on my current project.  As I begin working on the hooking project, I'll contact you and provide additional design details (which, of course, are not fully defined at this time) as they come to be.  So for some weeks ahead, I may not have any further contact.

Now... how may I contact you off-forum?  I don't recall seeing direct contact info.  If you have access to my email address (used by your discussions forum), please feel free to contact me at that address.
May 8, 2009 at 9:40 PM


Have you made any progress writing this "virtual registry" or other registry-hooking application?  I've worked fairly hard to master this, and I have a working sample for some registry operations.  But I am not successfully able to hook into ALL registry query operations.

I *think* I am hooking correctly into RegQueryValueExA, RegQueryValueExW, RegQueryValueA and RegQueryValueW.  However, when I compare the registry keys observed by RegMon / ProcMon, I don't see near the same volume of keys being intercepted through my EasyHook interface.  Perhaps there are other APIs to hook -- I am just not certain.

Further, I am having difficulty in determining the full registry path value of keys supplied to the hooked calls that I am successfully intercepting.  I can get the subkey or child key name from the passed params, but not the full path.  RegMon appears to be able to get the full paths, even for those keys that were not opened during the regmon session.  So, it is not a case of caching the key values to key paths.  Caching, tho, does remain an option; it just involves some resource locking that I wanted to avoid.

If you have any code that you can share of successful implementations of registry hooking, I would be much appreciative.


May 8, 2009 at 10:10 PM

I guess you could use a kernel mode driver using  RegistryCallback instead?

Ben Schwehn

May 8, 2009 at 11:46 PM
Edited May 8, 2009 at 11:59 PM

Or you could try to only hook the more basic user mode functions in ntdll: NtCreateKey, NtOpenKey, NtOpenKeyEx, NtQueryValueKey as there are so many different functions to access registry keys with(RegQueryMultipleValues, RegEnumKey, RegReplaceKey, SHQueryValueEx etc). I believe all those methods go through those few basic ntdll functions.

Benjamin Schwehn

May 9, 2009 at 8:47 AM

No, currently I have no plans to release such software....

But bschwehn ist right... either hook the basic NtDll methods or go directly into the kernel. But first you should try to get a sample working by hooking the NtDll methods. These guys are almost equal to the ones in kernel mode, so the only left to do would be to redirect the calls from kernel mode to your user mode application...




May 9, 2009 at 1:35 PM



I'm happy to see some activity on this thread - and hopefully you are making progress with this issue.  I had originally planned (hoped) to embark on the relevant project in January, focusing on the hooking in February.  An urgent project came along and set me behind schedule on this hooking issue.  The hooking task is now delayed until late summer.

jlb0001, once you get your code working, I'd be happy to pay you for your source code.  Please contact me if you have questions.

May 11, 2009 at 7:50 PM

Thanks Benjamin and Chris for the pointers.

Since I had no idea about the NtDll APIs, I thought I'd share a link to a CodeProject article that's really informative on the subject for those like me that weren't aware of this alternate API:


Oct 5, 2009 at 3:21 PM
Edited Oct 5, 2009 at 3:23 PM

Hello Benjamin, Chris and Jonatham,

Did anyone get some progress about monitoring registry? If yes, what functions were necessary to hooking ? There are some new samples?

I´m currently work in a project very similar with your purpose 13Qn16cwZpYrA5Wv, but with other application. I already hook file operations and so on, it´s missing finish the registry monitoring module This project doesn´t have comercial purpose, i am a mastering student and this is part of my final thesis which have the theme computer virtualization aprouch.

13Qn16cwZpYrA5Wv did you finish your project  ? 

Thanks, Rafael (Brasil)


Oct 5, 2009 at 7:01 PM
On 05.10.2009 15:21, superrafao wrote:
> From: superrafao
> Did anyone get some progress about monitoring registry?

I didn't do any work on this. But I don't think it should be too hard.
I'd start by just hooking all the NtDll Registry API and post specific
questions if you run into problems. If you're deciding on going to
kernel mode hooking, iirc there is an example in the EH documentation.

If you've never done anything in kernel mode before, have a look at some
of the basic kernel mode driver tutorials out there, also
has plenty information on kernel drivers.

Good luck with your thesis!

Benjamin Schwehn
Oct 6, 2009 at 12:54 PM

Hi Benjamin,

Thanks for reply, i will take a look at the documentation and tutorials as you said. I believe that monitoring the NtDll Api will work fine for me.

Thansk again,