+--------------------------------+
		     ¦ Data dissimulation techniques: ¦
		     ¦ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  ¦
		     ¦      Hiding your data in       ¦
		     ¦  a Restricted and Patrolled    ¦
		     ¦    District of CyberSpace.     ¦
		     ¦ ------------------------------ ¦
		     ¦      Written by  Arscene       ¦
		     ¦           for N0Way            ¦
		     +--------------------------------+

 I) Intro & Thanks & Disclaimer
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Dans la, heum, discipline, qui est la notre 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 access, et generalement dont il ne profite pas
 pleinement.  Il nous arrive aussi d'avoir a communiquer dans un
 environnement peu sur et controlé par des individus paranoiaques et
 megalomanes.  C'est pour ces deux raisons que j'ai ecrit ce file.
 Il s'adresse a tous, et j'espere qu'il vous sera utile (Que j'ai
 pas passé des nuits blanches pour rien, quoi).
  Remerciements/greets/good_karma a NeurAlien, Omega et O'Connell
 pour etre qui ils sont.
  GreetZ a tous les lecteurs de N0Way. N'oubliez pas que l'avenir;
 c'est vous.  Et que vous etes defini par vos actions, et non votre
 passé.
  This file also dedicated to Mr Toubon for his open mindedness and
 his efforts towards harmonious internationalisation.  Also to Mr
 Pasqua for his efforts to preserve peace at all cost and his
 unswaying belief in the principles of democracy, justice, and
 freedom.
  Bon, je suis sur que NeurAlien vas nous faire une superbe
 Disclaimer     qui couvre tout, mais j'aimerais rajouter la mienne:
  
  De ce texte complet, je n'ais ecrit et pensé que ces trois lignes.
  Dans ces trois lignes, une et une seule est un mensonge.
  Avant-hier, j'ai pensé voir un OVNI.
							     
 Faites moi du mail sur ce que vous pensez de ce Disclaimer, et vos
 idées pour faire mieux.

 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
 Supervisor, 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 object 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)...
 
 X) Bon, ben la le file est fini.  J'espere que vous avez apprecié,
 car ce fut interessant a ecrire.  En cas ou vous auriez deja
 oublié, me llamo Arscene, et je prends data/info/mail/insultes/louanges/
 demandes_en_marriage/pots_de_vin/prix_pulitzer/etc en bal Arscene sur
 The 0NE, le RTC EFZ, ou sur A-D. Si besoin, voici ma clé:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.3a

mQCNAi501fkAAAEEAMJm9gMhAGYaOnjYFzTVWxAX17rDX4tUjRG7wD6u5BgyOWFL
gtyx3p8NQJCtjZOuRGOvSRFdm0l/fYY3qWbaXFOSRAY516ihc0OZurYaTROoIk3u
/PuCUC9cHJmnFX6LpHj8MUtEpk1A19dM5UYmKQekDcSavCPv/xRorln5z03NAAUR
tAdBcnNjZW5l
=IosC
-----END PGP PUBLIC KEY BLOCK-----
 Contactez moi en BAL avant de m'envoyer quelque chose de
confidentiel pour verifier que vous avez bien ma VRAIE clé.
---------------------------------------------------------------------