<AlissonB> Quando estiver pronto pra começarmos, show!

<AlissonB> (acho que daqui a pouco a galera chega)

<AlissonB> De qualquer forma, eu compartilho o log inteiro depois :)

<AlissonB> Vamos ter uma introdução né, vendo Numbers and Tools (hexedit, hexdump, gdb)? :)

<[elt]eliezerb> Noite

<AlissonB> dae Eliezer

<AlissonB> só estamos esperando o Fábio voltar pra começar :)

<[elt]eliezerb> Bele

<[elt]eliezerb> To chegando no bus

<FabioOlive> opas

<AlissonB> dae FabioOlive, bora lá! :)

<FabioOlive> hehehe

<FabioOlive> então

<FabioOlive> hoje vamos falar de números, bytes, codificações e ferramentas de fuçação/escovação

<AlissonB> show :)

<FabioOlive> começando pelo básico, todos estão usando Linux, BSD ou pelo menos tem uma VM com isso?

<[elt]eliezerb> :)

<AlissonB> sim :)

<_edEr> (Y)

<FabioOlive> blz :)

<_edEr> consegui por uma máquina aqui do lado pra rodar

<FabioOlive> legal

<_edEr> mas to usando slitaz..

<_edEr> acho que vinga

<_edEr> =]

<FabioOlive> slitaz?

<_edEr> precisa do que rodando?

<AlissonB> FabioOlive é uma distribuição super-mini, uma das menores do mundo

<FabioOlive> só um terminalzinho

<_edEr> naõ tive tempo de instalar outra coisa

<FabioOlive> ahh legal

<FabioOlive> tendo um terminal de texto tá bom :)

<_edEr> ela instala em 1 min nessa máquina

<_edEr> blz

<FabioOlive> ok, começando pelo começo, a coisa mais absolutamente fundamental e básica em computadores digitais é o byte, sendo que a memória é só uma sequência finita de bytes e nada mais que isso

<FabioOlive> isso vocês sabem :)

<FabioOlive> talvez só não tenham parado pra pensar em todas as implicações disso

<AlissonB> é bom reforçar sempre os conceitos :)

<FabioOlive> vamos falar de novo: só o que existe é uma grande sequência de bytes, e NADA mais

<FabioOlive> strings, números com ponto flutuante, etc, tudo isso já é algo que não é “natural” e precisa ser codificado de alguma forma

<FabioOlive> vocês devem lembrar que um byte é um conjunto de 8 bits

<_edEr> (Y)

<[elt]eliezerb> Yep

<FabioOlive> ajzuse: beleza, estamos fazendo uma conversa sobre escovação de bits

<FabioOlive> com 8 bits conseguimos representar números de 0 a 255, que em binário vão de 00000000 a 11111111

<FabioOlive> qualquer coisa diferente disso já precisa pensar em uma forma de codificar na memória

<FabioOlive> as bases numéricas mais comuns na computação são a binária, a hexadecimal, a decimal e às vezes ainda a octal

<ajzuse> bah, esta parte de bits, bytes e enfins é mto bacana… da pra fazer muita coisa otimizada se souber trabalhar bem com eles

<FabioOlive> dependendo do tipo de informação que se está visualizando, cada base pode ser mais ou menos útil que as outras

<FabioOlive> e na verdade não tem nenhum mistério, as bases numéricas todas funcionam da mesma forma, com notação posicional como a decimal que estamos ocupados

<FabioOlive> ops, acostumados, não ocupados

<FabioOlive> hehe :D

<FabioOlive> só que algumas contam com menos dígitos e outras com mais

<[elt]eliezerb> 0 e 1

<[elt]eliezerb> 0 a 7

<[elt]eliezerb> 0 F

<[elt]eliezerb> 0 9

<FabioOlive> sim :)

<FabioOlive> da mesma forma que contamos 0 1 2 3 4 5 6 7 8 9 e aí acabam os dígitos e temos que incrementar a próxima casa, das dezenas, para 10 11 12 13 …, nas outras bases ocorre o mesmo

<FabioOlive> em binário só acontece mais rápido :)

<FabioOlive> 0 1 10 11 100 …

<FabioOlive> ou em hexadecimal acontece mais devagar, 0 1 2 3 4 5 6 7 8 9 acabam os dígitos mas se usa letras até completar os 16 dígitos, seguindo com A B C D E F

