Mais il y a quelque chose que je ne comprend pas trop dans le cryptage ROT je vois:
pFileBase[i] += PR_CLE;
pFileBase[i] c'est octect et un octect peut prendre 256 valeur décimal je crois :s
Alors je vois pas comment on peut ajouter a l'octet "pFileBase[i]" une valeur "int" qui peut largement dépasser 255 :s
A moins que lorsque l'octect arrive a la valeur 255+1 il se remet sur zero :/ Mais si c'est le cas ca veut dire qu'il n'y a que 256 clée possible et donc c'est vite cracké comme cryptage...
Expliquez-moi svp^^
Voila merci :)
cs_ThreaT
Messages postés3Date d'inscriptionjeudi 23 janvier 2003StatutMembreDernière intervention 3 août 2005 3 août 2005 à 19:00
MAIS WHAT THE FUCK !
MDR ! Alors comme ça on post ses PTI sur le web petit filou vas ;)
J'étais en train de chercher des petites sources peinard pour mon nouvel élève, et sur quoi je tombe excellent.
J'ai parcouru vite fais ton proj, c'est pas mal du tout :p
(Commentaires, code aéré, arguments espacés, interface tranquille,?)
Ce petit mois de cours n'aura pas été inutile.
J'espère que tu continues à t?acharner sur ton F7, et que tu n'as pas viré de bords en reprenant un langage obscur, pseudo compilé dont je tairais le nom.
Passe à la maiz un de ces 4, je te montrerais les sources si tu veux tripper, ça peut te donner des idées.
Amuse toi bien, et passe de bonne vacance.
@+
elguevel
Messages postés718Date d'inscriptionjeudi 19 décembre 2002StatutMembreDernière intervention22 novembre 20163 21 juil. 2005 à 09:24
bon en ce moment je bosse donc j'ai pas trop le temps, mais dès que j'ai un moment j'me pencherai sur une solution de ce genre. On fera un programme correct :)
Sinon j'avais penssé à un codage aléatoire, ou chaque bloc (de 4 ou 8 par exemple) serai codé avec une clé aléatoire differente pour chaque bloc, et la clé serai a chaque fois ecrite avec la chaine crypter pour pouvoir le décrypter, bon çà multiplie la taille du fichier résultant mais bon...
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 20 juil. 2005 à 18:15
Ainsi la solution AlexMAN ne posera pas de problème car VirtualAlloc résulte toujours correctement aligné et multiple de 4, suffit de retamponner dwsize octets dans le fichuier.
MuPuF
Messages postés536Date d'inscriptionmercredi 27 avril 2005StatutMembreDernière intervention22 août 2008 20 juil. 2005 à 18:00
bah, la lenteur c'est le disque dur lol, le pross ne sera que tres peu solicité ici. Avec l'algo que j'avais créé (cf plus haut) le pross était utilisé a 10% c'est le disque qui rammait (entre guillemet quand meme car 30Mo/sec ...).
Le prob avec ton algo AlexMAN c'est qu'il faut que ton fichier soit un multiple de 4 ... donc tu dois faire des tests et corriger en cas d'erreur, quel bazars ! Mais sinon ça peux etre sympa, coder 4 char sur 1 integer, si un autre type trouve ça ben chapeau lol, rien que ça ça suffirait pour empecher 99.99999% de toutes les personnes qui essairaient de le lire.
cs_AlexMAN
Messages postés1536Date d'inscriptionsamedi 21 décembre 2002StatutMembreDernière intervention24 mai 20091 20 juil. 2005 à 13:55
Moi je pense, qu'une optimisation possible, serait de traiter, non pas chaque caractere, mais plutot un groupe de 4 (4 char == 4 octets == 1 int) d'ou, au lieu de ta boucle, un truc du genre :
for (i = 0; i < dwSize; i += 4) {
*((DWORD *)(szFile + i)) ^= CLE;
}
Tu reduis par 4 le nombre de passages dans ta boucle (qui est la principale lenteur de ton prog) donc c'est tout bénef :)
C'etait juste une petite remarque, il y a certainement BEAUCOUP mieux, mais c'est un truc qui m'est venu a l'esprit en voyant ta source.
Si tu as du mal avec la syntaxe utilisée, demande.
elguevel
Messages postés718Date d'inscriptionjeudi 19 décembre 2002StatutMembreDernière intervention22 novembre 20163 20 juil. 2005 à 13:12
non mais je deconne en disant "cassé" car j'poste la source et j'ai une reponse 30 secondes après. (au moins les modo sont efficaces .. bravo)
Mais bon j'ai precisez dans les commentaires que j'etait pas très bon en C donc qu'il manquait d'"optimization" donc pour l'histoire de l'existance du fichier j'ai fait comme j'ai pu.
Et pour le XOR je dirai pas que çà sert a rien car comme je l'ai precisez, c'est un cas d'ecole pour les debutant .. et puis le but de ce site est d'apprendre et partager, non pas faire des programmes de fous pour en mettre plein les yeux :D
Mais je ne prend pas mal les critiques du tout, au contraire çà me fait avancer ;-)
Merci à tous.
MuPuF
Messages postés536Date d'inscriptionmercredi 27 avril 2005StatutMembreDernière intervention22 août 2008 20 juil. 2005 à 12:41
bah, il veut dire que apres tu dois continuer, c'est que le debut le XOR, moi je fais un xor de tout les chars puis je mélange des caracteres suivant la cléé puis je recommence encore une fois le mélange mais d'une autre maniere, le type qui trouvera comment j'ai fait méritera bien de lire des msg a la con ou meme des images pour un jeu, sachant que j'arrive a encoder 30 Mo/s de fichier, donc ça arrache..
elguevel
Messages postés718Date d'inscriptionjeudi 19 décembre 2002StatutMembreDernière intervention22 novembre 20163 20 juil. 2005 à 11:23
cassé :-s
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 20 juil. 2005 à 10:49
Salut,
on ne teste pas l'existence d'un fichier sur le fait de savoir si on peut l'ouvrir ou non, si un autre prog l'a ouvert avant en mode exclusif, ta fonction répond de manière totalement erronée.
if(0 > (long)GetFileAttributes(szfile)) ABSENT
Pour le reste, faut avouer qu'une boucle XOR présente peu d'intérêt.
7 déc. 2006 à 12:48
Dans ce cas à quoi sert ce if(bSens) ?
1 sept. 2006 à 02:41
C'est une bon code :)
Mais il y a quelque chose que je ne comprend pas trop dans le cryptage ROT je vois:
pFileBase[i] += PR_CLE;
pFileBase[i] c'est octect et un octect peut prendre 256 valeur décimal je crois :s
Alors je vois pas comment on peut ajouter a l'octet "pFileBase[i]" une valeur "int" qui peut largement dépasser 255 :s
A moins que lorsque l'octect arrive a la valeur 255+1 il se remet sur zero :/ Mais si c'est le cas ca veut dire qu'il n'y a que 256 clée possible et donc c'est vite cracké comme cryptage...
Expliquez-moi svp^^
Voila merci :)
3 août 2005 à 19:00
MDR ! Alors comme ça on post ses PTI sur le web petit filou vas ;)
J'étais en train de chercher des petites sources peinard pour mon nouvel élève, et sur quoi je tombe excellent.
J'ai parcouru vite fais ton proj, c'est pas mal du tout :p
(Commentaires, code aéré, arguments espacés, interface tranquille,?)
Ce petit mois de cours n'aura pas été inutile.
J'espère que tu continues à t?acharner sur ton F7, et que tu n'as pas viré de bords en reprenant un langage obscur, pseudo compilé dont je tairais le nom.
Sinon j'ai sortie un ptit freeware si tu veux jeté un ?il : http://entreprise.01net.com/windows/Utilitaire/reseau/fiches/32047.html
Passe à la maiz un de ces 4, je te montrerais les sources si tu veux tripper, ça peut te donner des idées.
Amuse toi bien, et passe de bonne vacance.
@+
21 juil. 2005 à 09:24
Sinon j'avais penssé à un codage aléatoire, ou chaque bloc (de 4 ou 8 par exemple) serai codé avec une clé aléatoire differente pour chaque bloc, et la clé serai a chaque fois ecrite avec la chaine crypter pour pouvoir le décrypter, bon çà multiplie la taille du fichier résultant mais bon...
20 juil. 2005 à 18:15
DWORD *pbits, *pout;
pmem = (BYTE*) VirtualAlloc(0, dwsize, MEMDISPO, PAGE_READWRITE);
pbits = (DWORD*) pmem;
pout = pmem + dwsize;
while(pbits < pout) {
*pbits ^= CLE;
pbits++;
}
Ainsi la solution AlexMAN ne posera pas de problème car VirtualAlloc résulte toujours correctement aligné et multiple de 4, suffit de retamponner dwsize octets dans le fichuier.
20 juil. 2005 à 18:00
Le prob avec ton algo AlexMAN c'est qu'il faut que ton fichier soit un multiple de 4 ... donc tu dois faire des tests et corriger en cas d'erreur, quel bazars ! Mais sinon ça peux etre sympa, coder 4 char sur 1 integer, si un autre type trouve ça ben chapeau lol, rien que ça ça suffirait pour empecher 99.99999% de toutes les personnes qui essairaient de le lire.
20 juil. 2005 à 13:55
for (i = 0; i < dwSize; i += 4) {
*((DWORD *)(szFile + i)) ^= CLE;
}
Tu reduis par 4 le nombre de passages dans ta boucle (qui est la principale lenteur de ton prog) donc c'est tout bénef :)
C'etait juste une petite remarque, il y a certainement BEAUCOUP mieux, mais c'est un truc qui m'est venu a l'esprit en voyant ta source.
Si tu as du mal avec la syntaxe utilisée, demande.
20 juil. 2005 à 13:12
Mais bon j'ai precisez dans les commentaires que j'etait pas très bon en C donc qu'il manquait d'"optimization" donc pour l'histoire de l'existance du fichier j'ai fait comme j'ai pu.
Et pour le XOR je dirai pas que çà sert a rien car comme je l'ai precisez, c'est un cas d'ecole pour les debutant .. et puis le but de ce site est d'apprendre et partager, non pas faire des programmes de fous pour en mettre plein les yeux :D
Mais je ne prend pas mal les critiques du tout, au contraire çà me fait avancer ;-)
Merci à tous.
20 juil. 2005 à 12:41
20 juil. 2005 à 11:23
20 juil. 2005 à 10:49
on ne teste pas l'existence d'un fichier sur le fait de savoir si on peut l'ouvrir ou non, si un autre prog l'a ouvert avant en mode exclusif, ta fonction répond de manière totalement erronée.
if(0 > (long)GetFileAttributes(szfile)) ABSENT
Pour le reste, faut avouer qu'une boucle XOR présente peu d'intérêt.
ciao...