Webmaster anonyme ; est-ce possible ?

Après m’être posé la question de comment créer un site web de façon anonyme sur Internet, je vous livre une petite procédure qui attend vos objections avec impatience… Attention, ceci n’est pas forcement très légal, au moins selon l’usage que vous en faites, et je ne vous recommande pas son usage si ce n’est dans le but pédagogique…

  • Tout d’abord je propose d’acheter une clef usb wifi en liquide pour éliminer les trace liées à l’adresse MAC plus tard. (il y a d’autres solutions, mais celle-ci est sûre)
  • D’installer ensuite une distribution Linux dans une VM pour s’assurer que toutes les trace OS seront vierges
  • Se connecter ensuite depuis un mac-do où l’on a obtenu une clef wep apres paiement de son burger en liquide
  • On ne se connectera au reseau wifi qu’en utilisant la clef wifi associée à la VM
  • L’etape suivante est de se créer un compte email (hotmail, gmail…)
  • Puis un compte paypal associé à cet email
  • Il faut ensuite un compte ebay sur lequel on vendra des produits divers, en exigeant un paiement paypal qui viendra remplir le compte paypal precedemment crée; les objets doivent être envoyés sans traces ; s’ils passent dans une enveloppe c’est mieux pour ne pas laisser de trace chez collisimo
  • En possession d’une identité vituelle et d’un peu d’argent, il est assez simple de trouver un vendeur de noms de domaine et d’hébergement qui accepte le paiement par paypal
  • A ce moment, il me semble que paypal demandera un numéro de carte bleu, là arrive l’opération la plus délicate et franchement illégale (donc à ne pas faire) qui consiste à rentrer le numéro de CB d’autrui. Le compte ne sera pas débité si le montant présent sur le paypal est suffisant ; il n’y aura donc pas de trace
  • Reste à installer le site …

La méthode est simple, je ne vous donne pas toutes les clefs, ceci est une démonstration de principe, c’est tout. Le principal problème est le nombre de burgers à ingérer pour supporter tout le processus.

Locker son ecran sur Mac Os X (tiger)

Il me semble étrange de constater combien il est compliqué de locker son écran sous Mac OS X quand cette fonctionnalité est la première de toute démarche de sureté. Bref… heureusement une solution existe. Plusieurs d’ailleurs, référencées dans le lien ci-joint.
La méthode qui me semble la plus pratique consiste à lancer le “Trousseau d’accès” depuis “Applications/Utilitaires” puis de choisir les préférences, et dans l’onglet “général”, cocher la case “Afficher l’état dans la barre des menus”. Vous aurez alors, dans la barre des menu, en haut de l’écran un petit cadenas permettant de locker l’écran en deux clicks.

Propagation de virus au travers de Wifi (anticipation)

Le fait de voir toutes ses AP visibles depuis mon réseau Wifi me font imaginer une nouvelle façon de propager un virus … un système nouveau efficasse et totalement automatique … Bien sure c’est totalement imaginaire, mais peut etre l’avenir ?
Voici quelques idées un peu en vrac…
Les virus que je trouve les plus impressionnant et interressant (disons intellectuellement parlant uniquement) sont ceux qui sont capable de s’auto-répliquer sans action de la part de l’utilisateur : ils sont emis par des machines infectées qui vous attaquent presque au hazard quand vous vous connectez sur Internet par exemple, s’installent puis se répliquent …

Le voie de contamination par l’Internet est connue, est en partie protégée par les systèmes de NAT et firewall intégrées aux routeurs.
Il existe maintenant une nouvelle voie de propagation : nos point d’accès Wifi. En effet, un virus, une fois installé sur une machine pourrait etre capable de scanner l’entourage wifi de votre réseau puis de mettre en oeuvre les technique d’attaque connue pour pénétrer ces réseaux voisins. Il pourra ensuite s’y dubliquer et les copies attaqueront les reseaux voisins… et ainsi de suite.

Avec le maillage Wifi actuel fournit par nos provider hexagonaux, la propagation de la contamination, en ville pourrait etre rapide et très large.

Les applications sont très larges et depassent d’usage classique d’un virus en permettant aussi la creation d’un reseau urbain logique multi-point de sortie / anonymisation …

Tout celà est totalement imaginaire, à ne surtout pas mettre en oeuvre bien sure, mais je trouve l’idée assez interressante.

