Development Tip

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

yourdevel 2020. 9. 29. 18:45
반응형

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

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

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

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

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

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

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

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

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

또한 @inazaruk는 다음과 같이 매우 잘 말했습니다. 코드에 무엇을하든 잠재적 인 공격자는 자신이 가능하다고 생각하는 방식으로 코드를 변경할 수 있습니다. 기본적으로 애플리케이션이 수정되지 않도록 보호 할 수 없습니다. 그리고 거기에 넣은 모든 보호 기능을 비활성화 / 제거 할 수 있습니다.

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

하지만 해킹을 더 어렵게 만들기 위해 다른 트릭을 할 수 있습니다. 예를 들어 난독 화를 사용합니다 (Java 코드 인 경우). 이것은 일반적으로 리버스 엔지니어링을 상당히 느리게합니다.

 3. 해킹을 더 어렵거나 불가능하게 만들 수있는 방법이 있습니까? APK 파일의 소스 코드를 보호하려면 어떻게해야하나요?

모두가 말했듯이, 아시다시피 100 % 보안은 없습니다. 하지만 구글이 내장 한 안드로이드의 시작점은 프로 가드 다. 공유 라이브러리 를 포함하는 옵션이있는 경우 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에 배포 하지 않으면 귀중한 자산을 보호 할 수 있습니다 . 대신 앱의 요청에 응답하는 서버를 설정하고 자산을 "사용"한 다음 (의미가 무엇이든간에) 결과를 다시 앱으로 보냅니다. 이 모델이 염두에두고있는 자산에 맞지 않으면 전략을 다시 생각할 수 있습니다.

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

앱 보안의 첫 번째 규칙 : 공격자가 물리적 또는 전자적 액세스를 무제한으로 얻는 모든 머신은 이제 실제 위치 나 비용 지불에 관계없이 공격자의 소유입니다.

앱 보안의 두 번째 규칙 : 공격자가 침투 할 수없는 물리적 경계를 벗어나는 소프트웨어는 코딩에 얼마나 많은 시간을 썼는지에 관계없이 이제 공격자에게 속합니다.

Third rule: Any information that leaves those same physical boundaries that an attacker cannot penetrate now belongs to your attacker, no matter how valuable it is to you.

The foundations of information technology security are based on these three fundamental principles; the only truly secure computer is the one locked in a safe, inside a Farraday cage, inside a steel cage. There are computers that spend most of their service lives in just this state; once a year (or less), they generate the private keys for trusted root certification authorities (in front of a host of witnesses with cameras recording every inch of the room in which they are located).

Now, most computers are not used under these types of environments; they're physically out in the open, connected to the Internet over a wireless radio channel. In short, they're vulnerable, as is their software. They are therefore not to be trusted. There are certain things that computers and their software must know or do in order to be useful, but care must be taken to ensure that they can never know or do enough to cause damage (at least not permanent damage outside the bounds of that single machine).

You already knew all this; that's why you're trying to protect the code of your application. But, therein lies the first problem; obfuscation tools can make the code a mess for a human to try to dig through, but the program still has to run; that means the actual logic flow of the app and the data it uses are unaffected by obfuscation. Given a little tenacity, an attacker can simply un-obfuscate the code, and that's not even necessary in certain cases where what he's looking at can't be anything else but what he's looking for.

Instead, you should be trying to ensure that an attacker cannot do anything with your code, no matter how easy it is for him to obtain a clear copy of it. That means, no hard-coded secrets, because those secrets aren't secret as soon as the code leaves the building in which you developed it.

