APK 파일의 역엔지니어링을 방지하는 방법

APK 파일의 역엔지니어링을 방지하는 방법

저는 안드로이드용 결제 처리 앱을 개발 중인데, 해커가 APK 파일의 리소스, 자산 또는 소스 코드에 접근하는 것을 방지하고 싶습니다.

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

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

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

이제 제 질문은 다음과 같습니다.

1. 안드로이드 APK의 리버스 엔지니어링을 어떻게 완벽하게 방지할 수 있습니까?이것이 가능합니까?
2. 해커들이 APK 파일을 해킹하지 못하도록 앱의 모든 리소스, 자산 및 소스 코드를 어떻게 보호할 수 있습니까?
3. 해킹을 더 어렵거나 불가능하게 만드는 방법이 있습니까?APK 파일에서 소스 코드를 보호하려면 무엇을 더 할 수 있습니까?

안드로이드 APK의 리버스 엔지니어링을 완전히 피할 수 있는 방법은 무엇입니까?이것이 가능합니까?

AFAIK, 역엔지니어링을 완전히 회피하기 위한 속임수는 없습니다.

그리고 @inazaruk이 매우 잘 말한 것도 있습니다.잠재적인 공격자는 코드에 대해 무엇을 하든 실행 가능하다고 판단되는 방식으로 코드를 변경할 수 있습니다.기본적으로 응용프로그램이 수정되지 않도록 보호할 수 없습니다.또한 보호 기능을 사용하지 않도록 설정하거나 제거할 수 있습니다.

해커들이 APK 파일을 해킹하지 못하도록 앱의 모든 리소스, 자산 및 소스 코드를 어떻게 보호할 수 있습니까?

하지만 해킹을 더 어렵게 만들기 위해 다양한 속임수를 쓸 수 있습니다.예를 들어, 난독화(Java 코드인 경우)를 사용합니다.이는 일반적으로 리버스 엔지니어링 속도를 크게 저하시킵니다.

해킹을 더 어렵거나 불가능하게 만드는 방법이 있습니까?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 파일들은 현재까지도 존재한다고 생각하지 않습니다. (만약 존재한다 해도 자바 디컴파일러만큼 좋지는 않을 것입니다.)또한 @nikolay가 설명에서 언급했듯이 서버와 장치 간에 상호 작용할 때 SSL을 사용해야 합니다.
3. 장치에 값을 저장할 때 원시 형식으로 저장하지 마십시오.예를 들어 게임이 있는데 사용자가 공유 기본 설정에 보유한 게임 통화의 양을 저장하는 경우입니다.그렇다고 치자.10000에. 저축하는 대신에.10000직접적으로 접직, 다과같알은고을사즘저다용장니합여와 같은 합니다.((currency*2)+1)/13 그서대 에 래에신.10000당신이 저장합니다.1538.53846154[공유 기본 설정]으로 이동합니다.그러나 위의 예는 완벽하지 않으며 반올림 오류 등으로 인해 통화가 손실되지 않는 방정식을 고안하기 위해 노력해야 합니다.
4. 서버 측면 태스크에서도 유사한 작업을 수행할 수 있습니다.예를 들어, 결제 처리 앱을 사용해 보겠습니다.사용자가 다음을 지불해야 한다고 가정해 보겠습니다.$200 보내는 대신에$200서버로 하여 사전작은 을 " " ", ", " 합하여 합니다.$200예를 들어, 서버에 단어와 값을 동일시하는 파일 또는 테이블이 있습니다.그럼 이렇게 합시다.Charlie에해는하에 합니다.$47,그리고.John$3 ㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠ$200보낼 수 있습니다Charlie 번 네번그고리고▁four.John◦ ◦서버에서 그들이 의미하는 바를 해석하고 합산합니다.이렇게 하면 해커는 어떤 단어가 어떤 값에 해당하는지 모르기 때문에 임의 값을 서버로 보낼 수 없습니다.보안의 추가적인 척도로서, 당신은 또한 이것에 대해 점 3과 유사한 방정식을 가질 수 있고, 매 시간마다 키워드를 변경할 수 있습니다.n일수
5. 마지막으로, 당신은 당신의 앱에 쓸모없는 소스 코드를 무작위로 삽입할 수 있습니다. 그래서 해커는 건초더미에서 바늘을 찾고 있습니다.인터넷의 스니펫을 포함하는 임의의 클래스를 삽입하거나 피보나치 시퀀스와 같은 임의의 것을 계산하기 위한 함수만 삽입합니다.이러한 클래스가 컴파일되어 있지만 앱의 실제 기능에 의해 사용되지 않는지 확인합니다.이러한 잘못된 클래스를 충분히 추가하면 해커가 실제 코드를 찾는 데 어려움을 겪을 수 있습니다.

