ASCII para texto

Receber uma sequência de números e precisar saber o que ela diz é uma situação mais comum do que parece. No BASIC clássico dos anos 1970 e 1980, armazenar strings em jogos ou programas educativos como arrays de inteiros em linhas `DATA` era uma técnica popular tanto por compactação quanto por ofuscação leve — afinal, `72 101 108 108 111` parecia mais opaco do que a string `Hello` escrita em texto simples. Protocolos de rede como SMTP e muitos sistemas de instrumentação industrial transmitem payloads onde o que chega ao debugger é uma sequência de inteiros decimais representando os bytes da mensagem. Logs de sistemas embarcados com frequência exibem caracteres como seus valores numéricos quando o driver de display não está disponível.

A conversão é direta: cada número decimal corresponde a um code point Unicode, e para os 128 primeiros valores (0 a 127) isso é idêntico à tabela ASCII original de 1963. O caractere `A` é o 65, `z` é o 122, o espaço é o 32, a quebra de linha é o 10. Para valores acima de 127, a ferramenta interpreta como code points Unicode e entrega o caractere correspondente — o que funciona corretamente para a maioria dos caracteres latinos com diacríticos. Vale lembrar que essa representação decimal de code points é diferente dos bytes UTF-8: `é` tem code point 233, mas em UTF-8 ocupa os bytes C3 A9 (195 e 169 em decimal).

O uso mais curioso dessa conversão é no contexto de ofuscação de código. Há anos, scripts JavaScript que queriam escapar de filtros de palavras-chave usavam `String.fromCharCode(101,118,97,108)` para construir a palavra `eval` em tempo de execução sem que ela aparecesse no código-fonte como texto legível. Ferramentas de análise estática que procuravam pela string `eval` nos scripts passavam direto. Hoje isso é um padrão de detecção bem conhecido, mas ainda aparece em payloads de injeção web. No lado mais inocente, é uma ferramenta essencial em CTF: quando você encontra uma série de números separados por espaços ou vírgulas em uma página suspeita, converter para texto costuma ser o primeiro passo para revelar a flag escondida.

Receiving a sequence of numbers and needing to know what they say is more common than it seems. In classic BASIC from the 1970s and 80s, storing strings in games or educational programs as integer arrays in `DATA` lines was a popular technique for both compaction and light obfuscation — after all, `72 101 108 108 111` looked more opaque than the string `Hello` written in plain text. Network protocols such as SMTP and many industrial instrumentation systems transmit payloads where what arrives in the debugger is a sequence of decimal integers representing the message bytes. Embedded system logs frequently display characters as their numeric values when the display driver is unavailable.

The conversion is straightforward: each decimal number maps to a Unicode code point, and for the first 128 values (0 to 127) this is identical to the original 1963 ASCII table. The character `A` is 65, `z` is 122, space is 32, line feed is 10. For values above 127, the tool interprets them as Unicode code points and delivers the matching character — which works correctly for most Latin characters with diacritics. Note that this decimal code point representation is different from UTF-8 bytes: `é` has code point 233, but in UTF-8 it occupies bytes C3 A9 (195 and 169 in decimal).

The most interesting use of this conversion is in the context of code obfuscation. For years, JavaScript scripts that wanted to evade keyword filters used `String.fromCharCode(101,118,97,108)` to construct the word `eval` at runtime without it appearing in the source as readable text. Static analysis tools scanning scripts for the string `eval` would pass right over it. Today this is a well-known detection pattern, but it still appears in web injection payloads. On the more innocent side, it is an essential tool in CTF challenges: when you find a series of space- or comma-separated numbers on a suspicious page, converting to text is usually the first step to reveal the hidden flag.

Recibir una secuencia de números y necesitar saber qué dice es una situación más común de lo que parece. En el BASIC clásico de los años setenta y ochenta, almacenar cadenas en juegos o programas educativos como arrays de enteros en líneas `DATA` era una técnica popular tanto por compactación como por ofuscación leve — al fin y al cabo, `72 101 108 108 111` parecía más opaco que la cadena `Hello` escrita en texto simple. Los protocolos de red como SMTP y muchos sistemas de instrumentación industrial transmiten payloads en los que lo que llega al depurador es una secuencia de enteros decimales que representan los bytes del mensaje. Los registros de sistemas embebidos muestran con frecuencia los caracteres como sus valores numéricos cuando el driver de visualización no está disponible.

La conversión es directa: cada número decimal corresponde a un code point Unicode y, para los primeros 128 valores (de 0 a 127), esto es idéntico a la tabla ASCII original de 1963. El carácter `A` es el 65, la `z` es el 122, el espacio es el 32 y el salto de línea es el 10. Para valores superiores a 127, la herramienta los interpreta como code points Unicode y devuelve el carácter correspondiente, lo que funciona correctamente para la mayoría de los caracteres latinos con diacríticos. Cabe recordar que esta representación decimal de code points es diferente de los bytes UTF-8: `é` tiene el code point 233, pero en UTF-8 ocupa los bytes C3 A9 (195 y 169 en decimal).

El uso más curioso de esta conversión es en el contexto de la ofuscación de código. Durante años, los scripts de JavaScript que querían evadir filtros de palabras clave usaban `String.fromCharCode(101,118,97,108)` para construir la palabra `eval` en tiempo de ejecución sin que apareciera en el código fuente como texto legible. Las herramientas de análisis estático que buscaban la cadena `eval` en los scripts la pasaban por alto. Hoy es un patrón de detección bien conocido, pero todavía aparece en payloads de inyección web. En el lado más inocente, es una herramienta esencial en los CTF: cuando encuentras una serie de números separados por espacios o comas en una página sospechosa, convertirlos a texto suele ser el primer paso para revelar la flag oculta.