Traitement binaire vers hexadecimal

Le
Zeldus
Bonsoir,

Je dispose d'un fichier "texte" de plusieurs dizaine de Mo composé de 0 et
de 1 généré par une moulinette écrite en C++ pour console Win32. Le but du
fichier est la démonstration du fonctionnement de l'étalement de spectre et
du CDMA (étalement d'un fichier dans un autre à l'aide d'un code de Gold par
exemple), exactement ce qu'on trouve dans le fonctionnement du GPS, l'UMTS
ou le WiFi 802.11a (mode DSS). En gros, on réalise des opérations de XOR bit
par bit à des vitesses différentes entre le fichier et une clé donnée ou un
autre fichier.

La petit programme génère bien un fichier résultant composé de 0 et de 1
conforme au fonctionnement de l'étalement de spectre. Le problème, c'est
qu'il n'est pas possible de travailler sur des octets car le GPS ou le WiFi
font des opérations de XOR sur des bits individuellement et que cela change
tout par rapport à un traitement octet par octet. Comment convertir ce
fichier sorti en un véritable fichier binaire qui puisse s'afficher dans un
éditeur hexadecimal avec non pas un affichage des codes ASCII des "0" et des
"1" mais un regroupement en hexa des bits 8 par 8 en binaire pur ? Cela
permettra de stocker le fichier en divisant la taille par 8, un bit ne sera
plus stockés individiellement par un octet mais par un bit sur le disque
dur. J'ai essayé 3 ou 4 éditeurs hexadécimaux (dont winhex) mais aucun ne
permet cette fonctionnalité. Y a-t-il un moyen d'éviter l'écriture d'une
routine en C++ ? Sinon, quelqu'un a-t-il un lien sur un éventuel exemple de
routine utilisable ?

Je ne sais pas si j'ai été assez clair, c'est assez spécifique comme
opération

Par avance, merci,

Zeldus
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
IOBA
Le #307125
"Zeldus" 46589ee2$0$19019$
| J'ai essayé 3 ou 4 éditeurs hexadécimaux (dont winhex) mais aucun ne
| permet cette fonctionnalité.

Si j'ai bien compris, tu es passé à côté du truc : dans WinHex, tu tapes
Alt+F5, et tu choisis ton format

Pas bien pigé ? C'est pas ça ?

--
IOBA
Fabien LE LEZ
Le #307124
On Sat, 26 May 2007 22:56:05 +0200, "Zeldus"
Y a-t-il un moyen d'éviter l'écriture d'une
routine en C++ ?


Je ne saisis pas bien le sens de ta question.
Je pense avoir compris ce que tu cherches à faire, mais si tu veux
éviter de le faire en C++, ben... faut pas écrire sur un forum
consacré au langage C++ !

C'est a priori assez trivial à faire en Perl, en PHP ou en C.
En Lisp, il y a certainement une solution très élégante pour les
connaisseurs, mais totalement incompréhensible pour le commun des
mortels.
Je me demande si on peut faire ça en bash. Si oui, ça m'intéresserait
de voir le programme...

Note que si ton but est que le fichier prenne moins de place sur le
disque, il suffit de le ziper.

Fabien LE LEZ
Le #307123
On Sat, 26 May 2007 22:56:05 +0200, "Zeldus"
Le problème, c'est
qu'il n'est pas possible de travailler sur des octets car le GPS ou le WiFi
font des opérations de XOR sur des bits individuellement


On peut très bien travailler sur des bits individuels à l'intérieur
d'octets.

Comment convertir ce
fichier sorti en un véritable fichier binaire


J'ai pondu à la va-vite un code tout pourri, qui pourrait fonctionner
si les phases de la Lune sont favorables. Je te laisse corriger,
tester, commenter, etc.

#include <iostream>
#include <fstream>

class DestinationBits
{
public:
void AjouterUnBit (int bit)
{
/* Une seule de ces deux lignes est valable, suivant l'ordre des
bits dans le fichier (poids fort au début ou à la fin). */
data= (data << 1) + bit;
//data|= bit << nb_bits;

if (++nb_bits == 8)
{
EnregistreOctet (data);
nb_bits= 0;
data= 0;
}
}

DestinationBits (std::ostream& destination_)
: data (0), nb_bits (0), destination (destination_) {}

private:
unsigned char data;
int nb_bits;
std::ostream& destination;

void EnregistreOctet (unsigned char octet)
{
destination.put (octet);
}
};

