APK 파일의 리버스 엔지니어링을 피하는 방법은 무엇입니까?

Android 용 결제 처리 앱 을 개발 중이며 해커가 APK 파일 에서 모든 리소스, 자산 또는 소스 코드에 액세스하지 못하게하고 싶습니다 .

누군가 .apk 확장자를 .zip으로 변경하면 압축을 풀고 모든 앱의 리소스 및 자산에 쉽게 액세스 할 수 있으며 dex2jar 및 Java 디 컴파일러를 사용하여 소스 코드에도 액세스 할 수 있습니다. Android APK 파일을 리버스 엔지니어링하는 것은 매우 쉽습니다. 자세한 내용은 스택 오버플로 질문 APK 파일에서 프로젝트로 리버스 엔지니어링을 참조하십시오 .

Android SDK와 함께 제공된 Proguard 도구를 사용했습니다. 서명 된 키 저장소와 Proguard를 사용하여 생성 된 APK 파일을 리버스 엔지니어링하면 난독 화 된 코드가 생성됩니다.

그러나 Android 구성 요소의 이름은 변경되지 않고 앱에서 사용되는 키-값과 같은 일부 코드는 변경되지 않습니다. Proguard 설명서에 따르면이 도구는 매니페스트 파일에 언급 된 구성 요소를 난독 처리 할 수 ​​없습니다.

이제 내 질문은 :

1. Android APK의 리버스 엔지니어링을 완전히 방지하려면 어떻게 해야합니까? 이것이 가능한가?
2. 해커가 어떤 식 으로든 APK 파일을 해킹 할 수 없도록 모든 앱의 리소스, 자산 및 소스 코드를 어떻게 보호 할 수 있습니까?
3. 해킹을 더 힘들거나 불가능하게 만드는 방법이 있습니까? APK 파일에서 소스 코드를 보호하기 위해 어떻게해야합니까?

 1. Android APK의 리버스 엔지니어링을 완전히 피하려면 어떻게해야합니까? 이것이 가능한가?

AFAIK, 리버스 엔지니어링을 완전히 피하기위한 트릭은 없습니다.

또한 @inazaruk는 다음과 같이 잘 말합니다. 코드에 상관없이 잠재적 인 공격자는 자신이 실행 가능한 방식으로 코드를 변경할 수 있습니다. 기본적으로 응용 프로그램이 수정되는 것을 보호 할 수 없습니다. 그리고 거기에 넣은 모든 보호 기능을 비활성화 / 제거 할 수 있습니다.

 2. 해커가 어떤 식 으로든 APK 파일을 해킹 할 수 없도록 모든 앱의 리소스, 자산 및 소스 코드를 어떻게 보호 할 수 있습니까?

해킹을 어렵게 만들기 위해 다른 트릭을 수행 할 수 있습니다. 예를 들어, 난독 화를 사용하십시오 (Java 코드 인 경우). 일반적으로 리버스 엔지니어링 속도가 크게 느려집니다.

 3. 해킹을 더욱 어렵거나 불가능하게 만드는 방법이 있습니까? APK 파일에서 소스 코드를 보호하기 위해 어떻게해야합니까?

모두가 말했듯이 아시다시피 100 % 보안은 없습니다. 그러나 구글이 내장 한 안드로이드의 시작은 프로 가드 (ProGuard)이다. 공유 라이브러리 를 포함 할 수있는 옵션이 있으면 C ++에 필요한 코드를 포함시켜 파일 크기, 통합 등을 확인할 수 있습니다. 모든 빌드에서 APK의 라이브러리 폴더에 외부 기본 라이브러리를 추가해야하는 경우이를 사용할 수 있습니다. 아래 제안에 의해.

라이브러리를 기본 라이브러리 경로에 놓으십시오. 기본은 프로젝트 폴더에서 "libs"입니다. 'armeabi' 대상 의 원시 코드를 빌드 한 경우 libs / armeabi 아래에 넣으십시오 . 가 내장되어있는 경우 armeabi-V7A 다음 아래에 넣어 libs와 / armeabi-V7A.

<project>/libs/armeabi/libstuff.so

AFAIK, 현재 / res 디렉토리의 파일을 더 이상 보호 할 수 없습니다.

그러나 소스 코드를 보호하기 위해 취할 수있는 단계 또는 최소한 모든 것이 아닌 경우 수행하는 단계가 있습니다.