<FabioOlive> aí acabam os 16 dígitos da unidade hexadecimal e se incrementa a segunda casa, da “dezesseisena” hehehe

<FabioOlive> 10 11 12 13 … 18 19 1A 1B 1C …

<FabioOlive> então, em hexadecimal, 8 + 8 dá 10 :)

<_edEr> kkk <FabioOlive> e aí vocês já devem começar a entender que é importante especificarmos de alguma forma qual é a base em que estamos trabalhando

<FabioOlive> pois 8 + 8 dá 16, para pessoas normais

<_edEr> (Y)

<FabioOlive> hehe

<_edEr> verdade

<[elt]eliezerb> Kkkj

<_edEr> fica uma piada

<FabioOlive> em geral, números soltos tipo 15, 42, 33 se considera decimal

<_edEr> tipo a “há 10 tipos de pessoas, as que entendem binário e as que naõ entendem”

<ajzuse> “Existem 10 tipos de pessoas… as que sabem contar em binário, e as que não sabem”

<ajzuse> ah, droga, o _edEr chegou antes

<ajzuse> aheuaheueahu

<_edEr> kkk

<[elt]eliezerb> Doidera low level

<FabioOlive> quando se quer deixar claro que um número é hexadecimal, se usa um prefixo 0x na frente, tipo 0x2A

<FabioOlive> esse prefixo, quando for lido por um compilador, interpretador, shell ou outro programa que esteja lendo o que estamos digitando, vai indicar a base do número

<[elt]eliezerb> Salva tudo AlissonB q o sinal vai cair aqui

<FabioOlive> se usa 0b para binário, tipo 0b1111

<FabioOlive> depois eu mando o log :) eu sempre salvo log de tudo no xchat :)

<ajzuse> 0x2A é equivalente a 42 na decimal né FabioOlive?

<ajzuse> (Relembrando as aulas de arquitetura)

<[elt]eliezerb> Show

<FabioOlive> acho que é, vamos ver: 2 * 16 + 10 == 32 + 10 == 42 isso :)

<[elt]eliezerb> Sim

<AlissonB> fiz com a calculadora bc e deu 42 :)

<FabioOlive> quando se está mexendo com permissões de arquivos em Unix/Linux, é comum usar Octal

<FabioOlive> o princípio é o mesmo, 0 1 2 3 4 5 6 7 10 11 12 13 14 15 16 17 20 21 …

<FabioOlive> nesse caso 4 + 4 == 10 :) em octal, claro

<FabioOlive> se usa o prefixo 0o pra deixar claro, ou em linguagem C e derivadas apenas um 0

<FabioOlive> então é interessante tomar cuidado, em linguagens de programação, com números que comecem com um 0 explícito assim

<cust> i ai cambada

<FabioOlive> eu lembro de um sysadmin que gostava de “alinhar” os IPs das máquinas na configuração com zeros pra ficar tudo bonitinho

<FabioOlive> tipo 192.168.001.042

<FabioOlive> aí se deu mal, pois o 001 até passa como 1 mesmo, mas o 042 não é 42 :)

<_edEr> kk

<ajzuse> rsrsrs

<ajzuse> que beleza este sysadmin

<FabioOlive> digitando um terminal dá pra converter rapidinho

<FabioOlive> $ echo $¹⁾

<FabioOlive> 34

<FabioOlive>

<AlissonB> o terminal já saca que é octal então

<FabioOlive> $ echo $²⁾

<FabioOlive> -bash: 082: value too great for base (error token is “082”)

<AlissonB> nice :)

<FabioOlive> viu que ele reclamou? eu botei o dígito 8, e está errado, pois octal só pode ir de 0 a 7

<_edEr> kk

<_edEr> legal

<FabioOlive> como estes sistemas são todos posicionais, cada casa tem um valor múltiplo da base

<_edEr> “sh: arithmetic syntax error ”

<FabioOlive> em decimal normal, temos 1, 10, 100, 1000 para as unidades, dezenas, centenas, milhares, e assim por diante

<FabioOlive> em hexadecimal as casas valem 1, 16, 256, 4096 e assim por diante

<FabioOlive> que é 16^0, 16^1, 16^2, 16^3, …

<FabioOlive> $ echo $³⁾

<FabioOlive> 256

<FabioOlive> $ echo $⁴⁾

<FabioOlive> 4096

