Data dissimulation techniques I) Intro il arrive souvent que nous ayions a dissimuler une certaine quantité de Data sur un systeme que nous visitions, ou qui possede des resources auquelles nous n'avons pas accès, et generalement dont il ne profite pas pleinement. Il nous arrive aussi d'avoir à communiquer dans un environnement peu sur et controlé par des admin paranoïaques et megalomanes. II) Cacher un file dans le OS ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Bon, d'abord les principes de base. Si vous etes sur un systeme 'étranger' (dont vous n'avez pas le controle complet), il arrive que vous vouliez posseder quelques files (fichiers), sans que les autres users, ou meme le root, ne le sache. Il faut donc les cacher. 1) Les attributs de systeme: La, on pense tout de suite aux attributs speciaux de fichiers (Caché ou Systeme, sous MS-DOS). Mais, si ces attributs font partie du systeme ils sont tres connus, et bon nombre de programmes peuvent les modifier, ou les ignorent tout simplement. Ils servent en general a proteger l'utilisateur de lui meme, en evitant par exemple qu'il n'efface des fichiers systemes. Par exemple: Crééz un fichier DOS puis faites soit ATTRIB +H ou ATTRIB +S dessus, et allez dans le file manager de Windows (Vous ne l'utilisez peut etre pas souvent, mais le proprietaire de systeme si). Allez sur le drive/dir ou est votre fichier caché. Normalement vous ne le voyez pas. Vous ne pouvez pas non plus l'effacer. Maintenant allez dans Affichage/Par type de fichiers. Cliquez sur 'Visualiser les fichiers systemes/cachés'. En revenant a l'ecran principal vous devriez voir votre fichier, mais en plus il aura un point d'exclamation rouge a coté de son nom, et il n'est plus tres discret maintenant. De meme, si vous avez LapLink 3 (recommandé), vous avez surement remarqué qu'il affiche les fichiers normaux en gris-DOS standard, mais les fichiers cachés ou systemes sont affichés en Blanc (High intensity) avec un '*' devant leur nom. Ideal pour se faire reperer. 2) Le choix: Les attributs du systeme peuvent donc soit bien dissimuler le fichier, soit le rendre tres evident. Il y a donc un choix a faire. Pensez vous que la/les personnes a qui vous voulez dissimuler le fichier seront assez intelligentes pour cliquer sur le bouton ? (C'est une vraie question, pas une question rhetorique). La reponse par default, dans mon cas, est Oui. Je prefere ne pas cacher mes files et utiliser d'autres options. 3) Tout en haut de l'arbre: Comme un objet caché dans un arbre, un file caché profond en haut de l'arbre est plus dur a reperer que si vous le laissiez dans la racine. En regle generale il ne faut rien mettre dans la racine, et preferer au moins 2 niveaux de profondeure. Voici un exemple: Pour une raison qui m'est propre je devais charger un TSR sur une PC en reseau Novell. Il fallait une ligne dans l'autoexec, et un endroit ou mettre le fichier sur le disque dur. Cette machine etait frequement utilisé par le SUPERVISOR (on se demande ce que faisait le TSR, hum ;-)) et l'AUTOEXEC.BAT lançait un antivirus resident qui scannait la racine de C: au demarage. Les noms des fichiers sur C:\ s'affichant pendant le scan. J'ai donc mis le fichier dans C:\DOS. Ainsi il n'etait pas remarqué par le scan, et la ligne dans l'autoexec ne paraissait pas suspecte car l'autoexec.bat sert justement a charger des programmes du repertoire DOS. Cet exemple me permet d'ajouter qu'il faut toujours essayer de placer un fichier parmi ses semblables, du moins exterieurement (j'y reviendrait en 4). Un autre exemple: J'avais un fichier de +4Mo a dissimuler sur un poste en local, le temps que je puisse amener de quoi le backup et le ramener chez moi. Je l'ai mis dans C:\EXCEL\EXEMPLES\AUTRE, il y a de cela au moins 6 mois. A dernière verification il y etait encore. Peu de gens s'aventurent haut dans un arbre, surtout s'il parait conforme. Une petite note quand meme: N'en faites pas trop. Il ne faut pas que le chemin soit sensiblement plus long que la moyenne sur le disque, car un backup ou un TREE pourrait le reperer aisement. Pour clore cette partie il me faut reserver une mention speciale a nos amis de chez M$, et plus particulierement le repertoire WINDOWS\SYSTEM. Celui-ci existe sur la grande majorité des machines, peut etre meme la votre. Combien d'entre vous savent combien de fichiers ils ont dans ce repertoire, et ce que fait chaque fichier ? En gros, on peut TOUT fourrer dans ce repertoire, si ce n'est ni trop gros ni trop voyant. Personne ne s'en rendra compte. 4) "A rose by any other name would smell as sweet" Pour ceux qui n'auraient pas compris ma citation de Shakespeare, Juliet dit qu'une rose, meme si on changait son nom, aurait quand meme la (bonne) odeure d'une rose. Mais un file ne sent pas, d'ou l'interet de changer son nom pour le dissimuler (Logique suspecte). Un nom qui fasse temporaire ( *.$$$, ~*.TMP, etc) est assez bon pour une courte periode, mais un sys/user intelligent risque de l'effacer au bout d'un moment. Un nom inventé est bon, de preference un nom qui ne soit pas comprehensible, de sorte a faire fichier systeme. Explication: En general un user va essayer de lire un file du nom README.NOW, il lira probablement le file WHATEVER.TXT, peut etre pas WHATEVER.DAT et surement pas PR4)Q567 sans extension. Un nom de ce type est bon, mais ce n'est pas ce qui se fait de mieux. Le nom devrait s'integrer a son environnement. Regardez se qui existe deja dans les alentours. Par exemple j'ai mis deux fichiers (HACK et VIEW pour ceux que cela interresse) dans le ROOT d'un drive ou il existait MENU1.OLD et MENU2.OLD. Simplement en les appelent MENU3.OLD et MENU4.OLD ils sont restes 'invisibles' pendant plus d'un mois (puis je les ais enlevé). CONFIG.OLD (ou .CPS ou .B~K) et la meme chose pour AUTOEXEC font de bon depos temporaires. Pour une plus longue echeance essayer TD451.DRV dans \WINDOWS\SYSTEM ou un truc du genre. 5) Conclusion (de part I) Petite conclusion rapide. Les trois regles d'or pour planquer un file sont: - Le mettre ou en utilisation normale un user ne le verait meme pas. - Que son nom s'integre a son environnement. - Choisir un nom/extension que l'user ne penserait pas, en marche normale a lire/ouvrir/lancer/etc. Et en, heu, regle d'argent: - Autant que possible, le crypter. 6) PS et PPS PS: Si vous cryptez le file il ne faut PAS que cela soit apparent, par exemple PGP met '----- BEGIN PGP MESSAGE -----' (ou un truc du genre) au debut de ce qu'il crypte. Si un sys/user voit cela il risque fort de le delete immediatement. PPS: Dans la serie Revenge/Annoy si vous voulez simplement irriter le sys/user dans ce cas faites tout le contraire de ce que dit ce file. Un fichier de 8Mo du nom de SECRET.COD, OCCULT.SEX, VIRUS.XXX dans le ROOT, completement crypté (du garbage au hasard) avec en premiere ligne 'JF-DES Crypted block. Checksum: 834A4C12' risque grandement d'amuser un sys/user, surtout si il en retrouve des variantes subtiles partout sur son disque :-) III) Cacher un file dans un autre ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Une technique encore plus subtile, et de par la meme meilleure, est de cacher un file directement dans un autre. Le file 'host' devrait etre un fichier anodin, qui a droit de residence legitime sur le systeme. Cela peut permettre de dissimuler encore plus efficacement un file sur un systeme, mais egalement (et probablement encore plus important) est que cette technique permet de créer un chemin sur entre 2 personnes a travers une zone non-sure du CyberSpace. Exemple: Dans les interets de la securité nationale et du peuple, un gouvernement debonnaire a rendu l'echange d'informations cryptés illégales. Non respet de cette loi vous fera deporté en Antarctique. Mais, CyberPunk que vous etes, vous devez envoyer vos C0deZ a quelqu'un. Vous ecrivez votre message, le cryptez. Puis vous digitalisez une photo de votre maison, inserez votre file dans la photo (en remplaçant le gresillement (l'aglomeration urbaine derrière chez vous en low-res) du fond par votre file crypté), puis vous U/L le tout a votre ami. Ce que je viens de decrire est fiction, mais montre un peu les possibilités de cette technique, qui commence d'ailleurs a faire du bruit (Remarquez l'allusion). [ OUh ouh Arscene, ce n'est plus Fiction !!! Cypherella des cypherpunks l'a fait sur Mac deja et j'ai eu des echos comme quoi la meme chose existe sur PC et Unix pour intégrer du code PGP a du JPEG et du GIF. ++NeurAlien] 1) Un peu de pratique Voici quelque endroits, sur PC, ou un file pourrait etre caché: - Dans un TXT: Un fichier TXT se finit par un CR, LF (qui font aller a la ligne) et un marqueur de fin de fichier. En Hex, cela donne 0D 0A 1A. Ajoutez ces 3 bytes a la fin d'un fichier TXT, puis ajoutez du text après, et ni TYPE ni EDIT n'afficheront ce nouveau text. Voici en detail: COPY CON FIRST.TXT >Essai de text XXX^Z (1 fichier ecrit) [Editez ce fichier et remplacez les 3 X respectivement par 0D, 0A et 1A] COPY CON TWO.TXT >Text secret^Z (1 fichier ecrit) COPY FIRST.TXT + TWO.TXT /b FINAL.TXT TYPE FINAL.TXT Essai de text Si vous ouvrez a nouveau FINAL.TXT dans votre editeur Hex vous verrez les 2 lignes. Cette technique n'est pas terrible en pratique (car un bon editeur ASCII ou traitement de texte fera apparaitre tout le texte) mais sert bien de demonstration - Dans un EXE: Tout EXE commence par un header d'une longeure variable de bytes, et avec l'utilisation rependue de compresseurs d'EXE le seul vrai moyen de voir si un header est valide est de lancer l'EXE. Pour inclure ce que vous voulez dans le header il suffit d'allonger sa taille. Cette taille s'exprime en paragraphes (16 bytes = 1 pararaph), est un WORD et ce trouve au 5ème WORD du fichier (10ème et 11ème byte). Après avoir ajouté la longeure de votre fichier / 16 ( + un peu pour etre sur ) au header il suffit d'inclure votre fichier a la fin de ce header. L'EXE devrait toujours fonctionner sans probleme. Si vous compez automatiser l'operation, il est bon d'inclure aussi la longeure du fichier en bytes et l'ancienne longueure du header. - Dans un GIF: Un GIF est formé de plusieures blocs. Un bloc commence par soit par un ',', (une virgule quoi), si c'est une image, par ';' si c'est la fin du fichier (bon, ok, c'est pas vraiment un bloc), ou par '!' si c'est une extension. La, cela devient interressant. Une extension peut etre n'importe quoi, un commentaire par exemple, en general un viewer de GIF reconnait certaines extension, et ignore tout simplement les valeures qu'il ne connait pas. D'ou l'idée de se faire un bloc 'Secret info'. Bon, comme aucun d'entre vous ne paye sa comm pour D/L N0Way, je peut sans crainte vous balancer ces extraits des DOC officielles: La première concerne les extensions GIF en general: GIF Extension Blocks are packaged in a manner similar to that used by the raster data though not compressed. The basic structure is: 7 6 5 4 3 2 1 0 Byte # +---------------+ |0 0 1 0 0 0 0 1| 1 '!' - GIF Extension Block Introducer +---------------+ | function code | 2 Extension function code (0 to 255) +---------------+ ---+ | byte count | | +---------------+ | : : +-- Repeated as many times as necessary |func data bytes| | : : | +---------------+ ---+ . . . . . . +---------------+ |0 0 0 0 0 0 0 0| zero byte count (terminates block) +---------------+ A GIF Extension Block may immediately preceed any Image Descriptor or occur before the GIF Terminator. All GIF decoders must be able to recognize the existence of GIF Extension Blocks and read past them if unable to process the function code. La seconde concerne le bloc d'extension particulier qui nous interresse: 26. Application Extension. a. Description. The Application Extension contains application-specific information; it conforms with the extension block syntax, as described below, and its block label is 0xFF. b. Required Version. 89a. c. Syntax. 7 6 5 4 3 2 1 0 Field Name Type +---------------+ 0 | | Extension Introducer ['!'] Byte +---------------+ 1 | | Extension Label [0xFF] Byte +---------------+ +---------------+ 0 | | Block Size [11] Byte +---------------+ 1 | | +- -+ 2 | | +- -+ 3 | | Application Identifier 8 Bytes +- -+ 4 | | +- -+ 5 | | +- -+ 6 | | +- -+ 7 | | +- -+ 8 | | +---------------+ 9 | | +- -+ 10 | | Appl. Authentication Code 3 Bytes +- -+ 11 | | +---------------+ +===============+ | | | | Application Data Data Sub-blocks | | | | +===============+ +---------------+ 0 | | Block Terminator Byte +---------------+ i) Extension Introducer - Defines this block as an extension. This field contains the fixed value 0x21 ['!' en ASCII]. ii) Application Extension Label - Identifies the block as an Application Extension. This field contains the fixed value 0xFF. iii) Block Size - Number of bytes in this extension block, following the Block Size field, up to but not including the beginning of the Application Data. This field contains the fixed value 11. iv) Application Identifier - Sequence of eight printable ASCII characters used to identify the application owning the Application Extension. v) Application Authentication Code - Sequence of three bytes used to authenticate the Application Identifier. An Application program may use an algorithm to compute a binary code that uniquely identifies it as the application owning the Application Extension. d. Extensions and Scope. This block does not have scope. This block cannot be modified by any extension. e. Recommendation. None. Bon, j'espere que tout le monde a compris :-) Ce qu'il faut faire devient plus clair: Trouvez un endroit ou mettre notre bloc, par exemple la fin du fichier ( seek(file, -1, SEEK_END); en C. La fin d'un GIF est marqué par un ';' ). Il suffit d'y inserer un '!', le code disant que ceci est une Application Extension (0xFF), le numero 11, puis votre ID specifique (Sur Compu$serve en forum PICS il y a une liste rassemblent tous le Application ID deja utilisés, liste geré par Larry Wood). Puis vous mettez votre code de 3 bytes, sorte de signature pour verifier que ce n'est pas un faux bloc, puis finalement vous balancez votre file, sans trop vous soucier de la compression (qui selon la doc doit etre RLE), car de toute façon il sera decodé par un soft maison, et pas par le viewer de GIF. Verifiez quand meme qu'aucun byte ne vaut 0, car ce byte marque la fin du bloc. Voila, une methode discrete et aisé. Merci Compu$serve. 2) Finalement... Au fait, j'ai traité certaines methodes, et j'espere que vous pensez deja a d'autres (elles sont illimités). Mais, je n'ais pas parlé de celle mentionné dans l'intro, du Crypted text dans du graphic. Ben, heu, a vous de la faire :-) Serieusement j'etudie la question, et j'ai vu certains programmes sur BBS qui pretendait faire exactement cela. Peut-etre un article ulterieure (enfin, j'ai dit peut-etre)...