77
Response Message Template Format 2Response Message Template Format 2 é o irmão flexível e explicitamente marcado por tags do Response Message Template Format 1 (80, referenciado ao lado): em vez de um layout de bytes fixo AIP-depois-AFL, é um template BER-TLV construído de verdade, que pode carregar o Application Interchange Profile (82) e o Application File Locator (94) como campos explicitamente marcados, em qualquer ordem, junto com o que quer que um cartão escolha devolver - exatamente por isso é também o template que o GENERATE AC usa para devolver o Application Cryptogram (9F26) e seus companheiros, um trabalho que o formato 1 nunca foi projetado para fazer. Por quase toda tag coberta neste dicionário que aparece numa resposta de GPO ou GENERATE AC poder chegar envolvida no 77, é possivelmente o template construído mais carregado de responsabilidade em todo o fluxo de transação EMV - um bug de parsing em como um terminal percorre a estrutura TLV aninhada do 77 não corrompe um campo, potencialmente corrompe a leitura da resposta inteira pelo terminal, e é por isso que a correção do parsing do 77 é fundamental para tudo que vem depois dele. Ver EMV 4.4 Book 3.
Decodificador interativo
Cole um valor hexadecimal desta tag para decodificar no seu navegador. Nada é enviado para lugar nenhum.
Esta tag não é um bitmap; o decodificador mostra uma interpretação baseada no formato.
Exemplo decodificado
A tag 77 é o wrapper que o cartão usa para responder ao GET PROCESSING OPTIONS e ao GENERATE AC quando quer ser explícito sobre o que está devolvendo. Onde sua irmã Response Message Template Format 1 (80) empacota o Application Interchange Profile e o Application File Locator num layout fixo sem tags internas, o Formato 2 devolve um template construído cujo valor é uma sequência de objetos TLV devidamente etiquetados — e essa explicitude é o que faz dele o formato que kernels modernos e cartões multiaplicação preferem.
Lê-lo é exatamente o que o decoder desta página faz: abrir o valor como BER-TLV aninhado e listar os objetos dentro. Uma resposta típica carrega o Application Interchange Profile (82), o Application File Locator (94) e, no GENERATE AC, o Cryptogram Information Data (9F27), o Application Cryptogram (9F26) e o Application Transaction Counter (9F36). Como cada elemento é etiquetado, o terminal encontra cada um pela tag em vez de pelo offset de byte, o que é robusto contra cartões que omitem ou reordenam campos.
O motivo pelo qual isso importa é que um bug de parser aqui corrompe toda a transação seguinte. Se o terminal interpretar mal a fronteira entre dois objetos TLV dentro do 77 — lendo o comprimento errado, ou parando cedo — vai atribuir o valor errado à tag errada, e toda decisão subsequente (qual método de autenticação, quais registros ler, qual tipo de criptograma) é construída sobre dados embaralhados. O sintoma costuma ser uma cascata de erros de "campo ausente" num cartão perfeitamente conforme.
A armadilha de integração é presumir que toda resposta usa o Formato 2. O cartão escolhe entre Formato 1 (template 80) e Formato 2 (template 77) com base em suas próprias preferências, e um terminal que só trata um vai ler o outro errado. A abordagem correta é ler a tag externa da resposta e despachar: se for 77, parsear como TLV construído; se for 80, ler o layout fixo AIP-depois-AFL. Fixar um caminho é a causa mais comum de "funciona em alguns cartões, falha em outros".
Uma nuance para decoders: 77 é construído, então seu valor é a concatenação dos bytes dos objetos filhos, e parseá-lo exige um parser BER-TLV de verdade que trate tags multi-byte (9F26, 9F36), comprimentos em forma longa e templates aninhados. Um parser ingênuo que presuma tags de byte único vai ler errado todos os objetos 9Fxx dentro.
Propriedades
| Tag | 77 |
|---|---|
| Nome | Response Message Template Format 2 |
| Formato | Binário |
| Tamanho | variável |
| Origem | Cartão (ICC) |
| Templates | — |
| Livros | EMV 4.4 Book 3 |
Perguntas frequentes
- O que é a tag EMV 77?
- A tag 77 é o Response Message Template Format 2: um template BER-TLV construído que o cartão usa para encapsular suas respostas ao GET PROCESSING OPTIONS e ao GENERATE AC. Ao contrário do Formato 1 (tag 80), seu valor é uma sequência de objetos TLV explicitamente etiquetados (82, 94, 9F26, 9F27, 9F36...), então o terminal encontra cada campo pela tag em vez de pelo offset de byte.
- Qual a diferença entre a tag 77 e a tag 80?
- Ambas encapsulam respostas do cartão, mas empacotam o conteúdo de forma diferente. A tag 80 (Formato 1) usa um layout fixo onde o AIP e o AFL ficam em offsets de byte conhecidos, sem tags internas. A tag 77 (Formato 2) usa TLV construído, então todo campo dentro é explicitamente etiquetado. O cartão escolhe qual usar; o terminal precisa tratar ambos.
- Como eu parseio o conteúdo da tag 77?
- Abra o valor com um parser BER-TLV, do mesmo jeito que o decoder desta página faz. Cada filho é um objeto etiquetado — leia sua tag, comprimento e valor, e então recurse se o filho também for construído. Trate tags multi-byte (9F26, 9F36) e comprimentos em forma longa; um parser que presume tags de byte único vai ler errado todos os objetos 9Fxx dentro.
- Por que recebo erros de "campo ausente" num cartão que deveria estar conforme?
- Geralmente é um erro de fronteira na interpretação dentro do 77. Se o terminal lê um comprimento errado ou para cedo, atribui o valor errado à tag errada, e toda busca de campo seguinte falha. O cartão está fino; o parser está embaralhando as fronteiras do TLV. Teste contra um hex dump conhecido para isolar.
Fontes
- EMV_v4.4_Book_3_Application_Specification, p. 200
Receba as novidades do site
Cadastre-se para receber novidades do site direto no seu email
Não enviaremos spam. Você pode cancelar a inscrição a qualquer momento.