<FabioOlive> ter familiaridade com hexadecimal é *fundamental* para escovar bits

<FabioOlive> pois é a base numérica que fica perfeita pra se manipular bytes de 8 bits

<_edEr> bacana..

<FabioOlive> (houveram algumas arquiteturas em que o byte tinha 9 bits, mas não vamos entrar nisso heheheh)

<_edEr> uawuehaweh

<_edEr> vish.. já tem bastante pra ver de sistemas de 8bits

<FabioOlive> se formos contando um a um em binário e hexadecimal, vamos ver que um dígito hexa equivale exatamente a 4 bits

<ajzuse> byte com 9 bits… isso é qnem o bit Quântico q tem 3 estados…

<FabioOlive> então dois dígitos hexa conseguem expressar toda a faixa de valores de um byte

<FabioOlive> 0 0000

<FabioOlive> 1 0001

<FabioOlive> 2 0010

<FabioOlive> 3 0011

<FabioOlive> …

<FabioOlive> C 1100

<FabioOlive> D 1101

<FabioOlive> E 1110

<FabioOlive> F 1111

<ajzuse> lol… nunca tinha me ligado nisso

<FabioOlive> então de 00 a FF conseguimos contar de 00000000 a 11111111

<FabioOlive> :)

<FabioOlive> por isso também que um bom editor hexadecimal é fundamental para a escovação

<ajzuse> da relação entre o o binário e o Hexadecimal…

<FabioOlive> e o bom e velho hexadecimal

<FabioOlive> opa, bom e velho hexdump

<ajzuse> haeuhaeueahueah

<FabioOlive> desculpem, estou meio cansadão e falhando as sinapses hehe

<ajzuse> mais uma ferramenta pra minha lista de guerra

<ajzuse> eahueaheuah

<FabioOlive> vejam aí se vocês tem o hexdump instalado, rodando “echo teste | hexdump -C”

<AlissonB> aqui tem, testei antes :)

<ajzuse> tenho

<FabioOlive> o “hexdump -C” é considerado o formato “canônico” (tradicional, ortodoxo, etc) de fazer um dump de alguma informação em hexadecimal

<_edEr> caiu

<FabioOlive> pois ele mostra a contagem de bytes em hexa na primeira coluna, depois até 16 bytes em hexadecimal seguidos da representação ASCII destes bytes se eles forem caracteres imprimíveis

<_edEr> =/

<ajzuse> que massa

<ajzuse> =D

<FabioOlive> esse formato é usado desde o tempo do debug do DOS :)

<FabioOlive> $ echo teste | hexdump -C

<FabioOlive> 00000000 74 65 73 74 65 0a |teste.|

<FabioOlive> vocês viram que a letra 't' corresponde ao número 0x74, a letra 'e' ao 0x65 e assim por diante

<AlissonB> hum

<FabioOlive> vale lembrar, novamente, que pro processador só o que existe são números

<FabioOlive> mais nada

<_edEr> (Y)

<FabioOlive> então mostrar texto já é uma grande conspiração

<ajzuse> heheheh

<FabioOlive> o que é que faz um 't' ser mostrado graficamente como um 't'?

<_edEr> eu perdi uma parte antes.. AlissonB cola no private pra mim?

<ajzuse> ai entra o ASCII ou o Unicode, certo FabioOlive?

<FabioOlive> certo, precisa existir uma combinação entre todas as partes envolvidas, de fazer corresponder um número fixo para cada símbolo

<FabioOlive> o mais antigo e comum é o ASCII

<FabioOlive> rodem aí “man ascii” no terminal

<ajzuse> sim, o ASCII vai de 0 a 255

<FabioOlive> na verdade, o ASCII vai de 0 a 127

<FabioOlive> ele só define 7 bits

<[elt]eliezerb> 7?

<[elt]eliezerb> So?

<ajzuse> pois é, agora fiquei boiando tbm

<ajzuse> aehueahueahua

<FabioOlive> porque no tempo do ari cachaça, se usava o oitavo bit para dizer que o caractere deveria ser negrito, ou vídeo invertido, ou coisa parecida :)

<ajzuse> poutz… q beleza

<ajzuse> aehuaehaeueh

<[elt]eliezerb> A siimm

<[elt]eliezerb> Bit de paridade

<[elt]eliezerb> Bit de sinal

<FabioOlive> [elt]eliezerb: boa, isso também

<_edEr> vish.