These key-values you have hard-coded should be removed from the application's source code entirely. Instead, they should be in one of three places; volatile memory on the device, which is harder (but still not impossible) for an attacker to obtain an offline copy of; permanently on the server cluster, to which you control access with an iron fist; or in a second data store unrelated to your device or servers, such as a physical card or in your user's memories (meaning it will eventually be in volatile memory, but it doesn't have to be for long).

Consider the following scheme. The user enters their credentials for the app from memory into the device. You must, unfortunately, trust that the user's device is not already compromised by a keylogger or Trojan; the best you can do in this regard is to implement multi-factor security, by remembering hard-to-fake identifying information about the devices the user has used (MAC/IP, IMEI, etc), and providing at least one additional channel by which a login attempt on an unfamiliar device can be verified.

The credentials, once entered, are obfuscated by the client software (using a secure hash), and the plain-text credentials discarded; they have served their purpose. The obfuscated credentials are sent over a secure channel to the certificate-authenticated server, which hashes them again to produce the data used to verify the validity of the login. This way, the client never knows what is actually compared to the database value, the app server never knows the plaintext credentials behind what it receives for validation, the data server never knows how the data it stores for validation is produced, and a man in the middle sees only gibberish even if the secure channel were compromised.

Once verified, the server transmits back a token over the channel. The token is only useful within the secure session, is composed of either random noise or an encrypted (and thus verifiable) copy of the session identifiers, and the client application must send this token on the same channel to the server as part of any request to do something. The client application will do this many times, because it can't do anything involving money, sensitive data, or anything else that could be damaging by itself; it must instead ask the server to do this task. The client application will never write any sensitive information to persistent memory on the device itself, at least not in plain text; the client can ask the server over the secure channel for a symmetric key to encrypt any local data, which the server will remember; in a later session the client can ask the server for the same key to decrypt the data for use in volatile memory. That data won't be the only copy, either; anything the client stores should also be transmitted in some form to the server.

Obviously, this makes your application heavily dependent on Internet access; the client device cannot perform any of its basic functions without proper connection to and authentication by the server. No different than Facebook, really.

Now, the computer that the attacker wants is your server, because it and not the client app/device is the thing that can make him money or cause other people pain for his enjoyment. That's OK; you get much more bang for your buck spending money and effort to secure the server than in trying to secure all the clients. The server can be behind all kinds of firewalls and other electronic security, and additionally can be physically secured behind steel, concrete, keycard/pin access, and 24-hour video surveillance. Your attacker would need to be very sophisticated indeed to gain any kind of access to the server directly, and you would (should) know about it immediately.

The best an attacker can do is steal a user's phone and credentials and log in to the server with the limited rights of the client. Should this happen, just like losing a credit card, the legitimate user should be instructed to call an 800 number (preferably easy to remember, and not on the back of a card they'd carry in their purse, wallet or briefcase which could be stolen alongside the mobile device) from any phone they can access that connects them directly to your customer service. They state their phone was stolen, provide some basic unique identifier, and the account is locked, any transactions the attacker may have been able to process are rolled back, and the attacker is back to square one.

 1. How can I completely avoid reverse engineering of an Android APK? Is this possible?

This isn't possible

 2. How can I protect all the app's resources, assets and source code so that hackers can't hack the APK file in any way?

When somebody change a .apk extension to .zip, then after unzipping, someone can easily get all resources (except Manifest.xml), but with APKtool one can get the real content of the manifest file too. Again, a no.

 3. Is there a way to make hacking more tough or even impossible? What more can I do to protect the source code in my APK file?

Again, no, but you can prevent upto some level, that is,

  • Download a resource from the Web and do some encryption process
  • Use a pre-compiled native library (C, C++, JNI, NDK)
  • Always perform some hashing (MD5/SHA keys or any other logic)

Even with Smali, people can play with your code. All in all, it's not POSSIBLE.

100% avoidance of reverse engineering of the Android APK is not possible, but you can use these ways to avoid extracting more data, like source code, assets form your APK, and resources:

  1. Use ProGuard to obfuscate application code

  2. Use NDK using C and C++ to put your application core and secure part of code in .so files

  3. To secure resources, don't include all important resources in the assets folder with APK. Download these resources at the time of application first start up.

Developers can take following steps to prevent an APK from theft somehow,

  • the most basic way is to use tools like ProGuard to obfuscate their code, but up until now, it has been quite difficult to completely prevent someone from decompiling an app.

  • Also I have heard about a tool HoseDex2Jar. It stops Dex2Jar by inserting harmless code in an Android APK that confuses and disables Dex2Jar and protects the code from decompilation. It could somehow prevent hackers from decompiling an APK into readable java code.

  • Use some server side application to communicate with the application only when it is needed. It could help prevent the important data.

At all, you can not completely protect your code from the potential hackers. Somehow, you could make it difficult and a bit frustrating task for them to decompile your code. One of the most efficient way is to write in native code(C/C++) and store it as compiled libraries.

 1. How can I completely avoid reverse engineering of an Android APK? Is this possible?

Impossible

 2. How can I protect all the app's resources, assets and source code so that hackers can't hack the APK file in any way?

Impossible

 3. Is there a way to make hacking more tough or even impossible? What more can I do to protect the source code in my APK file?

