1〉針對windows平臺客戶

可以考慮使用商用軟體如 Excelsior Jet 將你的程式.jar檔案轉化為一個可執行檔案(.exe).

This is foolproof: it is impossible to get the .java file back if you use Excelsior Jet (so long for all the people saying "it's impossible to prevent decompilation of a .class file"). Sure, an attacker could launch SoftIce and try to trace your .exe

2>平臺獨立性 包括 OS X and Linux ，並不想花錢買商用軟體 Excelsior Jet.

一種方法是讓程式只用能連線到網際網路的環境中使用，這樣可以通過線上檢測的方法來保護您的程式，這樣可以通過設計成服務端和客戶端安裝模式，讓部分程式功能必須通過服務端產生，通過網路傳送到客戶端的形式來保護。

I'm writing a commercial software written in Java. That software only makes sense if there's an Internet connection. Hence we "protect" our software, amongst other, by having part of the computation happening on the server side: we have several .class that won't work unless they're generated from the server side and we send them down the wire (and what is sent on the wire is always

如果你的客戶不滿意必須藉助網際網路環境的執行方式，當然可以讓他們選擇通過購買商用軟體的方式來保護。

This requires an Internet connection but if the user doesn't like how our software works then he's free to buy one our competitor's inferior product ;)

Decompiling will not do much good: you actively need to crack the software (ie reproduce what is happening on the server side) or you won't be able to use it.

另一種更實際的方法是通過“模糊”Java類檔案，同時引入位元組流亂碼處理，處理之後再通過Proguard處理，改變這個程式框架，去除面向物件架構來模糊化程式的邏輯和字元處理。最終的jar包還需依賴服務端傳送過來的java類，這樣程式的架構基本失去原樣，即使被破解，可維護性極差。

We use our own "string obfuscation" before we use Proguard. We also do source code instrumentation (we could have done bytecode instrumenation as well) where we remove lots of things from the code (like the "assert" that we comment out) and introduce some random "code flow obfuscation" [the software can take different paths yet obtain the same result, this is something that really makes the software hard to trace]).

Then we use Proguard (which is free) to flatten all our OO hierarchy and to obfuscate the already-code-flow-and-string-obfuscated code.

So our flow is:

• string obfuscation
• random code flow obfuscation
• Proguard
• final .jar that depends on .class that are (differently) dynamically generated on the server side.

In addition to that we release very regular (and automated) update which always make sure to modify a bit our client/server protection scheme (so that with each release an hypotethical attacker has to start mostly from scratch).

Of course it's easier to throw the towel in and to think: "there's nothing I can do to make an attacker's life harder because JAD can find back the .java file anyway" (which is more than very debatable and blatantly wrong in the case where you use a .class to .exe converter to protect your .class from decompiling).