Have a legacy code with a call to CryptImportKey function.
Recently faced a problem - on some machines code works fine, on some machines (at least on Win7x64 Pro) it returns 0 (GetLastError() returns an E_ACCESSDENIED error).
Don't actually know, what's the problem, and what kind of information can help investigate the problem. Will be provided, if any anyone give an advice.
I really appreciate any help you can provide.
Even admin user cannot perform this operation in described situation.
We try to do simple workaround - just rename the "ProgramData\Microsoft\Crypto\RSA\MachineKeys" folder and after automatic creating a new one just moved to it content from the old one. Don't now, how perfect is this "solution".
But it works.
UPD. Process runs from SYSTEM user, and it was enough to grant it with generic read/write access to this folder.
Related
I wrote a c++ program and I want to protect it.
I need that the program can run only on authorized computer, and I'd stop the program when I want.
I thought 2 solutions, but I'm not knowing if these are good or easily cracked.
The first solution:
local_mac_address = get_mac_address();
if(local_mac_address == "\* authorized addr */")
return true;
else
return false;
The second solution:
I upload an html page with a secret code on a my website.
page = download_page(url);
if(page == "my_secret_code")
return true;
else
return false;
If I'll change the code in the html source the program won't start.
What do you think about these 2 solution ?
Are they safety?
Edit:
The executable works on my computers in an office, so I want to avoid that someone can copy it and use on theyr computer
I'd say that both of these are easy to circumvent.
The first could be undone by simply preloading a shared library implementing the get_mac_address() function returning the expected result.
The second could easily be defeated by intercepting the network traffic and returning the expected reply.
Additionally, both could easily be disabled after a little work with a debugger, a disassembler and a hexeditor and just modifying the executable to bypass both checks.
Don't spend countless of hours trying to get your program "protected". It's impossible.
The moment that the executable is on the client's computer you have no control over what the client does with it and thus you should use your time working on more useful things for your application. Adding a bit of extra security is never a bad thing but don't make it the main focus point. If someone really wants to gain access, they will.
They are not safe at all.
The thing with protecting programs is that they are files,which can be opened by a disassembler or if you are so pro,with an hex editor.
With an disassembler your little code can be easily removed,and the program will run when the code is removed.
What you can is that you can encrypt the executable and have a decrypter at the start.Your site will give the decrypter the password,gives it another password to encrpyt the exec when it is done running for extra security.
if you put the decrypter at the start,or load the program as data(not exec) the decrypter wont have any problems running.Its called always online DRM.
My program is a dll that hooks into a running instance of IE. It's worked fine for years.
Recently I dusted it off and ran it, but the last line below fails with hr = 0x80040154:
#import <mshtml.tlb> rename("value", "theValue") rename("event", "theEvent")
#import <shdocvw.dll>
// ....
SHDocVw::IShellWindowsPtr spSHWinds;
HRESULT hr = m_spSHWinds.CreateInstance(__uuidof(SHDocVw::ShellWindows));
Could it matter that IE7 has been replaced by IE8? Where else should I look?
I'm using VS2008, if that matters.
Edited to add
I don't see that it could be a 32/64 bit issue - it ran fine last year on this same machine. The only thing that's changed (as far as I have noticed) is the version of IE, from 7 to 8.
Note to the bounty hunters:
I only have access to this system for a few hours a day (around 0:00 EST), so you may not get quick responses to your suggestions, but I will look into them.
If you think there are things I should be checking (registry values, for example), be specific.
Edited to add:
I now see that the first time I call CreateInstance, it returns 0x80070002, not 0x80040154.
That's going to be very hard to diagnose. The ShellWindows coclass is special, its CLSID registry key is HKEY_CLASSES_ROOT\CLSID\{9BA05972-F6A8-11CF-A442-00A0C90A8F39}. When you look there, you'll see nothing useful registered there. The background story is that this is a leftover of an ill-fated attempt to make the Windows shell resemble a web browser. Still visible today, enumerating the shell windows returns both Windows Explorer and Internet Explorer instances.
The SysInternals' ProcMon utility is almost always the weapon of choice to debug 0x80040154 errors but it falls flat here. You can see it probing the registry, and not finding what it is looking for, but then the program knows how to load ieframe.dll anyway. This can only work by the operating system intercepting the CoCreateInstance() call. Which makes sense in general, considering the coclass enumerates shell windows.
All you got left is the trial-and-error approach. Reinstall IE first, OS next. Or to shove the machine out of a 4th story window before it eats too much of your valuable time.
Specs: Windows 7 x64, Visual C++
Objective: I'm trying to get the remote PEB from a sample program (calc.exe e.g.). I've found the proc ID and I've opened a handle to the process with all the good rights. I've now moved on to writing a class to retrieve the location of the PEB from the process using PROCESS_BASIC_INFORMATION.
Problem: I've found several posts elsewhere that seem to indicate that the NtQueryInformationProcess turned to shit at MS. One post suggests a method of dynamic-runtime-linking NtQueryInformationProcess out of ntdll.dll. However, I think this would be unstable in the long-run (MS could remove NtQueryInformationProcess tomorrow) without extensive error handling.
This idea is realized later in this thread, and it is then suggested by Mike2343 that one should "use other methods."
Questions: What would be another method to locate the PEB of a remote process that doesn't involve NtQueryInformationProcess?
Thanks to anyone who spends any time looking at this.
Method I ended up using:
I stole pretty much all of this code and fixed it up for 64-bit. I spent a ton of time wrapping my head around various documents related to all of the different headers and structs. I also ran into an issue regarding the PE32+ format, where jcopenha was kind enough to enlighten me on a few problems I might be facing. After accounting for these problems I had a functioning program that is capable of obtaining a list of all the DLL's and their respective functions loaded in by an executable along with their relative addresses.
In retrospect, I don't think I had a good handle on what I was attempting to do. I think that I thought I was going to read in a process out of memory and find the PEB related structs or something (Later I found out that image headers and the like account for the information in the PEB). Albeit that may be possible, but what I have now is an offline example that reads in exe files and works for me.
I am trying to develop an IThumbnailProvider for use in Windows 7. Since this particular thumbnail would also be dependant on some other files in the same directory, I need to use something other than IInitializeWithStream to a path to work with, this being IInitializeWithItem. (Alternatively, I could use IInitializeWithFile, but that is even more frowned upon apparently.)
No matter what I do, I cannot get it to work. I have Microsoft's FileTypeVerifier.exe tool which gives the green light on using IInitializeWithItem, but when explorer calls it, it only seems to try IInitializeWithStream, ever. (This was tested by temporarily implementing said interface, and Beep()ing away in its Initialize()) Did I forget to configure something?
In short: how do I get this to work?
Okay, I finally found out what is the matter. To quote the Building Thumbnail Providers link on the MSDN website:
There are cases where initialization with streams is not possible. In scenarios where your thumbnail provider does not implement IInitializeWithStream, it must opt out of running in the isolated process where the system indexer places it by default when there is a change to the stream. To opt out of the process isolation feature, set the following registry value.
HKEY_CLASSES_ROOT
CLSID
{66742402-F9B9-11D1-A202-0000F81FEDEE}
DisableProcessIsolation = 1
I knew I was running out of process since I read elsewhere that thumbnailproviders ALWAYS ran out of process. But since that particular snippet is on almost -all- shell extension handlers, I interpreted it to be a overly happy copy-paste job, since it was -required- to run in-process the way I understood it.
And I was wrong. I hope this will help someone else in the near future. :)
I'm trying to use VDMEnumProcessWOW to find all 16 bit host processes on Vista. I call it, and it appears to not find any results even though I do have a 16 bit app running.
I've also tried calling VDMEnumTaskWOWEx with the process id I got for ntvdm.exe from Windows Task Manager, and that also returns no results.
ntvdm.exe has user name joeBlogs, and the application I've written to call VDMEnumProcessWOW is running as a service under the SYSTEM account. Is the problem that I need to have them running in the same session?
EnumProcesses works ok across sessions, but is VDMEnumProcessWOW different, or is there something else I'm missing? The documentation I've seen on this so far is a little sparse.
The VDM does contain the WowExec.exe task that the function's documentation says is required.
Thanks.
You can request the hotfix through this link.
Yes, a colleague just answered this. He ran into this problem before. It appears that VDMEnumProcessWOW does not work across sessions.
Also, Vista has some other problem enumerating 16 bit processes (I'm not exactly sure what they symptom is). There's a Microsoft supplied HotFix that is required to make this work.