전반적으로 앱을 100% 보호할 수 있는 방법은 없습니다.더 어렵게 만들 수는 있지만, 불가능하지는 않습니다.웹 서버가 손상될 수 있고, 해커는 여러 거래 금액과 사용자가 보내는 키워드를 모니터링하여 사용자의 키워드를 파악할 수 있으며, 해커는 소스를 꼼꼼히 살펴보고 어떤 코드가 더미인지 파악할 수 있습니다.

반격만 할 수 있을 뿐 절대 이길 수 없습니다.

컴퓨팅 역사의 어느 시점에서도 공격자에게 소프트웨어의 작업 복사본을 제공할 때 소프트웨어의 역설계를 방지할 수 없었습니다.또한, 대부분의 경우, 그것은 결코 가능하지 않을 것입니다.

이를 이해하면 명백한 해결책이 있습니다. 즉, 공격자에게 비밀을 누설하지 마십시오.APK의 콘텐츠를 보호할 수는 없지만 보호할 수 있는 것은 배포하지 않는 모든 것입니다.일반적으로 이 소프트웨어는 활성화, 결제, 규칙 시행 및 기타 중요한 코드 조각에 사용되는 서버 측 소프트웨어입니다.APK에 자산을 배포하지 않음으로써 귀중한 자산을 보호할 수 있습니다.대신 앱의 요청에 응답하고 자산을 "사용"한 다음 결과를 앱으로 다시 전송하는 서버를 설정합니다.이 모델이 생각하고 있는 자산에 적합하지 않으면 전략을 다시 생각해 보는 것이 좋습니다.

또한 앱 불법 복제를 방지하는 것이 주요 목표라면 신경 쓰지 않아도 됩니다.당신은 이미 이 문제에 대해 어떤 해적 퇴치 조치로도 당신을 구할 수 있는 것보다 더 많은 시간과 돈을 소비했습니다.이 문제를 해결하기 위한 투자 수익률이 너무 낮아 생각조차 할 수 없습니다.

앱 보안의 첫 번째 규칙:공격자가 물리적 또는 전자적으로 제한 없이 액세스할 수 있는 모든 컴퓨터는 실제 위치나 사용자가 지불한 금액에 관계없이 공격자의 소유입니다.

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

세 번째 규칙:공격자가 지금 침투할 수 없는 동일한 물리적 경계를 벗어나는 모든 정보는 사용자에게 얼마나 중요한지에 관계없이 공격자의 것입니다.

정보 기술 보안의 기초는 이 세 가지 기본 원칙에 기초하고 있습니다. 진정으로 안전한 컴퓨터는 안전한 컴퓨터, 패러데이 케이지 안, 강철 케이지 안에 잠겨 있는 컴퓨터입니다.대부분의 서비스 수명을 이 상태로 보내는 컴퓨터가 있습니다. 1년에 한 번(또는 그 이하) 신뢰할 수 있는 루트 인증 기관의 개인 키를 생성합니다(카메라로 방의 구석구석을 기록하는 다수의 목격자 앞에서).