1. ProGuard와 같은 도구를 사용하십시오. 이것들은 코드를 난독 화시키고, 디 컴파일 할 때 읽을 수 없도록 어렵게 만듭니다.
2. 서비스의 가장 중요한 부분을 앱과 PHP와 같은 서버 측 언어 뒤에 숨겨진 웹 서비스로 옮기십시오. 예를 들어, 알고리즘을 작성하는 데 백만 달러가 걸린다면. 분명히 사람들이 앱에서 앱을 도용하는 것을 원하지 않습니다. 알고리즘을 이동하여 원격 서버에서 데이터를 처리하도록하고 앱을 사용하여 간단히 데이터를 제공하십시오. 또는 NDK를 사용하여 파일을 .so 파일에 기본적으로 쓰면 apk보다 디 컴파일 가능성이 훨씬 낮습니다. .so 파일의 디 컴파일러가 지금도 존재한다고 생각하지 않습니다 (그렇더라도 Java 디 컴파일러만큼 좋지는 않습니다). 또한 주석에서 언급 한 @nikolay와 같이 서버와 장치간에 상호 작용할 때는 SSL을 사용해야합니다.
3. 장치에 값을 저장하는 경우 원시 형식으로 저장하지 마십시오. 예를 들어 게임이 있고 사용자가 SharedPreferences에 보유한 금액을 게임 통화로 저장하는 경우. 10000동전 이라고 가정 해 봅시다 . 대신 절약 10000과 같은 알고리즘을 사용하여 저장, 직접 ((currency*2)+1)/13. 따라서 대신에 SharedPreferences에 10000저장 1538.53846154합니다. 그러나 위의 예제는 완벽하지 않으며 반올림 오류 등으로 인해 통화를 잃지 않는 방정식을 만들어야합니다.
4. 서버 측 작업에 대해 유사한 작업을 수행 할 수 있습니다. 이제 예를 들어 실제로 결제 처리 앱을 살펴 보겠습니다. 사용자가의 결제를해야한다고 가정 해 보겠습니다 $200. 원시 $200값을 서버 로 전송하는 대신 더 작은 사전 정의 된 일련의 값을 보냅니다 $200. 예를 들어, 단어와 값을 동일시하는 파일 또는 테이블을 서버에 두십시오. , 및 에 Charlie해당 한다고 가정 해 봅시다 . 를 보내는 대신 네 번 보낼 수 있습니다.$47John$3$200CharlieJohn네번. 서버에서 의미를 해석하고 추가하십시오. 이는 해커가 어떤 단어가 어떤 값에 해당하는지 모르기 때문에 서버에 임의의 값을 보내지 못하게합니다. 보안을 강화하기 위해 포인트 3과 비슷한 방정식 n을 사용하고 며칠 마다 키워드를 변경할 수 있습니다.
5. 마지막으로 해커가 건초 더미에서 바늘을 찾도록 임의의 쓸모없는 소스 코드를 앱에 삽입 할 수 있습니다. 인터넷에서 스 니펫이 포함 된 임의의 클래스를 삽입하거나 피보나치 시퀀스와 같은 임의의 항목을 계산하는 함수 만 삽입하십시오. 이 클래스는 컴파일되지만 앱의 실제 기능에 사용되지 않아야합니다. 이러한 잘못된 클래스를 충분히 추가하면 해커가 실제 코드를 찾는 데 어려움을 겪을 수 있습니다.

대체로 앱을 100 % 보호 할 수있는 방법이 없습니다. 더 어렵게 만들 수는 있지만 불가능하지는 않습니다. 웹 서버가 손상 될 수 있고, 해커는 여러 트랜잭션 금액과 귀하가 전송하는 키워드를 모니터링하여 키워드를 파악할 수 있으며, 해커는 소스를 통해 고의로 이동하여 어떤 코드가 더미인지 파악할 수 있습니다.

당신은 싸울 수 있지만 결코 이길 수 없습니다.

컴퓨팅 역사상 어느 시점에서도 공격자에게 소프트웨어 사본을 제공 할 때 소프트웨어의 리버스 엔지니어링을 방지 할 수 없었습니다. 또한, 가능성은 거의 없습니다 .

이해 했으므로 확실한 해결책 이 있습니다. 공격자에게 비밀을주지 마십시오. APK의 내용을 보호 할 수 는 없지만 배포 할 수없는 것은 보호 할 수 있는 것 입니다. 일반적으로 이것은 활성화, 지불, 규칙 적용 및 기타 수분이 많은 코드에 사용되는 서버 측 소프트웨어입니다. APK에 소중한 자산을 배포 하지 않으면 소중한 자산을 보호 할 수 있습니다 . 대신 앱의 요청에 응답하고 에셋을 "사용"한 다음 결과를 앱으로 다시 보내는 서버를 설정하십시오. 이 모델이 마음에 든 자산에 적합하지 않은 경우 전략을 다시 생각할 수 있습니다.

또한 앱의 불법 복제를 방지하는 것이 주된 목표라면 귀찮게하지 마십시오. 불법 복제 방지 조치가 당신을 구할 수있는 것보다이 문제에 대해 이미 더 많은 시간과 돈을 소모했습니다. 이 문제를 해결하기위한 투자 수익은 너무 낮아서 생각조차하지 않습니다.

앱 보안의 첫 번째 규칙 : 공격자가 물리적 또는 전자적으로 제한없이 액세스 할 수있는 모든 머신은 이제 실제 위치 또는 비용에 관계없이 공격자에게 속합니다.

앱 보안의 두 번째 규칙 : 침입자가 침투 할 수없는 물리적 경계를 벗어나는 소프트웨어는 이제 코딩에 소요 된 시간에 관계없이 공격자의 소유입니다.

세 번째 규칙 : 공격자가 침투 할 수없는 동일한 물리적 경계를 벗어나는 정보는 사용자에게 아무리 가치가 있어도 공격자에게 속합니다.

정보 기술 보안의 기초는이 세 가지 기본 원칙을 기반으로합니다. 진정으로 안전한 유일한 컴퓨터는 금고, 패러데이 케이지 내부, 스틸 케이지 내부에 잠겨있는 컴퓨터입니다. 대부분의 서비스 수명을이 상태로 보내는 컴퓨터가 있습니다. 일 년에 한 번 (또는 그 이하), 그들은 신뢰할 수있는 루트 인증 기관을위한 개인 키를 생성합니다.