More tough - possible, but in fact it will be more tough mostly for the average user, who is just googling for hacking guides. If somebody really wants to hack your app - it will be hacked, sooner or later.

 1. How can I completely avoid reverse engineering of an Android APK? Is this possible?

That is impossible

 2. How can I protect all the app's resources, assets and source code so that hackers can't hack the APK file in any way?

Developers can take steps such as using tools like ProGuard to obfuscate their code, but up until now, it has been quite difficult to completely prevent someone from decompiling an app.

It's a really great tool and can increase the difficulty of 'reversing' your code whilst shrinking your code's footprint.

Integrated ProGuard support: ProGuard is now packaged with the SDK Tools. Developers can now obfuscate their code as an integrated part of a release build.

 3. Is there a way to make hacking more tough or even impossible? What more can I do to protect the source code in my APK file?

While researching, I came to know about HoseDex2Jar. This tool will protect your code from decompiling, but it seems not to be possible to protect your code completely.

Some of helpful links, you can refer to them.

Here are few methods you can try:

  1. Use obfuscation and tools like ProGuard.
  2. Encrypt some part of source and data.
  3. Use a proprietary inbuilt checksum in the app to detect tampering.
  4. Introduce code to avoid loading in a debugger, that is, let the app have the ability to detect the debugger and exit / kill the debugger.
  5. Separate the authentication as an online service.
  6. Use application diversity
  7. Use the finger printing technique for e.g., hardware signatures of the devices from different subsystem before authenticating the device.

The main question here is that can the dex files be decompiled and the answer is they can be "sort of". There are disassemblers like dedexer and smali.

ProGuard, properly configured, will obfuscate your code. DexGuard which is a commercial extended version of ProGuard, may help a bit more. However, your code can still be converted into smali and developers with reverse-engineering experience will be able to figure out what you are doing from the smali.

Maybe choose a good license and enforce it by the law in best possible way.

Your client should hire someone that knows what they are doing, who can make the right decisions and can mentor you.

Talk above about you having some ability to change the transaction processing system on the backend is absurd - you shouldn't be allowed to make such architectural changes, so don't expect to be able to.

My rationale on this:

Since your domain is payment processing, its safe to assume that PCI DSS and/or PA DSS (and potential state/federal law) will be significant to your business - to be compliant you must show you are secure. To be insecure then find out (via testing) that you aren't secure, then fixing, retesting, etcetera until security can be verified at a suitable level = expensive, slow, high-risk way to success. To do the right thing, think hard up front, commit experienced talent to the job, develop in a secure manner, then test, fix (less), etcetera (less) until security can be verified at a suitable level = inexpensive, fast, low-risk way to success.

As someone who worked extensively on payment platforms, including one mobile payments application (MyCheck), I would say that you need to delegate this behaviour to the server, no user name or password for the payment processor (whichever it is) should be stored or hardcoded in the mobile application, that's the last thing you want, because the source can be understood even when if you obfuscate the code.

Also, you shouldn't store credit cards or payment tokens on the application, everything should be, again, delegated to a service you built, it will also allow you later on, be PCI-compliant more easily, and the Credit Card companies won't breath down your neck (like they did for us).

The other upvoted answers here are correct. I just want to provide another option.

For certain functionality that you deem important you can host the WebView control in your app. The functionality would then be implemented on your web server. It will look like it's running in your application.

If we want to make reverse engineering (almost) impossible, we can put the application on a highly tamper-resistant chip, which executes all sensitive stuff internally, and communicates with some protocol to make controlling GUI possible on the host. Even tamper-resistant chips are not 100% crack proof; they just set the bar a lot higher than software methods. Of course, this is inconvenient: the application requires some little USB wart which holds the chip to be inserted into the device.

The question doesn't reveal the motivation for wanting to protect this application so jealously.

If the aim is to improve the security of the payment method by concealing whatever security flaws the application may have (known or otherwise), it is completely wrongheaded. The security-sensitive bits should in fact be open-sourced, if that is feasible. You should make it as easy as possible for any security researcher who reviews your application to find those bits and scrutinize their operation, and to contact you. Payment applications should not contain any embedded certificates. That is to say, there should be no server appliaction which trusts a device simply because it has a fixed certificate from the factory. A payment transaction should be made on the user's credentials alone, using a correctly designed end-to-end authentication protocol which precludes trusting the application, or the platform, or the network, etc.

