Traitement binaire vers hexadecimal

"Zeldus" <no@email.com> a écrit dans le message de news:
46589ee2$0$19019$426a74cc@news.free.fr...
| 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

On Sat, 26 May 2007 22:56:05 +0200, "Zeldus" <no@email.com>:

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.

On Sat, 26 May 2007 22:56:05 +0200, "Zeldus" <no@email.com>:

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);
}
}
}

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

"Fabien LE LEZ" <gramster@gramster.com> a écrit dans le message de news:
ur9h53ddhql0l01cf6tqakje6jh6hidf84@4ax.com...

On Sat, 26 May 2007 22:56:05 +0200, "Zeldus" <no@email.com>:

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

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

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.

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...)

"Sylvain" <noSpam@mail.net> a écrit dans le message de news:
4658d9d4$0$5091$ba4acef3@news.orange.fr...

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

On Sun, 27 May 2007 01:02:46 +0200, "Zeldus" <no@email.com>:

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.