Buckminster
(usa Debian)
Enviado em 31/05/2024 - 18:44h
01111111 = DELETE
01000101 = E
01001100 = L
01000110 = F
00000010 = STX (Start of Text, Começo de Texto)
00000001 = SOH (Start of Header, Começo de Cabeçalho)
00000001 = SOH (Start of Header, Começo de Cabeçalho)
00001001 = HT (Tabulação Horizontal)
00000000 = NUL
00000000 = NUL
00000000 = NUL
00000000 = NUL
00000000 = NUL
00000000 = NUL
00000000 = NUL
00000000 = NUL
00000010 = STX (Start of Text, Começo de Texto)
00000000 = NUL
00111110 = > (Sinal de Maior)
00000000 = NUL
00000001 = SOH (Start of Header, Começo de Cabeçalho)
00000000 = NUL
00000000 = NUL
00000000 = NUL
11100000 = à (a minúsculo craseado)
00010101 = NAK (Negativa de Confirmação)
Veja a Tabela ASCII no link abaixo:
https://www.ime.usp.br/~kellyrb/mac2166_2015/tabela_ascii.html
ou aqui
https://theasciicode.com.ar/ascii-control-characters/nak-negative-acknowledge-ascii-code-21.html#goo...
ou aqui
https://www.dm.ufscar.br/profs/caetano/iae2004/G8/tabelaascii.htm
No caso do à (a minúsculo craseado) ali você deve levar em consideração que utilizei um conversor de binário e todo conversor binário online converte para HTML, para os outros utilizei a Tabela ASCII.
O texto escrito em si não tem muita importância, neste caso.
00000000 = NUL, 00000000 é igual a nulo e nulo representa zero e geralmente é utilizado para marcar o final de uma string (um texto).
Veja bem, NUL não é a mesma coisa que NULL, acredito que tu saiba disso.
Por exemplo, em C, numa string terminada com o caractere NUL ('\0') podemos logo após inicializar a variável de ponteiro NULL quando a declaramos.
Um byte nulo geralmente indica o fim da string bem como o fim da cadeia de caracteres que a string representa.
Por exemplo, em relação ao "à" temos um byte adicional em UTF-8 porque a tabela ASCII não tem sinais diacríticos, no caso, a crase. Veja outro exemplo: a string (cadeia de caracteres) "ação" ocupa 6 bytes pois "ç" e "ã" ocupam 2 bytes cada na codificação UTF-8.
A tabela ASCII traz somente um byte por caractere, depois foi criado o UTF-8, além de outros.
O valor 0 para NUL foi escolhido, entre outras coisas, porque nunca lhe foi atribuída uma letra na Tabela ASCII, então, NUL é, grosso modo, nada, nem espaço vazio é, ou seja, mais precisamente, onde tem NUL tem nada magnetizado por isso na conversão para binário aparece um quadrado ou um símbolo estranho (quadrado com um x no meio, etc) que não faz parte da Tabela ASCII porque o conversor dará um valor por aproximação.
No caso dos teus binários acima, é o início de um arquivo ELF onde começamos a, obviamente, deletar tudo que tem anteriormente para depois informar que é um ELF (veja a tabela ASCII -
https://www.ime.usp.br/~kellyrb/mac2166_2015/tabela_ascii.html com os caracteres de controle).
Caso você utilizar um conversor binário online e tentar converter 01111111 (DELETE) não aparecerá nada, pois o conversor para HTML não entende.
Para 00000010 (STX) aparecerá um quadrado pelo mesmo motivo.
Lembrando que, antes, o conversor poderá converter para hexadecimal, tem isso também.
Caso for um binário empacotado não somente ofusca o conteúdo do binário original (que pode ou não ser malicioso), mas também pode confundir soluções antivírus (AVs), já que estas frequentemente comparam o hash dos arquivos suspeitos contra bases de hashes de binários conhecidos.
De qualquer maneira, não tente ler em linguagem humana gramatical, pois ali não tem texto nenhum, tenha em mente que você deve interpretar em linguagem de programação.
E você tem de levar em conta se o offset (deslocamento) é 32 ou 64 bits, tem isso também.
Acredito que o binário em questão é 32 bits, pois você postou 26 bytes o que dá metade de 52 bytes que é o tamanho de um cabeçalho ELF de 32 bits (64 bits tem cabeçalho de 64 bytes), mas posso estar errado, pois geralmente no cabeçalho tem em primeiro lugar dois bytes (em sistemas UNIX e Linux) que definem o "número mágico". O número mágico nada mais é do que uma constante com um propósito como, por exemplo, dizer o tipo do conteúdo do arquivo (se é texto, imagens, texto com imagens, etc).
Porém, geralmente os arquivos ELF para sistemas Linux usam o próprio conteúdo do arquivo para determinar o tipo, por isso pode estar faltando o "número mágico" ou você deixou uma parte fora ou não é Linux.
Outra coisa que geralmente tem também no cabeçalho ELF logo após o tal "número mágico" é o número 1 ou 2 em byte. Este byte é definido em 1 ou 2 para significar os formatos de 32 (x86) ou 64 bits, respectivamente, no arquivo ELF, porém, isso não é uma regra rígida e cada programador pode descartar, principalmente se estiver fazendo um arquivo malicioso.
Você pode usar um Disassembler, um Disassembler mantém uma estrutura de dados que descreve cada byte da seção .text, denominados offsets. A cada offset é associado um mapa de bits e um valor inteiro de 8 bytes utilizado durante a etapa dinâmica para armazenar o número de vezes que a instrução/bloco básico que inicia se naquele byte foi executado.
Lembrando que um arquivo ELF pode ser basicamente de 3 tipos: realocável, objeto compartilhado ou executável.
Vamos ao que interessa!
Esta parte final:
00000010 = STX (Start of Text, Começo de Texto)
00000000 = NUL
00111110 = > (Sinal de Maior)
00000000 = NUL
00000001 = SOH (Start of Header, Começo de Cabeçalho)
00000000 = NUL
00000000 = NUL
00000000 = NUL
11100000 = à (a minúsculo craseado)
00010101 = NAK (Negativa de Confirmação)
é início de texto com nul > nul, início de cabeçalho seguido de três bytes nulos, com "à" seguido de negativa de confirmação.
Lembrando que temos ACK (ACKnowledge - Confirmação) e NAK (Negative-AcKnowledge - Negativa de Confirmação), sim, é parecido com o ACK do "aperto de mão" (handshake) em redes. No caso tem somente a negativa NAK que significa um caractere de controle de transmissão transmitido por um receptor como uma resposta negativa ao remetente, ou seja, você espera uma resposta negativa e depois viria um if, else ou algo parecido.
Posso dizer que, em linguagem de programação, o programador ali quis informar que o começo do texto é maior do que o começo do cabeçalho, porém, isso não faz sentido porque geralmente o SOH vem antes de STX.
Aquele "à" não sei informar exatamente o significado, teria de ter mais coisas após para poder interpretar.
Pode ser que tu copiou e colou os "zeros e uns" quebrando uma sequência de caracteres, tem isso também, daí pode resultar que minha interpretação está toda errada.
Como o número de bytes por caractere não é fixo, a decodificação de uma sequência de bytes não é fácil. Como saber onde termina o código de um caractere e começa o código do caractere seguinte?
Aqui tem uma Tabela ASCII mais completa:
https://repositorio.ufu.br/bitstream/123456789/14443/4/SFOLima4DISSPRT.pdf
_________________________________________________________
Always listen the Buck!
Enquanto o cursor estiver pulsando, há vida!