If the aim is to prevent cloning, short of that tamper-proof chip, there isn't anything you can do to protect the program from being reverse-engineered and copied, so that someone incorporates a compatible payment method into their own application, giving rise to "unauthorized clients". There are ways to make it difficult to develop unauthorized clients. One would be to create checksums based on snapshots of the program's complete state: all state variables, for everything. GUI, logic, whatever. A clone program will not have exactly the same internal state. Sure, it is a state machine which has similar externally visible state transitions (as can be observed by inputs and outputs), but hardly the same internal state. A server application can interrogate the program: what is your detailed state? (i.e. give me a checksum over all of your internal state variables). This can be compared against dummy client code which executes on the server in parallel, going through the genuine state transitions. A third party clone will have to replicate all of the relevant state changes of the genuine program in order to give the correct responses, which will hamper its development.

I suggest you to look at Protect Software Applications from Attacks. It's a commercial service, but my friend's company used this and they are glad to use it.

Agreed with @Muhammad Saqib here: https://stackoverflow.com/a/46183706/2496464

And @Mumair give a good starting steps: https://stackoverflow.com/a/35411378/474330

It is always safe to assume that everything you distribute to your user's device, belong to the user. Plain and simple. You may be able to use the latest tools and procedure to encrypt your intellectual properties but there is no way to prevent a determined person from 'studying' your system. And even if the current technology may make it difficult for them to gain unwanted access, there might be some easy way tomorrow, or even just the next hour!

Thus, here comes the equation:

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

Even in as simple as an in-game economy. (Especially in games! There are more 'sophisticated' users there and loopholes spread in seconds!)

How do we stay safe?

Most, if not all, of our key processing systems (and database of course) located on the server side. And between the client and server, lies encrypted communications, validations, etc. That is the idea of thin client.

APK signature scheme v2 in Android N

The PackageManager class now supports verifying apps using the APK signature scheme v2. The APK signature scheme v2 is a whole-file signature scheme that significantly improves verification speed and strengthens integrity guarantees by detecting any unauthorized changes to APK files.

To maintain backward-compatibility, an APK must be signed with the v1 signature scheme (JAR signature scheme) before being signed with the v2 signature scheme. With the v2 signature scheme, verification fails if you sign the APK with an additional certificate after signing with the v2 scheme.

APK signature scheme v2 support will be available later in the N Developer Preview.

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

There is no way to completely avoid reverse engineering of an APK. To protect application assets, resources, you can use encryption.

  • Encryption will make harder to use it without decryption.choosing some strong encryption algorithm will make cracking harder.
  • Adding some spoof code into your main logic to make more harder for cracking.
  • If you can write your critical logic in any native language and that surely make harder for decompile.
  • Using any third party security frameworks like Quixxi

Basically it's not possible. It will never be possible. However, there is hope. You can use an obfuscator to make it so some common attacks are a lot harder to carry out including things like:

  1. Renaming methods/classes (so in the decompiler you get types like a.a)
  2. Obfuscating control flow (so in the decompiler the code is very hard to read)
  3. Encrypting strings and possibly resources

I'm sure there are others, but that's the main ones. I work for a company called PreEmptive Solutions on a .NET obfuscator. They also have a Java obfuscator that works for Android as well one called DashO.

Obfuscation always comes with a price, though. Notably, performance is usually worse, and it requires some extra time around releases usually. However, if your intellectual property is extremely important to you, then it's usually worth it.

Otherwise, your only choice is to make it so that your Android application just passes through to a server that hosts all of the real logic of your application. This has its own share of problems, because it means users must be connected to the Internet to use your app.

Also, it's not just Android that has this problem. It's a problem on every app store. It's just a matter of how difficult it is to get to the package file (for example, I don't believe it's very easy on iPhones, but it's still possible).

Its not possible to completely avoid RE but By making them more complex internally, you put make it more difficult for attackers to see the clear operation of the app, which may reduce the number of attack vectors.

If the application handles highly sensitive data, Various techniques exist which can increase the complexity of reverse engineering your code. One technique is to use C/C++ to limit easy runtime manipulation by the attacker. There are ample C and C++ libraries that are very mature and easy to integrate with Android offers JNI. An attacker must first circumvent the debugging restrictions in order to attack the application on a low level. This adds further complexity to an attack. Android applications should have android:debuggable=”false” set in the application manifest to prevent easy run time manipulation by an attacker or malware.