이제 대부분의 컴퓨터는 이러한 유형의 환경에서 사용되지 않습니다. 그들은 물리적으로 개방되어 있으며 무선 라디오 채널을 통해 인터넷에 연결되어 있습니다. 요컨대, 소프트웨어와 마찬가지로 취약합니다. 그러므로 그들은 신뢰할 수 없습니다. 컴퓨터와 소프트웨어가 유용하기 위해서는 반드시 알아야하거나해야 할 일이 있지만, 그 컴퓨터가 손상을 일으킬 수있는 정도를 알 수 없거나 충분히 할 수 없도록주의를 기울여야합니다 (적어도 해당 단일 시스템의 경계를 벗어나는 영구적 인 손상은 아님) ).

당신은 이미이 모든 것을 알고있었습니다. 그렇기 때문에 애플리케이션 코드를 보호하려고합니다. 그러나 그 안에 첫 번째 문제가있다. 난독 화 도구를 사용하면 코드를 엉망으로 만들 수 있지만 프로그램을 계속 실행해야합니다. 즉, 앱의 실제 논리 흐름과 앱이 사용하는 데이터는 난독 화의 영향을받지 않습니다. 약간의 끈기가 주어지면 공격자는 단순히 코드를 난독 화 할 수 있으며, 그가보고있는 것이 다른 것이 될 수없는 특정 경우에는 필요하지 않습니다.

대신, 공격자가 코드를 분명하게 확보하는 것이 얼마나 쉬운 지에 상관없이 공격자가 코드로 아무 것도 할 수 없도록해야합니다. 즉, 코드가 개발 한 건물을 떠나는 즉시 그 비밀은 비밀이 아니기 때문에 하드 코딩 된 비밀은 없습니다.

하드 코드 한 이러한 키-값은 응용 프로그램의 소스 코드에서 완전히 제거해야합니다. 대신, 그들은 세 곳 중 하나에 있어야합니다. 공격자가 오프라인 복사본을 얻는 것이 어렵지만 여전히 불가능하지는 않지만 장치의 휘발성 메모리. 아이언 주먹으로 액세스를 제어하는 ​​서버 클러스터에서 영구적으로; 또는 실제 카드 또는 사용자의 메모리와 같은 장치 또는 서버와 관련이없는 두 번째 데이터 저장소에 있습니다 (즉, 휘발성 메모리에 있지만 오래 걸리지 않아도 됨).

다음 구성표를 고려하십시오. 사용자는 메모리에서 장치로 앱의 자격 증명을 입력합니다. 안타깝게도 키로거나 트로이 목마에 의해 사용자의 장치가 손상되지 않았 음을 신뢰해야합니다. 이와 관련하여 할 수있는 최선의 방법은 사용자가 사용한 장치 (MAC / IP, IMEI 등)에 대한 위조하기 어려운 식별 정보를 기억하고 최소한 하나 이상의 추가 채널을 제공함으로써 다단계 보안을 구현하는 것입니다. 익숙하지 않은 장치의 로그인 시도를 확인할 수 있습니다.

자격 증명은 일단 입력되면 클라이언트 소프트웨어 (보안 해시 사용)에 의해 난독 처리되고 일반 텍스트 자격 증명은 삭제됩니다. 그들은 그들의 목적을 달성했습니다. 난독 화 된 자격 증명은 보안 채널을 통해 인증서 인증 서버로 전송되며,이 자격 증명은 다시 해시 하여 로그인의 유효성을 확인하는 데 사용되는 데이터를 생성합니다. 이런 식으로 클라이언트는 데이터베이스 값과 실제로 비교되는 것을 절대 알 수 없으며, 앱 서버는 유효성 검사를 위해 수신 한 내용의 평문 자격 증명을 알 수 없으며, 데이터 서버는 유효성 검사를 위해 저장 한 데이터가 생성되는 방식을 알지 못합니다. 보안 채널이 손상 되더라도 중간에는 횡설수설 만 보입니다.

확인되면 서버는 채널을 통해 토큰을 다시 전송합니다. 토큰은 보안 세션 내에서만 유용하며 임의 노이즈 또는 세션 식별자의 암호화 된 (따라서 확인할 수있는) 사본으로 구성되며 클라이언트 애플리케이션은 요청의 일부로 동일한 채널에서 서버로이 토큰을 보내야합니다. 무언가를하기 위해. 클라이언트 응용 프로그램은 돈, 민감한 데이터 또는 자체적으로 손상 될 수있는 다른 작업을 수행 할 수 없기 때문에이 작업을 여러 번 수행합니다. 대신 서버에이 작업을 수행하도록 요청해야합니다. 클라이언트 응용 프로그램은 최소한 일반 텍스트가 아닌 장치 자체의 영구 메모리에 중요한 정보를 쓰지 않습니다. 클라이언트는 서버가 기억할 로컬 데이터를 암호화하기 위해 보안 채널을 통해 서버에 대칭 키를 요청할 수 있습니다. 이후 세션에서 클라이언트는 휘발성 메모리에서 사용하기 위해 데이터를 해독하기 위해 서버에 동일한 키를 요청할 수 있습니다. 이 데이터 만이 유일한 사본은 아닙니다. 클라이언트가 저장하는 것은 서버에 어떤 형태로도 전송되어야합니다.

