android - studio - remover barra de titulo do app




Como evitar a engenharia reversa de um arquivo APK? (20)

Estou desenvolvendo um aplicativo de processamento de pagamentos para Android e quero evitar que um hacker acesse recursos, ativos ou código-fonte do arquivo APK .

Se alguém alterar a extensão .apk para .zip, poderá descompactá-lo e acessar facilmente todos os recursos e recursos do aplicativo, e usando dex2jar e um decompilador Java, eles também poderão acessar o código-fonte. É muito fácil fazer engenharia reversa de um arquivo APK do Android - para obter mais detalhes, consulte a pergunta sobre estouro de pilha. Engenharia reversa de um arquivo APK para um projeto .

Eu usei a ferramenta Proguard fornecida com o Android SDK. Quando faço a engenharia reversa de um arquivo APK gerado usando um keystore assinado e o Proguard, recebo um código ofuscado.

No entanto, os nomes dos componentes do Android permanecem inalterados e alguns códigos, como valores-chave usados ​​no aplicativo, permanecem inalterados. Conforme a documentação do Proguard, a ferramenta não pode ofuscar os componentes mencionados no arquivo de manifesto.

Agora minhas perguntas são:

  1. Como posso impedir completamente a engenharia reversa de um APK Android? Isso é possível?
  2. Como posso proteger todos os recursos, ativos e código-fonte do aplicativo para que os hackers não consigam hackear o arquivo APK de alguma forma?
  3. Existe uma maneira de tornar o hacking mais difícil ou mesmo impossível? O que mais posso fazer para proteger o código-fonte no meu arquivo APK?

1. Como posso evitar completamente a engenharia reversa de um APK Android? Isso é possível?

AFAIK, não há truque para evitar a engenharia reversa.

E também muito bem dito por @inazaruk: O que quer que você faça no seu código, um invasor em potencial é capaz de alterá-lo de qualquer maneira que ele achar viável . Você basicamente não pode proteger seu aplicativo de ser modificado. E qualquer proteção que você colocar lá pode ser desativada / removida.

2. Como posso proteger todos os recursos, ativos e código-fonte do aplicativo para que os hackers não consigam hackear o arquivo APK de alguma forma?

Você pode fazer truques diferentes para tornar o hacking mais difícil. Por exemplo, use ofuscação (se for código Java). Isso geralmente diminui a engenharia reversa significativamente.

3. Existe uma maneira de tornar o hacking mais difícil ou mesmo impossível? O que mais posso fazer para proteger o código-fonte no meu arquivo APK?

Como todos dizem, e como você provavelmente sabe, não há 100% de segurança. Mas o lugar para começar para o Android, que o Google construiu, é o ProGuard. Se você tiver a opção de incluir bibliotecas compartilhadas , inclua o código necessário em C ++ para verificar tamanhos de arquivos, integração, etc. Se você precisar adicionar uma biblioteca nativa externa à pasta de biblioteca do seu APK em cada compilação, poderá usá-la pela sugestão abaixo.

Coloque a biblioteca no caminho da biblioteca nativa, cujo padrão é "libs" na sua pasta de projeto. Se você construiu o código nativo para o alvo 'armeabi' então coloque-o em libs / armeabi . Se foi construído com armeabi-v7a , coloque-o em libs / armeabi-v7a.

<project>/libs/armeabi/libstuff.so

1. Como posso evitar completamente a engenharia reversa de um APK Android? Isso é possível?

Impossível

2. Como posso proteger todos os recursos, ativos e código-fonte do aplicativo para que os hackers não consigam hackear o arquivo APK de alguma forma?

Impossível

3. Existe uma maneira de tornar o hacking mais difícil ou mesmo impossível? O que mais posso fazer para proteger o código-fonte no meu arquivo APK?

Mais difícil - possível, mas na verdade será mais difícil principalmente para o usuário médio, que está apenas procurando por guias de hackers. Se alguém realmente quiser invadir seu aplicativo, ele será invadido, mais cedo ou mais tarde.


1. Como posso evitar completamente a engenharia reversa de um APK Android? Isso é possível?