Pour exister il faut au moins :

  • Une faille exploitable permettant l’auto-réplication des virus
  • Une methode d’attaque Wifi simple et rapide pour le Wep (on l’a) et le WPA
  • Une compatibilité de cette attaque avec le matériel wifi répendu et fonctionnant sous Windows

Avantages :

  • la diffusion du virus est quasiement impossible à tracer
  • La diffusion du virus passera par la voie des airs grace aux machines mobiles, elle penetre de fait une bonne parties de protections de réseaux classique
  • Elle peut s’en prendre à des appareils mobiles pourquoi pas (téléphones, PDA)

Applications :

  • Espionnage et surveillance
  • Constitution d’un reseau anonyme et utilisable de n’importe où en milieu urbain
  • Constitution d’un reseau à très fort maillage et donc très resistant
  • Classique groupe de robots d’attaque…

Cryptage WEP – Comment fonctionne-t-il ?

Quelques lignes pour décrire le fonctionnement d’un cryptage de type wep …
Le WEP (Wired Equivalent Privacy (lol)) repose sur un cryptage simple de type XOR (ou exclusif) entre la chaîne initiale et une clef de même longueur. La dite clef est obtenue par un algorithme RC4 initialisé à partir d’une clef partagée et un IV (Initialization Vector) aléatoire ou tout au moins dynamique.

Le cryptage se fait de la façons suivante :
– L’emetteur choisit un IV de 24 bits qu’il concatène à la clef partagée. De cette façon nous obtenons 2^24 clefs différentes à partir d’une clef partagée statique, elle même de 104 bits (pour un total de 128 bits).
– Le RC4 est initialisé avec cette clef : le but du RC4 est de remplir un tableau de 256 octets avec cette clef, puis de piocher dans ce tableau des valeurs tout en les modifiant au fur et à mesure. Cette methode permet à partir d’un clef d’obtenir une suite unique et pseudo aléatoire de valeurs à sa sortie.
– La sortie du RC4 est ensuite utilisée pour crypter la chaîne à envoyer. Le RC4 genère un flow de bits (ou octets) infini, il est donc tout à fait adapté au cryptage de données de longueur variable comme des trames réseaux.
– La trame est émise vers le destinataire en incluant l’IV de sorte que le destinaitre soit capable de recréer la même suite RC4 pour décrypter le message.
– Le recepteur est donc à même de générer une clef de (dé)cryptage identique à l’emeteur, issue de RC4, il ne lui reste plus qu’à appliquer la même fonction que pour le cryptage puisque (N XOR K) XOR K = N avec N le message initial.

Voila comment celà se passe, comment celà est-il attaqué alors ?
– Tout d’abord, avec une seule clef partagée, il y a 16M de clefs générées, ce qui signifie que la véritable clef de cryptage issue du RC4 change régulièrement, pour ainsi dire à chaque trame ce qui complique la donne.
– Pour attaquer ce type de cryptage, il faut donc tout d’abord s’attaquer à la véritable clef de crytage issue de RC4 et l’identifier ; en identifier un maximum. Pour se faire il est nécessaire de connaitre des données claires et cryptées, récupérer la clef est alors simple, il suffit d’appliquer : (N XOR K) XOR N = K. Cette opération est possible sur certaines trames récurentes dont l’entete est connue des ARP par exemple, ce qui permet de connaitre les premiers octets de la suite.
– Une fois que l’on a collecté de multiples entêtes de clefs issues de RC4 avec leur partie IV associée, il reste à trouver quelles sont les clefs sources ayant le plus probablement conduit à cette génération et ainsi déterminer la clef partagée initiale.
– Cette approche est statistique puisque plusieurs clefs peuvent conduire au même début de suite issu de RC4 (et nous ne connaissons que le début !) Ainsi nous ne pouvons calculer que des suppositions sur le contenu initial du tableau RC4 et eliminer des solutions impossibles.
– De fait pour optimiser la recherche, il est nécessaire, soit d’avoir un maximum de trames et d’IV (de 500.000 à 3 M en général), soit d’avoir des suites plus longues issues du RC4.

Comment fonctionne WEP ?

C’est à grand renfort d’articles sur tout la toile qu’un nouveau POC (Proof Of Concept) vient annoncer que WEP est mort ! rien de bien nouveau en soit puisqu’on l’avait dejà tué depuis des années, mais cette fois la méthode est plus rapide, plus automatique et sans doute bientot à la portée de tous, ou presque.