대부분의 컴퓨터는 이런 종류의 환경에서 사용되지 않습니다. 물리적으로 외부에 있고 무선 라디오 채널을 통해 인터넷에 연결되어 있습니다.간단히 말해서, 그들은 그들의 소프트웨어와 마찬가지로 취약합니다.그러므로 그들은 믿을 수 없습니다.컴퓨터와 해당 소프트웨어가 유용하기 위해서는 반드시 알아야 하거나 해야 하는 특정 사항이 있지만, 컴퓨터가 손상을 일으킬 정도로 충분히 알고 있거나 할 수 없도록 주의해야 합니다(최소한 단일 컴퓨터의 범위 밖에서 영구적인 손상은 아님).

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

대신, 공격자가 코드의 명확한 복사본을 얻는 것이 아무리 쉽더라도 코드를 사용하여 아무것도 할 수 없도록 해야 합니다.즉, 하드 코딩된 비밀이 없다는 것입니다. 코드가 개발된 건물을 떠나자마자 비밀이 아니기 때문입니다.

하드 코딩한 이러한 키 값은 응용 프로그램의 소스 코드에서 완전히 제거되어야 합니다.대신 장치의 휘발성 메모리(공격자가 오프라인 복사본을 얻기는 더 어렵지만 여전히 불가능하지는 않음), 영구적으로 액세스를 제어하는 서버 클러스터(철권으로 액세스를 제어하는 서버 클러스터), 장치 또는 서버와 관련 없는 두 번째 데이터 저장소 중 하나에 있어야 합니다.물리적 카드나 사용자의 메모리(즉, 결국 휘발성 메모리에 저장되지만 오래 사용할 필요는 없음)와 같은 것입니다.

다음과 같은 방식을 생각해 보십시오.사용자는 메모리에서 장치로 앱에 대한 자격 증명을 입력합니다.유감스럽게도 사용자의 장치가 키로거나 트로이 목마에 의해 이미 손상되지 않았음을 믿어야 합니다. 이와 관련하여 할 수 있는 최선의 방법은 사용자가 사용한 장치(MAC/IP, IMEI 등)에 대한 가짜 식별 정보를 기억하여 다중 요소 보안을 구현하는 것입니다.를 더 포함하는, 낯선 장치에 대한 로그인 시도를 확인할 수 있는 채널을 하나 이상 추가로 제공하는 방법.

일단 입력된 자격 증명은 클라이언트 소프트웨어(보안 해시 사용)에 의해 난독화되고 일반 텍스트 자격 증명은 삭제되어 용도에 적합합니다.난독화된 자격 증명은 보안 채널을 통해 인증서 인증 서버로 전송되며, 이 서버는 로그인의 유효성을 확인하는 데 사용되는 데이터를 생성하기 위해 다시 해시합니다.이렇게 하면 클라이언트는 데이터베이스 값과 실제로 비교되는 내용을 전혀 알 수 없고, 애플리케이션 서버는 유효성 검사를 위해 수신되는 내용의 일반 텍스트 자격 증명을 전혀 알 수 없으며, 데이터 서버는 유효성 검사를 위해 저장되는 데이터가 어떻게 생성되는지도 알 수 없으며, 보안 채널이 손상되더라도 중간에 있는 사람은 횡설수설하는 것만 볼 수 있습니다.

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

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

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

공격자가 할 수 있는 최선의 방법은 사용자의 전화기와 자격 증명을 훔치고 클라이언트의 제한된 권한으로 서버에 로그인하는 것입니다.이 경우 신용카드를 분실한 것과 마찬가지로 합법적인 사용자는 800번의 전화번호(가능하면 기억하기 쉽고 지갑에 넣고 다니는 카드의 뒷면이 아님)로 전화를 걸도록 지시되어야 합니다.모바일 장치와 함께 도난당할 수 있는 지갑 또는 서류 가방)을 고객 서비스에 직접 연결하는 모든 전화기에서 사용할 수 있습니다.전화기를 도난당했다고 진술하고, 기본적인 고유 식별자를 제공하며, 계정이 잠기고, 공격자가 처리할 수 있었던 모든 트랜잭션이 롤백되고, 공격자는 원점으로 돌아갑니다.

