Como evitar a engenharia reversa de um arquivo APK?

Questões sobre segurança no desenvolvimento de software, ambiente de desenvolvimento, normas, técnicas e ferramentas disponíveis.
BB96
Posts: 18
Joined: 09 Dec 2014 12:45

Como evitar a engenharia reversa de um arquivo APK?

Post by BB96 » 09 Dec 2014 21:59

Estou desenvolvendo um aplicativo de processamento de pagamentos para o Android, e eu quero evitar que um hacker acesse qualquer código de recursos, bens ou de origem do arquivo APK. Se alguém altera a extensão .apk para .zip, então eles podem descompactá-lo e acessar facilmente todos os recursos do aplicativo e ativos, e usando dex2jar e um decompiler Java, eles também podem acessar o código fonte. É muito fácil de fazer engenharia reversa de um arquivo APK Android - Para mais detalhes veja Safeval.Guru questão engenharia reversa de um arquivo APK para um projeto. Eu tenho usado a ferramenta Proguard fornecido com o SDK do Android. Quando eu fazer engenharia reversa de um arquivo APK gerados usando um armazenamento de chaves assinado e Proguard, recebo código ofuscado. No entanto, os nomes dos componentes Android permanecem inalteradas e algum código, como valores-chave utilizados no app, permanece inalterada. Conforme documentação Proguard a ferramenta não pode ofuscar componentes mencionados no arquivo de manifesto. Agora minhas perguntas são: Como posso evitar completamente a engenharia reversa de um APK Android? Isso é possível? Como posso proteger todos os recursos do aplicativo, ativos e código-fonte para que hackers não pode cortar o arquivo APK de alguma forma? Existe uma maneira de fazer pirataria mais difícil ou até mesmo impossível? O que mais posso fazer para proteger o código fonte no meu arquivo APK?

Alexandre Medeiros
Posts: 27
Joined: 02 Dec 2014 17:38

Re: Como evitar a engenharia reversa de um arquivo APK?

Post by Alexandre Medeiros » 09 Dec 2014 22:00

& Nbsp; 1. Como posso evitar completamente a engenharia reversa de um APK Android? Isso é possível? AFAIK, não há nenhum truque para evitar completa de engenharia reversa. E também é muito bem dito porinazaruk: Faça o que fizer ao seu código, um potencial invasor é capaz de mudá-lo de qualquer forma que ela ou ele acha viável. Você basicamente não pode proteger a sua aplicação seja modificado. E qualquer proteção que você colocar lá pode ser desativado / removido. & Nbsp; 2. Como posso proteger todos os recursos do aplicativo, ativos e código-fonte para que hackers não pode cortar o arquivo APK de alguma forma? Você pode fazer diversos truques para tornar mais difícil cortar embora. Por exemplo, usar ofuscação (se é código Java). Isso geralmente diminui significativamente engenharia inversa. & Nbsp; 3. Existe uma maneira de fazer pirataria mais difícil ou até mesmo impossível? O que mais posso fazer para proteger o código fonte no meu arquivo APK? Como toda a gente diz, e como você provavelmente sabe, não há 100% de segurança. Mas o ponto de partida para o Android, que o Google tem embutido, é ProGuard. Se você tem a opção de incluir as bibliotecas compartilhadas, você pode incluir o código necessário em C ++ para verificar tamanhos de arquivos, integração, etc. Se você precisa adicionar uma biblioteca nativa externa a pasta da biblioteca do seu APK em cada compilação, então você pode usá-lo pela sugestão abaixo. Coloque a biblioteca no caminho da biblioteca nativa que tem como padrão "libs" na pasta do projeto. Se você criou o código nativo para o alvo dos armeabi ', em seguida, colocá-lo sob libs / armeabi. Se ele foi construído com armeabi-v7a depois colocá-lo sob libs / armeabi-v7a. & Lt; projeto & gt; /libs/armeabi/libstuff.so

Márcio Rossi
Posts: 21
Joined: 09 Dec 2014 12:21

Re: Como evitar a engenharia reversa de um arquivo APK?

Post by Márcio Rossi » 09 Dec 2014 22:00

