디 컴파일을 방지하기 위해 컴파일 된 Java 클래스를 잠그는 방법은 무엇입니까?

디 컴파일을 방지하기 위해 컴파일 된 Java 클래스를 잠그는 방법은 무엇입니까?

---

디 컴파일을 방지하기 위해 컴파일 된 Java 클래스를 잠 그려면 어떻게합니까?

나는 이것이 인터넷에서 매우 잘 논의 된 주제 임에 틀림 없다는 것을 알고 있지만 그것들을 참조한 후에는 어떤 결론에 도달 할 수 없었다.

많은 사람들이 obfuscator를 제안하지만 기억하기 어려운 문자 시퀀스로 클래스, 메서드 및 필드의 이름을 변경하지만 민감한 상수 값은 어떻습니까?

예를 들어, 암호 기반 암호화 기술을 기반으로 암호화 및 암호 해독 구성 요소를 개발했습니다. 이제이 경우 모든 평범한 Java 사용자는 JAD 를 사용 하여 클래스 파일을 디 컴파일하고 소금 뿐만 아니라 비밀번호 값 (상수로 정의 됨)을 쉽게 검색 할 수 있으며, 작은 독립 프로그램을 작성하여 데이터를 복호화 할 수 있습니다!

또는 이러한 민감한 구성 요소를 네이티브 코드 (예 : VC ++)로 빌드하고 JNI 를 통해 호출해야 합니까?

---

고급 자바 바이트 코드 난 독기 중 일부는 단순한 클래스 이름 변경 이상의 기능을 수행합니다. 예를 들어, Zelix KlassMaster 는 코드 흐름을 따라 가기가 정말 어렵게 만들고 훌륭한 코드 최적화 도구로 작동하는 방식으로 코드 흐름을 뒤섞을 수도 있습니다.

또한 많은 obfuscator는 문자열 상수를 스크램블하고 사용하지 않는 코드를 제거 할 수 있습니다.

또 다른 가능한 솔루션 (난독 화를 반드시 제외 할 필요는 없음)은 암호화 된 JAR 파일 과 암호 해독을 수행하는 사용자 정의 클래스 로더를 사용하는 것입니다 (가급적 네이티브 런타임 라이브러리 사용).

세 번째 (그리고 아마도 가장 강력한 보호 기능을 제공함)는 GCC 또는 Excelsior JET 와 같은 기본 사전 컴파일러를 사용하는 것 입니다. 예를 들어 Java 코드를 플랫폼 별 기본 바이너리로 직접 컴파일합니다.

어쨌든 당신은 에스토니아어 "자물쇠는 동물을위한 것"이라는 속담을 기억해야합니다. 즉, 런타임 동안 모든 코드를 사용할 수 있고 (메모리에로드 됨) 충분한 기술, 결정 및 동기 부여가 주어지면 사람들이 코드를 디 컴파일, 스크램블 및 해킹 할 수 있고 그렇게 할 것입니다. 여러분의 임무는 단순히 프로세스를 다음과 같이 불편하게 만드는 것입니다. 당신은 여전히 ​​일을 계속할 수 있습니다 ...

---

암호화 된 데이터와이를 해독하는 소프트웨어에 모두 액세스 할 수있는 한 기본적으로이를 완벽하게 보호 할 수있는 방법은 없습니다. 이전에이 문제를 해결 한 방법은 동글, 원격 인증 서버 등과 같은 암호화 / 복호화를 처리하기 위해 외부 블랙 박스를 사용하는 것입니다.하지만 사용자가 자신의 시스템에 대한 전체 액세스 권한을 가지고 있다는 점을 감안할 때 어렵고 불가능하지는 않습니다. 온라인 게임 서버와 같이 "블랙 박스"에 저장된 기능에 제품을 직접 연결할 수 없다면.

---

면책 조항 : 저는 보안 전문가가 아닙니다.

이것은 나쁜 생각처럼 들립니다. 누군가에게 당신이 제공 한 '숨겨진'키로 물건을 암호화하게합니다. 나는 이것이 안전 할 수 있다고 생각하지 않는다.

비대칭 키가 작동 할 수 있습니다.

• 암호 해독을 위해 공개 키로 암호화 된 라이선스 배포
• 고객이 새 라이선스를 생성하고 암호화를 위해 귀하에게 보내도록합니다.
• 새 라이센스를 클라이언트로 다시 보냅니다.

확실하지는 않지만 클라이언트가 실제로 제공 한 공개 키로 라이센스 키를 암호화 할 수 있다고 생각합니다. 그런 다음 개인 키로 암호를 해독하고 다시 암호화 할 수도 있습니다.

당신은 당신이 실제로 바로 고객에서 물건을 받고 만들기 위해 고객 당 별도의 공개 / 개인 키 쌍을 유지할 수 - 지금 당신은 키에 대한 책임이 있습니다 ...

---

무엇을하든 '디 컴파일'될 수 있습니다. 그냥 분해하면됩니다. 또는 상수를 찾기 위해 메모리 덤프를보십시오. 컴퓨터가 그것들을 알아야하기 때문에 여러분의 코드도 알아야합니다.

이것에 대해 어떻게해야합니까?

키를 코드에서 하드 코딩 된 상수로 제공하지 마십시오. 사용자 별 설정으로 유지하십시오. 사용자가 해당 키를 관리하도록합니다.

---

@jatanp : 또는 더 좋은 방법은 디 컴파일하고 라이선스 코드를 제거하고 다시 컴파일 할 수 있다는 것입니다. Java를 사용하면이 문제에 대한 적절한 해킹 방지 솔루션이 있다고 생각하지 않습니다. 사악한 작은 동글조차도 Java로 이것을 막을 수 없습니다.