안드로이드 APK의 리버스 엔지니어링을 완전히 피할 수 있는 방법은 무엇입니까?이것이 가능합니까?

이것은 불가능합니다.

해커들이 APK 파일을 해킹하지 못하도록 앱의 모든 리소스, 자산 및 소스 코드를 어떻게 보호할 수 있습니까?

누군가가 .apk 확장자를 .zip으로 변경하면 압축을 푼 후에 누군가는 모든 리소스(Manifest.xml 제외)를 쉽게 가져올 수 있지만 APK 도구를 사용하면 매니페스트 파일의 실제 내용도 가져올 수 있습니다.다시, 아니오.

해킹을 더 어렵거나 불가능하게 만드는 방법이 있습니까?APK 파일에서 소스 코드를 보호하려면 무엇을 더 할 수 있습니까?

다시 말씀드리지만, 어느 정도까지는 막을 수 있습니다. 즉,

• 웹에서 리소스 다운로드 및 일부 암호화 프로세스 수행
• 사전 컴파일된 기본 라이브러리(C, C++, JNI, NDK) 사용
• 항상 해싱(MD5/SHA 키 또는 기타 로직)을 수행합니다.

에도.Smali사람들은 당신의 코드를 가지고 놀 수 있습니다.대체로, 그것은 가능하지 않습니다.

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

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

2. C와 C++을 사용하여 NDK를 사용하여 응용프로그램 코어와 코드의 일부를 보호합니다..so 파일

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

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

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

안드로이드 APK의 리버스 엔지니어링을 완전히 피할 수 있는 방법은 무엇입니까?이것이 가능합니까?

무리다

해커들이 APK 파일을 해킹하지 못하도록 앱의 모든 리소스, 자산 및 소스 코드를 어떻게 보호할 수 있습니까?

무리다

해킹을 더 어렵거나 불가능하게 만드는 방법이 있습니까?APK 파일에서 소스 코드를 보호하려면 무엇을 더 할 수 있습니까?

더 어려운 - 가능하지만, 사실 그것은 해킹 가이드를 검색하는 일반 사용자들에게 더 어려운 일이 될 것입니다.누군가가 정말로 당신의 앱을 해킹하고 싶다면, 조만간 해킹당할 것입니다.

안드로이드 APK의 리버스 엔지니어링을 완전히 피할 수 있는 방법은 무엇입니까?이것이 가능합니까?

그건 말도 안 돼.

해커들이 APK 파일을 해킹하지 못하도록 앱의 모든 리소스, 자산 및 소스 코드를 어떻게 보호할 수 있습니까?

개발자들은 ProGuard와 같은 도구를 사용하여 코드를 난독화하는 등의 조치를 취할 수 있지만, 지금까지는 누군가가 앱을 해체하는 것을 완전히 막는 것이 상당히 어려웠습니다.

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

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

해킹을 더 어렵거나 불가능하게 만드는 방법이 있습니까?APK 파일에서 소스 코드를 보호하려면 무엇을 더 할 수 있습니까?

저는 조사하면서 HoseDex2Jar에 대해 알게 되었습니다.이 도구를 사용하면 코드가 압축 해제되는 것을 방지할 수 있지만 코드를 완전히 보호할 수는 없는 것 같습니다.

몇 가지 유용한 링크를 참조할 수 있습니다.

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

여기서 중요한 질문은 덱스 파일을 압축 해제할 수 있느냐는 것입니다. 답은 "종류"가 될 수 있다는 것입니다.디덱서나 스몰 같은 디스어셈블러가 있습니다.

올바르게 구성된 ProGuard는 코드를 난독화합니다.ProGuard의 상업적 확장 버전인 덱스가드는 조금 더 도움이 될 수 있습니다.그러나 당신의 코드는 여전히 스몰로 변환될 수 있으며 리버스 엔지니어링 경험이 있는 개발자들은 스몰에서 당신이 무엇을 하고 있는지 알아낼 수 있습니다.

