Windows7 uses outlook 2010, at least where I work all windows7 systems are configured to use outlook 2010.
Are you saying that 2010 is a standard for Windows 7? ... That would be wrong, Windows 7 doesn't use 2010, it uses whatever Office version you've installed lol.
I would assume that it fails on Windows 7 because of the permission issues that were introduced ever since Vista and UAC. I'll have to take a look at the source code in more depth before I can verify that, but I don't see why it should be anything else if the same constraints were enforced with Outlook versions and whatnot during the tests.
edit: You are making the assumption that you have proper access to that registry location, even though you're being greedy and requesting all access, when you only need to read the value... A feature of the access control model may prevent this. Although, the issue here is with views to the registry WOW64 . Read this:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa384232%28v=vs.85%29.aspxAnd this:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa384129%28v=vs.110%29.aspxBy default, a 32-bit application running on WOW64 accesses the 32-bit registry view and a 64-bit application accesses the 64-bit registry view. The following flags enable 32-bit applications to access redirected keys in the 64-bit registry view and 64-bit applications to access redirected keys in the 32-bit registry view. These flags have no effect on shared registry keys.
From my testing RegOpenKeyEx() is returning ERROR_FILE_NOT_FOUND, meaning redirection is acting against it from what I can tell. What environments did RBA test this on exactly?
http://msdn.microsoft.com/en-us/library/windows/desktop/aa384253%28v=vs.85%29.aspxAn option I would've went with is to get Outlook to load your malicious DLL that calls to open and query the registry. This way, you'd inherently be granted the permissions of that process which probably already makes subsequent calls to check the registry value itself, and all you'd have to focus on is grabbing that value and sending it over. Look up the order in which DLL's are located, and enumerate the KnownDLL's object to make sure that the one you've chosen doesn't exist in System32. The domino effect starts as soon as a reboot takes place and Office is loaded at startup. The other way would be to inject directly, but an AV might be more aware of that.
edit: You're using a lot of code that looks more like genuine C, for a C++ project however.
Nice idea though. You should look at how lame the protection is for the PST file format too lol.