Est-ce alarmant ? en soit, utiliser Wep est alarmant depuis bien longtemps, donc un peu plus un peu moins ? et si vous dormez sur vos deux oreiles malgré cela et bien continuez ! il n’y a pas de raisons ; le tout c’est d’en être concient, non ?

Qu’est ce que cette nouvelle methode de Bitau, Handley et Joshlack ? Elle repose en fait sur l’utilisation d’un utilitaire existant dans le protocole 802.11 (Wifi) : la fragmentation de trame ou plutot la défragmentation par l’AP. Le rôle de l’AP dans un réseau avec architecture est de recevoir les trames de tout le monde puis de les réémettre : ainsi si tout le monde capte l’AP, tout le monde peut communiquer, y compris si deux postes sont trop distants pour se joindre directement … L’AP etant un périphérique intelligent, lorsqu’il recoit des fragments de trames, il commence par les réunir en trame plus grosses avant de les réémettre. Alors comment cela nous aide-t-il a craquer une clef Wifi, c’est assez simple :
Avec le cryptage WEP, qui n’est autre qu’un simple XOR, il suffit de connaitre une chaine et son equivalent crypté pour connaitre la clef de cryptage, donc puisque nous captons des données cryptées, il nous faut connaitre leur equivalent non crypté pour connaitre la clef associée. Les protocoles de couches basse nous aident en celà : certaines trames LLC/SNAC, ARP ont des parties qui sont constantes et celles-ci sont identifiables par des tailles caractéristiques. En captant ces trames, nous avons des données cryptées et connaissons leur équivalent non crypté. Ainsi il est possible d’obtenir facilement quelques octets de la clef de cryptage (qui n’est cependant pas directment la clef partagée que l’utilisateur configure).
Cette étape accomplie, la nouvelle solution par fragmentation entre en jeu : les morceaux de clef que nous avons sont trop petits, la fragementation va nous permettre de les multiplier : il suffit de renvoyer plusieurs fois la trame reçue en l’indiquant fragmentée : connaissons la cryptée et son équivalent décryptée. L’AP va recevoir ces fragments, les décrypter et les assembler dans une nouvelle trame qu’il va crypter puis, enfin, réémettre cettre trame sur le réseau. Cette trame nous allons pouvoir l’écouter, nous connaissons sa version non cryptée puisqu’il s’agit de la concaténation du message precédent avec lui-même et l’AP vient de nous fournir sa version cryptée. Nous sommes donc à même, comme à l’étape 1 de connaitre la clef associée, mais cette fois nous n’avons plus 8 octets mais n*8 octets (avec n le nombre de framents).

En continuant ainsi il est possible d’obtenir une clef de cryptage valide suffisemment grande pour crypter n’importe quel paquet. Nous allons donc pouvoir emettre sur le réseau n’importe quel paquet, sans connaitre la clef partagée initiale mais simplement la suite issue du RC4. Cette facultée va nous permettre de générer du traffic valide vers le réseau et ainsi collecter un maximum de trames pour, par la suite, lancer une attaque sur ces informations et en déduire la clef partagée (type aircrack).
Cette methode, présentée ainsi est donc une solution plus rapide et encore imparable pour générer du traffic : le principe de defragmentation est à la base du protocole, il est difficile de le bloquer alors que bloquer les réémissions forcée d’une methode aireplay est assez courant. Par ailleurs, il permet de connaitre bcp plus de données de chaque chaînes cryptées (contrairement aux ARP habituels) et ainsi d’etre plus efficasse avec moins de trames.
Cette mehode reste totalement interdite à l’utilisation hors de son propre réseau privé puisqu’elle demande l’emission de données vers le réseau distant, ce qui implique une intrusion dans le dit système, Acte répréhensible par la lois.

