Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top


We are in the position to offer a local appliance to run a version of our proprietary software, which is normally provided as SaaS.


What steps can be taken to mitigate trivial reverse-engineering in an untrusted environment, where they will have physical access to the box?

Clearly, it's 100% impossible to fully prevent IP leaks, as physical access is total access.

That said, what technical techniques could be applied to make reverse-engineering difficult/unfeasible?

Edit, for details:

  • The project is international, so legally limited
  • Network access is available, so perhaps a plan could be: Store applications on an encrypted filesystem, require a connection to one of our servers to retrieve the key for decryption, or something like that - anyone have any experience / insight?
share|improve this question

Hardware security tokens as mentioned can provide some security against piracy.

Not knowing what your software is, or what it does, it's hard to know what solutions could work. Are you putting the box on-site because it is more efficient? Are you putting the box on site so that the customer can administer it themselves? Is it because the customer is running it on an isolated network?

Many enterprise grade solutions use strict license agreements and cryptographicaly secure software keys with the name of the purchasing enterprise and the date of expiry clearly in them. It means that even employees who steal code only have limited use of it as the origin and time limits on its usage are clear.

But all this does little to nothing to protect against reverse-engineering.

Code obfuscators and obfuscating compilers might help you a bit. Again, it depends on your application, your application team, etc.

Physical tamper-resistance might also help, but it limits your ability to support the physical hardware. The payment card industry uses wire mesh inside some of their hardware with keys stored in volatile memory so that if the case is tampered with, important decryption keys are lost, rendering the device useless. Similar techniques are applied to HSMs (Hardware Security Modules), which are effectively tamper-resistant vaults for storing important crypto-keys.

The whole game is risk management. The expense of launching a lawsuit, the damage caused by a leak, the cost of securing the code, it all has to be weighed. Few secrets are so important that they need to be protected at all costs. The delay to market may cost you your time advantage, allowing a competitor to reach a comparable solution at a better price before you can get your locked down version out the door.

share|improve this answer
Thanks. The reason for the logistics is thanks to concerns over bringing data into the USA, which seems like everyone has a little bit of concern nowadays. – Bradley Jul 11 '13 at 15:38
Are you hearing this concern from customers? I'm trying to get a sense of the recent news and the impact to businesses which operate with the U.S. ... quickest short-term response for your business might be to use a hosting provider in the country of your customer. It would buy you time while you consider what's needed to create an appliance. Their domestic privacy law may be enough to convince them that you can't respond to U.S. requests to intrude on their data, and a statement that you're planning an appliance may address their future concerns. – mgjk Jul 12 '13 at 13:15

You can use obfuscation which can become cumbersome/complex, and if undocumented, not a good idea, or you can use something like Sentinel HASP. In a business situation though, SLA, TOS and voiding warranties make strong impacts when spelled out clearly. "THOU SHALL NOT ACCESS/REVERSE ENGINEER/etc, etc." It won't stop the reversing, but businesses take financial loss serious. More options would be boot encryption, passwords via booting, etc., however those too can become a management headache


share|improve this answer
Thanks for the response. Legally, we're limited due to the international nature of this project. It really sounds like the best we can hope to achieve is layers of obfuscation. :/ – Bradley Jul 11 '13 at 15:43

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.