<AlissonB> FabioOlive bora começar? :)
<NathanScapini> Opa
<FabioOlive> shazan!
<FabioOlive> haha
<AlissonB> haha :D
<FabioOlive> a filha foi dormir agora :)
<NathanScapini> oasdkasodkasd
<NathanScapini> tu devia ta ali já faz uns 20 minutos esperando 22:00 exato
<NathanScapini> Like Sheldon Cooper 
<FabioOlive> que nada, dei sorte :)
<NathanScapini> ausehuahesuehasuheuashesa
<NathanScapini> hehehehehe, to zuanndo
<AlissonB> vamos falar sobre o que?
<FabioOlive> escutem a última da minha filha de 2,7 anos: perguntamos se ela quer um maninho e ajudar a escolher o nome, ela disse que vai entrar na internet e procurar pra escolher o nome
<FabioOlive> <o>
<NathanScapini> oasdkasodkasodkasdoaskdoaskdokasd
<NathanScapini> véi, isso é um orgulho pra um pai
<AlissonB> owned!
<NathanScapini> owned
<AlissonB> debita 100 pontos lá no ranking
<AlissonB> :D
<NathanScapini> saodkaodkasodkas
<FabioOlive> quando é que eu começo a ensinar python e TCP/IP pra ela? :D
<AlissonB> acorda ela aí :D
<AlissonB> diz pra não perder nas terças as 10
<NathanScapini> ou o contrário talvez aconteça, não?
<FabioOlive> ahahaha boa!
<NathanScapini> hehehehe, pode cre
<FabioOlive> sim, com 4 anos ela vai me olhar e dizer: ih pai, esse lance de python não tá com nada, eu prefiro ruby
<NathanScapini> vish, aí ta feita a briga
<FabioOlive> buenas, vamos começar a conversa então
<FabioOlive> qual foi o assunto escolhido? redes?
<NathanScapini> Opa, show de bola. Bora lá
<FabioOlive> borintão
<FabioOlive> :Ð
<AlissonB> eu voto filesystems
<FabioOlive> opa 1×1
<NathanScapini> eu votaria redes
<AlissonB> [[elt]Uhilian]: decide :)
<NathanScapini> faça as honras
<[elt]Uhilian> hehehe….file systems hoje se não se importar!!!
<NathanScapini> blz
<[elt]Uhilian> :)
<NathanScapini> deixamos redes pra semana que vem <0>
<[elt]Uhilian> já era meu voto antessss =]
<AlissonB> show :D
<FabioOlive> :D ok então fs
<[elt]Uhilian> ;)
<FabioOlive> fs == filesystem
<FabioOlive> essa é a lição mais importante
<FabioOlive> dã
<FabioOlive> então tá
<FabioOlive> quem aqui já alterou permissões de um inode no disco usando uma agulha e um imã?
<NathanScapini> oasdkoasdkaoskdasodkasod
<NathanScapini> asdokkosdkoadskodasko
<NathanScapini> permissões
<NathanScapini> pqp
<NathanScapini> perai
<NathanScapini> com agulha?
<NathanScapini> de quem mundo você é?
<AlissonB> uauhahuahua
<FabioOlive> pra magnetizar o pontinho certo :D
<[elt]Uhilian> nuossaa
<[elt]Uhilian> hahahah
<FabioOlive> com um disco desses deve ser possível: http://www.youtube.com/watch?v=ovjt_UKok74
<AlissonB> o.O
<AlissonB> Chuck Norris can install windows 8 Ultimate on that Hard? Drive .
<NathanScapini> esse aew precisa de uma talhadeira pra magnetizar no “pontinho” certo
<AlissonB> heheh
<AlissonB> boa
<[elt]Uhilian> hehhee….parece um motor
<FabioOlive> não sei se vocês já estudaram sobre discos rígidos, mas a maneira mais fácil de descrever um disco é como uma sequência de blocos de dados
<FabioOlive> na RAM os dados são apenas uma grande fileira de bytes
<FabioOlive> se pode acessar qualquer byte facilmente
<FabioOlive> em um disco, as informações são gravadas em blocos chamadas setores, que tem um tamanho de 512 bytes
<NathanScapini> yeah
<FabioOlive> (hoje em dia existe um padrão de discos com setor de 4K, mas não vamos pensar nisso agora)
<FabioOlive> setores de 512 bytes existem desde que o mundo é mundo e o noé fez a arca
<FabioOlive> houveram outros tamanhos em outros computadores (se não me engano os Amiga usavam 488 bytes), mas 512 se tornou o padrão de fato há muito tempo
<FabioOlive> então sempre se que quer acessar alguma coisa no disco, se passa qual é o setor que se quer acessar
<FabioOlive> tipo: ô disco, lê pra mim o setor 274256. Aí a controladora de disco manda pra memória RAM os 512 bytes que correspondem àquele setor
<FabioOlive> ou o contrário: ô disco, grava pra mim os 512 bytes a partir desse endereço na RAM no setor 23785427. aí ele escreve e retorna o status se rolou legal
<FabioOlive> é sempre em blocos
<AlissonB> blocos == setores?
<FabioOlive> não tem como dizer “quero mudar esse byte do setor”, neste caso é necessário ler o setor, alterar o byte que se quer na memória e gravar o setor inteiro com o byte modificado de volta
<FabioOlive> AlissonB: sim e não, olha que legal
<FabioOlive> existem sistemas de arquivos que usam o próprio tamanho do setor do disco como unidade de alocação
<_edEr> Boa noite
<FabioOlive> e outros que preferem usar tamanhos diferentes, agrupando vários setores em um “bloco”
<FabioOlive> opa _edEr
<AlissonB> olá _edEr :)
<_edEr> estava lanvando a loça.. demorei um pouco
<AlissonB> já começamos :)
<AlissonB> depois vai o log inteiro pra galera
<_edEr> humm
<_edEr> blz
<_edEr> Y)
<FabioOlive> então falar em setores ou blocos pode ser a mesma coisa ou pode ser diferente :) um setor é sempre a unidade mínima endereçada pelo hardware do disco
<AlissonB> o que seria uma “unidade de alocação”?
<_edEr> qual é o assunto em pauta??
<FabioOlive> e alguns sistemas de arquivos (tipo ext3, ext4 e outros, a maioria dos FSs do Linux) preferem agrupar vários setores e trabalhar em termos de uma unidade maior, chamada bloco
<_edEr> acho qu eé partiços
<AlissonB> _edEr filesystems
<_edEr> uawheuhaew
<_edEr> blz
<FabioOlive> AlissonB: “unidade de alocação” é o setor, (ou o bloco:)
<AlissonB> ah, ok
<FabioOlive> depende do nível de abstração :)
<FabioOlive> o disco sempre vai enxergar setores
<FabioOlive> de 512 bytes
<FabioOlive> o sistema de arquivos pode preferir trabalhar de outra forma
<_edEr> tipo 4096 bytes no ntfs
<_edEr> ?
<FabioOlive> o mais comum no caso do Linux (e outros sistemas também, talvez o Windows seja assim) é usar 4K como unidade de alocação gerenciada pelo sistema de arquivos
<FabioOlive> isso
<_edEr> humm
<_edEr> isso influencia em desempenho?
<FabioOlive> 4096 bytes é o tamanho de uma página de memória na arquitetura x86 (32 e 64), então facilita trabalhar na gerência de memória e gerência de arquivos com o mesmo tamanho da “unidade mínima de alocação'
<_edEr> hum
<FabioOlive> _edEr: pode influenciar sim, dependendo de como o FS é organizado. Se tu gerencias setores diretamente, um arquivo muito grande vai precisar de muito mais blocos de 512B do que blocos de 4096B
<FabioOlive> é como construir uma casa com tijolos maiores :)
<_edEr> hum
<FabioOlive> vai menos tijolo pra assentar e empilhar :)
<_edEr> bom
<_edEr> entendo
<FabioOlive> e tem a facilidade da gerência de memória também. no caso do Linux, ele pode dizer “ô driver, manda o bloco 675315 pra página de memória em 0xFFFFF2374765”
<FabioOlive> e gerencia páginas e blocos da mesma forma
<AlissonB> o que seria uma página de memória?
<FabioOlive> se não fosse assim, teria que gerenciar mais de um setor em cada página, quantas partes da página estão “ocupadas” com setores lidos, etc
<FabioOlive> AlissonB: é a unidade mínima de gerência de memória quando se está usando o processador em modo protegido, com gerência de memória por paginação na MMU (Memory Management Unit)
<FabioOlive> mas isso fica pra outra aula :)
<AlissonB> [FabioOlive]: página de memória é como o setor do hd então?
<FabioOlive> basicamente o kernel vai alocando memória para os processos em bloquinhos de 4KB :)
<FabioOlive> mais ou menos isso :)
<_edEr> D:
<FabioOlive> mas voltemos aos setores
<FabioOlive> então, basicamente, embora seja uma complicação de “cilindros, setores, cabeças” e etc, o disco na verdade nada mais é do que uma grande sequência de setores de 512 bytes
<FabioOlive> isso de cilindro, cabeça, etc é uma terminologia do tempo daquele disco serra-elétrica no vídeo lá de cima, só que infelizmente essa maneira de conversar com os discos continua quase até hoje
<FabioOlive> é como um apelido ruim que o cara ganha no jardim de infância e nunca consegue se livrar
<_edEr> legal.. não querendo atrapalhar: quando, no gparted, tem a opçaõ “arredondar para cilindros” isso é o que?
<FabioOlive> significa alocar a partição desde o início de um suposto cilindro até o final de um outro cilindro
<FabioOlive> deixa eu arranjar um gráfico
<FabioOlive> do ponto de vista do software, a gente pode considerar o disco apenas como uma sequência de setores mesmo, começando no 0 até o tamanho do disco
<FabioOlive> nenhum desses setores tem nada de especial por si só, MAS a gente convenciona que o setor 0 é o Master Boot Record
<AlissonB> o setor 0 teria uma posição específica fisicamente no disco
<AlissonB> ou é convenciado que ele vai ser o 0 e pronto?
<FabioOlive> pois o BIOS do computador está programado para achar o primeiro disco disponível, ler os 512 bytes deste setor 0 para a memória e executar o que vier como código
<[elt]Uhilian> no caso a mbr?
<FabioOlive> AlissonB: a alocação começa na parte mais interna do disco, e vai aumentando à medida que a cabeça de leitura/gravação vai se movendo pra fora
<AlissonB> então seria bem ao meio :)
<FabioOlive> [elt]Uhilian: sim, mbr. eu falei Master Boot Record acima :) MBR
<[elt]Uhilian> legal, não tinha associado :p
<FabioOlive> AlissonB: isso :) nas imagens que tem no google acima, vocês podem ter uma idéia de como é a alocação
<FabioOlive> então, basicamente o BIOS dá uma inicializada geral na máquina, lê o setor 0 (MBR) do disco de boot e salta pra ele
<FabioOlive> então desde o primeiro byte o MBR precisa ter código executável, que neste caso é responsável por
<FabioOlive> identificar qual é a primeira partição do disco marcada como bootável, ler o primeiro setor DELA e saltar pra ele
<FabioOlive> o primeiro setor de uma partição bootável é chamado Partition Boot Record
<FabioOlive> e neste caso imagina-se que ele vai saber fazer coisas como carregar o GRUB, que por sua vez vai carregar o kernel e finalmente bootar o Sistema Operacional
<FabioOlive> o mais complicado em um setor de boot é conseguir fazer algo útil em apenas 512 bytes :)
<AlissonB> MBR → PBR → GRUB → KERNEL → S.O
<FabioOlive> na verdade até menos, no caso do MBR, pois um pedaço do MBR é separado para a tabela de partições (acho que dá uns 64 bytes)
<FabioOlive> e todo setor de boot precisa ter nos últimos bytes a “assinatura” 0x55 0xAA
<FabioOlive> AlissonB: exato :)
<FabioOlive> $ sudo hexdump -C /dev/sda | head
<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..|
<_edEr> bacana.. já vi exemplos de OS em assembly com 400 bytes. apenas prar escrever um “oi”
<FabioOlive> aqueles primeiros bytes, EB 63 90 já é instruções em linguagem de máquina
<FabioOlive> no caso, ele “salta” alguns bytes pra frente, pois outra coisa que temos no MBR são coisas como nome de volume e outras informações que se convencionou colocar ali
<FabioOlive> é bem apertado :)
<_edEr> imagino..
<FabioOlive> mas o trabalho do MBR é razoavelmente fácil, ele só precisa olhar as partições que estão declaradas nele mesmo (ou seja, já foi lido junto com ele pelo BIOS), achar uma bootável e carregar o PBR dela e saltar pra ele
<_edEr> deve ser como montar um grande guarda-roupas em uma quitinete
<FabioOlive> o MBR geralmente já vem programado de fábrica, mas pode ser recarregado sem stress
<FabioOlive> o PBR vai ser instalado quando o sistema operacional é instalado
<_edEr> humm
<FabioOlive> e aí o PBR basicamente vai ser programado pra ler os blocos do loader do sistema operacional pra memória e executar ele
<FabioOlive> no caso do DOS, o próprio PBR consegue ler o IO.SYS e MSDOS.SYS e etc :) mas isso porque o sistema de arquivos FAT é simplíssimo
<AlissonB> fico imaginando como isso acontece
<FabioOlive> AlissonB: é a própria instalação do GRUB, por exemplo, que faz isso
<AlissonB> hum
<FabioOlive> tu já tem o sistema de arquivos criado, e manda instalar o grub, ele basicametne copia o executável do grub pro disco, pergunta pro driver do disco em que setores ele ficou, e programa no PBR a lista de setores que precisam ser lidos :)
<FabioOlive> se tu mover o grub depois disso já era, não boota mais :)
<FabioOlive> pois o PBR vai sempre ler aqueles mesmos setores que foram programados durante a instalação
<FabioOlive> se atualizar o grub, precisa atualizar o Partition Boot Record rapidinho, senão no próximo boot ele vai carregar coisa errada
<FabioOlive> bom
<FabioOlive> mas isso tudo ainda não é falando de sistemas de arquivos
<FabioOlive> vocês devem ter visto que até agora estamos falando de setores pra cá, blocos pra lá, etc
<FabioOlive> pois essa é a interface mais “crua” do disco
<FabioOlive> se vocês fossem escrever vírus de boot hoje em dia seria importante saber disso :) mas não é o caso
<FabioOlive> o fato é que obviamente é chato ficar trabalhando com setores e blocos
<FabioOlive> nós queremos trabalhar com arquivos e diretórios :)
<FabioOlive> um sistema de arquivos é apenas uma forma de organizar os blocos do disco de forma a criar essa ilusão de arquivos e diretórios, escondendo de nós a complexidade do acesso ao disco
<FabioOlive> :)
<AlissonB> pois é, só vendo essas explicações pra ver como é complexo o esquema
<_edEr> suspeitei desde o princípio
<FabioOlive> um FS (file system) gasta alguns blocos pra organizar os outros blocos de forma mais amigável
<FabioOlive> então aí podemos dizer “abra o arquivo foobar”, e o FS na verdade vai pedir pro driver do disco “leia os setores 27836 27836 1254 1265 438526 234”
<FabioOlive> massa que 27836 saiu repetido, mas eu juro que só bati a mão no teclado :D minha intenção não era confundir hehehe
<Uhilian> heheh….eles não seguem uma ordem pois são fragmentados, não é?
<AlissonB> boa pergunta Uhilian :)
<FabioOlive> depende da estratégia de alocação do FS, mas sim, no caso de windows e FAT a gente tinha que “desfragmentar” de tempos em tempos
<AlissonB> dai fica em sequencia?
<FabioOlive> os sistemas de arquivos do Unix usam várias estratégias de alocação, pré-alocação ou alocação atrasada para tentar deixar sempre em sequência
<FabioOlive> pois estando em sequência aumenta muito o desempenho
<FabioOlive> a cabeça magnética não precisa ficar pipocando de trilha em trilha no disco :)
<Uhilian> pois é, pq ouvi dizer que tem FS que não fragmentam os arquivos, é verdade?
<FabioOlive> sim, como os do Linux por exemplo
<Uhilian> legal
<FabioOlive> se der alguma fragmentação, por um uso realmente bizarro, vai ser menos de 1%
<_edEr> tem outra forma de leitura em hardware.. que aumenta o desempenho
<FabioOlive> “leitura em hardware”
<_edEr> kkkkkkkkkkk
<FabioOlive> e qual leitura não seria em hardware? :)
<_edEr> nem me liguei
<FabioOlive> quando a gente começa a pensar mais no baixo nível a gente pega mais essas besteiras de marketing :)
<_edEr> UAHWEUAUWEHUAHE
<_edEr> verdade
<_edEr> vou ver se acho o nome disso
<FabioOlive> então, como é que um FS organiza os blocos?
<FabioOlive> claro que cada um tem o seu jeito, mas existe geralmente alguma estrutura básica comum
<Uhilian> pelo ordem de nós?
<FabioOlive> tipo
<FabioOlive> praticamente todos os FSes usam o primeiro bloco da partição como “super bloco” e colocam nele as informações mais vitais do FS, como o seu nome, identificação e vesão do FS em uso, flags diversas dizendo quais características ou extensões estão em uso, qual é o tamanho do FS, e onde estão as tabelas de alocação de blocos, inodes e etc
<FabioOlive> e, obviamente, no caso dos FS Unix, qual é o inode do diretório raiz
<FabioOlive> uma das principais coisas que um FS precisa fazer é manter o controle de quais blocos estão alocados e quais não estão
<FabioOlive> pra não virar bagunça e as aplicações ficarem escrevendo nos blocos dos arquivos das outras e etc :)
<FabioOlive> no caso da FAT, a organização é mais ou menos assim:
<FabioOlive> o bloco 0 vai conter o nome do FS, tamanho, versão da FAT em uso, etc
<FabioOlive> depois disso vem a FAT em si, File Allocation Table, que dá nome ao próprio sistema de arquivos
<FabioOlive> depois uma cópia de backup da FAT
<FabioOlive> e depois o diretório raiz, que tem tamanho fixo (ou tinha há alguns anos)
<FabioOlive> $ truncate -s 10M teste-fat.img
<FabioOlive> $ mkdosfs teste-fat.img
<FabioOlive> mkdosfs 3.0.12 (29 Oct 2011)
<FabioOlive> $ hexdump -C teste-fat.img
<FabioOlive> 00000000 eb 3c 90 6d 6b 64 6f 73 66 73 00 00 02 04 04 00 |.<.mkdosfs……|
<FabioOlive> 00000010 02 00 02 00 50 f8 14 00 20 00 40 00 00 00 00 00 |….P… .@…..|
<FabioOlive> 00000020 00 00 00 00 00 00 29 e6 8e 12 15 20 20 20 20 20 |……)…. |
<FabioOlive> 00000030 20 20 20 20 20 20 46 41 54 31 36 20 20 20 0e 1f | FAT16 ..|
<FabioOlive> 00000040 be 5b 7c ac 22 c0 74 0b 56 b4 0e bb 07 00 cd 10 |.[|.”.t.V…….|
<FabioOlive> 00000050 5e eb f0 32 e4 cd 16 cd 19 eb fe 54 68 69 73 20 |^..2…….This |
<FabioOlive> 00000060 69 73 20 6e 6f 74 20 61 20 62 6f 6f 74 61 62 6c |is not a bootabl|
<FabioOlive> 00000070 65 20 64 69 73 6b 2e 20 20 50 6c 65 61 73 65 20 |e disk. Please |
<FabioOlive> 00000080 69 6e 73 65 72 74 20 61 20 62 6f 6f 74 61 62 6c |insert a bootabl|
<FabioOlive> 00000090 65 20 66 6c 6f 70 70 79 20 61 6e 64 0d 0a 70 72 |e floppy and..pr|
<FabioOlive> 000000a0 65 73 73 20 61 6e 79 20 6b 65 79 20 74 6f 20 74 |ess any key to t|
<FabioOlive> 000000b0 72 79 20 61 67 61 69 6e 20 2e 2e 2e 20 0d 0a 00 |ry again … …|
<FabioOlive> 000000c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…………….|
<FabioOlive> *
<FabioOlive> 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |…………..U.|
<FabioOlive> 00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…………….|
<FabioOlive> *
<FabioOlive> 00000800 f8 ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 |…………….|
<FabioOlive> 00000810 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…………….|
<FabioOlive> *
<FabioOlive> 00003000 f8 ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 |…………….|
<FabioOlive> 00003010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…………….|
<FabioOlive> *
<FabioOlive> 00a00000
<FabioOlive> $ file teste-fat.img
<FabioOlive> teste-fat.img: x86 boot sector, mkdosfs boot message display, code offset 0x3c, OEM-ID ” mkdosfs”, sectors/cluster 4, root entries 512, sectors 20480 (volumes ⇐32 MB) , Media descriptor 0xf8, sectors/FAT 20, heads 64, serial number 0x15128ee6, label: ” ”, FAT (16 bit)
<FabioOlive> pra esse teste, eu criei um arquivo de 10MB, e pedi pro mkdosfs criar um sistema de arquivos (FAT) nele
<AlissonB> o truncate cria o arquivo?
<FabioOlive> ele escolheu, pelo tamanho da imagem, usar FAT16, que usa 16bits pra armazenar os números de blocos do FS
<FabioOlive> AlissonB: sim, ele cria (ou “corta”) um arquivo com o tamanho desejado
<FabioOlive> se o arquivo já existe, ele “trunca” no tamanho que tu passou
<FabioOlive> notem no hexdump acima como ele escreveu pouca coisa no arquivo
<FabioOlive> só o que ele criou foi um Partition Boot Record (que na verdade apenas indica que o “disco” não é bootável) e inicializou as duas cópias da FAT
<FabioOlive> 00000800 f8 ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 |…………….|
<FabioOlive> 00000810 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…………….|
<FabioOlive> esses bytezinhos ali são uma FAT de 16bits inicializada :) é simples demais mesmo :)
<FabioOlive> ah, uma coisa: notem a saída do comando “file” ali em cima
<FabioOlive> sectors/cluster 4
<FabioOlive> cada “bloco” (que ele chamou de cluster) dessa FAT vai ocupar 4 setores. 4 * 512 == 2048 bytes por “bloco”
<AlissonB> hmmm
<FabioOlive> agora vou montar essa imagem e criar um arquivo, pra gente ver as mudanças
<GLLanzana> AlissonB, me manda o log amanha. to via android em pf.
<AlissonB> [GLLanzana]: blz, o FabioOlive manda pra lista amanhã :)
<FabioOlive> $ hexdump -C teste-fat.img
<FabioOlive> …
<FabioOlive> 00000800 f8 ff ff ff 00 00 ff ff 00 00 00 00 00 00 00 00 |…………….|
<FabioOlive> 00000810 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…………….|
<FabioOlive> *
<FabioOlive> 00003000 f8 ff ff ff 00 00 ff ff 00 00 00 00 00 00 00 00 |…………….|
<FabioOlive> 00003010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…………….|
<FabioOlive> *
<FabioOlive> 00005800 41 74 00 65 00 73 00 74 00 65 00 0f 00 db 2e 00 |At.e.s.t.e……|
<FabioOlive> 00005810 74 00 78 00 74 00 00 00 ff ff 00 00 ff ff ff ff |t.x.t………..|
<FabioOlive> 00005820 54 45 53 54 45 20 20 20 54 58 54 20 00 00 a0 08 |TESTE TXT ….|
<FabioOlive> 00005830 7c 41 7c 41 00 00 a0 08 7c 41 03 00 0d 00 00 00 ||A|A….|A……|
<FabioOlive> 00005840 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…………….|
<FabioOlive> *
<FabioOlive> 0000a000 74 65 73 74 65 20 64 65 20 46 41 54 0a 00 00 00 |teste de FAT….|
<FabioOlive> 0000a010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…………….|
<AlissonB> os pontos são espaços?
<AlissonB> 00 = espaço em hexa?
<FabioOlive> notem que ele mudou um pouco as FATs, basicamente alocando um bloco pro conteúdo do arquivo
<FabioOlive> 00 é 0, o hexdump mostra um . porque não é um caractere imprimível :)
<FabioOlive> a FAT mudou de:
<FabioOlive> 00000800 f8 ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 |…………….|
<FabioOlive> pra
<FabioOlive> 00000800 f8 ff ff ff 00 00 ff ff 00 00 00 00 00 00 00 00 |…………….|
<FabioOlive> ou seja, só adicionou um 0xffff ali
<FabioOlive> não vamos entrar agora em detalhes de como a FAT encadeia os blocos, mas basta dizer que ela alocou o 4º bloco do volume para o arquivo, e que era o último (e único) bloco do arquivo
<FabioOlive> (4º pois é a quarto número de 16bits desde o início da FAT)
<AlissonB> e como a gente identifica os bytes ai na saída do hexdump?
<AlissonB> tipo, daqui até aqui é tanto…
<FabioOlive> AlissonB: como assim?
<AlissonB> como eu consigo identificar que é no 4º só olhando a saída do hexdump?
<FabioOlive> a partir de 0x00000800 temos 0xfff8 0xffff 0x0000 e 0xffff :)
<FabioOlive> 16 bits == 2 bytes, == f8 ff acima, que é o número 0xfff8 de 16bits
<AlissonB> isso ainda tá meio obscuro pra mim
<AlissonB> hehe
<FabioOlive> vai escovando bits que um dia cai a ficha
<FabioOlive> o conteúdo do arquivo está fácil de achar :)
<FabioOlive> 0000a000 74 65 73 74 65 20 64 65 20 46 41 54 0a 00 00 00 |teste de FAT….|
<FabioOlive> 0000a010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…………….|
<FabioOlive> eu tinha rodado ”””[root@odin ~]# echo teste de FAT > /mnt/teste.txt”””
<FabioOlive> o que é um pouco mais obscuro é entender o diretório raiz, com o nome do arquivo e tal
<FabioOlive> 00005800 41 74 00 65 00 73 00 74 00 65 00 0f 00 db 2e 00 |At.e.s.t.e……|
<FabioOlive> 00005810 74 00 78 00 74 00 00 00 ff ff 00 00 ff ff ff ff |t.x.t………..|
<FabioOlive> 00005820 54 45 53 54 45 20 20 20 54 58 54 20 00 00 a0 08 |TESTE TXT ….|
<FabioOlive> 00005830 7c 41 7c 41 00 00 a0 08 7c 41 03 00 0d 00 00 00 ||A|A….|A……|
<FabioOlive> cada nome em um diretório de um FS FAT tem exatamente 32 bytes
<FabioOlive> ali em cima temos 64 bytes, pois além de guardar o nome “nativo” TESTE.TXT (o FAT original não diferencia maiúsculas de minúsculas e sempre guarda tudo em maiúsculas), e o nome “chique” teste.txt, para o uso dos DOS mais novos, como DOS XP, DOS Vista, DOS 7 e o novíssimo DOS 8 :)
<FabioOlive> na época do WinDOS 95, foi criada uma extensão/gambiarra em cima do FAT para guardar nomes bonitos de arquivos
<FabioOlive> que basicamente usam entradas de diretórios padrão do FAT com atributos “impossíveis” e guardam o nome bonito nelas
<FabioOlive> é aquilo que se vê como “At.e.s.t.e……” “t.x.t………..” acima
<AlissonB> tem como fazer uma saída normal disso?
<AlissonB> tipo
<AlissonB> hexdump -C nome | ……
<FabioOlive> ?
<FabioOlive> como assim “normal”?
<AlissonB> um outro comando que transforma em texto legível
<FabioOlive> isso é o normal, isso é a grande gambiarra que é o FAT :)
<AlissonB> mas digamos que eu esteja analisando a tua imagem em FAT
<_edEr> vish
<FabioOlive> bom, pra ler de forma legível, o melhor é montar e ler :) o Sistema de Arquivos vai saber interpretar essa gambiarra por nós :)
<AlissonB> hm, boa :)
<FabioOlive> $ sudo mount -o loop teste-fat.img /mnt
<FabioOlive> $ ls -l /mnt
<FabioOlive> total 2
<FabioOlive> -rwxr-xr-x. 1 root root 13 Nov 27 23:05 teste.txt
<FabioOlive> :)
<AlissonB> nice
<AlissonB> o que é a opção loop?
<FabioOlive> mas veja a gambiarra que o Sistema de Arquivos tem que desfazer pra gente poder ler isso :)
<FabioOlive> no mount, a opção loop diz que é pra montar um arquivo como se fosse uma partição
<FabioOlive> ignore isso por agora
<AlissonB> :)
<FabioOlive> na verdade aquela primeira entrada de diretório na imagem a gente pode remover, que a versão “crua” TESTE.TXT continuará válida
<FabioOlive> vamos testar isso :)
<FabioOlive> vou abrir com hexedit e zerar essa parte toda:
<FabioOlive> 00005800 41 74 00 65 00 73 00 74 00 65 00 0f 00 db 2e 00 |At.e.s.t.e……|
<FabioOlive> 00005810 74 00 78 00 74 00 00 00 ff ff 00 00 ff ff ff ff |t.x.t………..|
<FabioOlive> $ hexdump -C teste-fat.img
<FabioOlive> …
<FabioOlive> *
<FabioOlive> 00005820 54 45 53 54 45 20 20 20 54 58 54 20 00 00 a0 08 |TESTE TXT ….|
<FabioOlive> 00005830 7c 41 7c 41 00 00 a0 08 7c 41 03 00 0d 00 00 00 ||A|A….|A……|
<FabioOlive> 00005840 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…………….|
<FabioOlive> *
<FabioOlive> sumiu aquela parte :) vamos montar e ver
<FabioOlive> $ ls -l /mnt
<FabioOlive> total 2
<FabioOlive> -rwxr-xr-x. 1 root root 13 Nov 27 23:05 TESTE.TXT
<FabioOlive> hehe ficou só o nome “feio”
<FabioOlive> se tentarmos criar um nome de arquivo muito grande, fica mais feio ainda
<AlissonB> BLABLA~
<AlissonB> algo assim
<AlissonB> massa
<AlissonB> desmascarando a fat
<AlissonB> hahahah
<FabioOlive> [root@odin ~]# ll /mnt/
<FabioOlive> total 4
<FabioOlive> -rwxr-xr-x. 1 root root 21 Nov 27 23:23 nome-de-arquivo-super-grande-pra-FAT.txt
<FabioOlive> 00005840 44 74 00 00 00 ff ff ff ff ff ff 0f 00 44 ff ff |Dt………..D..|
<FabioOlive> 00005850 ff ff ff ff ff ff ff ff ff ff 00 00 ff ff ff ff |…………….|
<FabioOlive> 00005860 03 64 00 65 00 2d 00 70 00 72 00 0f 00 44 61 00 |.d.e.-.p.r…Da.|
<FabioOlive> 00005870 2d 00 46 00 41 00 54 00 2e 00 00 00 74 00 78 00 |-.F.A.T…..t.x.|
<FabioOlive> 00005880 02 76 00 6f 00 2d 00 73 00 75 00 0f 00 44 70 00 |.v.o.-.s.u…Dp.|
<FabioOlive> 00005890 65 00 72 00 2d 00 67 00 72 00 00 00 61 00 6e 00 |e.r.-.g.r…a.n.|
<FabioOlive> 000058a0 01 6e 00 6f 00 6d 00 65 00 2d 00 0f 00 44 64 00 |.n.o.m.e.-…Dd.|
<FabioOlive> 000058b0 65 00 2d 00 61 00 72 00 71 00 00 00 75 00 69 00 |e.-.a.r.q…u.i.|
<FabioOlive> 000058c0 4e 4f 4d 45 2d 44 7e 31 54 58 54 20 00 00 f5 0a |NOME-D~1TXT ….|
<FabioOlive> 000058d0 7c 41 7c 41 00 00 f5 0a 7c 41 04 00 15 00 00 00 ||A|A….|A……|
<FabioOlive> olha que chinelagem :)
<AlissonB> :)
<FabioOlive> o nome padrão do DOS ficou NOME-D~1.TXT
<FabioOlive> pois o FAT original só pode ter 8 caracteres para o nome e 3 pra extensão
<FabioOlive> e o nome “bonito” ficou esparramado nas entradas de diretório anteriores
<AlissonB> overflow
<FabioOlive> então abrindo essa FAT em um DOS antigo ele não vai entender nada e vai mostrar só o NOME-D~1.TXT
<AlissonB> já vi disso
<FabioOlive> já um DOS mais novo (como o DOS XP e Ultimate DOS 7) vai saber da gambiarra e na verdade olhar as entradas de diretório anteriores a ele, e ver se naquela bagunça ele acha um nome “bonito”
<FabioOlive> note que gastou uma entrada inteira de 32 bytes pra armazenar o último “t” de nome-de-arquivo-super-grande-pra-FAT.txt
<FabioOlive> já um sistema de arquivos Unix é muito mais elegante
<FabioOlive> e já é feito para armazenar nomes de arquivos com até 256 caracteres ou mais
<FabioOlive> sem xunxo
<FabioOlive> dentro daqueles 32 bytes para cada entrada do diretório, estão coisas como o nome, os atributos, o tamanho e qual é o primeiro bloco do arquivo
<FabioOlive> buscando no google por “fat directory entry format” dá pra olhar e decodificar manualmente aqueles bytes
<FabioOlive> 000058c0 4e 4f 4d 45 2d 44 7e 31 54 58 54 20 00 00 f5 0a |NOME-D~1TXT ….|
<FabioOlive> 000058d0 7c 41 7c 41 00 00 f5 0a 7c 41 04 00 15 00 00 00 ||A|A….|A……|
<FabioOlive> mas antes é bom saber se vocês ainda estão acordados :Ð
<AlissonB> im
<AlissonB> (:
<_edEr> up
<_edEr> {:
<_edEr> ativos capitão!
<NathanScapini> opa
<NathanScapini> Na escuta
<FabioOlive> ok! vamos ver então :)
<AlissonB> só uma dúvida antes de prosseguir
<AlissonB> 4e = quantos bytes?
<AlissonB> ali em cima
<AlissonB> cada bloco de dois digitos em hexa
<FabioOlive> http://en.wikipedia.org/wiki/File_Allocation_Table
<NathanScapini> não estou participando ativamente porque tenho que entregar o Projeto de pesquisa até sexta e falta bastante ainda, vish. Mas estou lendo daqui =D
<FabioOlive> ok beleza NathanScapini :)
<FabioOlive> AlissonB: é um byte tchê
<FabioOlive> AlissonB: olha a primeira aula :)
<AlissonB> hum, isso que eu reli já hehe :A
<FabioOlive> um byte contém 8 bits, que podem se expressos em dois dígitos hexadecimais
<FabioOlive> de 00 a FF
<FabioOlive> .o>
<AlissonB> boa!
<_edEr> tá dormindo AlissonB
<_edEr> kkk
<AlissonB> o cérebro vai parando gradativamente
<_edEr> humm
<FabioOlive> lendo em http://en.wikipedia.org/wiki/File_Allocation_Table#Directory_entry vamos decodificar
<AlissonB> prossiga por favor FabioOlive :)
<FabioOlive> como já notamos, os primeiros 8 bytes são o nome “curto” e depois os próximos 3 são a extensão “curta”
<FabioOlive> depois disso temos um byte para atributos
<FabioOlive> que nesse caso é o valor 0x20 na primeira linha
<FabioOlive> que simplesmente indica que é um arquivo normal e que não foi feito backup dele ainda :) bit chamado “Archive”
<FabioOlive> depois temos um byte ignorado, sem conteúdo útil para nenhum sistema atual
<FabioOlive> (o primeiro 0x00 da primeira linha)
<AlissonB> agora peguei o fio da meada
<AlissonB> :D
<FabioOlive> depois temos o primeiro caractere do nome do arquivo se ele tiver sido deletado, pois no FAT ele “deleta” arquivos mudando o primeiro byte pra E5
<FabioOlive> (burrice incrível)
<_edEr> O.o
<FabioOlive> isso é o segundo 0x00 da primeira linha
<FabioOlive> depois os dois últimos bytes da primeira linha são a hora de criação do arquivo
<FabioOlive> codificado de maneira estranha :)
<_edEr> OxF50A
<_edEr> ?
<_edEr> isso é a hora?
<AlissonB> sim
<FabioOlive> isso, neste caso como é little-endian, se lê como 0x0af5
<FabioOlive> pois o byte menos significativo do número de 16bits é escrito antes
<AlissonB> outra hora explica isso de little-endian e big-endian :)
<FabioOlive> sim :)
<FabioOlive> passando pra segunda linha, os primeiros dois bytes indicam a data de criação do arquivo
<FabioOlive> 000058c0 4e 4f 4d 45 2d 44 7e 31 54 58 54 20 00 00 f5 0a |NOME-D~1TXT ….|
<FabioOlive> 000058d0 7c 41 7c 41 00 00 f5 0a 7c 41 04 00 15 00 00 00 ||A|A….|A……|
<FabioOlive> seria o 7c 41 ali
<FabioOlive> depois mais 2 bytes para a data do último acesso, notem que é igual, 7c 41
<FabioOlive> a data de hoje é codificada de forma bem compacta nos bits ali, e vai no máximo até 2099
<FabioOlive> espero que até lá não se use mais FAT!
<_edEr> auwehuawheuauwe
<_edEr> somos 2
<FabioOlive> depois temos mais 2 bytes para direitos de acesso (00 00), 2 bytes para hora da última modificação (f5 0a)
<FabioOlive> depois data da última modificação (7c 41 de novo), depois finalmente chegamos em 2 bytes que indicam qual é o primeiro bloco no disco de conteúdo do arquivo (04 00 ou seja, bloco 0x0004) <FabioOlive> depois disso, os últimos 4 bytes são o tamanho do arquivo (15 00 00 00, o que dá um tamanho de 0x00000015 ou 21 bytes)
<FabioOlive> nota-se que um sistema de arquivos FAT não pode ter arquivos com mais de 4GB de tamanho, pois não cabe nos 32bits usados para o campo tamanho no diretório
<_edEr> humm
<_edEr> por isso então
<FabioOlive> a única coisa que presta pensar agora é naquela informação do primeiro bloco do arquivo
<Uhilian> Nicee
<FabioOlive> tem um 0x0004 ali
<_edEr> eu ia perguntar antes. mas resolvi esperar.. ^^)
<FabioOlive> “o quarto bloco”
<FabioOlive> 0000a800 74 65 73 74 65 20 64 65 20 6e 6f 6d 65 20 67 72 |teste de nome gr|
<FabioOlive> 0000a810 61 6e 64 65 0a 00 00 00 00 00 00 00 00 00 00 00 |ande…………|
<FabioOlive> o hexdump mostrou o conteúdo a partir do byte 0000a800 do início da imagem
<FabioOlive> e cada bloco nessa imagem tem 2048 bytes
<FabioOlive> vamos dividir pra ver
<FabioOlive> $ echo $1)
<FabioOlive> 21
<FabioOlive> na verdade está no bloco 21 a partir do início da “partição”
<FabioOlive> MAS
<FabioOlive> temos que descontar os blocos gastos com o setor de boot e as FATs
<FabioOlive> lá em cima o comando “file” disse que cada FAT ocupa 20 setores, que dá 5 blocos pra cada uma
<FabioOlive> então desconta 10 porque são duas FATs
<FabioOlive> desconta 1 porque o primeiro bloco é o partition boot record/superbloco do FAT
<FabioOlive> o file disse também que no diretório raiz cabem 512 entradas, e são 32 bytes pra cada uma
<FabioOlive> $ echo $2)
<FabioOlive> 8
<FabioOlive> desconta 8 blocos gastos para o diretório raiz então
<FabioOlive> então juntando, temos 1 + 10 + 8 == 19 blocos gastos para PBR, FAT e raiz
<FabioOlive> aí o bloco 20 é ocupado pelo arquivo TESTE.TXT, e o bloco 21 para o arquivo NOME-D~1TXT
<FabioOlive> :)
<FabioOlive> continua meio misterioso porque é que ele chama o bloco 21 de 4, mas tudo bem :) tava vendo agora que o TESTE.TXT ficou no bloco 20, e ele chamou isso de 0x0003
<FabioOlive> coisas do FAT
<_edEr> O.o
<FabioOlive> talvez seja 3 e 4 a partir de algum ponto mágico do disco :)
<_edEr> o FAT é um cara muito estranho.. kkk
<FabioOlive> sim
<FabioOlive> pense num sistema de arquivos que foi criado na década de 1970 para discos em que cabiam 180KB ou coisa do tipo
<FabioOlive> bom gente, já é meia-noite
<FabioOlive> está bom por hoje? :)
<_edEr> verdade
<AlissonB> acho que sim :D
<AlissonB> tenho que reler com calma
<_edEr> pra época era grande coisa já
<AlissonB> amanhã
<_edEr> vish.. verdade
<AlissonB> muita coisa nova pra digerir
<FabioOlive> :)
<_edEr> por isso que estou com a sensação que tem areia nos olhos.. kkk
<FabioOlive> vou pegar o log e mandar pra lista
<AlissonB> isso :)
<_edEr> ok
<_edEr> =]
<FabioOlive> hoje foi uma escovada furiosa né?
<_edEr> bah.. foi show
<_edEr> =D
<AlissonB> doidera low level (by Eliezer)
<_edEr> :)
<FabioOlive> mais low level que isso só puxando o ferro de solda :)
<AlissonB> HAHAUHAUHAUHAUH
<AlissonB> boa
<NathanScapini> asodkaodkasokadoaskdasodkodask
<FabioOlive> então tá gurizada! boas escovadas por aí, vou mandar o log e me mandar pra cama :) boas noites!