Les auteurs de cette methode, proposent une autre alternative à la simple collecte d’informations en vue de connaitre la clef partagée ; en effet, ils proposent d’utiliser cette methode, associée à d’autres pour forcer l’AP à router des paquets cryptés vers l’Internet : dans ce cas, le paquet emis en direction de l’Internet est décrypté par l’AP avant d’etre envoyé sur la ligne (logique on sort du WLAN). Le site distant est alors un site amis du pirate qui va ainsi recevoir les données décryptées issues du réseau WLAN dit “sécurisé” … pas mal ! Le principe en est assez simple, il s’agit de créer une entête IP a destination du serveur sur l’Internet, de l’indiquer fragmenter et de réémettre un paquet crypté que l’on souhaite faire décrypter en l’indiquant comme étant la suite du précédent. L’AP va alors decrypter les deux, concaténer le paquet “secret” à notre entete IP, constater qu’il s’agit d’une trame pour l’extérieur et la router décryptée. Reste que ce type d’attaque est plus facile à tracer qu’un wardriving sauvage, rendu rapide par la methode.

Quid de l’implémentation ? Les auteurs proposent quelques sources de leur POC, la mise en oeuvre demande un contrôle au niveau le plus bas des cartes Wifi, pour, entre autre, gérer les flags permettant la fragmentation au niveau logiciel. Ces possibilités ne sont pas offertes sure toutes les puces ou demandent des workaround un peu touchy .. bref, pour l’instant 2 chips sont supportés dont le PRISM2. Il y a de fortes chances pour que d’autres arrivent.
Point vraiment interressant, ce qu’ils ont mis en oeuvre est totalement automatisé, contrairement à ce qui existe sur aircrack. Les outils aircrack ne peuvent pas etre mis entre toutes les mains, elle doivent toujours être averties : ligne de commandes, options compliquées… Une solution entierement automatisée pourrait etendre la chose aux pirate boutoneux du dimanche …
Il n’en reste pas moins que ca ne marche et ne marchera sans doute jamais que sous Linux et autre BSD ;o)

Portes dérobées dans les BIOS

Les fabriquants de bios prévoient souvent des portes dérobées pour accéder aux bios alors que ceux-ci sont protégés par des mots de passe … bien utile pour s’eviter un démontage suivi de son clear CMOS …
En voici une liste :

Backdoor Passwords

Many BIOS manufacturers have provided backdoor passwords that can be used to access the BIOS setup in the event you have lost your password. These passwords are case sensitive, so you may wish to try a variety of combinations.

WARNING: Some BIOS configurations will lock you out of the system completely if you type in an incorrect password more than 3 times. Read your manufacturers documentation for the BIOS setting before you begin typing in passwords.

Award BIOS backdoor passwords:

ALFAROME	 	BIOSTAR	 	KDD	 	ZAAADA
ALLy	 	CONCAT	 	Lkwpeter	 	ZBAAACA
aLLy	 	CONDO	 	LKWPETER	 	ZJAAADC
aLLY	 	Condo	 	PINT	 	01322222
ALLY	 	d8on	 	pint	 	589589
aPAf	 	djonet	 	SER	 	589721
_award	 	HLT	 	SKY_FOX	 	595595
AWARD_SW	 	J64	 	SYXZ	 	598598
AWARD?SW	 	J256	 	syxz	 	 
AWARD SW	 	J262	 	shift + syxz	 	 
AWARD PW	 	j332	 	TTPTHA	 	 
AWKWARD	 	j322	 	 	 	 
awkward 	 	 	 	 	 	

AMI BIOS Backdoor Passwords:

AMI	 	BIOS	 	PASSWORD	 	HEWITT RAND
AMI?SW	 	AMI_SW	 	LKWPETER	 	CONDO

Phoenix BIOS Backdoor Passwords:

phoenix	 	PHOENIX	 	CMOS	 	BIOS

Misc. Common Passwords

ALFAROME	 	BIOSTAR	 	biostar	 	biosstar
CMOS	 	cmos	 	LKWPETER	 	lkwpeter
setup	 	SETUP	 	Syxz	 	Wodj

Other BIOS Passwords by Manufacturer
Manufacturer      	Password

VOBIS & IBM	merlin
Dell	        Dell
Biostar	        Biostar
Compaq	        Compaq
Enox	        xo11nE
Epox	        central
Freetech	Posterie
IWill	        iwill
Jetway	        spooml
Packard Bell	bell9
QDI	        QDI
Siemens	        SKY_FOX
TMC	        BIGO
Toshiba	        Toshiba

Toshiba BIOS

Most Toshiba laptops and some desktop systems will bypass the BIOS password if the left shift key is held down during boot

IBM Aptiva BIOS

Press both mouse buttons repeatedly during the boot

Appeler la messagerie d’un destinataire

