是值得嘗試的Spring應用程序的混淆嗎？

我想使用混淆器（例如ProGuard）來保護我的Web應用程序中的IP。我知道混淆字節碼的侷限性，並且可以反編譯它。但是，如果我知道網絡服務器上存在混淆的戰爭文件，我感覺會好一點... 使用ProGuard進行第一次測試後，我懷疑他們使用「入口點」的方法對使用SpringMVC的Web應用程序是否有用。 ..和春天。如果我必須「保留」所有的@Repository，@Service，@Controller和@Component註釋類，併爲此將它們排除在混淆之外，那麼這樣一個工具的主要問題就不會實現。我讀過，我應該使用基於Java的Spring配置，而對於Spring 3.1，這方面有很多改進，但是值得使用它？任何工具真的可以混淆Spring Beans嗎？是值得嘗試的Spring應用程序的混淆嗎？

Dominik

來源

2011-11-01 Dominik

如果這是一個未在客戶機上部署的Web應用程序，那麼它肯定不值得。如果是，它*可能*，但我通常會持懷疑態度。 –

模糊服務器端代碼沒有意義。

如果攻擊者能夠在您的服務器的文件系統，該文件.war將是你最問題

來源

2011-11-01 12:23:56 Bozho

我會跟Bozho同意，這是隻安裝自己控制的服務器上的條件，但也有病例在那裏你可以發送給客戶，你想要的東西像簡單的DRM，然後你想混淆爲小增加保護。

我從來沒有用過Spring，但是你面臨的問題聽起來像是一個常見的混淆問題，你不能保護入口點，因爲在某些時候某些不知道混淆的東西需要調用它。

如果可能的話，我建議重構，讓入口點類變爲啞殼，通過調用包含實現的混淆類。

一個額外的音符，它總是有用使用反編譯器在你混淆的JAR，你會看到很快你混淆的努力有多成功了&什麼重要的代碼是未進行模糊處理，那麼你就可以調整配置&改善混淆。

來源

2011-11-01 12:42:05 Jonathan

我希望這個問題還沒有回答。

我有@Dominik表達的同樣的問題。

如果我們繼續@Repository，@Service，@Controller，@Component，@Entities，@Transactional & @Cachable完好，它沒有意義在所有混淆。如果我錯了，請糾正我。任何人嘗試任何不同的方法來混淆Spring MVC代碼？

來源

2015-03-26 13:01:08 devThoughts

是值得嘗試的Spring應用程序的混淆嗎？

回答

相關問題