Decodifique o Calldata: Removendo Hex, Base64 e um XOR Repetido
O desafio
Uma longa string hexadecimal foi extraída de uma transação suspeita de contrato inteligente e marcada como 'calldata EVM' pelo indexador. Não é realmente calldata - é uma mensagem escondida sob três camadas empilhadas. Reverta-as na bancada e envie o flag oculto (HDNA{...}).
O que você vai aprender
- Reconhecer que caracteres apenas hexadecimais indicam uma camada de transporte em hex
- Remover três transformações empilhadas na ordem inversa correta
- Identificar um blob base64 dentro da camada hex pelo seu conjunto de caracteres e preenchimento
- Aplicar um XOR de chave curta repetida para recuperar o texto puro subjacente
- Descartar operações isca cujo formato de entrada não corresponde aos dados
Habilidades testadas
Pré-requisitos
- Familiaridade com leitura de hex e base64
- Entendimento de que XOR é sua própria inversa
- Noção básica de como é o calldata EVM
Como funciona
Dados on-chain são apenas bytes, e bytes são fáceis de disfarçar. Aqui alguém pegou um texto puro curto, criptografou com XOR usando uma chave repetida pequena, codificou o resultado em base64 para que sobrevivesse como texto, depois codificou essa string em hex para que passasse por calldata de transação. Calldata de verdade começa com um seletor de função de 4 bytes e é codificado em ABI; esse blob não tem nada dessa estrutura, o que é o primeiro sinal de que o rótulo 'calldata' é um disfarce.
As camadas são removidas na ordem inversa em que foram aplicadas. A camada mais externa é hex, porque todo caractere está em 0-9a-f - decodifique e você obtém uma string base64 imprimível. Decodifique essa e você fica com bytes brutos ainda ilegíveis, porque foram criptografados com XOR. XOR é simétrico: reaplicar a mesma chave com a mesma operação a cancela, já que A XOR B XOR B = A. A chave aqui é apenas os dois bytes tx, repetidos ao longo da mensagem.
A bancada modela isso como uma receita em que cada operação alimenta a próxima. Adicione From Hex, depois From Base64, depois XOR com a chave tx, e o flag aparece ao vivo na saída. As outras operações (ROT, Vigenere, atbash, reverse, URL-decode) são iscas - seus formatos de entrada nunca correspondem ao que você tem em cada etapa.
Erros comuns
- Confiar no rótulo 'calldata'. Os dados não têm estrutura ABI nem seletor de função - nunca foi calldata, apenas bytes disfarçados como tal.
- Remover as camadas na ordem errada. Tentar base64 antes do hex, ou XOR antes de qualquer decodificação, gera lixo. Camada mais externa primeiro.
- Tentar adivinhar uma chave XOR longa. A chave tem dois bytes; não faça força bruta no que o enunciado já entrega.
- Adicionar operações isca. ROT e Vigenere atuam sobre letras, não sobre bytes brutos - verifique o formato dos dados antes de adicionar uma operação.
Como se proteger
Para defensores, a lição é que embrulhar um payload em hex e base64 sobre uma chave XOR estática é ofuscação, não proteção - isso só atrasa um olhar casual, nunca um analista determinado. Trate qualquer campo que 'deveria' ser estruturado (calldata, um token, um cookie) mas não é como suspeito, e decodifique-o.
- Valide se o calldata on-chain realmente corresponde à ABI do contrato antes de confiar no rótulo.
- Decodifique automaticamente e faça varredura de XOR em blobs hex e base64 não estruturados durante a triagem para revelar mensagens ocultas.
- Use criptografia autenticada com uma chave gerenciada quando os dados precisarem ser realmente confidenciais.
- Trate qualquer XOR de chave curta repetida como totalmente recuperável, por você e por adversários igualmente.