분명히 이것은 응용 프로그램이 인터넷 액세스에 크게 의존하게 만듭니다. 클라이언트 장치는 서버에 대한 적절한 연결 및 인증 없이는 기본 기능을 수행 할 수 없습니다. 페이스 북과 다르지 않습니다.

이제 공격자가 원하는 컴퓨터는 서버입니다. 클라이언트 응용 프로그램 / 장치가 아니라 서버가 돈을 벌거나 다른 사람들이 자신의 즐거움을 위해 고통을 줄 수 있기 때문입니다. 괜찮아; 모든 클라이언트를 보호하는 것보다 서버를 보호하는 데 드는 비용과 노력에 훨씬 더 많은 돈을 지불합니다. 서버는 모든 종류의 방화벽 및 기타 전자 보안을 지원할 수 있으며 강철, 콘크리트, 키 카드 / 핀 액세스 및 24 시간 비디오 감시를 통해 물리적으로 보호 할 수 있습니다. 공격자는 실제로 서버에 직접 액세스하려면 매우 정교해야하며 서버에 대해 즉시 알아야합니다.

공격자가 할 수있는 최선의 방법은 사용자의 전화 및 자격 증명을 훔치고 클라이언트의 제한된 권한으로 서버에 로그인하는 것입니다. 신용 카드 분실과 마찬가지로 이러한 경우에는 합법적 인 사용자에게 800 번호로 전화를 걸도록 지시해야합니다. 액세스 할 수있는 모든 휴대 전화에서 고객 서비스에 직접 연결하는 휴대 전화에서 도난당했습니다. 그들은 전화기를 도난 당했다고 말하고, 기본 고유 식별자를 제공하고, 계정이 잠겨 있으며, 공격자가 처리 할 수 ​​있었던 모든 트랜잭션이 롤백되고 공격자는 다시 정사각형으로 돌아갑니다.

 1. Android APK의 리버스 엔지니어링을 완전히 피하려면 어떻게해야합니까? 이것이 가능한가?

불가능하다

 2. 해커가 어떤 식 으로든 APK 파일을 해킹 할 수 없도록 모든 앱의 리소스, 자산 및 소스 코드를 어떻게 보호 할 수 있습니까?

누군가가 .apk 확장자를 .zip으로 변경하면 압축을 풀면 누군가가 쉽게 모든 리소스를 얻을 수 있지만 ( Manifest.xml 제외 ) APKtool 을 사용하면 매니페스트 파일의 실제 내용도 얻을 수 있습니다. 다시 한 번

 3. 해킹을 더욱 어렵거나 불가능하게 만드는 방법이 있습니까? APK 파일에서 소스 코드를 보호하기 위해 어떻게해야합니까?

다시 말하지만, 어느 정도까지는 막을 수 있습니다.

• 웹에서 리소스를 다운로드하고 암호화 프로세스를 수행하십시오.
• 사전 컴파일 된 원시 라이브러리 사용 (C, C ++, JNI, NDK)
• 항상 일부 해싱 ( MD5 / SHA 키 또는 기타 논리)을 수행하십시오.

로도 Smali사람들은 코드를 가지고 놀 수 있습니다. 대체로 가능하지 않습니다.

Android APK의 리버스 엔지니어링을 100 % 피할 수는 없지만 다음 방법을 사용하여 소스 코드, APK의 자산 및 리소스와 같은 더 많은 데이터 추출을 피할 수 있습니다.

1. ProGuard를 사용하여 응용 프로그램 코드를 난독 처리

2. 사용 NDK 사용하여 C 및 C ++를 응용 프로그램 코어와 코드의 보안 부분을 넣어 .so파일을

3. 리소스를 보호하려면 APK를 사용하여 자산 폴더에 중요한 리소스를 모두 포함시키지 마십시오. 응용 프로그램을 처음 시작할 때 이러한 리소스를 다운로드하십시오.

개발자는 APK가 도난 당하지 않도록 다음 단계를 수행 할 수 있습니다.

• 가장 기본적인 방법은 ProGuard코드를 난독 화하는 것과 같은 도구를 사용하는 것이지만 지금까지 누군가가 앱을 디 컴파일하는 것을 완전히 막는 것은 매우 어려웠습니다.

• 또한 HoseDex2Jar 도구에 대해 들었습니다 . Dex2Jar안드로이드 APK에 무해한 코드를 삽입하여 코드를 혼동하고 비활성화 Dex2Jar하고 코드 디 컴파일로부터 보호 함으로써 중단 됩니다 . 해커가 APK를 읽을 수있는 Java 코드로 디 컴파일하는 것을 막을 수 있습니다.

• 필요한 경우에만 일부 서버 측 응용 프로그램을 사용하여 응용 프로그램과 통신하십시오. 중요한 데이터를 방지하는 데 도움이 될 수 있습니다.

잠재적 인 해커로부터 코드를 완전히 보호 할 수는 없습니다. 어떻게 든 코드를 디 컴파일하는 것이 어려워지고 약간의 좌절감을 줄 수 있습니다. 가장 효율적인 방법 중 하나는 네이티브 코드 (C / C ++)로 작성하여 컴파일 된 라이브러리로 저장하는 것입니다.

시도 할 수있는 몇 가지 방법은 다음과 같습니다.

