I am adding a feature to my bot to protect cd-keys and account passwords from other malicious users that may use your computer.

The process is:

Create a file with the encrypted attribute, but not really encrypted. Write the sensitive data to the file, close the file. Then open and read the file using OpenEncryptedFileRaw and ReadEncryptedFileRaw. Uuencode the resulting data and put it in the registry for storage. To get them back, the process is reversed, creating the file using OpenEncryptedFileRaw and WriteEncryptedFileRaw, close it, then read it back in the normal method. In theory this should work, but it is unproven due to stack corruption problem I am having.

During the callback, on the first iteration of a manual copy, the value of the ulLength variable (seen in ExportCallback) is being interpreted as an address (or something like that). For explanitory purposes. Lets say the ulLength vairable is 7. The program will try to read from address 7. The only thing I can think of is stack corruption, but I am sure I never did anything to corrupt the stack; I created a small test project where it only did this and still had the same problem.

Any thoughts?

[quote author=Shout link=topic=12316.msg121839#msg121839 date=1122184675]Any thoughts?[/quote]

I think it'd help to see the code that is causing the problem.

I think the question that begs asking is why not just use the encrypted file on the disk as opposed to writing its contents to the registry?