int main()
{
std::ifstream ifs ("source.txt");
std::ofstream ofs ("out.bin", std::ios::binary);
// Je te laisse gérer le paramétrage et la gestion d'erreurs...

DestinationBits destination (ofs);

char c;
while ( (c=ifs.get()) != EOF )
{
if (c=='0')
{
destination.AjouterUnBit (0);
}
else if (c=='1')
{
destination.AjouterUnBit (1);
}
}
}

G.T
Le #307122
Salut,

Si j'ai bien compris, tu es passé à côté du truc : dans WinHex, tu tapes
Alt+F5, et tu choisis ton format
Pas bien pigé ? C'est pas ça ?
Ben je me demande... On dirait que ses 0 et 1 sont en ASCII, donc 0x30 et

0x31 en binaire... Et qu'il voudrait QUE les valeurs binaires... Donc que
son 0x30 soit un 0 et son 0x31 un 1.
Bon allez, j'écris la solution en clair : retrancher 0x30 de chaque octet.

a+,
--
G.T
205 Diesel & turbo-Diesel : www.205d.com

Zeldus
Le #307121
"Fabien LE LEZ"
On Sat, 26 May 2007 22:56:05 +0200, "Zeldus"
Y a-t-il un moyen d'éviter l'écriture d'une
routine en C++ ?


Je ne saisis pas bien le sens de ta question.
Je pense avoir compris ce que tu cherches à faire, mais si tu veux
éviter de le faire en C++, ben... faut pas écrire sur un forum
consacré au langage C++ !

C'est a priori assez trivial à faire en Perl, en PHP ou en C.
En Lisp, il y a certainement une solution très élégante pour les
connaisseurs, mais totalement incompréhensible pour le commun des
mortels.
Je me demande si on peut faire ça en bash. Si oui, ça m'intéresserait
de voir le programme...

Note que si ton but est que le fichier prenne moins de place sur le
disque, il suffit de le ziper.



Merci pour vos réponses,

En fait, le but est aussi de pouvoir faire des tests sur des fichiers WAV en
"XORAN" un fichier d'environ 38 Ko sur un fichier WAV de 763 Mo (durée d'un
CD Audio) en l'étalant largement. Dans le cadre de l'étalement de spectre en
GPS, on "XOR" les données utiles à 50 bps sur un code de 1023 bits qui se
répète toutes les milliseconde. De mémoire, cela fait un changement de bit
utile (les messages de navigation GPS) tous les 20460 bits de code (le code
de 1023 bits qui se répète sans cesse). Pour récupérer le message utile, il
suffit de refaire un XOR du code synchronisé sur le flux sorti et de
récupérer le message (en supprimant la redondance des 20460 bits qui seront
réptés pour chaque bit utile transmis). Ce système d'étalement par XOR d'un
petit flux dans un autre flux beaucoup plus gros est utilisé également dans
la 3G en téléphonie mobile avec l'UMTS, le CDMA 2000 et d'une manière un peu
différente en WiFi 802.11a lors des débits de 1 et 2 Mbps.

En suivant ce système dérivé du GPS, on calcule qu'on peut"étaler" un
fichier de 38 Ko sur la longueur d'un CD Audio de 74 minutes. Ca ressemble
fortement à de la steganographie puisqu'il est nécessaire d'avoir le fichier
WAV original non modifié afin de récupérer le code utile camouflé. Je me
demandais si le fait d'étaler le fichier de 38 Ko dans le WAV de 763 Mo
était audible à l'oreille (je n'en ai aucune idée). Pour cela, il faut bien
que je convertisse mon fichier ASCI de 0 et 1 en un fichier WAV réellement
binaire qui fera de la belle musique quand il sera joué.

Pour le C++, je débute mais je me sens déjà assez à l'aise avec ce langage,
surement le plus efficace pour ce que je voudrais essayer de faire.
J'aimerai voir jusqu'à combien on peut réduire le facteur d'étalement et
ainsi augmenter la taille du fichier qu'on peut camoufler dans le WAV, il y
a bien un moment ou on doit commencer à entendre des perturbations audio
audibles dans le WAV. On peut imaginer un style assez original de
steganographie par la suite, vu que les CD Audio d'un même artiste / album
sont rigourseusment identiques d'un point de vue binaire dans le monde (sous
réserve qu'ils ne soient pas rayés), il doit être possible de camoufler le
fichier avec la nécessité d'avoir l'original du CD Audio pour le décoder...

Par exemple, on pourrait ainsi envoyer n'importe quel fichier étalé dans le
dernier titre de U2 ou de Madonna, et n'importe qui ayant le CD audio
original avec le bon titre pourrait récupérer le fichier. C'est juste une
idée comme ça !