아마도 좋은 면허증을 선택하고 법에 따라 가능한 한 최선의 방법으로 시행할 것입니다.

고객은 자신이 무엇을 하고 있는지 알고 올바른 결정을 내리고 여러분에게 조언을 해줄 수 있는 사람을 고용해야 합니다.

위에서 백엔드에서 트랜잭션 처리 시스템을 변경할 수 있는 기능을 가지고 있다는 것은 터무니없는 일입니다. 이러한 아키텍처 변경을 허용해서는 안 되므로 변경할 수 있을 것으로 기대하지 마십시오.

이에 대한 저의 근거는 다음과 같습니다.

귀하의 도메인은 지불 처리이므로 PCI DSS 및/또는 PADSS(및 잠재적인 주/연방법)가 귀하의 비즈니스에 중요하다고 가정해도 무방합니다. 이를 준수하려면 귀하가 안전하다는 것을 증명해야 합니다.보안을 유지하려면 테스트를 통해 보안이 안전하지 않음을 확인한 다음 적절한 수준에서 보안이 확인될 때까지 수리, 재테스트 등을 수행합니다. = 비용이 많이 들고, 느리고, 위험성이 높은 성공 방법.올바른 작업을 수행하려면 사전에 열심히 생각하고, 경험이 풍부한 인재를 업무에 투입하고, 안전한 방식으로 개발한 다음, 보안이 적절한 수준에서 검증될 때까지 테스트, 수정(축소) 등의 작업을 수행합니다. = 비용이 적게 들고, 빠르고, 위험이 적은 방법으로 성공할 수 있습니다.

하나의 모바일 결제 애플리케이션(MyCheck)을 포함하여 결제 플랫폼에서 광범위하게 일한 사람으로서, 저는 당신이 이 행동을 서버에 위임할 필요가 있다고 말하고 싶습니다.결제 프로세서(어느 것이든)에 대한 사용자 이름 또는 암호는 모바일 응용 프로그램에 저장되거나 하드 코딩되어서는 안 됩니다.코드를 난독화해도 소스를 이해할 수 있기 때문에, 그것은 당신이 절대로 원하지 않는 것입니다.

또한, 당신은 애플리케이션에 신용카드나 결제 토큰을 저장해서는 안 됩니다.모든 것을 다시 한 번 구축한 서비스에 위임해야 합니다.또한 나중에 PCI를 더 쉽게 준수할 수 있으며, 신용카드 회사들은 (우리에게 그랬던 것처럼) 당신의 목을 조르지 않을 것입니다.

만약 역설계(거의)가 불가능하게 만들고 싶다면, 우리는 애플리케이션을 내부적으로 모든 민감한 것들을 실행하고 호스트에서 GUI를 제어할 수 있도록 일부 프로토콜과 통신하는 매우 변조에 강한 칩에 넣을 수 있습니다.변조 방지 칩도 100% 균열 방지가 되지 않습니다. 소프트웨어 방식보다 훨씬 더 높은 수준으로 설정할 뿐입니다.물론 불편합니다. 애플리케이션은 칩을 장치에 삽입하기 위해 약간의 USB 사마귀가 필요합니다.

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

애플리케이션이 가지고 있을 수 있는 보안 결함(알려졌거나 그렇지 않은 경우)을 은폐하여 결제 방법의 보안을 향상시키는 것이 목적이라면, 이는 완전히 잘못된 생각입니다.보안에 민감한 비트는 실제로 오픈 소스여야 합니다.귀하의 애플리케이션을 검토하는 보안 연구원이 해당 비트를 찾아 해당 비트의 작동을 면밀히 조사하고 귀하에게 연락할 수 있도록 최대한 쉽게 해야 합니다.결제 응용 프로그램에 인증서가 포함되어 있으면 안 됩니다.즉, 공장의 고정 인증서를 가지고 있다는 이유만으로 장치를 신뢰하는 서버 애플리케이션이 없어야 합니다.결제 거래는 애플리케이션, 플랫폼, 네트워크 등을 신뢰할 수 없도록 올바르게 설계된 종단 간 인증 프로토콜을 사용하여 사용자의 자격 증명만으로 이루어져야 합니다.

