Believe it or not, I have been told that some people rely on Cryptozor(us) software for file encryption.
Cryptozor(us) is from Thomas Nerrant. The author's primary web site seems down currently, but it is possible to find a working mirror: there are some available on [1][2][3].
First impression is that the GUI is ... poor, to say the least.
The software claims using PC1 and CARACACHS algorithms, which are mostly unknown from the community. This is often bad news ... for the software :)
First tries
First of all, let's try to encrypt a simple, plaintext file (such as "README.TXT"). The original file size is 15,331 bytes. A "README.TXT.CTZ" file is created on output. Here are the results using different passwords and the CARACACHS-128 algorithm:
- File #1, input password "a", output file size 15,402 bytes.
- File #2, input password "aa", output file size 15,402 bytes.
But the really bad news is that file #2 has exactly the same distribution:
What kind of "encryption" algorithm could give such results ? Having a closer look, file #1 and #2 differ on byte ranges [0x00..0x1C] and [0x3C00..0x3C1F]. Both files are otherwise exactly the same !
At this point, we are pretty confident in the fact that the output file is "scrambled" with a fixed key, and that the encryption key is useless in the process of decryption. Now let's have a look at "CRYPTOZORUS.EXE".
Binary analysis
Having unpacked the file (upx -d cryptozorus.exe), we begin analysis. An idea to start with would be searching for a string reference to "!#? Bad Password ?#!". Such a reference can be found in the following piece of code (comments have been added later):
.text:0040314D case6_bad_password: ; CODE XREF: dispatch_sub+181j
.text:0040314D cmp ebx, 6
.text:00403150 jnz short case7_stopped
.text:00403152 mov word ptr [edi+10h], 50h
.text:00403158 mov edx, offset a?BadPassword? ; " !#? Bad Password ?#!"
.text:0040315D lea eax, [ebp+var_1C]
.text:00403160 call wrap_LStrFromPChar
The function at 0x00402F88 is clearly a switch/case related to the program's internal state. We call it "dispatch_sub()". When state == 6, "bad password" is displayed.
There are many references to dispatch_sub(), so it is better to trace the program with a debugger (namely OllyDbg) to find the caller on case 6. The result is pretty obvious:
.text:00408218 bad_password: ; CODE XREF: maybe_write_file+FFj
.text:00408218 push 6 ; 6 = BAD PASSWORD
.text:0040821A mov eax, [esi]
.text:0040821C mov edx, [eax]
.text:0040821E push edx
.text:0040821F call dispatch_sub
This piece of code is entered on the following condition:
.text:00408071 call test_password
.text:00408076 add esp, 8
.text:00408079 test al, al
.text:0040807B jz bad_password ; 6 = BAD PASSWORD
By replacing "jz bad_password" with "nop", it is possible to completly bypass password checking.
Conclusion
By patching 2 bytes inside the program file, we made a program that will decrypt any file without knowing the password. Total analysis time is under 20 minutes. Would you call that security software ?
PS. Having a closer look at test_password(), it seems that this function relies on the "CRYPTOZORUS_THOMASNERRANT.COM" string. The exact purpose of this string is left as an exercise to the reader. There are 2 possibilities:
- This is the fixed encryption key;
- This string, encrypted with user password, is used for password checking on decryption.
4 comments:
Hello,
Given that I am the author of this software, I have to intervene concerning this article.
In a first time, about why Cryptozorus is not developed anymore, it is only because I do not have the time nor the envy to deal with that.
Otherwise, concerning the coding algorithms used (PC1 and Caracachs) those two come from the same author, Alexandre Pukall, and they are freely available ( http://membres.lycos.fr/pc1 ; http://membres.lycos.fr/caracachs ). You say that there is a possible weakness in those algorithms, in the first part of your article. I encourage you if you want, to contact the creator of those algorithms (alexandermail@hotmail.com) and may be discuss with him about your cryptanalysis.
The implementation which was made in my software clearly shows a weakness as you explained in your article. Moreover, we can remark that the weakness and other vulnerabilities concerning those types of software generally come from the implementation more than the encryption algorithms themselves.
This software did not claimed to offer the ultimate security or privacy. Anyway, I don't think that any software can easily deal with that. Indeed, invulnerability is an ideal to reach, however, it is not forcibly a possible objective, in the absolute. The most important thing concerning a security software (as an encryption software) is to give the privacy at least the time during which the information to protect is valuable. You could say me that there is also the case where a person or organization wants or need to protect something during a very long time because it seems to remain critical even after years... There is no miracle in this particular case, indeed, the best thing to do is to regularly re-encode it, each time using a different passphrase but you also have to always use the last version of a proven security software. However, in this particular case, we speak about a really critical information, the kind of information I am really not sure everybody have notably among the common people... Even if, everybody knows that an alleviating stuff for the others can be really precious to someone in particular ;)
I would certainly found that vulnerability if I continued to develop this soft, and so, found a better solution, more secure (hashing method, CRC checking, etc...).
I first developed that soft at the end of High-School and prolonged a little bit at the beginning of my Bachelor. I was a newbie in programming and so I did not have forcibly the experience to deal with such a project.
Anyway, I hardly think that if I had to re-make a similar piece of software today, I would not develop it in the same way. I would have a better design, more structured and with a better development method, for example well testing basic features before adding some more new ones, in order to have a solid basis.
This software is not anymore developed nor supported, that is why I strongly recommend to use another ciphering software as for example the well-known GnuPG in constant evolution and Open-Source which can really be valuable for this type of software.
Anyway, Thank you for your article, because we can really learn from our mistakes. Your article allowed me to see an error concerning the conception of my software, and it could help me to take care about that in the future, notably if one day, I have to re-develop a similar piece of code.
Thus, we should say that criticism can really be positive if it is argued and lead to an awaking and so a possible future improvement or at least not to reproduce the same mistakes.
Bonjour,
Étant l'auteur de ce logiciel, je me dois d'intervenir au sujet de cet article.
Tout d'abord, concernant le fait que Crytpozorus ne soit plus développé, cela est dû au fait que je n'ai plus le temps ni forcement l'envie de le faire.
Sinon, concernant les algorithmes de chiffrement utilisés (PC1 et Caracachs) ces deux algorithmes proviennent du même auteur, Alexandre Pukall, et sont disponibles librement ( http://membres.lycos.fr/pc1 ; http://membres.lycos.fr/caracachs ). Vous évoquez la possible faiblesse de ces algorithmes dans la première partie de votre article. Je vous encourage si vous le souhaitez à contacter l'auteur de ceux-ci (alexandermail@hotmail.com) qui est au demeurant une personne fort charmante, et qui a toujours répondu a mes interrogations.
L'implémentation qui en a été faite dans mon logiciel montre clairement une faiblesse comme cela a été démontré. On peut d'ailleurs remarquer que les faiblesses dans ce type de logiciel viennent généralement de l'implémentation plus que des algorithmes de chiffrement eux-même.
Ce logiciel n'avait de tout façon pas la prétention, loin de la, d'offrir une sécurité totale. De tout manière, je crois qu'aucun logiciel ne peut s'en targuer, car l'invulnérabilité est un idéal vers lequel tendre mais pas forcement un objectif atteignable dans l'absolue, l'important pour un logiciel de sécurité (notamment de chiffrement) étant surtout de retarder le plus possible le fait que l'information soit déchiffrée par un tiers non souhaité, afin que les informations protégées ne soient plus forcement d'une très grande valeur. Après il reste bien sûr le cas où les informations que l'on souhaite protéger soient, même avec le temps, toujours sensibles, et là il n'y a pas de solution miracle, juste peut-être prendre le soin de re-chiffrer à intervalle régulier celles-ci en utilisant des passphrases différentes et également en utilisant toujours les dernière versions et surtout les versions éprouvées des meilleurs logiciels en la matière. Mais dans ce cas la on parle d'une information réellement sensible, information que à mon avis très peu de particuliers ont en leur possession même si l'on sait bien que parfois une chose anodine pour les autres peut nous paraître personnellement la plus importante au monde ;)
J'aurais certainement trouvé cette vulnérabilité si j'avais continué à développer ce soft, et ainsi trouvé une solution beaucoup plus convenable et sécurisée (méthode de hashing, CRC vérification ou autre).
C'est un soft que j'ai commencé a développer à la fin du lycée et continué un peu au début de mes études supérieurs. Je débutais alors le développement logiciel et n'avait donc pas forcement encore acquis l'expérience et le recul nécessaire à un tel projet.
De toute façon, je pense sincèrement que si j'avais à refaire ce soft aujourd'hui, je ne m'y prendrais pas du tout de la même manière. J'opterais pour un design plus structuré et une meilleurs méthode de développement, par exemple en éprouvant d'abord les caractéristiques de bases avant d'en rajouter de nouvelles, afin d'avoir des briques propres et saines sur lesquels reposer et développer des fonctionnalités qui pour profiter de cette base solide.
Ce logiciel n'étant de tout façon plus développé ni supporté, je recommande fortement d'utiliser un autre logiciel de chiffrement tel que par exemple le très éprouvé GnuPG qui est en constante évolution et qui plus est, est Open-Source ce qui lui donne forcement du crédit, surtout pour ce type de logiciel.
En tout cas, merci pour votre article car c'est en apprenant de ces erreurs que l'on peut s'améliorer. Votre article m'a ainsi permis de voir une erreur que j'avais commise et me permettra d'y prêter plus attention à l'avenir notamment si j'ai un jour à re-développer un logiciel similaire.
Comme quoi la critique peut être positive si elle est argumentée et amene à une prise de conscience menant à une possible future amélioration ou tout du moins à ne pas re-commettre les mêmes erreurs.
very useful post. I would love to follow you on twitter.
Took me time to read the whole article, the article is great but the comments bring more brainstorm ideas, thanks.
- Johnson
Post a Comment