1. 난독 화 및 ProGuard 와 같은 도구를 사용하십시오 .
2. 소스 및 데이터의 일부를 암호화합니다.
3. 앱에서 독점적 인 내장 체크섬을 사용하여 변조를 감지하십시오.
4. 디버거에로드되지 않도록 코드를 도입하십시오. 즉, 앱이 디버거를 감지하고 디버거를 종료 / 종료하는 기능을 갖도록하십시오.
5. 인증을 온라인 서비스로 분리하십시오.
6. 응용 프로그램 다양성 사용
7. 장치를 인증하기 전에 다른 서브 시스템에서 장치의 하드웨어 서명과 같은 지문 인쇄 기술을 사용하십시오.

 1. Android APK의 리버스 엔지니어링을 완전히 피하려면 어떻게해야합니까? 이것이 가능한가?

불가능한

 2. 해커가 어떤 식 으로든 APK 파일을 해킹 할 수 없도록 모든 앱의 리소스, 자산 및 소스 코드를 어떻게 보호 할 수 있습니까?

불가능한

 3. 해킹을 더욱 어렵거나 불가능하게 만드는 방법이 있습니까? APK 파일에서 소스 코드를 보호하기 위해 어떻게해야합니까?

더 힘든-가능하지만 실제로 해킹 가이드를 찾기 위해 인터넷을 사용하는 일반 사용자에게는 더 힘들 것입니다. 누군가가 실제로 앱을 해킹하려는 경우 조만간 해킹됩니다.

 1. Android APK의 리버스 엔지니어링을 완전히 피하려면 어떻게해야합니까? 이것이 가능한가?

그건 불가능 해

 2. 해커가 어떤 식 으로든 APK 파일을 해킹 할 수 없도록 모든 앱의 리소스, 자산 및 소스 코드를 어떻게 보호 할 수 있습니까?

개발자는 ProGuard와 같은 도구를 사용하여 코드를 난독 처리하는 등의 단계를 수행 할 수 있지만 지금까지는 누군가가 앱을 디 컴파일하는 것을 완전히 막는 것이 매우 어려웠습니다.

그것은 정말 훌륭한 도구이며 코드의 공간을 줄이면서 코드를 '역전'하는 어려움을 증가시킬 수 있습니다.

통합 ProGuard 지원 : ProGuard는 이제 SDK 도구와 함께 제공됩니다. 개발자는 이제 릴리스 빌드의 통합 부분으로 코드를 난독 처리 할 수 ​​있습니다.

 3. 해킹을 더욱 어렵거나 불가능하게 만드는 방법이 있습니까? APK 파일에서 소스 코드를 보호하기 위해 어떻게해야합니까?

연구하는 동안 HoseDex2Jar 에 대해 알게되었습니다 . 이 도구는 코드 디 컴파일을 방지하지만 코드를 완전히 보호하는 것은 불가능합니다.

유용한 링크 중 일부는 참조 할 수 있습니다.

• Proguard, Android 및 라이센스 서버
• Android LVL 애플리케이션 보안
• 스택 오버플로 질문 안드로이드 앱을 리버스 엔지니어링으로부터 보호하는 것이 실제로 불가능합니까?
• 스택 오버플로 질문 코드를 보호하기 위해 Android APK 파일의 리버스 엔지니어링을 방지하는 방법은 무엇입니까?

여기서 가장 중요한 질문은 dex 파일을 디 컴파일 할 수 있고 "정렬"할 수 있다는 것입니다. dedexer 및 smali 와 같은 디스어셈블러가 있습니다 .

올바르게 구성된 ProGuard는 코드를 혼란스럽게합니다. 상용 확장 버전의 ProGuard 인 DexGuard는 조금 더 도움이 될 수 있습니다. 그러나 코드를 여전히 smali로 변환 할 수 있으며 리버스 엔지니어링 경험이있는 개발자는 smali에서 수행중인 작업을 파악할 수 있습니다.

좋은 라이센스를 선택하고 법률에 따라 가능한 한 최선의 방법으로 시행하십시오.

고객은 자신이하는 일을 알고 올바른 결정을 내리고 멘토링 할 수있는 사람을 고용해야합니다.

백엔드에서 트랜잭션 처리 시스템을 변경할 수있는 능력이 있다는 것에 대해 위에서 이야기하십시오. 이러한 아키텍처 변경을 허용해서는 안되므로 그렇게 할 수 없습니다.

이것에 대한 나의 근거 :

귀하의 도메인은 결제 처리이므로 PCI DSS 및 / 또는 PA DSS (및 잠재적 주 / 연방 법률)가 귀하의 비즈니스에 중요하다고 가정하는 것이 안전합니다. 준수하려면 귀하가 안전하다는 것을 보여 주어야합니다. 안전하지 않다면 (테스트를 통해) 보안이 적절한 수준 = 비싸고 느리고 위험이 높은 성공 방법으로 검증 될 수있을 때까지 안전하지 않은 것을 확인한 다음, 수정, 재시험 등을 확인하십시오. 옳은 일을하기 위해, 열심히 생각하고, 숙련 된 인재를 직업에 투입하고, 안전한 방식으로 개발 한 다음, 보안이 적절한 수준에서 검증 될 수있을 때까지 테스트하고, 고치거나 (낮음) 등을 줄입니다. 위험이 적은 성공 방법.