<ajzuse> sou de um pouco depois deste tempo…

<_edEr> legal

<[elt]eliezerb> Sempre tem um na frente

<FabioOlive> era bem comum antigamente, nas comunicações seriais, usar 7 bits de dados e um de paridade :)

<[elt]eliezerb> Eh um bit de verificacao

<FabioOlive> enfim, isso continua sendo um empecilho para algumas coisas até hoje

<ajzuse> verdade, alguns dispositivos serial até hj possuem configuração de bit de paridade

<FabioOlive> por exemplo, os headers de uma mensagem enviada via email precisam ser ASCII, e só ASCII mesmo 7 bits

<[elt]eliezerb> Yep

<FabioOlive> então, caracter acentuado no Subject de um email precisa ser codificado de forma “criativa” :)

<_edEr> kkkk

<_edEr> uhuawehawe

<FabioOlive> deixa achar um aqui…

<_edEr> bah.. quando abre um fonte de email é uma tristeza..

<[elt]eliezerb> Mais 5km de moto, ja ja to de volta

<_edEr> (Y)

<FabioOlive> Subject: =?ISO-8859-1?Q?Cria=E7=E3o_de_RPM_=2D_PEV?=

<[elt]nathan> daew everybody

<[elt]nathan> to aew

<AlissonB> só um pouquinho atrasado

<AlissonB> hehehe

<AlissonB> mas tá valendo, depois a gente manda o log

<AlissonB> :)

<Nathan> furou o pneu do carro :S

<Nathan> sussa =D

<_edEr> bah..

<FabioOlive> bizarro esse padrão :) basicamente esse trambolho acima diz que o conjunto de caracteres usado é o ISO-8859-1 (ASCII nos primeiros 128 códigos e depois mais 128 com acentos e etc pra fechar 8bits)

<FabioOlive> =?ISO-8859-1?Q?Cria=E7=E3o_de_RPM_=2D_PEV?=

<_edEr> ahweuhawuh

<FabioOlive> =?ISO-8859-1? == codificado em ISO-8859-1 (digitem “man latin1” para ver o conjunto se quiserem)

<FabioOlive> Q? == Quoted Printable, que basicamente diz que o = é um caracter especial que serve pra colocar um caractere especial expresso em hexadecimal

<FabioOlive> Cria=E7=E3o_de_RPM_=2D_PEV é o assunto do email, codificado

<_edEr> ta.. dae o ”=E7=E3” é o codigo hexa de algo

<_edEr> ?

<FabioOlive> isso =E7 é o código hexa do ç em ISO-8859-1

<FabioOlive> =E3 é ã

<FabioOlive> olhem no man latin1 :)

<FabioOlive> _ vira espaço

<FabioOlive> e 2D é o sinal de - em ASCII mesmo

<FabioOlive> então o subject desse email é “Criação de RPM - PEV”

<FabioOlive> a vantagem do ISO-8859-1 é que usa apenas um byte de 8 bits

<AlissonB> e porque ele apareceu pra ti dessa forma “nua”?

<FabioOlive> na verdade eu peguei o header cru :)

<FabioOlive> o programa de email decodifica sozinho e mostra direitinho :)

<FabioOlive> mas é legal saber e é um bom exemplo :)

<AlissonB> saquei :P

<ajzuse> isso é interessante qdo vc está com um sniffer de pacote ativo em uma rede, normalmente os textos aparecem assim

<FabioOlive> sim, pois vão aparecer sem “interpretação”

<_edEr> verdade

<FabioOlive> vão aparecer os bytes “crus”, e não “cozidos” hehehe

<FabioOlive> então, como vínhamos falando

<ajzuse> exatamente

<ajzuse> galera, vou ter que sair, terminar uns calculos ainda

<ajzuse> até mais

<AlissonB> até :)

<ajzuse> faleu FabioOlive pelas explicações, depois se puder manda os logs =D

<_edEr> é bom saber pois quando dá problema com server de email. (no meu caso) consigo entender melhor o “fonte” do email

<FabioOlive> a grande conspiração da placa de vídeo, da impressora e de todos os dispositivos em que se entra ou mostra caracteres e texto, é que todos precisam seguir a mesma tabela de conversão de números em símbolos gráficos equivalentes ao caractere esperado

<FabioOlive> senão daria uma confusão daquelas! :)

<AlissonB> verdade :)