Je fais juste des tests et des essais, (vu que je travaille dans les
télécoms mobiles et que je me spécialise dans l'étalement de spectre), c'est
juste pour étudier ce phénomène avec des exemples pratiques et concrets en
informatique. Pour les télécoms et les codes de Gold, c'est bcp moins
concret je trouve puisque le résulat ne pourra jamais être réellement un
fichier exploitable comme un WAV (il faut étaler avec des codes plus ou
moins orthogonaux pour émettre en meme temps sur la même fréquence).

Bonne soirée,

Zeldus


Loïc Joly
Le #307081

J'ai pondu à la va-vite un code tout pourri, qui pourrait fonctionner
si les phases de la Lune sont favorables. Je te laisse corriger,
tester, commenter, etc.


Moi aussi j'ai pondu, avec une approche légèrement différente, mais
probablement aussi buggée, car tout aussi peu testée... :

#include <bitset>
#include <fstream>

using namespace std;

int main()
{
ifstream in("fichierEntrée.txt");
ofstream out("fichierSortie.txt", ios_base::binary);
bitset<8> bs;
while(in >> bs)
{
unsigned char c = static_cast<unsigned_char>(bs.to_ulong());
out.put(c);
}
}

--
Loïc

Sylvain
Le #307080
Zeldus wrote on 27/05/2007 01:02:

En fait, le but est aussi de pouvoir faire des tests sur des fichiers WAV en
"XORAN" un fichier d'environ 38 Ko sur un fichier WAV de 763 Mo (durée d'un
CD Audio) en l'étalant largement.


ceci serait de la /dispersion/ de données (les 38ko) dans un ensemble
plus grand (tel un CD).

Dans le cadre de l'étalement de spectre en
GPS, on "XOR" les données utiles à 50 bps sur un code de 1023 bits qui se
répète toutes les milliseconde. De mémoire, cela fait un changement de bit
utile (les messages de navigation GPS) [...]


et ne correspond pas - pour ce que j'en sais, mais peut être me
trompe-je - aux techniques telles les sauts de fréquence FHSS ou
"étalement" (DSSS) où "étalement" est compris comme le fait de répartir
(étaler) l'information sur plusieurs porteuses simultanément (pour aller
plus vite ou permettre la vérification par redondance).

j'ai plus l'impression que tu veux faire de la dispersion que de
l'étalement.

En suivant ce système dérivé du GPS, on calcule qu'on peut"étaler" un
fichier de 38 Ko sur la longueur d'un CD Audio de 74 minutes. Ca ressemble
fortement à de la steganographie puisqu'il est nécessaire d'avoir le fichier
WAV original non modifié afin de récupérer le code utile camouflé.


et s'apparente donc exactement à de la stéganographie.
savoir si "on calcule" que l'on peut mettre 38ko dans 74mn de bruit mais
pas dans 72mn est - heureusement - sûrement pas le fond du problème.

Pour cela, il faut bien
que je convertisse mon fichier ASCI de 0 et 1 en un fichier WAV réellement
binaire qui fera de la belle musique quand il sera joué.


oui, donc lire par bloc de 8 caractères et construire un octet avec.
où est la difficulté ?

Pour le C++, je débute mais je me sens déjà assez à l'aise avec ce langage,
surement le plus efficace pour ce que je voudrais essayer de faire.
J'aimerai voir jusqu'à combien on peut réduire le facteur d'étalement et
ainsi augmenter la taille du fichier qu'on peut camoufler dans le WAV


tel que tu le présentes, on peut stocker 0 bit !! puisque leur
reconstruction impose d'utiliser un original public, n'importe qui
pourra extraire ce code camouflé (j'espère que tu ne conçois pas cela
pour transmettre des secrets) et n'importe qui pourra savoir si un
message est dissimulé.

lorsque l'on fait de la stéganographie sur une image on est aidé par le
fait que 1) on ne repose pas sur une image modèle 2) le codeur comme le
décodeur utilise un algo secret qui lui seul permet d'extraire les bits
d'information ... cela n'empêche pas la plupart des codes de stégano.
d'être assez nul pour mettre les bits en continu sans /dispersion/ (là
où ton propos est une piste intéressante).

un moment ou on doit commencer à entendre des perturbations audio
audibles dans le WAV.


"entendre" n'est pas l'unique critère qu'il faudrait satisfaire.
une comparaison bit à bit avec le binaire d'origine trahira toujours ton
camouflage.

la nécessité d'avoir l'original du CD Audio pour le décoder...


cette "nécessité" n'étant en aucun cas une difficulté ne parle pas de
chiffrement car le système serait de protection nulle.
(je suppose que "décoder" doit se lire "déchiffrer")

Sylvain.

geo cherchetout
Le #309586
Le 27.05.2007 01:02, *Zeldus* a écrit fort à propos :