Isso não é possível

2. Como posso proteger todos os recursos, ativos e código-fonte do aplicativo para que os hackers não consigam hackear o arquivo APK de alguma forma?

Quando alguém muda uma extensão .apk para .zip, depois de descompactar, alguém pode facilmente obter todos os recursos (exceto Manifest.xml ), mas com o APKtool é possível obter o conteúdo real do arquivo de manifesto. Mais uma vez, um não.

3. Existe uma maneira de tornar o hacking mais difícil ou mesmo impossível? O que mais posso fazer para proteger o código-fonte no meu arquivo APK?

Mais uma vez, não, mas você pode evitar até algum nível, isto é,

  • Baixe um recurso da Web e faça algum processo de criptografia
  • Use uma biblioteca nativa pré-compilada (C, C ++, JNI, NDK)
  • Sempre execute algum hash (chaves MD5 / SHA ou qualquer outra lógica)

Mesmo com o Smali , as pessoas podem brincar com o seu código. Tudo somado, não é possível.


Como posso proteger todos os recursos, ativos e código-fonte do aplicativo para que os hackers não consigam hackear o arquivo APK de alguma forma?

Um arquivo APK é protegido pelo algoritmo SHA . Você pode ver alguns arquivos na pasta META-INF do APK. Se você extrair qualquer arquivo APK e alterar qualquer conteúdo, feche-o novamente e, quando executar esse novo arquivo APK em uma máquina Android, isso não funcionará, pois os hashes SHA-1 nunca serão iguais.


Nada é seguro quando você o coloca na mão do usuário final, mas alguma prática comum pode dificultar a invasão de dados por parte do invasor.

  • Coloque sua lógica principal (algoritmos) no lado do servidor.
  • Comunique-se com o servidor e o cliente; certifique-se de que o servidor e o cliente de comunicação b / w estejam protegidos via SSL ou HTTPS; ou usar outros algoritmos de geração de pares de chaves de técnicas (ECC, RSA). Certifique-se de que as informações confidenciais permaneçam criptografadas de ponta a ponta.
  • Use sessões e expire-as após um intervalo de tempo específico.
  • Criptografe recursos e busque-os do servidor sob demanda.
  • Ou você pode fazer o aplicativo híbrido que sistema de acesso via webviewproteger o recurso + código no servidor

Múltiplas abordagens; isso é óbvio que você tem que sacrificar entre desempenho e segurança


100% de evitar a engenharia reversa do APK Android não é possível, mas você pode usar essas formas para evitar a extração de mais dados, como o código-fonte, os recursos do APK e os recursos:

  1. Use o ProGuard para ofuscar o código do aplicativo

  2. Use o NDK usando C e C ++ para colocar o núcleo do seu aplicativo e proteger parte do código em arquivos .so

  3. Para proteger recursos, não inclua todos os recursos importantes na pasta de recursos com o APK. Faça o download desses recursos no momento da primeira inicialização do aplicativo.


AFAIK, você não pode mais proteger os arquivos no diretório / res do que eles estão protegidos agora.

