May 2014 -

Should the user add decoys for tamper-proofing ?

Just because users use White Hawk Software tools does not prevent them from adding some protection code of their own.

Decoys are among the best defenses. However, use of decoys can become dangerous and may be tricky. 45-OIMP28-M

Consider a decoy having been introduced. What are the possibilities?

The decoy is not detected.
Nothing happens; no good, no bad. It still is there for possible later detection.
The decoy is detected, but confused with the real thing.
The best possible outcome. Attacker stops searching because he thought he got the result.
The decoy is detected and recognized to be a decoy.
The worst possible outcome. Any attacker is reinforced that there must be something worth hiding. Attacker will multiply efforts to search for the real thing.

Use of decoys is a strategic decision which can be made only after evaluating the possible outcomes and their consequences.

Should decoys be protected? Of course. If a decoy is not protected doesn’t that just scream this code is intended for viewing? On the other side: don’t protect it too well, or an attacker has no clue of the decoy and won’t waste his time.
So, how well should decoys be protected? That is a difficult question; maybe protect it just a tiny bit less then the real code. Or, have several decoys and protect them at different levels.

When time permits I plan on blogging how NestX86 itself takes advantage of decoys at different levels. …Here it is

Wanted by the FBI

Headline of the day

Chinese military unit charged with cyber-espionage…
(Guardian and 10000 other news sources) wanted

Will hacking indictment against Chinese stop theft of U.S. trade secrets?
(Business Journal)U.S. Charges Five Chinese Military Hackers with Cyber Espionage
(U.S. Department of Justice )

Another alternative could be…
3 guesses what other solutions White Hawk Software is thinking about?

new official reply

includes: An indictment is merely an accusation, and a defendant is presumed innocent unless proven guilty in a court of law.

Eat your own dog food

We reached an interesting way-point: “We got to eat our own dog food”. We created a protection for the protection-tool. First the obvious: we need tamper-proofing for the same reason everybody else does. But the second point is more interesting: pixabay_dog-72333 about every customer will ask us whether we protect our own tool. We just have to do it.

Of course we would have a good excuse: The majority of the NestX86 protection-tool is written in a high level, byte-coded language. Our product is about protecting machine-code in object files. That may be a very good excuse technically, but to our customers it may nevertheless feel lame.

We can’t really handle byte-codes, but we still had to fake it. Instead of writing another protection-tool, we made a custom-protection. It is a prime example for how good expert work and protection-design can make up for lots of automatic tools. We also learned the lesson we want our customers to learn: One can develop one’s own protection, but buying a tool is much cheaper. (We knew that before.)

We know our program. We know what parts we really want to protect. We know what parts might give most insight into the internal workings of the important parts. Our tools’ performance is so good, we can easily give away some computer cycles for the protection. Doing it manually, we can add some devious decoys. Not random decoys, but decoys aimed at the particular circumstances. In addition we can protect the base libraries together with the real tool. The quantity alone of the protected code should discourage most attackers. (How can an attacker crack the binary if the source code with all its documentation is still hard to comprehend?) We don’t randomly rename identifiers, but make sure our renaming causes confusion and some aliasing. A small number of artificial sub-classing, use of undocumented private algorithms and some multithreading should dot the i-s and cross the t-s. Not yet having a protection tool doesn’t mean we didn’t create a number of special-purpose hacks for modifications to our source code before compilation.

For now we skip semantics-preserving transformations, until we have a decent automatic pixabay_food-bowl-281980 analyzer and composer for byte codes. If we weren’t a penny pinching startup company we would have bought a tool from one of our competitors. The free tools we tried were too difficult to use for our program base. The grin of a competitors sales-person selling us a tamper-proofing tool would just have been completely unbearable.

Go try to hack our tool while there is still some possibility. With the next release, or maybe the after-next, you can forget that. Sorry, this is rhetorical only: For legal reasons the license for our tool prohibits reverse engineering of the tool.