I have a quick question. I want to use encrpytion/decryption in my application. I will encrypt some data using my private key, and I want
the application to decrypt the encrypted data using the public key.

However, I'd like to hide the public key in the application so that it cannot
be discovered by people disassembling the EXE file.

What is the best way to hide it in the code so it is at least relatively difficult to find the public key?

Thank you!

1 Search "steganography" in Google

2 Look into Malathia site.

3. Hiding the Key can be trivial, Hiding the PROCESS that reads the key and does the encrypt-decrypt job is a completely different matter. Once you isolate that code it would be simple to catch it reading the "hidden" public key. That is the challenge

I guess my question should have had 2 parts:

Part #1: How do I hide the public key in the file itself so that you can't just look at it with a disassemler and a hex editor and figure it out in 2 minutes?

This one, you answered. Thank you. I will do the searches you suggested.

Part #2: How do I hide the public key once it is extracted from the EXE file and it is sitting in memory?

Without some code to defeat SoftICE or debugging tools which can attach themselves to processes, I can't hide it, right? No matter how well I hide this key in the EXE file, it has to be used at some point, and at that point it is vulnerable.

Do you have any suggestions to at least make it relatively difficult to get to the key once it is extracted and sitting in the process memory?

Thank you!

Why would you need to hide the public key? I mean this is the whole point of asymetric crypto, is that the public key is well, hmm its : public !!!

No one will be able to do anything with it anyway without the private key.

Anyway, if you have to hide something, then your app isn't truly secure, and you haven't thought it out correctly. Crypto, when correctly applied, is secure. It's just most people screw it up.



At the risk of sounding like a jerk, this is a reversing board, not a create-a-protection board. We help enough authors improve their protection as it is

-nt20

Well, kind of. When you encrypt something with the public key, only the private key can decrypt it. Conversely, when you encrypt something with the private key, only the public key can decrypt it. That sounds useless, but it's actually more or less how signing a document with your private key works. If the public key succesfully decrypts the signature block, then you know that the sig block was made by the private key. And if the decrypted signature block is still a succesful hash of the signed text, then you can be reasonably certain that the document hasn't been modified since the signature was made. That's a bit of an oversimplification, but you get the idea.

Somehow I don't think that's what was meant here, though. I think the OP got the keys backwards. Encrypt with the public, decrypt with the private. I suppose you could encrypt your code with your public key and then hope to "hide" your private key in the software somewhere so that you could decrypt it covertly, but that's not nearly as secure as it sounds. Public key cryptography is strong if and only if you keep your private key private. But more than that, sooner or later you're going to have to decrypt the code in memory, at which point it could be dumped and analyzed in unencrypted form.

Well as TBone and tesla suggested, perhaps I am doing something I shouldn't be doing... I am planning to use the encrpytion/decryption for a software registration system. If I am only sending the app some information in encrpyted form, then keeping the public key in the app and encrypting the info using the private key should be fine.

If I ever hope to send something back from the app to myself in encrypted form though, then I'd like the key to be secret still so that someone else can't find the key and forge a message back. Then I won't know if the app sent the message or someone else using the app's key sent the message...

I didn't post the message on here to come up with a good protection system although the replies kinda steered the conversation in the direction. I posted the message here in the hopes of finding a good way to hide the key in the EXE file somehow. Since you guys reverse engineer all the time, I figured you'd know of some tricks that I wouldn't know or couldn't easily find about.

So if you could tell me what ways I can use to hide the key in the EXE and in the memory, I'll worry about creating a good security model.

Thanks again!