AFAIK, você não pode proteger os arquivos no diretório / res mais do que eles são protegidos agora. No entanto, existem passos que você pode tomar para proteger seu código-fonte, ou pelo menos o que ele faz, se não tudo. Use ferramentas como ProGuard. Estes irão ofuscar o seu código, e torná-lo mais difícil de ler quando compilado, se não impossível. Mova as partes mais críticas do serviço fora do app, e em um webservice, escondido atrás de uma linguagem do lado do servidor, como PHP. Por exemplo, se você tem um algoritmo que é tomado um milhão de dólares para escrever. Você obviamente não quero que as pessoas roubando-lo do seu app. Mova o algoritmo e tê-lo processar os dados em um servidor remoto, e usar o aplicativo para simplesmente fornecer-lhe os dados. Ou use o NDK para escrevê-los de forma nativa em arquivos .so, que são muito menos propensos a ser compilado do que apks. Eu não acho que um decompiler para arquivos .so ainda existe a partir de agora (e mesmo que o fizesse, não seria tão bom quanto os decompilers Java). Além disso, comonikolay mencionado nos comentários, você deve usar SSL quando interagem entre o servidor eo dispositivo. Ao armazenar valores no dispositivo, não armazená-los em um formato raw. Por exemplo, se você tem um jogo, e você está armazenando a quantidade de moeda no jogo o usuário tem em SharedPreferences. Vamos supor que é 10 mil moedas. Em vez de salvar 10000 diretamente, salve-o usando um algoritmo como ((moeda * 2) +1) / 13. Então, em vez de 10 mil, você economiza 1538,53846154 nas SharedPreferences. No entanto, o exemplo acima não é perfeito, e você vai ter que trabalhar para chegar a uma equação que não vai perder a moeda a erros de arredondamento, etc Você pode fazer uma coisa semelhante para as tarefas do lado do servidor. Agora, para um exemplo, vamos realmente ter seu aplicativo de processamento de pagamentos. Digamos que o usuário tem que fazer um pagamento de US $ 200. Em vez de enviar um $ 200 valor bruto para o servidor, enviar uma série de menores, pré-definidos, valores que somam US $ 200. Por exemplo, tem um arquivo ou uma mesa em seu servidor que equivale palavras com valores. Então, vamos dizer que Charlie corresponde a US $ 47, e John a US $ 3. Então, ao invés de enviar US $ 200, você pode enviar Charlie quatro vezes e John quatro vezes. No servidor, interpretar o que eles significam e adicioná-lo para cima. Isso impede que um hacker de mandar valores arbitrários para o servidor, como eles não sabem o que a palavra corresponde ao que valor. Como medida adicional de segurança, você pode ter uma equação semelhante ao ponto 3, para isso também, e alterar as palavras-chave a cada n número de dias. Finalmente, você pode inserir aleatória código fonte inútil em seu aplicativo, de modo que o hacker está à procura de uma agulha num palheiro. Insira aulas aleatórias contendo trechos da internet, ou apenas funções para calcular coisas aleatórias como a seqüência de Fibonacci. Certifique-se que essas classes compilar, mas não são utilizados pela funcionalidade real do app. Adicionar o suficiente desses falsos aulas, e o hacker teria um tempo difícil encontrar seu código real. Em suma, não há nenhuma maneira de proteger seu aplicativo 100%. Você pode tornar mais difícil, mas não impossível. O seu servidor web pode ser comprometida, o hacker poderia descobrir suas palavras-chave, monitorando vários valores das transações, e as palavras-chave que você envia para ele, o hacker poderia meticulosamente passar pela fonte e descobrir qual o código é um manequim. Você só pode lutar para trás, mas nunca ganham.

Ethan Morton
Posts: 28
Joined: 09 Dec 2014 12:21

Re: Como evitar a engenharia reversa de um arquivo APK?

Post by Ethan Morton » 09 Dec 2014 22:00