하나의 모바일 결제 응용 프로그램 (MyCheck)을 포함하여 지불 플랫폼에서 광범위하게 일한 사람으로서,이 동작을 서버에 위임해야한다고 지불 프로세서에 대한 사용자 이름이나 암호 (어느 쪽이든)를 저장하거나 코드를 난독 처리 할 때도 소스를 이해할 수 있기 때문에 모바일 애플리케이션에서 하드 코딩 된 것은 원하는 것입니다.

또한 응용 프로그램에 신용 카드 또는 지불 토큰을 저장해서는 안되며 모든 것을 다시 빌드 한 서비스에 위임해야하며 나중에 더 쉽게 PCI를 준수 할 수 있으며 신용 카드 회사가 이길 수 있습니다. 목을 숨 쉬지 마십시오.

여기에 반대 의견이 올랐습니다. 다른 옵션을 제공하고 싶습니다.

중요하다고 생각되는 특정 기능 의 경우 앱에서 WebView 컨트롤을 호스팅 할 수 있습니다. 그런 다음 기능은 웹 서버에서 구현됩니다. 응용 프로그램에서 실행중인 것처럼 보입니다.

리버스 엔지니어링 (거의)을 거의 불가능하게하려면 애플리케이션을 변경 방지 기능이 뛰어난 칩에 배치 할 수 있습니다.이 칩은 민감한 모든 내용을 내부적으로 실행하고 일부 프로토콜과 통신하여 호스트에서 GUI를 제어 할 수 있도록합니다. 변조 방지 칩조차도 100 % 균열 방지가 아닙니다. 그들은 소프트웨어 방법보다 막대를 훨씬 높게 설정했습니다. 물론 이것은 불편하다. 애플리케이션은 칩이 디바이스에 삽입되도록하는 약간의 USB 사마귀가 필요하다.

문제는이 응용 프로그램을 그렇게 열심히 보호하려는 동기를 밝히지 않습니다.

응용 프로그램의 보안 결함 (알거나 다른)을 숨겨서 지불 방법의 보안을 향상시키는 것이 목표라면 완전히 잘못된 것입니다. 보안에 민감한 비트는 가능하면 공개 소스 여야합니다. 응용 프로그램을 검토하는 보안 연구원이 해당 비트를 찾아 작동을 면밀히 조사하고 연락 할 수 있도록 가능한 한 쉽게 만들어야합니다. 결제 애플리케이션에는 포함 된 인증서가 없어야합니다. 즉, 공장에서 고정 된 인증서를 가지고 있기 때문에 장치를 신뢰하는 서버 응용 프로그램이 없어야합니다. 응용 프로그램, 플랫폼 또는 네트워크 등을 신뢰할 수 없도록 올바르게 설계된 종단 간 인증 프로토콜을 사용하여 사용자의 자격 증명만으로 결제 거래를 수행해야합니다.

변조 방지 칩이 부족한 복제를 막는 것이 목적이라면 프로그램이 리버스 엔지니어링 및 복사되는 것을 막기 위해 할 수있는 일이 없기 때문에 누군가가 자신의 응용 프로그램에 호환 가능한 지불 방법을 통합하여 "무단 클라이언트"로 상승합니다. 무단 클라이언트를 개발하는 것을 어렵게하는 방법이 있습니다. 하나는 프로그램의 전체 상태 (모든 상태 변수)의 스냅 샷을 기반으로 체크섬을 만드는 것입니다. GUI, 로직 등 복제 프로그램의 내부 상태는 정확히 동일하지 않습니다. 물론, 이것은 외부에서 볼 수있는 상태 전이 (입력 및 출력으로 관찰 할 수 있음)는 비슷하지만 거의 동일한 내부 상태를 갖는 상태 머신입니다. 서버 응용 프로그램은 프로그램을 조사 할 수 있습니다. 자세한 상태는 무엇입니까? (즉 모든 내부 상태 변수에 대한 체크섬을 제공하십시오). 이는 서버에서 병렬로 실행되고 실제 상태 전환을 거치는 더미 클라이언트 코드와 비교할 수 있습니다. 타사 복제본은 올바른 응답을 제공하기 위해 정품 프로그램의 모든 관련 상태 변경 사항을 복제하여 개발을 방해해야합니다.

@Muhammad Saqib와 동의 함 : https://stackoverflow.com/a/46183706/2496464

그리고 @Mumair는 좋은 시작 단계를 제공합니다 : https : //.com/a/35411378/474330

사용자의 장치에 배포 한 모든 내용이 사용자에게 있다고 가정하는 것이 항상 안전합니다. 평범하고 단순합니다. 최신 도구와 절차를 사용하여 지적 재산을 암호화 할 수 있지만 결정된 사람이 시스템을 '연구'하는 것을 막을 방법은 없습니다. 그리고 현재의 기술로 인해 원치 않는 액세스가 어려워 질 수 있지만 내일 또는 다음 시간에도 쉬운 방법이있을 수 있습니다!

따라서 여기 방정식이 있습니다.

When it comes to money, we always assume that client is untrusted.

게임 내 경제만큼이나 간단합니다. (특히 게임에서! 더 '정교한'사용자가 있으며 허점이 몇 초 만에 퍼집니다!)

우리는 어떻게 안전합니까?

전부는 아니지만 대부분의 주요 처리 시스템 (및 데이터베이스)은 서버쪽에 있습니다. 그리고 클라이언트와 서버 사이에는 암호화 된 통신, 유효성 검사 등이 있습니다. 이것이 씬 클라이언트의 아이디어입니다.