복제를 방지하는 것이 목적이라면 프로그램이 역설계되고 복사되지 않도록 보호할 수 있는 방법이 없으므로 누군가가 호환 가능한 결제 방법을 자신의 애플리케이션에 통합하여 "무단 클라이언트"를 생성할 수 있습니다.허가받지 않은 고객을 개발하는 것을 어렵게 만드는 방법들이 있습니다.하나는 프로그램의 전체 상태, 즉 모든 상태 변수의 스냅샷을 기반으로 체크섬을 만드는 것입니다.GUI, 논리, 뭐든지.복제 프로그램의 내부 상태가 완전히 동일하지는 않습니다.물론 외부에서 볼 수 있는 상태 전환이 유사하지만(입력 및 출력에서 관찰할 수 있음) 내부 상태는 거의 동일하지 않은 상태 기계입니다.서버 응용 프로그램은 프로그램을 조회할 수 있습니다. 자세한 상태는 무엇입니까?(즉, 모든 내부 상태 변수에 대한 체크섬을 제공합니다.)이는 실제 상태 전환을 통해 서버에서 병렬로 실행되는 더미 클라이언트 코드와 비교할 수 있습니다.타사 복제본은 올바른 응답을 제공하기 위해 실제 프로그램의 모든 관련 상태 변경을 복제해야 하며, 이는 프로그램 개발을 방해합니다.

여기서 업데이트된 다른 답변은 정확합니다.저는 단지 다른 옵션을 제공하고 싶습니다.

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

여기서 @Muhammad Saqib에 동의합니다: https://stackoverflow.com/a/46183706/2496464

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

사용자의 장치에 배포하는 모든 것은 사용자의 것이라고 가정하는 것이 항상 안전합니다.있는 그대로의 단순한.최신 도구와 절차를 사용하여 지적 재산을 암호화할 수는 있지만 단호한 사람이 시스템을 '공부'하는 것을 막을 방법은 없습니다.그리고 비록 현재의 기술이 그들이 원치 않는 접근을 얻는 것을 어렵게 만들 수 있을지라도, 내일 혹은 심지어 다음 시간에 어떤 쉬운 방법이 있을지도 모릅니다!

따라서 방정식은 다음과 같습니다.

돈에 관해서는, 우리는 항상 고객이 신뢰할 수 없다고 가정합니다.

게임 내 경제처럼 단순한 경우에도. (특히 게임에서!그곳에는 더 많은 '세련된' 사용자들이 있고 몇 초 만에 허점이 확산됩니다!)

어떻게 하면 안전하게 지낼 수 있을까요?

전부는 아니더라도 대부분의 주요 처리 시스템(및 데이터베이스)은 서버 측에 있습니다.그리고 클라이언트와 서버 사이에는 암호화된 통신, 검증 등이 있습니다.그것은 얇은 고객의 아이디어입니다.

공격으로부터 소프트웨어 응용 프로그램 보호를 검토하는 것이 좋습니다.상업적인 서비스인데 친구 회사에서 이걸 사용했는데 기꺼이 이용해주신대요.

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

• 암호화를 사용하면 암호 해독 없이 사용하기가 더 어려워집니다.강력한 암호화 알고리즘을 선택하면 크래킹이 더 어려워집니다.
• 스푸핑 코드를 기본 로직에 추가하여 크래킹을 더 어렵게 만듭니다.
• 만약 당신이 어떤 모국어로도 당신의 비판적인 논리를 쓸 수 있다면, 그것은 확실히 분해하기를 더 어렵게 만들 것입니다.
• Quixxi와 같은 타사 보안 프레임워크 사용