Primeira regra de segurança app: Qualquer máquina para que um atacante ganha acesso físico ou electrónico irrestrito agora pertence a seu atacante, independentemente de onde ele realmente é ou o que você pagou por ele. Segunda regra de segurança app: Qualquer software que deixa os limites físicos no interior do qual um atacante não pode penetrar agora pertence a seu atacante, independentemente da quantidade de tempo que você gastou codificá-lo. Terceira regra: Qualquer informação que deixa esses mesmos limites físicos que um atacante não pode penetrar agora pertence a seu atacante, não importa o quão valioso é para você. As bases da segurança de tecnologia da informação são baseados nestes três princípios fundamentais; o computador apenas verdadeiramente seguro é aquele trancada em um cofre, dentro de uma gaiola Farraday, dentro de uma gaiola de aço. Há computadores que passam a maior parte de suas vidas em serviço apenas neste estado; uma vez por ano (ou menos), eles geram as chaves privadas para autoridades de certificação raiz confiáveis ​​(em frente de uma multidão de testemunhas com câmeras registrando cada centímetro da sala em que eles estão localizados). Agora, a maioria dos computadores não são utilizados sob esses tipos de ambientes; eles estão fisicamente em campo aberto, conectado à Internet através de um canal de rádio sem fio. Em suma, eles são vulneráveis, como é o seu software. Eles são, portanto, não é confiável. Há certas coisas que os computadores e seu software deve saber ou fazer, a fim de ser útil, mas é preciso ter cuidado para garantir que eles nunca podem saber ou fazer o suficiente para causar danos (pelo menos não um dano permanente fora dos limites do que única máquina ). Você já sabia de tudo isso; é por isso que você está tentando proteger o código de sua aplicação. Mas, é aí que reside o primeiro problema; ferramentas de obscurecimento pode tornar o código uma bagunça para um ser humano para tentar cavar através de, mas o programa ainda tem de correr; isso significa que o fluxo de lógica real do app e os dados que ele usa não são afetados por ofuscação. Dado um pouco de tenacidade, um atacante pode simplesmente un-ofuscar o código, e que não é nem mesmo necessário, em certos casos em que o que ele está olhando não pode ser outra coisa, mas o que ele está procurando. Em vez disso, você deve estar tentando assegurar que um atacante não pode fazer qualquer coisa com o seu código, não importa o quão fácil é para ele para obter uma cópia clara do mesmo. Isso significa que, sem segredos codificados, porque esses segredos não são segredo, assim que o código sai do prédio em que você desenvolveu. Estes valores-chave que você tenha-codificados devem ser retirados a partir do código-fonte do aplicativo inteiramente. Em vez disso, eles devem estar em um dos três locais; memória volátil no dispositivo, o que é mais difícil (mas ainda não impossível) para um atacante para obter uma cópia offline; permanentemente no cluster de servidor, para que você controlar o acesso com um punho de ferro; ou em um segundo armazenamento de dados não relacionados ao seu dispositivo ou servidores, como um cartão físico ou nas memórias do seu usuário (o que significa que acabará por ser na memória volátil, mas não tem de ser por muito tempo). Considere o seguinte esquema. O usuário digita suas credenciais para o aplicativo da memória no dispositivo. Você deve, infelizmente, confiamos que o dispositivo do usuário não estiver comprometida por um keylogger ou Trojan; o melhor que você pode fazer a este respeito é para implementar a segurança multi-fator, lembrando-se de difícil identificação falso informações sobre os dispositivos que o usuário tenha usado (MAC / IP, IMEI, etc), e fornecer pelo menos um canal adicional por que pode ser verificado uma tentativa de login em um dispositivo desconhecido. As credenciais, uma vez que entrou, foram ofuscados pelo software do cliente (usando um hash seguro), e as credenciais de texto simples descartados; elas têm servido o seu propósito. As credenciais ofuscado são enviados através de um canal seguro para o servidor de autenticação de certificado, o que os hashes novamente para produzir os dados usados ​​para verificar a validade do login. Dessa forma, o cliente nunca sabe o que está realmente em comparação com o valor base de dados, o servidor app nunca sabe as credenciais em texto puro por trás do que ele recebe para validação, o servidor de dados nunca sabe como os dados que armazena para validação é produzido, e um homem de meio vê apenas rabiscos, mesmo que o canal seguro foram comprometidos. Uma vez verificado, o servidor transmite de volta um token sobre o canal. O token é útil apenas dentro da sessão segura, é composto por um ou outro ruído aleatório ou uma cópia criptografada (e, portanto, passível de verificação) dos identificadores de sessão, bem como a aplicação cliente deve enviar este token no mesmo canal para o servidor como parte de qualquer pedido fazer alguma coisa. O aplicativo cliente vai fazer isso muitas vezes, porque ele não pode fazer qualquer coisa que envolva dinheiro, os dados sensíveis, ou qualquer outra coisa que poderia ser prejudicial, por si só; deve, em vez pedir ao servidor para fazer esta tarefa. A aplicação cliente nunca vai escrever qualquer informação sensível para a memória persistente no próprio dispositivo, pelo menos não em texto simples; o cliente pode pedir ao servidor através do canal seguro para uma chave simétrica para criptografar todos os dados locais, que o servidor vai se lembrar; numa sessão posterior, o cliente pode pedir que o servidor para a mesma chave para desencriptar os dados para uso na memória volátil. Esses dados não será a única cópia, qualquer um; Qualquer coisa que o cliente armazena também deve ser transmitida de alguma forma para o servidor. Obviamente, isso torna a sua aplicação fortemente dependente do acesso à Internet; o dispositivo cliente não pode executar qualquer uma de suas funções básicas, sem conexão adequada para e autenticação pelo servidor. Não é diferente do que o Facebook, realmente. Agora, o computador que o atacante quer é o seu servidor, porque ele e não o cliente app / dispositivo é a coisa que pode fazer-lhe dinheiro ou fazer com que outras pessoas da dor para seu prazer. Isso está ok; você recebe muito mais estrondo para seu fanfarrão gastar dinheiro e esforço para proteger o servidor do que em tentar assegurar a todos os clientes. O servidor pode estar por trás de todos os tipos de firewalls e outros segurança eletrônica, e, adicionalmente, pode ser fisicamente seguro por trás de aço, concreto, abre com acesso / pin, e vigilância de vídeo de 24 horas. Seu invasor precisa ser muito sofisticado, de fato para ganhar qualquer tipo de acesso ao servidor diretamente, e você (deveria) saber sobre isso imediatamente. O melhor que um invasor pode fazer é roubar telefone de um usuário e as credenciais e logar-se ao servidor com direitos limitados do cliente. Caso isto aconteça, assim como a perda de um cartão de crédito, o usuário legítimo devem ser instruídos a ligar para um número 800 (de preferência fácil de lembrar, e não no verso de um cartão que eles carregam em sua bolsa, carteira ou pasta que poderia ser roubado juntamente com o dispositivo móvel) a partir de qualquer telefone que eles podem acessar que conecta-los diretamente para o seu serviço ao cliente. Afirmam seu celular foi roubado, fornecer algum identificador único de base, e a conta é bloqueada, quaisquer transações que o atacante pode ter sido capaz de processar serão revertidas, e que o atacante está de volta à estaca zero.