<FabioOlive> por exemplo, em modo texto puro, quando o sistema operacional vai escrever uma mensagem, o que ele faz é escrever bytes numéricos na memória de vídeo, e magicamente a placa de vídeo mostra os caracteres certos

<_edEr> imagino.. cada um usando um “padrão” diferente dos outros

<FabioOlive> usando uma VM com DOS, dá pra fazer programinhas que bagunçam direto na memória de vídeo e ficam aparecendo caracteres malucos :)

<FabioOlive> até aqui está tranquilo?

<FabioOlive> naquela linha do hexdump:

<FabioOlive> 00000000 74 65 73 74 65 0a |teste.|

<FabioOlive> o que é o 0a que tem ali? (por sinal, ali é esperado que tudo seja hexa mesmo ,então não tem 0x na frente :)

<AlissonB> 0a indicaria octal, mas nesse caso eu não sei :x

<FabioOlive> HEXdump, ou seja, é tudo hexa

<FabioOlive> man ascii

<FabioOlive> procura por 0A

<FabioOlive> 012 10 0A LF '\n' (new line)

<AlissonB> vi aqui

<AlissonB> nova linha

<FabioOlive> é o caractere de nova linha, que o echo sempre adiciona no final

<FabioOlive> se fosse uma impressora, esse caractere de controle diria pra ela “volta a cabeça de impressão pro início da linha e avança uma linha no papel”

<FabioOlive> uma impressora das antigas, claro, as atuais nem isso sabem :)

<AlissonB> é um caracter adicional que sempre vai ter?

<FabioOlive> no caso do terminal, existe um programa (que é o “emulador de terminal”, por isso que tem esse nome) que interpreta esses bytes e também faz a mesma coisa, quando lê um 0A ele volta o cursor do terminal para a próxima linha

<FabioOlive> sempre tem quando se quer fazer uma nova linha em um terminal :)

<FabioOlive> tens que entender o seguinte: qual é o significado dos bytes? quem é que está interpretando isso, e de que forma?

<FabioOlive> 0A em outro contexto, tipo no meio de uma imagem PNG, seria outra coisa

<FabioOlive> sacou?

<FabioOlive> só o que o computador tem na memória são bytes de 8 bits

<FabioOlive> o que define o significado desses bytes é o “contexto” em que estão sendo interpretados

<FabioOlive> vamos ver um pedaço de uma PNG

<FabioOlive> $ hexdump -C Pictures/Mascote-Bugre.png | head -3

<FabioOlive> 00000000 89 50 4e 47 0d 0a 1a 0a 00 00 00 0d 49 48 44 52 |.PNG……..IHDR|

<FabioOlive> 00000010 00 00 00 80 00 00 00 73 08 06 00 00 00 50 38 0a |…….s…..P8.|

<FabioOlive> 00000020 7c 00 00 00 04 73 42 49 54 08 08 08 08 7c 08 64 ||….sBIT….|.d|

<FabioOlive> note que essa imagem Mascote-Bugre.png começa com 89 50 4e 47 0d 0a 1a 0a

<_edEr> pelo que sei os primeiros n bytes são o cabeçalho do arquivo

<FabioOlive> 50 4e 47 dá pra ver que são os caracteres P N G, que é a “assinatura” de uma imagem PNG. qualquer programa que abra um arquivo e veja esta sequência de bytes no início vai provavelmente interpretar o arquivo como sendo uma imagem PNG

<FabioOlive> exato

<_edEr> identifica que tipo de arquivo estamos trabalhando..

<_edEr> certo?

<_edEr> não lembro certo quando bytes

<FabioOlive> o cabeçalho identifica o tipo e algumas informações mais gerais do arquivo, geralmente a versão do padrão de codificação usado, etc

<FabioOlive> _edEr: varia para cada tipo de arquivo, não tem um tamanho fixo de cabeçalho

<_edEr> humm blz..

<_edEr> (:

<FabioOlive> basicamente, um dia um bando de experts em imagem digital sentaram e pensaram em uma forma de representar uma imagem em um arquivo, e começaram pelo cabeçalho identificando o formato com 89 50 4e 47 :)

<FabioOlive> existe um padrão publicado que diz exatamente como ler e interpretar cada pedaço do arquivo PNG para conseguir restaurar a imagem a partir da sua representação na sequência de bytes que compõem o arquivo