공격으로부터 소프트웨어 응용 프로그램을 보호 하는 것이 좋습니다 . 상업적인 서비스이지만 친구의 회사에서이 서비스를 사용했으며 사용하게되어 기쁩니다.

Android N의 APK 서명 체계 v2

PackageManager 클래스는 이제 APK 서명 체계 v2를 사용한 앱 확인을 지원합니다. APK 서명 체계 v2는 APK 파일의 무단 변경을 감지하여 검증 속도를 크게 향상시키고 무결성 보장을 강화하는 전체 파일 서명 체계입니다.

이전 버전과의 호환성을 유지하려면 v2 서명 체계로 서명하기 전에 APK를 v1 서명 체계 (JAR 서명 체계)로 서명해야합니다. v2 서명 체계를 사용하면 v2 체계로 서명 한 후 추가 인증서로 APK에 서명하면 확인이 실패합니다.

APK 서명 체계 v2 지원은 나중에 N Developer Preview에서 제공 될 예정입니다.

http://developer.android.com/preview/api-overview.html#apk_signature_v2

APK의 리버스 엔지니어링을 완전히 피할 수있는 방법은 없습니다. 응용 프로그램 자산, 리소스를 보호하기 위해 암호화를 사용할 수 있습니다.

• 암호화는 암호 해독없이 사용하기 어렵게합니다. 강력한 암호화 알고리즘을 선택하면 크래킹이 어려워집니다.
• 크래킹을 더욱 어렵게하기 위해 스푸핑 코드를 기본 로직에 추가합니다.
• 모든 논리로 중요한 논리를 작성할 수 있고 반드시 디 컴파일하기가 더 어려워집니다.
• Quixxi 와 같은 타사 보안 프레임 워크 사용

기본적으로 불가능합니다. 절대 불가능합니다. 그러나 희망이 있습니다. Obfuscator 를 사용 하여 다음과 같은 것들을 포함하여 일반적인 공격을 수행하기가 훨씬 어려울 수 있습니다.

1. 메소드 / 클래스 이름 바꾸기 (디 컴파일러에서 다음과 같은 유형을 얻습니다 a.a)
2. 난독 화 제어 흐름 (디 컴파일러에서 코드를 읽기가 매우 어렵습니다)
3. 문자열 및 가능한 리소스 암호화

나는 다른 사람들이 있다고 확신하지만 그것이 주요한 것입니다. 저는 .NET 난독 화 장치 에서 PreEmptive Solutions라는 회사에서 일하고 있습니다. 또한 DashO 라는 Android 및 Android에서도 작동하는 Java 난독 화 장치가 있습니다 .

그러나 난독 화는 항상 가격과 함께 제공됩니다. 특히 성능은 일반적으로 좋지 않으며 일반적으로 릴리스 전후로 약간의 시간이 필요합니다. 그러나 지적 재산이 귀하에게 매우 중요하다면 일반적으로 가치가 있습니다.

그렇지 않으면, 당신의 유일한 선택은 안드로이드 응용 프로그램이 응용 프로그램의 모든 실제 논리를 호스팅하는 서버로 전달되도록하는 것입니다. 앱을 사용하려면 사용자가 인터넷에 연결되어 있어야하기 때문에 자체적으로 문제가 있습니다.

또한이 문제가있는 것은 Android만이 아닙니다. 모든 앱 스토어에서 문제가됩니다. 패키지 파일을 얻는 것이 얼마나 어려운지에 대한 문제입니다 (예를 들어, iPhone에서는 그것이 쉽지 않다고 생각하지만 여전히 가능합니다).

RE를 완전히 피할 수는 없지만 내부적으로 더 복잡하게 만들면 공격자가 앱의 명확한 작동을보기가 더 어려워 져 공격 경로 수가 줄어들 수 있습니다.

응용 프로그램이 매우 민감한 데이터를 처리하는 경우 코드 리버스 엔지니어링의 복잡성을 증가시킬 수있는 다양한 기술이 있습니다. 한 가지 기술은 C / C ++를 사용하여 공격자가 쉽게 런타임 조작을 제한하는 것입니다. 매우 성숙하고 Android 오퍼 JNI와 쉽게 통합 할 수있는 충분한 C 및 C ++ 라이브러리가 있습니다. 공격자는 응용 프로그램을 낮은 수준에서 공격하기 위해 먼저 디버깅 제한을 우회해야합니다. 이로 인해 공격이 더욱 복잡해집니다. Android 애플리케이션에는 공격자 또는 맬웨어가 런타임을 쉽게 조작하지 못하도록 애플리케이션 매니페스트에 android : debuggable =”false”가 설정되어 있어야합니다.

추적 검사 – 응용 프로그램은 현재 디버거 또는 기타 디버깅 도구에 의해 추적되고 있는지 확인할 수 있습니다. 추적되는 경우 응용 프로그램은 사용자 데이터를 보호하기 위해 암호화 키를 삭제하거나 서버 관리자에게 알리거나 자체적으로 방어하려는 다른 유형의 응답과 같은 여러 가지 가능한 공격 대응 작업을 수행 할 수 있습니다. 이는 프로세스 상태 플래그를 확인하거나 ptrace attach의 반환 값 비교, 부모 프로세스 확인, 프로세스 목록의 블랙리스트 디버거 또는 프로그램의 다른 위치에서 타임 스탬프를 비교하는 것과 같은 다른 기술을 사용하여 확인할 수 있습니다.