Android 7.0의 APK 서명 체계 v2(Nougat)

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

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

APK 시그니처 스킴 v2 지원은 N Developer Preview에서 나중에 제공될 예정입니다.

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

기본적으로 불가능합니다.그것은 결코 가능하지 않을 것입니다.하지만, 희망이 있습니다.난독화기를 사용하여 다음과 같은 일반적인 공격을 수행하기가 훨씬 더 어려워질 수 있습니다.

1. 이름 에서는 "/" " " " " " " (" " " " " " " " " "와 같은 .a.a)
2. 제어 흐름이 난독화됨(따라서 디컴파일러에서는 코드를 읽기가 매우 어려움)
3. 문자열 및 가능한 리소스 암호화

다른 사람들도 있겠지만, 그게 주요한 것들입니다.저는 .NET 난독화기의 Preemptive Solutions라는 회사에서 일하고 있습니다.그들은 또한 DashO라고 불리는 Android용 자바 난독화기를 가지고 있습니다.

하지만 난독화에는 항상 대가가 따릅니다.특히, 성능은 대개 더 나쁘고, 출시 전후에 시간이 좀 더 필요합니다.하지만, 여러분의 지적 재산이 여러분에게 매우 중요하다면, 보통 그럴 가치가 있습니다.

그렇지 않으면 Android 응용프로그램이 응용프로그램의 모든 실제 논리를 호스트하는 서버를 통과하도록 하는 것이 유일한 선택입니다.이는 사용자가 앱을 사용하려면 인터넷에 연결되어 있어야 한다는 것을 의미하기 때문에 고유한 문제가 있습니다.

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

Android에서는 소스 코드와 리소스의 100% 보안이 불가능합니다.하지만 리버스 엔지니어에게는 조금 어렵게 만들 수 있습니다.이에 대한 자세한 내용은 아래 링크에서 확인할 수 있습니다.

일정한 값을 안전하게 저장하고 앱 개발자를 위한 모바일 앱 보안 모범 사례를 방문하십시오.

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

물론, 그것은 또한 해킹될 수 있고 소스 코드 보호와 관련이 없지만, 해커들이 당신의 앱을 속이는 것을 더 어렵게 만드는 또 다른 보안 계층을 고려합니다.

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

응용 프로그램이 매우 민감한 데이터를 처리하는 경우 코드 역설계의 복잡성을 증가시킬 수 있는 다양한 기술이 존재합니다.한 가지 기술은 C/C++를 사용하여 공격자에 의한 쉬운 런타임 조작을 제한하는 것입니다.매우 성숙하고 통합하기 쉬운 충분한 C 및 C++ 라이브러리가 있으며 Android는 JNI를 제공합니다.

공격자는 먼저 낮은 수준에서 응용 프로그램을 공격하려면 디버깅 제한을 우회해야 합니다.이로 인해 공격이 더욱 복잡해집니다.Android 응용 프로그램은 다음과 같아야 합니다.android:debuggable=”false”응용 프로그램 매니페스트에 설정되어 공격자 또는 악성 프로그램에 의한 실행 시간 조작을 쉽게 방지합니다.

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

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

이진 제거 – 기본 이진 제거는 응용 프로그램의 하위 수준 기능 구성을 보기 위해 공격자가 필요로 하는 시간과 기술 수준을 높이는 효과적인 방법입니다.이진을 제거하면 이진의 기호 테이블이 제거되므로 공격자가 응용 프로그램을 쉽게 디버그하거나 역설계할 수 없습니다.스트리핑이나 UPX 사용과 같은 GNU/리눅스 시스템에 사용되는 기술을 참조할 수 있습니다.

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

일부 은행 앱은 클래스, 문자열, 자산, 리소스 파일 및 네이티브 라이브러리의 암호화뿐만 아니라 난독화를 제공하는 덱스가드를 사용하고 있는 것으로 알고 있습니다.