<AlissonB> no caso, se fossemos fazer um novo Gimp, precisaríamos ler essa documentação? :)

<FabioOlive> não existe mágica, qualquer arquivo deve ser lido e interpretado pelo programa que foi feito para interpretar o formato que a sequência de bytes do arquivo segue

<FabioOlive> AlissonB: exato :)

<AlissonB> mas por exemplo, agora estamos vendo hexa

<FabioOlive> para ler ou escrever arquivos PNG, ou MP3 ou seja o que for, é preciso ler o padrão de codificação e implementá-lo

<AlissonB> o processador não vai ver em hexa, e sim em binário, correto?

<FabioOlive> sim, pois na verdade estamos olhando a matrix de forma crua

<FabioOlive> ah sim

<FabioOlive> lá no processador mesmo seria em binário, mas não faz diferença, pois 8bits e 2 dígitos hexa contém exatamente a mesma informação

<FabioOlive> por isso é sempre tão mais fácil entender e trabalhar com o hexa

<_edEr> humm

<FabioOlive> se formos olhar um código de máquina e sua interpretação em Assembly, por exemplo, vamos ver hexa

<FabioOlive> $ objdump -d /bin/cat | more

<FabioOlive> /bin/cat: file format elf64-x86-64

<FabioOlive> ]…

<FabioOlive> 401a09: 48 89 f5 mov %rsi,%rbp

<FabioOlive> 401a0c: 53 push %rbx

<FabioOlive> 401a0d: 31 db xor %ebx,%ebx

<FabioOlive> 401a0f: 48 81 ec 48 01 00 00 sub $0x148,%rsp

<FabioOlive> 401a16: 89 7c 24 4c mov %edi,0x4c(%rsp)

<FabioOlive> 401a1a: e8 11 ff ff ff callq 401930 <getpagesize@plt>

<FabioOlive> se procurarmos dentro do arquivo /bin/cat, que casualmente é um programa executável, vamos achar essa sequência

<FabioOlive> 48 89 f5 53 31 db …

<FabioOlive> isso é o que o processador vai ver, claro que em versão binária

<FabioOlive> só o que existem são bytes de 8 bits, o que eles significam depende do contexto

<FabioOlive> neste caso eles são instruções de máquina da arquitetura x86

<FabioOlive> e o processador vai interpretar eles dessa forma

<FabioOlive> isso é igual na memória ou no disco

<FabioOlive> um disco rígido é apenas milhões de blocos de bytes de 8 bits :)

<_edEr> (:

<_edEr> como dito(escrito) no começo.. tudo é Byte de 8 bits

<FabioOlive> opa, tive uma pequena interrupção

<FabioOlive> :)

<FabioOlive> se formos olhar o disco com hexdump, vamos ver todos os setores do disco, desde o MBR até as partições e etc igualzinho…

<FabioOlive> $ sudo hexdump -C /dev/sda | more

<FabioOlive> [sudo] password for fleite:

<FabioOlive> 00000000 eb 63 90 10 8e d0 bc 00 b0 b8 00 00 8e d8 8e c0 |.c…………..|

<FabioOlive> 00000010 fb be 00 7c bf 00 06 b9 00 02 f3 a4 ea 21 06 00 |…|………!..|

<FabioOlive> 00000020 00 be be 07 38 04 75 0b 83 c6 10 81 fe fe 07 75 |….8.u……..u|

<FabioOlive> 00000030 f3 eb 16 b4 02 b0 01 bb 00 7c b2 80 8a 74 03 02 |………|…t..|

<FabioOlive> 00000040 80 00 00 80 6a 4a 08 00 00 08 fa 90 90 f6 c2 80 |….jJ……….|

<FabioOlive> 00000050 75 02 b2 80 ea 59 7c 00 00 31 00 80 01 00 00 00 |u….Y|..1……|

<FabioOlive> 00000060 00 00 00 00 ff fa 90 90 f6 c2 80 74 05 f6 c2 70 |………..t…p|

<FabioOlive> …

<FabioOlive> 00000160 8e c6 fc f3 a5 1f 61 ff 26 5a 7c be 86 7d eb 03 |……a.&Z|..}..|

<FabioOlive> 00000170 be 95 7d e8 34 00 be 9a 7d e8 2e 00 cd 18 eb fe |..}.4…}…….|

<FabioOlive> 00000180 47 52 55 42 20 00 47 65 6f 6d 00 48 61 72 64 20 |GRUB .Geom.Hard |