Otávio Cardoso
Posts: 19
Joined: 08 Dec 2014 18:06

Re: Como evitar a engenharia reversa de um arquivo APK?

Post by Otávio Cardoso » 09 Dec 2014 22:00

100% prevenção de engenharia reversa do APK Android não é possível, mas você pode usar esses meios para evitar a extração de mais dados, como o código-fonte, os ativos formar seus APK e recursos: Use ProGuard para ofuscar o código do aplicativo Use NDK usando C e C ++ para colocar o seu núcleo de aplicação e parte segura de código em arquivos .so Para garantir os recursos, não incluem todos os recursos importantes na pasta de ativos com APK. Faça o download desses recursos no momento da aplicação iniciar pela primeira vez.

Rodrigo Costa
Posts: 19
Joined: 04 Dec 2014 13:26

Re: Como evitar a engenharia reversa de um arquivo APK?

Post by Rodrigo Costa » 09 Dec 2014 22:01

& Nbsp; 1. Como posso evitar completamente a engenharia reversa de um APK Android? Isso é possível? Isso é impossível & nbsp; 2. Como posso proteger todos os recursos do aplicativo, ativos e código-fonte para que hackers não pode cortar o arquivo APK de alguma forma? Os desenvolvedores podem tomar medidas como o uso de ferramentas como ProGuard para ofuscar o seu código, mas, até agora, tem sido muito difícil de evitar completamente alguém de decompiling um app. É uma ferramenta realmente grande e pode aumentar a dificuldade de "reverter" o seu código, enquanto a diminuir a pegada do seu código. Integrado ProGuard apoio: ProGuard agora é empacotado com as ferramentas do SDK. Agora os desenvolvedores podem ofuscar o seu código como parte integrante de uma compilação de lançamento. & Nbsp; 3. Existe uma maneira de fazer pirataria mais difícil ou até mesmo impossível? O que mais posso fazer para proteger o código fonte no meu arquivo APK? Ao pesquisar, eu vim a saber sobre HoseDex2Jar. Esta ferramenta irá proteger o seu código de decompiling, mas não parece ser possível para proteger o seu código completamente. Alguns dos links úteis, você pode se referir a eles. Proguard, Android, e Licenciamento do Servidor Protegendo Android LVL Applications Safeval.Guru questão É realmente impossível proteger os apps Android de engenharia reversa? Safeval.Guru pergunta Como evitar a engenharia reversa de um arquivo APK Android para garantir código?