If you are looking to have the application possibly send data back to you in an encrypted fashion, you should look into the internals of how SSL and Kerebos security works. They use techniques to validify the sender of messages on both ends, I believe especially Kerebos was designed for the type of thing you are describing (preventing "man in the middle" But I don't have my security book in front of me so I don't remember 100%.

No doubt about it, using crypto the right way for real security is hard. You'll have to study up on it a bit to find the correct way. Like I said, you are only as strong as your weakest link, and most shareware authors don't know enough about crypto and end up implementing it with a big loophole. If it's implemented right though, you won't have to hide anything because there just won't be much a cracker can do.

It wouldn't hurt to invest in a good crypto book that explains the basic methodologies and techniques (not necessarily the algorithms, because they can be complex). After that you can move on to the algos.

-nt20

Isn't it so that when you pack your exe with exe stealth it will almost be impoossible to unpack.. If thats true you can just pack it with exe stealth.

Yes, of course, why didn't we think of that...

Now when that's settled, I guess we can close down this board, all is lost anyway if people start using exestealth on their applications...

hmm. Does dev_zero work for a certain packer company or something..

Anyway, you want to be another ignorant shareware author? Don't be ignorant, learn something new, get some crypto books and learn how to do it right.

-nt20

I fully agree. Learn to crack and then learn to protect. It's the only way to go.

Sadly, the more I reverse engineer apps and see how their protection works, the more pesimisstic I get. Ultimately the CPU has to execute the instructions which means at some point somehow, the code will be vulnerable in memory or in the registers. I don't think there is anyway around that without detecting SoftICE and debuggers in memory and preventing them from doing their dirty work. I don't know if I want to invest much time into trying to keep seasoned crackers out of my code. They are not potential customers anyhow since they were not willing to pay for the app in the first place.

By the way, I have been reading crypto books for a while now. Right now I am munching on "Applied Cryptography" by Bruce Scheier. Reading cryptography doesn't help too much. Cryptography books are not written to teach shareware programmers how to protect their code. Some of the techniques in such books could definitely be used to protect the executable, or create time-limited, crippled code, but it is definitely not a straightforward thing to do. You have to read the books and devise your own method which may or may not be secure.

I am basically trying to stop casual people from figuring out (using debugging tools) where my keys are, how the decryption works and what part of the EXE holds the protection related code... No amount of encryption will help me to achieve this. The best I can do is make life harder for people who are determined to crack my protection. For that, I need to hide things well which is why I came here. For some reason I thought a reverse engineering forum would have lots of people who come across good tricks to make it hard to figure out what an EXE does. I know you guys are not crackers per se, but you still have to figure out how code works without looking at its source code. I could be wrong. If this is not a good place and you know of a better forum, please do let me know!

Thank you.

um once again.
if you wanna use asymmetric crypto and runtime code decryption why hide public (rsa) key ? dont see any reason to do that. if i find "trash" code in disassembly and see a 1024bit rsa key i will definitely drop cracking this one. unless of course someone may try find bugs in your crypto implementations. but VERY few ppl actually do that
on the other hand 1 leaked key and you are yet another author of cracked shareware ;p

Howdy,

Lets look at it from a different angle.

Who hides a public key ? We all agree that it makes no sense but,
Why not hide it ? For the lack of a better phrase, call it a "encrypted access key".

A sort of double keyed protection. Is it foolish ? Maybe.
I don't think we have looked at all the possibilities.

In order to protect a demo/share version, the author needs a way to "protect" his app from the ware--z people.
Would it be easier to block this encrypted key or add cripple crap to the prog ?
I think cripple crap is a waste of time. Sooner or later someone will wade through the bazillion lines and figure it out.

If you encrypt it, you have one more layer of protection.
If your key has been exposed, would it not be easier to just kill the bad key and issue a new one with future downloads ?

I know there are progs that use something like this. Kind of like the reg code blocking after something has been ware---zed to hell.

Just some thoughts,
Woodmann

Well based on what is suggested above by r4g3, someone could go into the exe, find the public key, decrypt the encrypted code, dump it to a file, fix up the PE and run the app forever... I am not saying it is easy to do, but it is not that hard either. For this scheme to work, you need to hide the public key. Asymmetric crypto works much better for -say- securing a comm channel. When the user has access to your binary, a disassembler and some time, it is not as good.

You are all correct that if I implement things correctly, I shouldn't have to hide anything. I really like the idea of not using obscurity as security. Definitely not the right way to go.

I need to come up with a method that makes everything depend on each other so that people cannot change anything in the EXE binary, cannot bypass anything (modification of EXE should not be allowed), cannot modify the public key embedded in the app, etc.. so and so forth. I also need to somehow find a way around dumping. The app will have to do much more than just decrypting the encrypted version of itself and run it. If someone dumps that code to a file and tries to run it, it should somehow know that something is wrong (EXE integrity checking).

What I just said in this post renders my original question useless since trying to hide information is irrelevant. It will eventually be found. Thank you for helping me see that point.

Thank you all for your input and time.

yes, but again - you can do that only if you have a valid key. this is because is usuall shemes rsa is used only to prevent keygens. entered serial decrypted with rsa, sanity check and then use some part of decrypted serial for symmetric cipher which does the actual code decryption. This is becuz rsa would be too slow and more importantly decrypting using public key would indeed make whole thing useless (and yes you should worry about hiding it in that case).
It seems to me that you dont fully understand how it should be implemented.

LOL. You are on a quest for the holy grail of protections I'd say. If you find it you could make lot$ of money selling it to other shareware authors that's for sure.

Anyway, disregarding the whole EXE protection in itself, I thought you had said you would have been fine with the key being public but you wanted the app to be able to talk OUT to an external location securely. That's why I recommended Kerebos and SSL implementation study because you seemed to indicate you only wanted to prevent someone from using your public key and and making a fake message. Now, normally, people don't use the PUBLIC key to encrypt a message for authentication. That wouldn't make sense since it's a public key. They encrypt with the private key, and send it out to the world, and the world uses the public key to decrypt and see that the data is valid. If you want to go BOTH ways, you need a different implementation, which I believe you can find how to do with Kerebos or other. They use timed session keys combined with checksums, etc, etc, and also I think use a third party to help in the validation.

So I only was attacking your implementation because I thought this was your mission. Simply protecting an EXE- well, this has been performed over and over again by numerous shareware authors, you'll just have to try and think of everything that could be done to your app and try to prevent it. Without slowing the app to a crawl.

-nt20