En suivant ce système dérivé du GPS, on calcule qu'on peut"étaler" un
fichier de 38 Ko sur la longueur d'un CD Audio de 74 minutes. Ca ressemble
fortement à de la steganographie puisqu'il est nécessaire d'avoir le fichier
WAV original non modifié afin de récupérer le code utile camouflé. Je me
demandais si le fait d'étaler le fichier de 38 Ko dans le WAV de 763 Mo
était audible à l'oreille (je n'en ai aucune idée).


Bonjour,
Je réponds à des idées par des idées :
Pour que ce soit le moins audible possible, tu peux toujours caser les
bits clandestins à la place des bits de poids le plus faible de chaque
échantillon du fichier WAV.
Par ailleurs, en supposant que le fichier de 38 ko ( ~ 3 Mbits) soit
uniformément réparti dans un document dont la durée d'écoute est de
l'ordre de 2 heures, le bruit produit dans le pire des cas ne pourrait
avoir une fréquence supérieure à 200 Hz environ. (Signal supposé : 0 1 0
1 0 1 0 1 0 1...)

Zeldus
Le #307079
"Sylvain" 4658d9d4$0$5091$

et ne correspond pas - pour ce que j'en sais, mais peut être me
trompe-je - aux techniques telles les sauts de fréquence FHSS ou
"étalement" (DSSS) où "étalement" est compris comme le fait de répartir
(étaler) l'information sur plusieurs porteuses simultanément (pour aller
plus vite ou permettre la vérification par redondance).

j'ai plus l'impression que tu veux faire de la dispersion que de
l'étalement.



Bonjour !

Il y a plusieurs techniques de transmission à large bande, le FHSS, le DSSS,
l'OFDM entre autres. En DSS, le signal est étalé sur une fréquence unique,
assez large (1 Mhz dans le cadre du GPS et 5 Mhz pour l'UMTS) mais il n'y a
bien qu'une seule porteuse. Ce système est utilisé pour le GPS, l'UMTS, le
CDMA ONE, etc... En Bluetooth, on utile une technique différente avec
effectivement, le saut de fréquence. Par ailleurs, que ce soit dans la TNT,
l'ADSL, le DAB et le WiFi 802.11G, on utile un tout autre système, la
transmission OFDM avec plusieurs porteuses simultanées, ce que tu sembles
évoquer ici même mais ces techniques sont bien différentes du DSSS utilisé
en GPS et en UMTS.


Pour le C++, je débute mais je me sens déjà assez à l'aise avec ce
langage, surement le plus efficace pour ce que je voudrais essayer de
faire. J'aimerai voir jusqu'à combien on peut réduire le facteur
d'étalement et ainsi augmenter la taille du fichier qu'on peut camoufler
dans le WAV


tel que tu le présentes, on peut stocker 0 bit !! puisque leur
reconstruction impose d'utiliser un original public, n'importe qui pourra
extraire ce code camouflé (j'espère que tu ne conçois pas cela pour
transmettre des secrets) et n'importe qui pourra savoir si un message est
dissimulé.



Non, mon but est plus pédagogique. Je n'ai rien de secret à transmettre mais
je voulais illustrer la technique DSSS avec un exemple concret sur des
fichiers informatiques. C'est quand même plus parlant que les ondes radio je
trouve :-)

Bon dimanche,

Zeldus


Fabien LE LEZ
Le #307078
On Sun, 27 May 2007 01:02:46 +0200, "Zeldus"
En fait, le but est aussi de pouvoir faire des tests sur des fichiers WAV en
"XORAN" un fichier d'environ 38 Ko sur un fichier WAV de 763 Mo


Oui, bon, OK. Mais pourquoi diable te retrouves-tu avec un fichier
texte contenant des '0' et des '1' ?
Tu as un fichier binaire au départ, tu le lis, tu modifies quelques
bits dans les octets lus, et tu réécris le résultat. Aucune place pour
des '0' et des '1' en texte ici.

Je me
demandais si le fait d'étaler le fichier de 38 Ko dans le WAV de 763 Mo
était audible à l'oreille (je n'en ai aucune idée).


AMHA, ça va être très aléatoire. Si le bit modifié à un endroit est un
bit de poids fort, ça risque d'être détectable ; toutefois, si ta
carte son n'est pas trop pourrie, il y a des chances pour qu'elle
filtre ça en sortie, rendant la modification inaudible à tes oreilles.
De même, un lecteur de CD audio sait corriger ces "bits parasites",
car les erreurs de lecture sur un CD audio sont fréquentes.

Publicité
Poster une réponse
Anonyme