Joaquín Molina
Posts: 26
Joined: 09 Dec 2014 12:20

Re: Como evitar a engenharia reversa de um arquivo APK?

Post by Joaquín Molina » 09 Dec 2014 22:01

Os desenvolvedores podem tirar seguintes passos para evitar que um APK do roubo de alguma forma, a maneira mais básica é usar ferramentas como ProGuard para ofuscar o seu código, mas, até agora, tem sido muito difícil de evitar completamente alguém de decompiling um app. Também tenho ouvido falar sobre um HoseDex2Jar ferramenta. Ele pára Dex2Jar através da inserção de código inofensivo em um APK Android que confunde e desativa Dex2Jar e protege o código da decompilation. Pode de alguma forma impedir que hackers decompiling um APK em código java legível. Use algum aplicativo do lado do servidor para se comunicar com a aplicação somente quando ela é necessária. Pode ajudar a prevenir os dados importantes. Ao todo, você não pode proteger completamente o seu código a partir dos potenciais hackers. De alguma forma, você pode torná-lo difícil e uma tarefa frustrante pouco para eles descompilar seu código. Uma das maneira mais eficiente é escrever em código nativo (C / C ++) e armazená-lo como bibliotecas compiladas.

Renata Freitas
Posts: 24
Joined: 09 Dec 2014 11:54

Re: Como evitar a engenharia reversa de um arquivo APK?

Post by Renata Freitas » 09 Dec 2014 22:01

A questão principal aqui é que pode os arquivos dex ser compilado e a resposta é que eles podem ser "espécie de". Existem disassemblers como dedexer e smali. ProGuard, devidamente configurado, vai ofuscar o seu código. DexGuard que é uma versão comercial estendido de ProGuard, pode ajudar um pouco mais. No entanto, o seu código ainda pode ser convertida em smali e desenvolvedores com experiência de engenharia reversa será capaz de descobrir o que você está fazendo do smali. Talvez escolher um bom licença e fazer cumprir a lei na melhor maneira possível.

Felipe Monteiro
Posts: 17
Joined: 02 Dec 2014 17:49

Re: Como evitar a engenharia reversa de um arquivo APK?

Post by Felipe Monteiro » 09 Dec 2014 22:01

& Nbsp; 1. Como posso evitar completamente a engenharia reversa de um APK Android? Isso é possível? Impossível & nbsp; 2. Como posso proteger todos os recursos do aplicativo, ativos e código-fonte para que hackers não pode cortar o arquivo APK de alguma forma? Impossível & nbsp; 3. Existe uma maneira de fazer pirataria mais difícil ou até mesmo impossível? O que mais posso fazer para proteger o código fonte no meu arquivo APK? Mais resistente - possível, mas na verdade ele vai ser mais difícil principalmente para o usuário médio, que está apenas pesquisando para hackear guias. Se alguém realmente quer cortar o seu app - que vai ser cortado, mais cedo ou mais tarde.

BUTTON_POST_REPLY