컴파일된 Java 클래스를 잠그는 방법은 무엇입니까?

컴파일된 Java 클래스를 잠그는 방법은 무엇입니까?

컴파일된 Java 클래스를 잠그려면 어떻게 해야 합니까?

인터넷에서 잘 논의되는 주제라는 것을 알지만, 참고해서 결론을 내리지 못했습니다.

많은 사람들이 난독화기를 제안하지만, 단지 기억하기 어려운 문자 시퀀스로 클래스, 메서드, 필드 이름만 바꾼다면 민감한 상수 값은 어떻게 될까요?

예를 들어 암호 기반 암호화 기술을 기반으로 암호화 및 암호 해독 구성 요소를 개발했다고 가정합니다.이 경우 평균적인 Java 사용자는 JAD를 사용하여 클래스 파일을 디컴파일하고 비밀번호 값(정수로 정의됨)과 salt를 쉽게 취득할 수 있습니다.그러면 작은 독립 프로그램을 작성하여 데이터를 복호화할 수 있습니다.

또는 이러한 중요한 컴포넌트를 네이티브코드(예를 들어 VC++)로 빌드하고 JNI를 통해 호출해야 합니까?

일부 고급 Java 바이트 코드 난독화기는 클래스 이름 망글링 이상의 기능을 수행합니다.예를 들어, Zelix Klass Master는 코드 플로우를 매우 이해하기 어려운 방법으로 스크램블 할 수 있으며, 뛰어난 코드 옵티마이저로서 기능합니다.

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

(난독화를 반드시 배제하는 것은 아닙니다) 다른 해결 방법은 암호화된 JAR 파일과 복호화를 실행하는 커스텀클래스로더를 사용하는 것입니다(가능하다면 네이티브 런타임라이브러리를 사용하는 것이 좋습니다).

세 번째(그리고 가장 강력한 보호 기능을 제공할 수 있음)는 GCC나 Excelsior JET 등의 네이티브 컴파일러를 사용하여 Java 코드를 플랫폼 고유의 네이티브 바이너리로 직접 컴파일하는 것입니다.

어쨌든 에스토니아 속담에 있듯이 자물쇠는 동물을 위한 것이다.즉, 런타임 중에 모든 코드를 사용할 수 있고(메모리에 로드), 충분한 스킬, 결정력 및 동기 부여가 주어지면, 사람들은 당신의 코드를 디컴파일하고 해독하고 해킹할 수 있습니다.당신의 일은 그저 프로세스를 최대한 불편하게 만들고 계속 일을 하는 것뿐입니다.

암호화된 데이터와 암호를 해독하는 소프트웨어 모두에 액세스할 수 있는 한 기본적으로 이 데이터를 완벽하게 보호할 수 있는 방법은 없습니다.지금까지 이 문제를 해결한 방법은 동글, 리모트 인증 서버 등 외부 블랙박스를 사용하여 암호화/복호화를 처리하는 것입니다.그러나 사용자가 자신의 시스템에 완전히 액세스할 수 있기 때문에 온라인 게임 서버 등 "블랙박스"에 저장된 기능에 제품을 직접 연결할 수 없는 경우를 제외하고는 불가능한 일이 아니라 어려운 작업만 하게 됩니다.

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

좋지 않은 생각인 것 같습니다.당신이 준 '숨겨진' 키로 다른 사람에게 물건을 암호화하게 하는 겁니다.이건 안전할 수 없을 것 같아.

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

• 암호 해독을 위해 공용 키를 사용하여 암호화된 라이센스 배포
• 고객이 새로운 라이선스를 생성하여 암호화를 위해 보내드립니다.
• 클라이언트에 새 라이선스를 반송합니다.

확실하지는 않지만, 고객님께서 주신 공개 키로 라이센스 키를 실제로 암호화할 수 있을 것 같습니다.그런 다음 개인 키로 암호를 해독하고 다시 암호화할 수도 있습니다.