Trace Checking – An application can determine whether or not it is currently being traced by a debugger or other debugging tool. If being traced, the application can perform any number of possible attack response actions, such as discarding encryption keys to protect user data, notifying a server administrator, or other such type responses in an attempt to defend itself. This can be determined by checking the process status flags or using other techniques like comparing the return value of ptrace attach, checking parent process, blacklist debuggers in the process list or comparing timestamps on different places of the program.

Optimizations - To hide advanced mathematical computations and other types of complex logic, utilizing compiler optimizations can help obfuscate the object code so that it cannot easily be disassembled by an attacker, making it more difficult for an attacker to gain an understanding of the particular code. In Android this can more easily be achieved by utilizing natively compiled libraries with the NDK. In addition, using an LLVM Obfuscator or any protector SDK will provide better machine code obfuscation.

Stripping binaries – Stripping native binaries is an effective way to increase the amount of time and skill level required of an attacker in order to view the makeup of your application’s low level functions. By stripping a binary, the symbol table of the binary is stripped, so that an attacker cannot easily debug or reverse engineer an application.You can refer techniques used on GNU/Linux systems like sstriping or using UPX.

And at last you must be aware about obfuscation and tools like ProGuard.

Aren't TPM chips (Trusted Platform Module) supposed to manage protected code for you ? They are becoming common on PCs (especially Apple ones) and they may already exist in today's smartphone chips. Unfortunately there is no OS API to make use of it yet. Hopefully Android will add support for this one day. That's also the key to clean content DRM (which Google is working on for WebM).

Nothing is secure when you put it on end-users hand but some common practice may make this harder for attacker to steal data.

  • Put your main logic (algorithms) into server side.
  • Communicate with server and client; make sure communication b/w server and client is secured via SSL or HTTPS; or use other techniques key-pair generation algorithms (ECC, RSA). Ensure that sensitive information is remain End-to-End encrypted.
  • Use sessions and expire them after specific time interval.
  • Encrypt resources and fetch them from server on demand.
  • Or you can make Hybrid app which access system via webview protect resource + code on server

Multiple approaches; this is obvious you have to sacrifice among performance and security

If your app is this sensitive then you should consider the payment processing part at server side. Try to change your payment processing algorithms. Use android app only for collecting and displaying user information (i.e account balance) and rather than processing payments within java codes, send this task to your server using a secure SSL protocol with encrypted parameters. Create fully encrypted and secure API to communicate with your server.

Of course, It can also be hacked too and it has nothing to do with source codes protection but consider it another security layer to make it harder for hackers to trick your app.

How can I protect all the app's resources, assets and source code so that hackers can't hack the APK file in any way?

An APK file is protected with the SHA-1 algorithm. You can see some files in the META-INF folder of APK. If you extract any APK file and change any of its content and zip it again and when you run that new APK file on an Android machine, it will not work, because the SHA-1 hashes will never match.

While I agree there's no 100% solution that's going to protect your code, v3 of HoseDex2Jar is now up if you want to give it a try.

Tool: Using Proguard in your application it can be restricted to reverse engineering your application

I can see that good answer in this thread . In addition to you can use facebook redex to optimize the code. Redex works on .dex level where proguard work as .class level.

100% security of the source code and resources is not possible in Android. But, you can make little bit difficult for the reverse engineer. You can find more details on this in below links:

Visit Saving constant values securely and https://www.agicent.com/blog/mobile-app-security-best-practices/

when they have the app on their phone, they have full access to memory of it. so if u want to prevent it from being hacked, you could try to make it so that u cant just get the static memory address directly by using a debugger. they could do a stack buffer overflow if they have somewhere to write and they have a limit. so try to make it so when they write something, if u have to have a limit, if they send in more chars than limit, if (input > limit) then ignore, so they cant put assembly code there.

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

반응형

'Development Tip' 카테고리의 다른 글

테이블에서 두 행 사이의 공간?  (0) 2020.09.29
Swift for 루프 : 인덱스, 배열 요소?  (0) 2020.09.29
GNU Makefile 변수 할당 =,? =, : = 및 + =의 차이점은 무엇입니까?  (0) 2020.09.29
HTML5에 부동 입력 유형이 있습니까?  (0) 2020.09.29
OS X 터미널에서 커서를 단어 단위로 이동하는 방법이 있습니까?  (0) 2020.09.29

'Development Tip'의 다른글

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

관련글

댓글

티스토리툴바