No entanto, existem etapas que você pode seguir para proteger seu código-fonte, ou pelo menos o que ele faz, se não tudo.

  1. Use ferramentas como o ProGuard. Estes irão ofuscar o seu código e dificultar a leitura quando descompilados, se não impossíveis.
  2. Mova as partes mais críticas do serviço para fora do aplicativo e para um serviço da Web, oculto atrás de uma linguagem do lado do servidor, como o PHP. Por exemplo, se você tem um algoritmo que lhe deu um milhão de dólares para escrever. Você obviamente não quer que as pessoas o roubem do seu aplicativo. Mova o algoritmo e faça com que ele processe os dados em um servidor remoto e use o aplicativo para simplesmente fornecer os dados. Ou use o NDK para gravá-los nativamente em arquivos .so, que são muito menos propensos a serem descompilados do que os apks. Eu não acho que um descompilador para arquivos .so exista até agora (e mesmo se existisse, não seria tão bom quanto os decompiladores de Java). Além disso, como @nikolay mencionado nos comentários, você deve usar o SSL ao interagir entre o servidor e o dispositivo.
  3. Ao armazenar valores no dispositivo, não os armazene em um formato bruto. Por exemplo, se você tiver um jogo e estiver armazenando a quantidade de moeda do jogo que o usuário possui em SharedPreferences. Vamos supor que sejam 10000 moedas. Em vez de salvar diretamente 10000 , salve-o usando um algoritmo como ((currency*2)+1)/13 . Portanto, em vez de 10000 , você salva 1538.53846154 no 1538.53846154 . No entanto, o exemplo acima não é perfeito, e você terá que trabalhar para chegar a uma equação que não perca dinheiro para erros de arredondamento, etc.
  4. Você pode fazer uma coisa semelhante para tarefas do lado do servidor. Agora, por exemplo, vamos pegar seu aplicativo de processamento de pagamentos. Digamos que o usuário tenha que fazer um pagamento de $200 . Em vez de enviar um valor bruto de $200 para o servidor, envie uma série de valores menores e predefinidos que somam $200 . Por exemplo, tenha um arquivo ou tabela no seu servidor que equacione palavras com valores. Então digamos que Charlie corresponda a $47 e John a $3 . Então, em vez de enviar $200 , você pode enviar Charlie quatro vezes e John quatro vezes. No servidor, interprete o que eles significam e some-os. Isso impede que um hacker envie valores arbitrários para o seu servidor, pois eles não sabem qual palavra corresponde a qual valor. Como uma medida adicional de segurança, você poderia ter uma equação semelhante ao ponto 3 para isso também e alterar as palavras-chave a cada n número de dias.
  5. Finalmente, você pode inserir código-fonte inútil e aleatório em seu aplicativo, para que o hacker esteja procurando uma agulha em um palheiro. Inserir classes aleatórias contendo trechos da internet, ou apenas funções para calcular coisas aleatórias, como a seqüência de Fibonacci. Certifique-se de que essas classes sejam compiladas, mas não sejam usadas pela funcionalidade real do aplicativo. Adicione o suficiente dessas classes falsas, e o hacker teria dificuldade em encontrar seu código real.

Apesar de tudo, não há como proteger seu aplicativo em 100%. Você pode tornar isso mais difícil, mas não impossível. Seu servidor web pode ser comprometido, o hacker pode descobrir suas palavras-chave monitorando vários valores de transação e as palavras-chave que você envia para ele, o hacker pode vasculhar a fonte e descobrir qual código é falso.

Você só pode revidar, mas nunca vencer.


Aqui estão alguns métodos que você pode tentar:

  1. Use obfuscation e ferramentas como o ProGuard .
  2. Criptografar alguma parte da fonte e dos dados.
  3. Use uma soma de verificação incorporada proprietária no aplicativo para detectar adulteração.
  4. Introduzir código para evitar o carregamento em um depurador, ou seja, permitir que o aplicativo detecte o depurador e saia / mate o depurador.
  5. Separe a autenticação como um serviço online.
  6. Use a diversidade de aplicativos
  7. Use a técnica de impressão digital para, por exemplo, assinaturas de hardware dos dispositivos de um subsistema diferente antes de autenticar o dispositivo.

Em nenhum momento da história da computação, já foi possível evitar a engenharia reversa de software quando você dá uma cópia de trabalho dele ao atacante. Além disso, na maior probabilidade, nunca será possível .

Com isso entendido, há uma solução óbvia: não dê seus segredos para o invasor. Embora você não possa proteger o conteúdo do seu APK, o que você pode proteger é algo que você não distribui. Normalmente, esse é um software do lado do servidor usado para coisas como ativação, pagamentos, imposição de regras e outros pequenos códigos. Você pode proteger ativos valiosos ao não distribuí-los no seu APK. Em vez disso, configure um servidor que responda a solicitações do seu aplicativo, "use" os ativos (o que quer que isso signifique) e, em seguida, envie o resultado de volta ao aplicativo. Se esse modelo não funcionar para os ativos que você tem em mente, convém repensar sua estratégia.