고객별로 공개 키/개인 키 쌍을 별도로 보관하여 적절한 고객으로부터 실제로 정보를 얻을 수 있도록 할 수 있습니다.이제 키를 책임지게 되었습니다.

당신이 무엇을 하든, 그것은 '해체'될 수 있다.분해만 하면 돼또는 메모리 덤프를 보고 상수를 찾습니다.컴퓨터가 그걸 알아야 하니까 코드도 알아야 해

어떻게 해야 하죠?

키를 코드로 하드코드된 상수로 발송하지 마십시오.사용자별 설정으로 유지합니다.사용자에게 키를 관리할 책임을 부여합니다.

@jatanp: 또는 더 좋은 것은 디컴파일, 라이선스 코드 삭제 및 재컴파일입니다.자바에서는 이 문제에 대한 적절한 해킹 방지 솔루션이 없다고 생각합니다.자바에서는 사악한 작은 동글조차도 이것을 막을 수 없었다.

내 비즈니스 매니저들은 이것에 대해 걱정하고 있고, 나는 너무 많은 생각을 하고 있다.한편, 델은 라이센스 조건을 준수하는 대기업에 애플리케이션을 판매하고 있습니다.일반적으로 빈 카운터와 변호사 덕분에 안전한 환경입니다.라이선스가 올바르게 기술되어 있으면 디컴파일 자체가 불법이 될 수 있습니다.

따라서 애플리케이션을 위해 필요한 것과 같이 강력한 보호가 정말 필요합니까?고객 기반은 어떻게 생겼습니까? (기업?)아니면 10대 게이머들이 몰려들거나, 이것이 더 큰 문제가 될 수 있는 곳이 있을까요?

바이트 코드 암호화를 안심하고 사용할 수 있습니다.

사실 위의 문서 "Cracking Java byte-code encryption"에는 논리 오류가 포함되어 있습니다.이 문서의 주요 주장은 실행 전에 모든 클래스를 복호화하여 메서드에 전달해야 한다는 것입니다.하지만 이것은 사실이 아니다.

여기서 놓치는 전제조건은 정규 또는 표준 Java 런타임 환경에서 실행된다는 것입니다.보호된 Java 앱이 이러한 클래스를 시작할 뿐만 아니라 복호화 및 전달까지 의무화할 수 있는 것은 없습니다.ClassLoader, ,, 준, j JRE는 가로채기존 JRE는 가로채지 defineClass(...)에는 이는 패치가 적용된 Java API에서 된 JRE를 입니다.ClassLoader또는 보호된 Java 앱이 전혀 작동하지 않기 때문에 가로채는 것이 없기 때문에 할 수 없는 다른 "스킬"도 있습니다.그리고 어떤 "패치 파인더"가 사용되는지, 해커들이 사용하는 속임수는 전혀 문제가 되지 않습니다.이러한 기술적인 세부 사항은 전혀 다른 이야기입니다.

라이센스 솔루션을 찾고 있다면 TrueLicense API를 확인해 보십시오.비대칭 키 사용에 기반을 두고 있습니다.하지만, 당신의 애플리케이션이 깨질 수 없는 것은 아닙니다.모든 애플리케이션을 충분한 노력으로 크래킹할 수 있습니다.Stu가 대답했듯이, 정말 중요한 것은 얼마나 강력한 보호가 필요한지 알아내는 것입니다.

오프라인에서 효과적인 바이러스 대책 방법은 없는 것 같아요.비디오 게임 업계는 그것을 찾기 위해 여러 번 노력했고 그들의 프로그램들은 항상 손상되어 왔다.유일한 해결책은 프로그램을 서버에 접속하여 온라인으로 실행해야 하고, 이를 통해 링크 키를 확인할 수 있으며, 라이선시에 의한 액티브한 접속은 한 번에 1개뿐입니다.이것이 월드 오브 워크래프트나 디아블로의 작동 방식이다.보안을 우회할 수 있도록 개발된 프라이빗 서버도 있습니다.