<FabioOlive> 00000190 44 69 73 6b 00 52 65 61 64 00 20 45 72 72 6f 72 |Disk.Read. Error|

<FabioOlive> e assim por diante

<FabioOlive> aqueles primeiros bytes que apareceram ali, eb 63 90 10 8e d0 bc 00 …

<FabioOlive> fazem parte do código de boot do MBR do disco, o Master Boot Record

<FabioOlive> é esse código de máquina que boota o meu computador :)

<_edEr> humm…

<_edEr> legal..

<FabioOlive> se eu for ali com um editor hexadecimal e mudar o eb 63 90 … meu computador não vai mais bootar, pois as instruções estarão incorretas

<FabioOlive> da mesma forma que se eu abrir uma imagem PNG e sair mudando os bytes, provavelmente ela vai ficar toda quebrada e não vai carregar

<_edEr> assim tambem pode ser reconstruido a MBR ?

<FabioOlive> sim

<FabioOlive> o MBR não tem nada de mágico

<_edEr> {:

<FabioOlive> são apenas uns 440 bytes que são responsáveis por olhar qual é a primeira partição marcada como bootável, e carregar o primeiro setor dela na memória e saltar pra ele

<_edEr> editor hexadecimal tu utiliza?

<FabioOlive> o primeiro setor de uma partição é o PBR, Partition Boot Record

<_edEr> é.. eu li que era 512.. provavelmente algum é reservado.. ou sl

<FabioOlive> que basicamente vai saber carregar o boot loader do Sistema Operacional instalado, como o GRUB no meu caso

<FabioOlive> e aí o GRUB sabe carregar o kernel Linux e finalmente meu Fedora boota :)

<FabioOlive> sim, um setor de disco é um bloco de 512 bytes

<FabioOlive> no caso do MBR, se usa uns 64 bytes do finalzinho, se não me engano, para a tabela de partições

<FabioOlive> e os dois últimos bytes do setor sempre devem ser 0x55 0xAA para marcar como um setor de boot válido

<FabioOlive> pois um disco todo vazio (zerado geral) vai ter 00 00 nessas posições

<_edEr> humm

<FabioOlive> olha só:

<FabioOlive> 000001d0 1f 3f 83 fe ff ff 00 a8 0f 00 00 40 33 25 00 00 |.?………@3%..|

<FabioOlive> 000001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…………….|

<FabioOlive> 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |…………..U.|

<FabioOlive> lá no finzinho tem 55 aa

<_edEr> \o/

<FabioOlive> essa linha começa em 1f0, e tem 16 bytes, então a próxima seria 0x200

<FabioOlive> 0x200 dá 512 ou seja, ali terminou o primeiro setor :)

<FabioOlive> com um bom editor hexadecimal dá pra sair investigando tudo no computador

<FabioOlive> eu uso um bem simples e tosco, chamado hexedit

<_edEr> humm

<AlissonB> uma hora dessas tenta ver se esse é bom FabioOlive

<AlissonB> http://hte.sourceforge.net/

<AlissonB> me indicaram ele :)

<_edEr> pra win eu tenho o XVI32

<_edEr> nunca usei outro

<_edEr> =/

<FabioOlive> AlissonB: parece ser interessante sim

<AlissonB> bom galera, creio que por hoje tá massa né :)

<AlissonB> tivemos uma boa base sobre low level :D

<_edEr> woooww.. ja é 20 pra meia noite

<_edEr> o tempo voa

<AlissonB> e nessas competições é essencial saber isso :D

<FabioOlive> sim, acho que por hoje tá bom, espero que tenham gostado :)

<AlissonB> foi bem produtivo, talvez amanhã eu retome a ler descansado

<AlissonB> e as dúvidas eu pergunto :)

<_edEr> (:

<AlissonB> FabioOlive++

<mibotz> FabioOlive tem 76 pontos de karma

<AlissonB> enfim, boa noite a todos

<FabioOlive> ht.x86_64 : File editor/viewer/analyzer for executables

<AlissonB> pode ser na terça sempre?

<FabioOlive> boa, tem esse ht empacotado pra Fedora, e pra OpenBSD também :)

<FabioOlive> sim, acho que pode ser sim

<FabioOlive> vamos vendo aos poucos

<FabioOlive> vou mandar o log pra todos daquela thread