Java 코드 보호 방법

기술적 관점에서 Java 코드를 일반적인 보호 조치 및 도구로부터 효과적으로 보호하는 방법을 살펴보겠습니다. 1. Java 를 exe 로 패키지화하는 특징: jar 를 실행 파일로 포장하는 것은 유용하지만 Java 프로그램에는 보호가 되지 않습니다. Exe 를 생성하면 일반 실행 파일과 같은 효과가 있을 것이라고 생각하지 마십시오. Exe 로 패키지화된 이러한 프로그램이 실행되면 jar 파일이 쉽게 구할 수 있는 임시 디렉토리에 해제됩니다. 일반적으로 사용되는 도구는 exe4j, jsmooth, NativeJ 등입니다. Jsmooth 에서 생성된 Exe 런타임 임시 디렉토리는 exe 가 있는 디렉토리 또는 사용자 임시 디렉토리에 있습니다. Exe4j 가 생성한 exe 런타임 임시 디렉토리는 사용자 임시 디렉토리에 있습니다. NativeJ 생성 exe 는 winrar 에서 직접 연 다음 zip 형식의 jar 파일로 복원하여 원본 파일을 얻습니다. 사용 및 배포의 편의를 위해서만 Java 코드를 보호할 필요가 없다면 이러한 도구를 사용하는 것이 좋습니다. 2.java obfuscator 의 특징: 하나 이상의 처리 방법을 통해 클래스 파일과 Java 소스 코드를 혼동하고, 혼동된 코드를 디컴파일하기 어렵고, 디컴파일 후 코드를 읽고 이해하기 어려운 새 클래스를 생성합니다. 이런 혼란기에는 많은 도구가 있고, 또한 매우 효과적이다. 단점: 혼란스러운 코드를 디컴파일 한 후에는 읽기가 쉽지 않지만 코드에 숨겨진 민감한 내용은 경험 많은 사람이 발견하거나 계산하는 데 더 많은 시간을 할애 할 수 있습니다. 그리고 많은 응용 프로그램에서 모든 코드를 혼동할 수 있는 것은 아니며, 종종 주요 라이브러리, 클래스 이름, 메소드 이름, 변수 이름 등이 있습니다. 사용 요구 사항의 제한으로 혼동해서는 안 된다. 3. Java 프로그램을 서버에서 격리시키는 특징: Java 프로그램을 서버에 배치하면 사용자가 클래스 파일 및 관련 지원 파일에 액세스할 수 없고 클라이언트는 인터페이스를 통해서만 액세스할 수 있습니다. 이 방법을 사용하면 클라이언트/서비스 모드 응용 프로그램에서 Java 코드를 보다 잘 보호할 수 있습니다. 단점은 고객/서비스 모델이어야 하며, 이 모델의 적용 범위를 제한해야 한다는 것입니다. 논리적 노출은 항상 약한 부분이기 때문에 클라이언트는 일반적으로 인터페이스에 액세스할 때 보안 인증이 필요합니다. 4.Java 암호화 보호의 특징: 사용자 정의 클래스 로더는 클래스 파일 및 관련 파일을 암호화하고 런타임 시 관련 파일을 해독하고 클래스를 로드합니다. 보호를 위해 사용자 정의 로컬 코드 실행자는 사용자 정의 클래스 로더, 암호화 및 암호 해독된 관련 클래스 및 지원 파일도 보호해야 합니다. 이 방법은 Java 코드를 효과적으로 보호합니다. 단점: JRE 패키지에서 클래스 로드와 관련된 Java 클래스 또는 가상 시스템 동적 라이브러리를 대체하여 Java 바이트 코드를 차단할 수 있습니다. Jar2exe 는 이러한 도구에 속합니다. 5.AOT 특징: Java 코드 정적 컴파일 비용 시스템 코드, 일반 JRE 와 분리. 이 방법은 Java 코드를 매우 효과적으로 보호할 수 있으며, 프로그램 시작은 일반 JVM 보다 조금 빠릅니다. 대표적인 것은 GNU 의 gcj 로, Java 코드를 미리 완전히 컴파일할 수 있지만 gcj 에는 JRE 5 를 완전히 지원하지 않고 JRE 6 이후 버전을 지원하지 않는 등 많은 제한이 있습니다. Java 플랫폼의 복잡성으로 인해 최신 Java 버전과 JRE 를 완전히 사전 컴파일하는 것은 매우 어렵습니다. 따라서 이러한 도구는 종종 유연한 방식으로 실시간 컴파일해야 하는 곳에서 사전 컴파일과 실시간 컴파일의 혼합체가 됩니다. 단점: 일반 JRE 와의 차이점 및 Java 어플리케이션의 복잡성으로 인해 Java 프로그램의 모든 jar 를 완벽하게 보호할 수 있는 것은 아닙니다. 이 도구에서 제공하는 하나의 운영 환경만 사용할 수 있습니다. 툴 업데이트가 지연되거나 특정 버전의 JRE 가 필요한 경우 지원되지 않을 수 있습니다. 이동 제트기는 이런 도구에 속한다. 6. JNI 보호 기능 사용: JNI 를 통해 민감한 방법 및 데이터를 처리합니다. 이 방법은 "Java 프로그램을 서버로 격리" 하는 것과 약간 유사하며 보호해야 할 코드와 데이터를 동적 라이브러리로 "격리" 하는 것으로 볼 수 있지만, 차이점은 독립 실행형 프로그램에서 사용할 수 있다는 것입니다. 단점은 위에서 언급 한 "Java 프로그램을 서버로 격리" 하는 것과 유사합니다. 7. JRE 를 떠나지 않는 포괄적인 보호 기능: 미리 컴파일하지 않고, JRE 를 떠나지 않고, 다양한 소프트 보호 방식을 사용하여 Java 프로그램이 도난되는 것을 여러모로 방지합니다. 이렇게 하면 사용자 지정 실행기와 로더, 암호화, JNI, 보안 감지, 실행 파일 생성 등 다양한 보호 조치가 채택되기 때문입니다. , 보호 기능이 크게 향상되었으며 Java 코드도 매우 효과적으로 보호됩니다. 단점: jar 파일의 존재 방식 변화와 Java 어플리케이션의 복잡성으로 인해 Java 프로그램의 모든 jar 파일을 완전히 보호할 수 있는 것은 아닙니다. 일부 JRE 버전은 지원되지 않을 수 있습니다. JXMaker 는 이 도구에 속합니다. 8. 암호화 잠금 기능이 있는 하드웨어 보호 기능: 하드웨어 관련 전용 프로그램을 사용하여 자바 가상 머신 이니시에이터의 셸을 만들고, 가상 머신 및 자바 프로그램의 지원 파일을 암호화하고, 셸을 시작하고, 하드웨어 관련 보호 운영 환경을 구축하고, 암호화 잠금에 내장된 프로그램과 상호 작용하여 보안을 강화할 수 있습니다. 이 방법은 위의 "JRE 를 떠나지 않는 고객 과실/사고 보장" 과 비슷하지만 특수 하드웨어 장치를 사용하여 Java 코드를 잘 보호할 수 있습니다. 단점: 일부 사람들은 암호화 자물쇠가 사용자가 사용하기 불편하며 설치마다 하나씩 설치해야 한다고 생각합니다. 위의 설명에서 우리는: 1 을 볼 수 있습니다. 각종 보호 방식은 각각 장단점이 있으므로 실제 상황에 따라 선택해야 한다. 2. 자바 코드를 더 잘 보호하기 위해서, 우리는 종합적인 보호 조치를 사용해야 합니다. 3. 독립 실행형 환경에서 Java 코드를 진정으로 효과적으로 보호하려면 로컬 코드 프로그램이 필요합니다. 물론 보안은 상대적입니다. 한편으로는 당신의 보호 조치와 도구가 달성할 수 있는 정도에 따라, 반면에 해커의 의지와 능력에 따라 기술적으로만 지적 재산권을 보호할 수는 없습니다. 결론적으로, 우리는 가능한 모든 방법으로 Java 코드를 보호할 수 있으며, 그 규칙들에 얽매이지 말아야 한다.