최적화 -고급 수학 계산 및 기타 복잡한 논리 유형을 숨기려면 컴파일러 최적화를 활용 하면 객체 코드를 난독 처리 하여 공격자가 쉽게 분해 할 수 없으므로 공격자가 특정 코드를 이해하기가 더 어려워집니다. Android에서는 NDK와 함께 기본적으로 컴파일 된 라이브러리를 활용하여보다 쉽게 ​​수행 할 수 있습니다. 또한 LLVM Obfuscator 또는 모든 보호기 SDK를 사용하면 더 나은 기계 코드 난독 처리가 가능합니다.

이진 제거 – 기본 이진 제거는 응용 프로그램의 하위 수준 기능의 구성을보기 위해 공격자에게 필요한 시간과 기술 수준을 향상시키는 효과적인 방법입니다. 바이너리를 제거하면 바이너리의 기호 테이블이 제거되므로 공격자가 응용 프로그램을 쉽게 디버깅하거나 리버스 엔지니어링 할 수 없습니다. sstriping 또는 UPX와 같은 GNU / Linux 시스템에서 사용되는 기술을 참조 할 수 있습니다.

그리고 마지막으로 난독 및 ProGuard와 같은 도구에 대해 알고 있어야합니다.

앱이 민감한 경우 서버 측의 결제 처리 부분을 고려해야합니다. 결제 처리 알고리즘을 변경해보십시오. Java 코드 내에서 결제를 처리하는 대신 사용자 정보 (예 : 계정 잔액)를 수집 및 표시하는 경우에만 Android 앱을 사용하십시오. 암호화 된 매개 변수가있는 보안 SSL 프로토콜을 사용하여이 작업을 서버로 보내십시오. 완전히 암호화되고 안전한 API를 작성하여 서버와 통신하십시오.

물론 해킹 당할 수도 있으며 소스 코드 보호와 관련이 없지만 해커가 앱을 속이기 어렵게 만드는 또 다른 보안 계층을 고려하십시오.

TPM 칩 (Trusted Platform Module)이 보호 된 코드를 관리하도록되어 있지 않습니까? PC (특히 Apple)에서 일반화되고 있으며 오늘날의 스마트 폰 칩에 이미 존재할 수 있습니다. 불행히도 아직 그것을 사용할 OS API는 없습니다. Android가이 날에 대한 지원을 추가하기를 바랍니다. 그것은 또한 콘텐츠 DRM (Google이 WebM을 위해 노력하고있는)을 정리하는 열쇠입니다.

최종 사용자가 손에 넣을 때 안전한 것은 없지만 일반적인 관행으로 인해 공격자가 데이터를 훔치기가 더 어려워 질 수 있습니다.

• 주요 논리 (알고리즘)를 서버 측에 넣으십시오.
• 서버 및 클라이언트와 통신하십시오. 서버와 클라이언트 간의 통신이 SSL 또는 HTTPS를 통해 보호되는지 확인하십시오. 또는 다른 기술 키 쌍 생성 알고리즘 (ECC, RSA)을 사용하십시오. 민감한 정보가 엔드-투-엔드 암호화 상태로 유지되도록하십시오.
• 특정 시간 간격 후에 세션을 사용하고 만료하십시오.
• 리소스를 암호화하고 필요에 따라 서버에서 가져옵니다.
• 또는 webview서버의 리소스 + 코드 보호 를 통해 시스템에 액세스하는 하이브리드 앱을 만들 수 있습니다

여러 접근; 이것은 성능 과 보안 중에서 희생해야한다는 것이 분명합니다.

이 글에서 그 정답을 볼 수 있습니다. 또한 페이스 북 redex을 사용 하여 코드를 최적화 할 수 있습니다 . Redex는 .dex수준으로 작업을 보호하는 수준에서 작동 .class합니다.

안드로이드에서는 소스 코드와 리소스의 100 % 보안이 불가능합니다. 그러나 리버스 엔지니어에게는 약간의 어려움이 있습니다. 이에 대한 자세한 내용은 아래 링크를 참조하십시오.

상수 값을 안전하게 저장 하고 https://www.agicent.com/blog/mobile-app-security-best-practices/를 방문 하십시오.

해커가 어떤 식 으로든 APK 파일을 해킹 할 수 없도록 모든 앱의 리소스, 자산 및 소스 코드를 어떻게 보호 할 수 있습니까?

APK 파일은 SHA-1 알고리즘으로 보호됩니다 . APK 의 META-INF 폴더에 일부 파일이 있습니다 . APK 파일을 추출하고 내용을 변경하고 다시 압축하면 Android 시스템에서 새 APK 파일을 실행할 때 SHA-1 해시가 절대 일치하지 않으므로 작동하지 않습니다.

귀하의 코드를 보호 할 100 % 솔루션이 없다는 데 동의하지만 HoseDex2Jar v3 은 이제 시도해보십시오.

도구 : 응용 프로그램에서 Proguard를 사용하면 응용 프로그램을 리버스 엔지니어링하도록 제한 할 수 있습니다

클래스, 문자열, 자산, 리소스 파일 및 기본 라이브러리의 암호화뿐만 아니라 난독 화를 제공하는 일부 은행 응용 프로그램에서 DexGuard를 사용하고 있음을 알고 있습니다.

https://www.guardsquare.com/en/products/dexguard