그렇다고는 해도, 중소규모 기업이나 대기업이 불법 복제 소프트웨어를 사용하고 있다고는 생각하지 않습니다.왜냐하면, 라이센스 비용은 트라이얼 버전에 비해 최소한(아마도, 프로그램에 얼마의 요금이 부과되고 있는지는 알 수 없습니다.

Q: .class 파일을 암호화하고 커스텀클래스로더를 사용하여 로드 및 복호화 작업을 하면 디컴파일이 방지됩니까?

A: Java 바이트 코드 디컴파일을 방지하는 문제는 언어 자체만큼이나 오래되었습니다.다양한 난독화 툴이 시판되고 있음에도 불구하고, 초보 자바 프로그래머들은 그들의 지적 재산을 보호하기 위한 새롭고 영리한 방법을 계속해서 생각하고 있다.이번 자바 Q&A에서는 토론 포럼에서 자주 재탕되는 아이디어에 대한 몇 가지 신화를 불식시켰다.

Java .class 파일을 원본과 매우 유사한 Java 소스로 재구성할 수 있는 매우 쉬운 방법은 Java 바이트 코드 설계 목표 및 트레이드오프와 많은 관련이 있습니다.무엇보다도 Java 바이트 코드는 바이트 코드 인터프리터와 JIT(Just-In-Time)/HotSpot 다이내믹 컴파일러에 의한 콤팩트성, 플랫폼 독립성, 네트워크 이동성 및 분석 용이성을 위해 설계되었습니다.컴파일된 .class 파일은 원래 소스 코드보다 쉽게 분석할 수 있도록 프로그래머의 의도를 명확하게 표현하고 있습니다.

완전히 분해되는 것을 막지는 않더라도 최소한 더 어렵게 만들기 위해 몇 가지 작업을 수행할 수 있습니다.예를 들어 컴파일 후의 스텝으로 .class 데이터를 마사지하여 바이트코드를 디컴파일 할 때 읽기 어렵게 하거나 유효한 Java 코드로 디컴파일 할 수 있습니다(또는 둘 다).극단적인 메서드 이름 오버로드를 실행하는 방법이나 제어 흐름을 조작하여 Java 구문을 통해 나타낼 수 없는 제어 구조를 만드는 방법 등은 후자에 적합합니다.보다 성공적인 상용 난독화기는 이러한 기술과 다른 기술을 혼합하여 사용합니다.

유감스럽게도 두 가지 접근 방식 모두 JVM이 실행할 코드를 실제로 변경해야 하며, 많은 사용자가 이러한 변환으로 인해 애플리케이션에 새로운 버그가 추가되지 않을까 우려하고 있습니다.또한 메서드 및 필드 이름을 변경하면 리플렉션 호출이 중지될 수 있습니다.실제 클래스 및 패키지 이름을 변경하면 다른 여러 Java API(JNDI(Java Naming and Directory Interface), URL 공급자 등)가 손상될 수 있습니다.이름 변경에 가세해 클래스 바이트 코드 오프셋과 송신원 회선 번호의 관련성이 변경되었을 경우, 원래의 예외 스택트레이스의 회복이 어려워질 가능성이 있습니다.

다음으로 원래 Java 소스 코드를 난독화하는 옵션이 있습니다.그러나 기본적으로 이것은 유사한 문제를 일으킵니다.암호화, 난독화가 아니라?

아마도 위와 같이 생각하실 것입니다. "바이트 코드를 조작하는 대신 컴파일 후 모든 클래스를 암호화하고 JVM 내에서 즉시 복호화(커스텀 클래스 로더로 실행 가능)하면 어떨까요?그러면 JVM은 원래 바이트 코드를 실행하지만 디컴파일이나 리버스 엔지니어링은 할 수 없습니다.

불행하게도, 당신이 이 아이디어를 처음 생각해 낸 사람이라고 생각하는 것과 그것이 실제로 효과가 있다고 생각하는 것 모두 틀릴 것이다.그 이유는 암호화 스킴의 강도와는 관계가 없습니다.

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