Além disso, se seu principal objetivo for evitar a pirataria de aplicativos : não se incomode. Você já gastou mais tempo e dinheiro com esse problema do que qualquer medida antipirataria poderia ter a esperança de salvá-lo. O retorno do investimento para resolver este problema é tão baixo que não faz sentido sequer pensar nisso.


Os desenvolvedores podem seguir as etapas a seguir para evitar que um APK seja roubado,

  • A maneira mais básica é usar ferramentas como o ProGuard para ofuscar seu código, mas até agora, tem sido muito difícil impedir completamente que alguém descompile um aplicativo.

  • Também ouvi falar de uma ferramenta HoseDex2Jar . Ele pára Dex2Jar inserindo código inofensivo em um APK Android que confunde e desativa Dex2Jar e protege o código de descompilação. De alguma forma, isso poderia impedir que os hackers descompilassem um APK em código java legível.

  • Use algum aplicativo do lado do servidor para se comunicar com o aplicativo somente quando for necessário. Isso poderia ajudar a evitar os dados importantes.

Em tudo, você não pode proteger completamente o seu código contra os hackers em potencial. De alguma forma, você pode tornar difícil e um pouco frustrante a tarefa de descompilar seu código. Uma das maneiras mais eficientes é escrever em código nativo (C / C ++) e armazená-lo como bibliotecas compiladas.


Seu cliente deve contratar alguém que saiba o que está fazendo, que possa tomar as decisões certas e que possa orientá-lo.

Falar acima sobre você ter alguma capacidade de alterar o sistema de processamento de transações no back-end é um absurdo - você não deve ter permissão para fazer essas alterações de arquitetura, portanto, não espere poder fazê-lo.

Minha justificativa sobre isso:

Como o seu domínio é o processamento de pagamentos, é seguro assumir que o PCI DSS e / ou PA DSS (e as leis estaduais / federais em potencial) serão significativos para o seu negócio - para estar em conformidade, você deve mostrar que está seguro. Para ser inseguro, descubra (por meio de testes) que você não está seguro, consertando, testando novamente, etc., até que a segurança possa ser verificada em um nível adequado = caminho caro, lento e de alto risco para o sucesso. Para fazer a coisa certa, pense bem de antemão, comprometa o talento experiente no trabalho, desenvolva-se de maneira segura, teste, conserte (menos), etc. (menos) até que a segurança possa ser verificada em um nível adequado = barato, rápido, caminho de baixo risco para o sucesso.


APK esquema de assinatura v2 no Android N

A classe PackageManager agora suporta a verificação de aplicativos usando o esquema de assinatura do APK v2. O esquema de assinatura v2 do APK é um esquema de assinatura de todo o arquivo que melhora significativamente a velocidade de verificação e fortalece as garantias de integridade, detectando alterações não autorizadas nos arquivos APK.

Para manter a compatibilidade com versões anteriores, um APK deve ser assinado com o esquema de assinatura v1 (esquema de assinatura JAR) antes de ser assinado com o esquema de assinatura v2. Com o esquema de assinatura v2, a verificação falhará se você assinar o APK com um certificado adicional após assinar com o esquema v2.

O suporte ao esquema de assinatura v2 do APK estará disponível posteriormente no N Developer Preview.

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


Apenas uma adição às já boas respostas acima.

Outro truque que eu sei é armazenar códigos valiosos como biblioteca Java. Em seguida, defina essa biblioteca para ser seu projeto Android. Seria bom como arquivo C .so, mas Android Lib faria.

Dessa forma, esses códigos valiosos armazenados na Biblioteca do Android não serão visíveis após a descompilação.


Como alguém que trabalhou extensivamente em plataformas de pagamento, incluindo um aplicativo de pagamentos móveis (MyCheck), eu diria que você precisa delegar esse comportamento para o servidor, nenhum nome de usuário ou senha para o processador de pagamento (o que for) deve ser armazenado ou codificado no aplicativo móvel, essa é a última coisa que você deseja, porque a origem pode ser entendida mesmo quando você ofusca o código.