저는 이 질문에 대한 좋은 답이 있다는 것을 알 수 있습니다.또한 Facebook ReDex를 사용하여 코드를 최적화할 수 있습니다.ReDex는 다음에서 작동합니다..dexProGuard가 작동하는 수준.class레벨

도구: 응용프로그램에서 ProGuard를 사용하면 응용프로그램을 역설계하는 것이 제한될 수 있습니다.

최종 사용자의 손에 넣을 때 안전한 것은 없지만 일부 일반적인 방법은 공격자가 데이터를 훔치기 어렵게 만들 수 있습니다.

• 기본 논리(알고리즘)를 서버 측에 배치합니다.
• 서버 및 클라이언트와 통신하거나, SSL 또는 HTTPS를 통해 서버와 클라이언트 간의 통신이 보호되는지 확인하거나, 키 쌍 생성 알고리즘(ECC 및 RSA)에 다른 기술을 사용합니다.중요한 정보를 종단 간 암호화된 상태로 유지합니다.
• 세션을 사용하고 특정 시간 간격이 지나면 만료됩니다.
• 리소스를 암호화하고 요청 시 서버에서 가져옵니다.
• 아니면 당신은 만들 수 있습니다. 잡종의 시스템에 액세스하는 앱webview서버에서 리소스 + 코드 보호

다양한 접근 방식으로 성능과 보안 측면에서 희생해야 합니다.

TPM(Trusted Platform Module) 칩은 보호된 코드를 관리해야 하는 것이 아닙니까?

PC(특히 Apple 제품)에서 일반화되고 있으며 오늘날의 스마트폰 칩에 이미 존재할 수 있습니다.안타깝게도, 아직 그것을 활용할 수 있는 OS API가 없습니다.안드로이드가 언젠가 지원을 추가하기를 바랍니다.이것이 구글이 WebM을 위해 연구하고 있는 콘텐츠 DRM을 청소하는 열쇠이기도 합니다.

해커들이 APK 파일을 해킹하지 못하도록 앱의 모든 리소스, 자산 및 소스 코드를 어떻게 보호할 수 있습니까?

APK 파일은 SHA-1 알고리즘으로 보호됩니다.APK의 META-INF 폴더에서 일부 파일을 볼 수 있습니다.APK 파일을 추출하고 내용을 변경한 후 다시 압축을 풀면 Android 컴퓨터에서 새 APK 파일을 실행할 때 SHA-1 해시가 일치하지 않기 때문에 작동하지 않습니다.

그들이 그들의 전화기에 앱을 가지고 있을 때, 그들은 그것의 메모리에 대한 완전한 접근을 가지고 있습니다. 그래서 만약 당신이 그것이 해킹되는 것을 방지하고 싶다면, 당신은 디버거를 사용하여 단지 직접 정적인 메모리 주소를 얻을 수 있도록 그것을 만드는 것을 시도할 수 있습니다.쓸 곳이 있고 한계가 있는 경우 스택 버퍼 오버플로를 수행할 수 있습니다.그래서 그들이 무언가를 쓸 때, 당신이 제한이 있어야 한다면, 그들이 제한보다 많은 문자를 보낸다면, 만약 그들이 (입력 > 제한)을 무시한다면, 그렇게 하도록 노력하세요. 그래서 그들은 어셈블리 코드를 거기에 넣을 수 없습니다.

위의 이미 좋은 답변에 추가할 뿐입니다.

제가 아는 또 다른 요령은 귀중한 코드를 자바 라이브러리로 저장하는 것입니다.그런 다음 해당 라이브러리를 Android 프로젝트로 설정합니다.C.so 파일은 좋지만 Android Lib는 좋습니다.

이렇게 하면 Android Library에 저장된 이러한 중요한 코드가 압축을 푼 후에는 표시되지 않습니다.

언급URL : https://stackoverflow.com/questions/13854425/how-to-avoid-reverse-engineering-of-an-apk-file