Ce message n’a pas grand chose à faire là et c’est un peu un inclassable mais bon … Petite note pour rappel sur comment obtenir directement la messagerie d’un correspondant plutot que de faire sonner son GSM. Pour France télécom, il faut composer le 06 80 80 ab cd avec abcd tel que le numéro du destinataire est 06 ab cd ?? ??. Pour SFR, il faut appeler le 06 12 00 12 12
Ensuite, se laisser guider par le système vocal.

Patch du driver rt2570 pour permettre le changement d’adresse MAC

Note : depuis mon patch à été ajouté directement dans les drivers natif …

Le drivers rt2570, correspondant aux chip USB ralink souffre d’un petit bug, à moins qu’il ne s’agisse d’une fonctionnalité, je ne sais pas ! il n’est pas possible de changer leur adresse MAC.

Après analyse du problème, il s’avère que lorsque l’on remonte le driver par un ifconfig rausb0 up celui-ci effectue une réinitialisation complète du périphérique incluant donc le rechargement de l’adresse MAC d’origine et venant donc écraser celle configurée précédemment par le ifconfig rausb0 hw ether ….

La solution a ce problème est assez simple, lors de l’init que l’on trouve dans rtusb_main.c il suffit de tester si l’adresse MAC du net_dev vaut 00, auquel cas on charge celle de la carte (premier appel) sinon, on conserve la valeur du net_dev qui correspond à celle forcée.
Ce qui se traduit par :

Dans la fonction usb_rtusb_open, ligne 1231 environ
RTUSBCmd_kill =0;
CreateThreads(net_dev);
memcpy(pAdapter->net->dev_addr, pAdapter->CurrentAddress, pAdapter->net->addr_len);
// Clear Reset Flag before starting receiving/transmitting
RTMP_CLEAR_FLAG(pAdapter, fRTMP_ADAPTER_RESET_IN_PROGRESS);

Va devenir:

RTUSBCmd_kill =0;
CreateThreads(net_dev);
// at every open handler, copy mac address.
// PATCH >>>>>>>>>>>>>>>>>>
if ( net_dev->dev_addr[0] == 0 && net_dev->dev_addr[1] == 0 && net_dev->dev_addr[2] == 0 &&
net_dev->dev_addr[3] == 0 && net_dev->dev_addr[4] == 0 && net_dev->dev_addr[5] == 0 ) {
// First time initialization
memcpy(pAdapter->net->dev_addr, pAdapter->CurrentAddress, pAdapter->net->addr_len);
} else {
// Next time “la vérité est ailleurs!”
memcpy(pAdapter->CurrentAddress, pAdapter->net->dev_addr, pAdapter->net->addr_len);
}
// <<<<<<<<<<<<<<<<< PATCH

// Clear Reset Flag before starting receiving/transmitting
RTMP_CLEAR_FLAG(pAdapter, fRTMP_ADAPTER_RESET_IN_PROGRESS);

Après on recompile, et la solution a l’air de fonctionner …. ??? et bien en fait non elle ne fonctionne pas !! oups.. j’aurais dû un peu plus tester … j’avais un petit oubli … voila qui est corrigé ! merci à larbig d’avoir complété le boulo.
Il semble en effet que l’adresse MAC doit être la même entre le pAdapter et le net_dev sans quoi les trames ne sont pas emises dans l’air … ennuyeux. voici donc le patch complet et cette fois testé !! sisi !! Les modifications sont cette fois dans rtusb_init.c où il faut modifier la fonction NICReadEEPROMParameters de la façon suivante :