내 비즈니스 관리자는 이것에 대해 걱정하고 너무 많이 생각합니다. 그러나 다시 우리는 라이선스 조건을 준수하는 경향이있는 대기업에 애플리케이션을 판매합니다. 일반적으로 빈 카운터와 변호사 덕분에 안전한 환경입니다. 라이센스가 올바르게 작성된 경우 자체 디 컴파일하는 행위는 불법 일 수 있습니다.

그래서 나는 당신이 당신의 응용 프로그램을 찾고있는 것처럼 정말로 강화 된 보호가 필요합니까? 고객 기반은 어떻게 생겼습니까? (기업? 아니면 10 대 게이머 대중, 어디가 더 문제가 될까요?)

---

라이선스 솔루션을 찾고 있다면 TrueLicense API를 확인할 수 있습니다 . 비대칭 키 사용을 기반으로합니다. 그러나 애플리케이션이 크랙 될 수 없다는 의미는 아닙니다. 모든 애플리케이션은 충분한 노력으로 크랙 될 수 있습니다. 정말 중요한 것은 Stu가 대답 했듯이 귀하에게 얼마나 강력한 보호가 필요한지 파악하는 것입니다.

---

효과적인 오프라인 불법 복제 방지 방법이 없다고 생각합니다. 비디오 게임 산업은 여러 번 시도해 왔으며 그들의 프로그램은 항상 크랙되었습니다. 유일한 해결책은 프로그램이 서버와 온라인으로 연결되어 실행되어야하므로 lincense 키를 확인할 수 있고 라이센스 사용자가 한 번에 하나의 활성 연결 만 있는지 확인할 수 있습니다. 이것이 월드 오브 워크래프트 또는 디아블로의 작동 방식입니다. 심지어 보안을 우회하기 위해 개발 된 개인 서버가 있습니다.

그렇긴하지만 중대형 기업이 불법 복제 소프트웨어를 사용한다고 생각하지 않습니다. 라이선스 비용이 적기 때문입니다 (아마도 프로그램에 대해 얼마나 많은 비용을 청구해야하는지 모르겠습니다). 평가판 비용.

---

걱정없이 바이트 코드 암호화를 사용할 수 있습니다.

사실은 위에서 인용 한 "자바 바이트 코드 암호화 크래킹"에 논리 오류가 포함되어 있습니다. 논문의 주요 주장은 모든 클래스를 실행하기 전에 암호를 해독하고 ClassLoader.defineClass(...)메서드에 전달해야한다는 것 입니다. 그러나 이것은 사실이 아닙니다.

The assumption missed here is provided that they are running in authentic, or standard, java run-time environment. Nothing can oblige the protected java app not only to launch these classes but even decrypt and pass them to ClassLoader. In other words, if you are in standard JRE you can't intercept defineClass(...) method because the standard java has no API for this purpose, and if you use modified JRE with patched ClassLoader or any other “hacker trick” you can't do it because protected java app will not work at all, and therefore you will have nothing to intercept. And absolutely doesn't matter which “patch finder” is used or which trick is used by hackers. These technical details are a quite different story.

---

Q: If I encrypt my .class files and use a custom classloader to load and decrypt them on the fly, will this prevent decompilation?

A: The problem of preventing Java byte-code decompilation is almost as old the language itself. Despite a range of obfuscation tools available on the market, novice Java programmers continue to think of new and clever ways to protect their intellectual property. In this Java Q&A installment, I dispel some myths around an idea frequently rehashed in discussion forums.

The extreme ease with which Java .class files can be reconstructed into Java sources that closely resemble the originals has a lot to do with Java byte-code design goals and trade-offs. Among other things, Java byte code was designed for compactness, platform independence, network mobility, and ease of analysis by byte-code interpreters and JIT (just-in-time)/HotSpot dynamic compilers. Arguably, the compiled .class files express the programmer's intent so clearly they could be easier to analyze than the original source code.

Several things can be done, if not to prevent decompilation completely, at least to make it more difficult. For example, as a post-compilation step you could massage the .class data to make the byte code either harder to read when decompiled or harder to decompile into valid Java code (or both). Techniques like performing extreme method name overloading work well for the former, and manipulating control flow to create control structures not possible to represent through Java syntax work well for the latter. The more successful commercial obfuscators use a mix of these and other techniques.

Unfortunately, both approaches must actually change the code the JVM will run, and many users are afraid (rightfully so) that this transformation may add new bugs to their applications. Furthermore, method and field renaming can cause reflection calls to stop working. Changing actual class and package names can break several other Java APIs (JNDI (Java Naming and Directory Interface), URL providers, etc.). In addition to altered names, if the association between class byte-code offsets and source line numbers is altered, recovering the original exception stack traces could become difficult.

Then there is the option of obfuscating the original Java source code. But fundamentally this causes a similar set of problems. Encrypt, not obfuscate?

Perhaps the above has made you think, "Well, what if instead of manipulating byte code I encrypt all my classes after compilation and decrypt them on the fly inside the JVM (which can be done with a custom classloader)? Then the JVM executes my original byte code and yet there is nothing to decompile or reverse engineer, right?"

Unfortunately, you would be wrong, both in thinking that you were the first to come up with this idea and in thinking that it actually works. And the reason has nothing to do with the strength of your encryption scheme.

참고URL : https://stackoverflow.com/questions/49379/how-to-lock-compiled-java-classes-to-prevent-decompilation