Além disso, você não deve armazenar cartões de crédito ou fichas de pagamento no aplicativo, tudo deve ser, novamente, delegado a um serviço que você criou, ele também permitirá que você seja compatível com PCI mais facilmente e as empresas de cartão de crédito ganhas não respire o seu pescoço (como eles fizeram por nós).


Basicamente não é possível. Isso nunca será possível. No entanto, há esperança. Você pode usar um obfuscation para fazer com que alguns ataques comuns sejam muito mais difíceis de realizar, incluindo coisas como:

  1. Renomeando métodos / classes (assim, no decompiler você obtém tipos como aa)
  2. Ofuscando o fluxo de controle (assim, no decompiler, o código é muito difícil de ler)
  3. Criptografar seqüências de caracteres e possivelmente recursos

Tenho certeza de que existem outros, mas são os principais. Eu trabalho para uma empresa chamada PreEmptive Solutions em um obfuscator .NET . Eles também têm um obfuscator Java que funciona para o Android, bem como um chamado DashO .

A ofuscação sempre vem com um preço, no entanto. Notavelmente, o desempenho é geralmente pior, e requer algum tempo extra em torno de lançamentos normalmente. No entanto, se a sua propriedade intelectual é extremamente importante para você, então geralmente vale a pena.

Caso contrário, sua única opção é fazer com que seu aplicativo Android passe apenas para um servidor que hospede toda a lógica real de seu aplicativo. Isso tem sua própria parcela de problemas, porque significa que os usuários devem estar conectados à Internet para usar seu aplicativo.

Além disso, não é apenas o Android que tem esse problema. É um problema em todas as lojas de aplicativos. É apenas uma questão de como é difícil chegar ao arquivo do pacote (por exemplo, não acredito que seja muito fácil em iPhones, mas ainda é possível).


Concordou com @Muhammad Saqib aqui: https://.com/a/46183706/2496464

E o @Mumair oferece boas etapas iniciais: https://.com/a/35411378/474330

É sempre seguro assumir que tudo que você distribui para o dispositivo do usuário pertence ao usuário. Claro e simples. Você pode usar as ferramentas e procedimentos mais recentes para criptografar suas propriedades intelectuais, mas não há como impedir que uma determinada pessoa "estude" seu sistema. E mesmo que a tecnologia atual possa dificultar o acesso indesejado, pode haver um caminho fácil amanhã, ou até mesmo na próxima hora!

Assim, aqui vem a equação:

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

Mesmo tão simples quanto uma economia no jogo. (Especialmente em jogos! Há mais usuários 'sofisticados' lá e brechas espalhadas em segundos!)

Como nos mantemos seguros?

A maioria, se não todos, dos nossos principais sistemas de processamento (e banco de dados, é claro) localizados no lado do servidor. E entre o cliente e o servidor, estão as comunicações criptografadas, as validações, etc. Essa é a ideia do thin client.


Eu posso ver essa boa resposta neste segmento. Além de você pode usar o Facebook redexpara otimizar o código. O Redex trabalha em .dexnível onde o proguard funciona como .classnível.



Não são os chips TPM (Trusted Platform Module) que devem gerenciar código protegido para você? Eles estão se tornando comuns em PCs (especialmente os da Apple) e podem já existir nos chips de smartphones atuais. Infelizmente, não há API do sistema operacional para fazer uso dele ainda. Espero que o Android adicione suporte para este dia. Essa também é a chave para limpar o DRM de conteúdo (no qual o Google está trabalhando para o WebM).


Se o seu aplicativo for tão sensível, você deve considerar a parte de processamento de pagamento no lado do servidor. Tente alterar seus algoritmos de processamento de pagamento. Use o aplicativo Android apenas para coletar e exibir informações do usuário (ou seja, saldo da conta) e, em vez de processar pagamentos em códigos Java, envie essa tarefa para o servidor usando um protocolo SSL seguro com parâmetros criptografados. Crie uma API totalmente criptografada e segura para se comunicar com seu servidor.

Claro, ele também pode ser hackeado e não tem nada a ver com a proteção de códigos-fonte, mas considera-o uma outra camada de segurança para tornar mais difícil para os hackers enganarem seu aplicativo.





reverse-engineering