VOID    NICReadEEPROMParameters(
        IN      PRT2570ADAPTER  pAdapter)
{
        USHORT                  i;
        int                     value;
        UCHAR                   TmpPhy;
        EEPROM_TX_PWR_STRUC     Power;
        EEPROM_ANTENNA_STRUC    Antenna;//blue
//      EEPROM_VERSION_STRUC    Version;

        DBGPRINT(RT_DEBUG_TRACE,"--> NICReadEEPROMParameters ");

        //Read MAC address.
        RTUSBReadEEPROM(pAdapter, EEPROM_MAC_ADDRESS_BASE_OFFSET, pAdapter->PermanentAddress, ETH_LENGTH_OF_ADDRESS);
        DBGPRINT_RAW(RT_DEBUG_TRACE,"MAC address ReadEEPROM : ");
        for (i = 0; i < ETH_LENGTH_OF_ADDRESS; i++)
                DBGPRINT_RAW(RT_DEBUG_TRACE,"%02x ", pAdapter->PermanentAddress[i]);
        DBGPRINT_RAW(RT_DEBUG_TRACE," ");

        if (pAdapter->PortCfg.bLocalAdminMAC != TRUE)
        {
                pAdapter->CurrentAddress[0] = pAdapter->PermanentAddress[0];
                pAdapter->CurrentAddress[1] = pAdapter->PermanentAddress[1];
                pAdapter->CurrentAddress[2] = pAdapter->PermanentAddress[2];
                pAdapter->CurrentAddress[3] = pAdapter->PermanentAddress[3];
                pAdapter->CurrentAddress[4] = pAdapter->PermanentAddress[4];
                pAdapter->CurrentAddress[5] = pAdapter->PermanentAddress[5];
        }

devient

VOID    NICReadEEPROMParameters(
        IN      PRT2570ADAPTER  pAdapter, struct net_device *net_dev)
{
        USHORT                  i;
        int                     value;
        UCHAR                   TmpPhy;
        EEPROM_TX_PWR_STRUC     Power;
        EEPROM_ANTENNA_STRUC    Antenna;//blue
//      EEPROM_VERSION_STRUC    Version;

        DBGPRINT(RT_DEBUG_TRACE,"--> NICReadEEPROMParameters ");

        //Read MAC address.
        RTUSBReadEEPROM(pAdapter, EEPROM_MAC_ADDRESS_BASE_OFFSET, pAdapter->PermanentAddress, ETH_LENGTH_OF_ADDRESS);
        DBGPRINT_RAW(RT_DEBUG_TRACE,"MAC address ReadEEPROM :");
        for (i = 0; i < ETH_LENGTH_OF_ADDRESS; i++)
                DBGPRINT_RAW(RT_DEBUG_TRACE,"%02x ", pAdapter->PermanentAddress[i]);
        DBGPRINT_RAW(RT_DEBUG_TRACE,"");

        if (pAdapter->PortCfg.bLocalAdminMAC != TRUE)
        {

           if ( net_dev->dev_addr[0] == 0 && net_dev->dev_addr[1] == 0 && net_dev->dev_addr[2] == 0 &&
             net_dev->dev_addr[3] == 0 && net_dev->dev_addr[4] == 0 && net_dev->dev_addr[5] == 0    ) {
                // Startup time ... read the original MAC
                pAdapter->CurrentAddress[0] = pAdapter->PermanentAddress[0];
                pAdapter->CurrentAddress[1] = pAdapter->PermanentAddress[1];
                pAdapter->CurrentAddress[2] = pAdapter->PermanentAddress[2];
                pAdapter->CurrentAddress[3] = pAdapter->PermanentAddress[3];
                pAdapter->CurrentAddress[4] = pAdapter->PermanentAddress[4];
                pAdapter->CurrentAddress[5] = pAdapter->PermanentAddress[5];
           } else {
                // Next time, get the MAC from net_dev->dev_addr
                printk(KERN_INFO "net_dev supplies MAC, activating this one :%02x:%02x:%02x:%02x:%02x:%02x.",
                        net_dev->dev_addr[0], net_dev->dev_addr[1], net_dev->dev_addr[2],
                        net_dev->dev_addr[3], net_dev->dev_addr[4], net_dev->dev_addr[5]);
                memcpy(pAdapter->CurrentAddress, pAdapter->net->dev_addr, pAdapter->net->addr_len);
           }
        }

La mécanique est axactement la même que celle faite précédemment : lors du premier appel on fait comme si de rien n’etait et on recupère l’adresse en EEPROM, pour les appels suivant on choisit la MAC du net_dev à la place.
Pour que ca fonctionne il reste deux petites modifications, modifier le header de cette fonction : dans rt2570sw.h

VOID  NICReadEEPROMParameters(
      IN  PRT2570ADAPTER       pAdapter);

devient :

VOID  NICReadEEPROMParameters(
      IN  PRT2570ADAPTER       pAdapter, 
      struct net_device *net_dev);

enfin il reste l’appel de la fonction de lecture à modifier, dans rtusb_main.c:

   NICReadEEPROMParameters(pAdapter, net_dev);

Ca y est !!