SDK가 강화되지 않은 경우 보안 위험은 무엇입니까?

SDK가 강화되지 않으면 어떤 보안 위험이 있나요?

1 경쟁 제품이나 악의적인 당사자가 내부 구현 세부 사항이나 내부 호출 프로세스를 쉽게 엿볼 수 있으며 심지어 개인 데이터가 유출될 수도 있습니다.

Android 플랫폼 SDK의 대부분은 Java 언어로 작성되어 쉽습니다. 디컴파일됩니다. 단순한 난독화는 내부 구현 세부정보를 노출할 수 있지만 SDK 내의 개인 데이터는 유출될 가능성이 더 높습니다. 이러한 세부사항이 핵심기술의 구현 방식을 드러낸다면 이는 핵심기술의 유출과 다름없다.

2. 악의적인 행위자가 바이트코드 삽입 등을 통해 악성코드를 이식한 후 다시 패키징하여 출시합니다.

SDK의 특성상 앱과 같은 서명 검증 로직이 없으므로 일단 악의적인 행위자 귀하의 SDK에 일부 악성코드나 악성 광고가 심어져 재게시될 경우, 이를 탐지하기 어렵고 개발자의 브랜드 이미지와 평판에 심각한 영향을 미치게 됩니다.

3.크랙된 사람은 핵심 로직을 우회하여 경제적 손실을 초래합니다

SDK에 결제 기능이 있고 악의적인 행위자가 분석하여 결제 로직을 찾아내는데, 결제 관련 로직이 잘 검증되지 않는 경우가 발생합니다. 서버 측에서는 악의적인 행위자가 AOP를 사용하여 이러한 결제 로직을 제거하면 유료 서비스를 무료로 사용할 수 있습니다.

4. SDK 자체에는 취약점이 있을 수 있으며 악의적인 당사자가 쉽게 악용할 수 있습니다.

SDK 개발자는 개발 중에 기능 구현에 중점을 두는 경우가 많으며 일반적으로 보안에 너무 많은 관심을 기울이지 않습니다. 자체 개발한 SDK에는 취약점이 없다고 보장하기 어렵습니다. 따라서 SDK에 일부 보안 취약점이 존재하고, 이러한 취약점이 악의적인 행위자에 의해 알려지고 악용되면 언제든지 폭발할 수 있는 지뢰를 설치하는 것과 같습니다. SDK 개발자의 평판은 데이터 및 개인 정보 보안에 대한 위협으로 인해 영향을 받을 뿐만 아니라 문제가 발생할 경우 금전적 보상 책임을 져야 할 수도 있습니다.

해결 방법

위의 보안 위험 분석을 통해 문제의 핵심은 악의적인 사용자가 SDK의 구현 로직을 쉽게 얻을 수 있다는 점을 알 수 있습니다. 따라서 개발자는 다음과 같은 보호 조치를 취하는 것이 좋습니다.

1. 주요 데이터 수정은 서버 측 검증을 통과해야 합니다. 예를 들어 위에서 언급한 결제 관련 로직에서 잔액 또는 결제 금액과 관련된 데이터 수정이 먼저 이루어져야 합니다. 서버 측 검증을 통과한 후 결과를 클라이언트에 동기화합니다.

2. 기본 레이어에서 핵심 로직을 구현합니다. Java 레이어의 일부 핵심 로직을 JNI 레이어로 전송하고 이를 C/C++로 구현합니다.

3. 문자열 처리 암호화: 코드의 문자열, 특히 민감한 정보가 포함된 문자열은 런타임에 암호화되고 해독되어야 합니다.

그러나 위의 사항을 달성하는 것만으로는 충분하지 않으며 일반 개발자를 막을 수 있을 뿐입니다. 우리가 열심히 개발한 SDK가 전문 크래커의 손에 들어가는 대포 사료가 되어 재정적 손실을 초래할 수도 있습니다.

따라서 Yidun의 SDK 강화 서비스 등 타사 보안 서비스에 연결하는 것이 좋습니다.

Yidun SDK 강화 소개

Yidun SDK 강화를 소개하기에 앞서 현재 대부분의 개발자들이 사용하고 있는 난독화 방식인 Proguard를 먼저 소개하겠습니다. Proguard는 Android 플랫폼에서 가장 널리 사용되는 난독화 기술로, 추상 구문 트리를 통해 구문 수준에서 처리되므로 처리된 코드를 읽고 이해하기 어렵습니다. 아래와 같이:

그러나 클래스 이름과 메서드 이름을 "a, b, c"와 같은 의미 없는 임의의 문자열로 변경하면 크래커를 읽고 이해하는 데 드는 비용이 증가할 수 있지만 분명히 효과는 극히 제한적입니다. 크래커의 경우 코드의 의도를 파악하는 것은 시간 문제일 뿐입니다.

그렇다면 이둔의 SDK 강화 솔루션은 무엇일까요? 다음으로 소개해드릴 내용은

1. Yidun SDK 강화 VMP 솔루션

보호할 클래스의 메소드를 추출하고 추출된 명령어를 암호화한 후 런타임 시 커스텀 가상머신을 통해 실행하여 크랙을 가능하게 하는 것입니다. 독자는 원래 코드 논리를 얻을 수 없습니다.

효과는 다음과 같습니다.

2. Yidun SDK 강화 Java2c 솔루션

이 솔루션은 보호하려는 클래스의 메소드를 Nativeize하는 동시에 원래의 함수 구현 로직을 변환하는 것입니다. Native 레이어에 해당하는 C/C++로 코드 실행 시 해당 Native 함수를 직접 실행합니다. 그 효과는 다음과 같습니다.

강화 전 예시

강화 후 예시

정적 분석의 관점에서 Proguard 난독화와 비교하면 강화 후의 방식이 명백합니다. 네이티브화되었으며 로직이 구현되었습니다. Java 레이어에서는 완전히 보이지 않습니다. Java 계층의 원래 기능 로직을 JNI 계층의 C/C++ 코드 구현으로 변환하는 동시에 생성된 Native 계층 SO를 암호화하여 모든 측면에서 크래킹 난이도를 개선합니다.

(참고: 위 그림에서 더 명확하게 볼 수 있도록 강화된 방법은 해당 네이티브 레이어 구현으로 변환되었으며 생성된 네이티브 레이어 SO는 암호화되지 않습니다. 실제로 Yidun SDK 강화 Java2c 솔루션은 암호화를 위해 강화 후 네이티브 레이어 생성)

위 내용은 SDK가 강화되지 않은 경우 보안 위험은 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!