Saturday, November 5, 2011

Let us stop with the buzz on TOR

Hi to all

Since a few weeks a huge buzz has arised around the TOR security and especially regarding the attack we have designed and experimented. I decided not to react, not to feed the buzz since I do not like it and if controversy may sometimes be constructive, in the present case, things have gone too far: stupid comments on comments from others (on which basis since we have published only a very few things yet?), personal attacks close sometimes to libelling, huge emotions, doubts and fear that may be understood however, collective hysteria...

However, going on sticking away would in some sense backing this buzz. It is time to remind that the only possible goal is to have more security, to determine whether really our attack can put seriously TOR security into question and go ahead to try to find solutions to improve. Security is a too serious thing to be only a playground for buzz. Even if -- especially as a former military cryptanalyst -- I do not fully agree on a few conceptual choices in TOR, there must be no doubt for anyone about our will to contribute to the TOR security and this from the very beginning. We must not forget that a few people who use TOR are putting sometimes their life into danger (political opponents, militaries...) for a more democratic and free society. In this respect, we cannot waste a precious time. Up to me, the issue is very clear: there is absolutely no doubt that we need a solution like TOR even this solution is far from being perfect. But is there such a thing as a perfect solution, especially if you add political and national security issues?

When I decided to work on TOR -- by mid of 2010 -- I was just interested in the crypto part, looking for some application of the concept of dynamic cryptographic trapdoor that I had imagined a few years ago. So far I could test it only in non public yet real networks. Hence it was not possible to publish anything on those results. So at the beginning, I had nothing against TOR and I still don't.

When it was clear that TOR could also succumbed to this concept, I imagined the attack under the present light of media. If I have a rather good knowledge of network technology, it was not sufficient and I needed to have more skilled guys, especially to find ways to force 3-node routes through compromised nodes with a very high probability. Two of my best students of our N&IS Specialised master, Seun from Nigeria and Leonard from Tanzania -- two really excellent students -- have joined the party on April 2011. They have worked very hard, have done an excellent job both at the academic level and at the operational/technical level. I can say that as a tutor, I am really proud of their work. Of course, for anyone who knows how research works, you never totally start from scratch and Seun and Leonard's first tasks were to establish a bibliography on the existing network approaches used by previous researchers: Murdoch, Evans, Danezis, Pappas, Bendiken... who all have been mentioned in the slides. Then they have developped their own tools/approaches to fit my operational intent. Just as it is required in any research work. And other people doing hacking or research are doing the same.

We have just done research, serious, good and operational research up to me. We have tested our attack in conditions close to the reality. People will make their own ideas. I decided at that time not to make buzz, just to present this work in hacking conferences. Unfortunately my employer -- an academic institution -- has required from me to present my attack to French journalists. I have accepted since an employer is always right...or you have to resign. But at the very end, I did not really mind: who cares about news published in French in the world? Then things went wrong and the hype created by others has gone too far. The TOR foundation contacted me in a form that was probably not very fair -- to my perception at last -- and myself I have to make a throrough criticism of myself when facing the resulting buzz. After 22 years in the Army (in the French Marine Corps Infantry), I suppose that I have kept a not very flexible and accomodating mind. Sorry for that. We have decided that it was necessary to restore the contact with the TOR foundation and its president Roger Dingledine to go beyond our differences in opinions, views and interpretations and go ahead towards more security in TOR in a more constructive way. Any other end would have been totally irresponsible from Seun and me.

Our attack works not because the TOR source code has flaws. Once again, it is well-written and in a secure way. It is more related to conceptual issues. We have just analyzed the TOR network at a higher level, by considering it as a critical infrastructure and using a large, multi-level and coordinated attacks. Up to me according to personal information, which are confirmed partly on the TOR website, I am convinced that China (especially in 2009 and late 2010) has already tried similar attacks and has been, at least partly successful. Of course we cannot accept that.

The main problem comes from the fact that
  1. the TOR network relies on volunteers which most of the time do not secure their computers. That is dramatic. Just imagine the security nightmare in a big company where every user would be free to choose the operationg system, the way to configure it... We will not publish all what we have detected. But be sure that we have seen horrible things as far as security is concerned. In this respect, we think that an overall computer security policy should be enforced and any OR not complying with it should be banned from the network.
  2. TCP is a nightmare as well and this is the main issue. I am not a network expert but I have the feeling that it will difficult to built more security at that level. We have managed to return a few of the TOR protections against DDoS against TOR itself when considering local, surgical strikes.
But to be honest, being able to force 3-node circuits can be exploited only if there exists a significant part of ORs that have been compromised. So back to the first point.

Up to me there is some hope and technical improvements should be possible. Among many possible ideas. we propose:
  • as an emergency measure, to ban weak ORs that are not secure enough. This requires to make fingerprinting and active auditing what we did actually but only partly for legal reasons.
  • to add steganography techniques in TOR. Remember that using cryptography focuses attention and hence attacks. Why not a steganographic version of TOR?
  • to limit not so say prevent the installation of dynamic cryptographic backdoors (memory protection by hardware-based virtualization for instance, malicious cryptography techniques to prevent memory tampering, process protection techniques [we have developped a few in our lab]...).
Seun intends to dedicate his PhD thesis to the enhancement of the TOR security with innovative propositions. He is just waiting for a PhD grant. We are ready to contribute and to be involved anyway.

We have sent all source code and slides to the TOR foundation in order to help it to design and release a potentially more secure version of TOR. Recent exchanges with Roger seem to show that somehow our work is considered as significant and was not greatly exaggerated. That is sufficient to us. I let him confirm or not. We will release the source code and data as scheduled on November 10th (right after PacSec 2011) unless the TOR foundation recommends to wait a little bit more. As researchers and hackers we just need our contribution to be recognized. If it has helped finally to take part to the enhancement of overall TOR security, well we will proud of that.

Special thanks to Dragos, Rodrigo and Filipe.

Eric Filiol & Oluwaseun REMI-OMOSOWON

Tuesday, November 1, 2011

TOR Attack Technical Details

Hi to all

As announced in a previous one, this post presents and details the different technical details on our TOR attack. These data will be released little by little but everything should be finally available before the end of November. So stay tuned to follow regular additions to this post.

We do prefer take time and release the most recent developments with respect to the TOR foundation updates, patches... But we also understand that people are looking forward to have those technical details. Since some of them are ready and since making them public does not challenge the interests of H2HC2011/PacSec 2011 organizers, well why wait more?

An updated version of the attack (to adapt to the forthcoming updates and patches of the TOR code in November and December and to present the TOR security evaluation dedicated botnet we are currently developping) will be presented at the 28th Chaos Communication Congress (28C3) in Berlin.

Here are the data provided:
  • The Google Earth maps of existing ORs (public and hidden ones; allOS ORs and Windows ORs) at the date of November 1st, 2011. Hidden TOR relay bridges (195 extracted by now; text list here) have been automatically extracted with the tor_brige library provided hereafter. This map is essentiel and is part of the intelligence step of the attack. Building large, coordinated, multilevel attacks -- as militaries usually do -- requires to have this generalized view of the target. New maps at the date of November 10th, 2011 (310 hidden relay bridges extracted so far): all ORS and Windows ORs.
  • The tor_extend library which enables (1) to automate the extraction of hidden TOR nodes (relay bridges) and (2) to execute the spinning technique (second of the 3 combined techniques to force 3-node routes towards compromised nodes). This library has been written by Oluwaseun Remi-Omowoson. The library can also be accessed through the Rubyforge link and Rubygem link (relevant documentation here). Simply typeset "gem install tor-extend" to install.
  • H2HC 2011/Pacsec 2011 slides.
  • PacSec video.
  • Technical paper which also contains the SCAPY script code to play the TCP Reset technique (first of the 3 techniques combined to force 3-node routes towards compromised nodes). Available by end of January 2012.
  • The tor_extend library version 2.0.0 (28C3 version). Contains everything in a single file (source code, documentation, ruby code, Google Earth map of ORs including 355 hidden relays extracted so far...). 28C3 slides. These data will be the last public version available. Very important point following feedbacks and comments from Roger Dingledine (thanks Roger!): in our slides we focus on Windows ORs/relays without correlating to bandwidth. This was just a choice among many other possible. Optimally it is true that we have to target/infect primarily the nodes with high bandwidth. And following this dicussion it is clear that many other options are possible. So, up to the choice of the target subset to infect, the general concept/approach of our attack remains valid.
  • The malware part (installing the dynamic cryptographic trapdoor) is not public. The malware also embeds a few structures to contribute to forcing 3-route nodes (refer to the paper).
Please note that the source code provided (when relevant) is the PoC version only (not optimized). Optimized versions are not public (since they are part of the TOR security evaluation botnet which is currently developped).

To conclude, we would like to stress on the fact that TOR is not only solution available (just to counter stupid comments claiming that without TOR the security world would be empty). We recommand the excellent book (free) "How to bypass Internet censorship" which describes various tools which are worth mentioning and considering.


Sunday, October 30, 2011

First Feedbacks from H2HC and our TOR Attack

Hi to all

The talk given at H2HC 2011 in Sao Paulo has caused a lot of reactions and interests in our work (especially this night from a TOR developper whose mail was far more constructive and positive than previous ones). It is probably time to go ahead the recent stupid buzz and reactions. To put things into perspective, people must know that we did choose to enter this buzz and wait until our talk and that forthcoming in PacSec 2011. We expect to be more constructive in this way.

We perfectly understand the concerns of the TOR community. Be sure that contrary to stupid allegations it is not our intent not to contribute for more security in TOR (but honestly first emails from the TOR foundation were more on strong requirement mode -- not to say intimidation -- than with a real collaboration spirit ensuring the interests of conferences organizers). We are not easy men and we do like everything close to intimidation. And we do not like useless buzz.

People first must know and be convinced that we do not have anything against TOR. This network is just the only real public case on which we can test the concept of dynamic trapdoors and publish something with the expectation to be useful and constructive at the very final end.

As far as vulnerabilities are concerned -- TOR community is concerned with potential bugs --, in fact we cannot speak of sotware vulnerabilities. The TOR code is rather very well and securely written. Our attack relates more to the conceptual designs and of the exploitation of different aspects on which those designs rely on. We worked at a higher level by considering the TOR network as a critical infrastructure and we have developped operational cyberwarfare scenarios (these approaches are part of the research topics our our lab). to take the control over TOR as would do rogue non-democratic countries , terrorists or reduced sized groups of bad guys.

We manage to force 3-node circuits to go through a few nodes -- with very high probability -- we have compromised in an initial step with malware using malicious cryptography techniques installing dynamic cryptographic backdoors. To do that, most of the time we just turn protection mechanisms in place (for instance to prevent large DDoS) back against TOR itself. The TCP reset attack cannot be avoided since it exploit a part of the TCP implementation. Most the techniques we used (local and targeted congestion path, spinning technique ou TCP reset) cannot really be avoided. It is a problem of conceptual design both for TOR but also for the protocols it relies on (mostly TCP). It is a common approach in cyberattacks to turn protections set up by the target... against the target! Awful indeed but really efficient.

So we do not want to criticize TOR uselessly since the problem is not TOR in itself only. This network is a first solution intending to provide some sort of secure environment that must be followed by other generation of OR or other similar solutions. But since we now are very convinced that it is effectively possible to take control over TOR when working both a low and high level at the same time (this is the reason why we needed to have a precise and complete map of all the OR even the hidden ones; and we manage to find all hidden nodes, China or any other bad guys are able to do it as well). Nowadays hacking techniques and methods still have only a limited and reduced view (instance of binaries or of systems) but they did not apply yet what military world is using: large, high level views to organize, plan and conduct coordinated attacks, combining several technical bricks and tools.

So, we are currently preparing all stuff (source code , paper, slides) and as soon as they are ready we will send them to the TOR foundation and make them publicly available. We already made suggestions to a few TOR developpers. Seun is currently working to adapt the attack to the recent update (that corrects partly the spinning technique). He is very confident at succeeding in this.

Seun should prepare a Phd and we intend to provide new approaches to enable and propose some sort of third generation of TOR that would contribute to solve the present conceptual problems. Part of the solution would be to use steganography to provide TRANSEC aspects. But we should also propose to protect the code loaded in memory to limit the techniques of dynamic cryptographic trapdoors. And we have many other ideas coming from malicious cryptography techniques we have recently developped.

Once again, the very final goal of our work is to provide a better solution at the end. That is why we did not want to enter the buzz and stay aside to go on working
We hope that people will understand

To finish I would like to thank people at H2HC (Rodrigo, Filipe and all the very nice guys I have met) as well people from PacSec (Dragos and his team) for their confidence and trust. We owe very much to them

Have a nice (hacking) day to all


Monday, October 17, 2011

Future publications of the lab


People from the lab have an intense technical production and are about to present papers in the next months. Here are the main ones:
  • H2HC 2011 - Sao Paulo, Brazil - Tutorial in cryptanalysis (8 hours) (E. Filiol).
  • H2HC 2011 - Sao Paulo, Brazil - The TOR Attack. (E. Filiol)
  • PacSec 2011 - Tokyo, Japan - The TOR Attack (E. Filiol)
  • Computer Security 2011, Mexico City, Mexico. Analyzing Android Applications (A. Desnos + G. Gueguen).
  • Medays 2011, Tanger, Morocco. E-Security: Comment lutter contre l'émergence permanente de nouveaux risques (E. Filiol).
  • Black Hat Abu Dhabi 2011. Android: from Reversing to Decompilation (A. Desnos + G. Gueguen).
  • Malcon 2011, India. How to make your Home Botnet. (B. David).
  • HICSS 2012, Hawai, USA. Android: Static Analysis Using Similarity Distance (A. Desnos).
  • HICSS 2012, Hawai, USA. New Trends in Security Evaluation of Bayesian Network-based Malware Detection Models (E. Filiol + S. Josse).
All papers, slides and tools are and should be soon available.
Have a nice day

E. F.

Thursday, October 13, 2011

Libre Office International Conférence in Paris Day I

Hi to all

From October 13th to October 15th, a major event in computing industry takes place in Paris: the International Libre Office Conference. The official website is here while the detailed program is here. We will not describe all the technical contents of the different talks since the slides of all of them will be on the official website.

Jonathan Dechaux who attends the conference has harvested a lot of good/interesting news for the day I of the event. Here are the main of them among which are offical announcements:
  • Libre Office is already used by 25 000 000 users and it is expected that in the next forthcoming years the number will grow to 200 000 000 users .
  • The suite is going to be part of the software on the USB key delivered for free to 800 000 Paris aera students ("Ile de France"). The Paris area moreover has joined the LibreOffice fundation as well as the Brazilian government.
  • The cloud version of LibreOffice has been officially announced (with a Firefox plug-in). The GTK, ODF and HTML5 technologies has been chosen. The result will be LibreOffice Online. You can watch a demo video here.
    The only problem (from a security point of view) lies in the fact that it will still integrate Macros and therefore is likely to become a Pandora box.
  • Libre Office is going to equip 500 000 computers of the French government.
  • The suite is about to be available on Android and iOS.
There were the news from day I. More info here.
Have a nice day

Wednesday, June 29, 2011

Publication ESIEA Espoir Recherche

Bonjour à tous

Baptiste David, étudiant ESIEA et espoir recherche de deuxième année au laboratoire a présenté ses travaux menés sur l'identification en PERL des équations différentielles, lors des "Journées PERL 2011", à Paris les 24 et 25 juin 2011.

Les slides sont disponibles ici.

Bonne journée à tous


Tuesday, June 28, 2011

CVO recrute sur Laval

Bonjour à tous,

Le laboratoire de cryptologie et de virologie opérationnelles recrute et propose deux postes (CDI) sur Laval.

  • Un jeune docteur en informatique/mathématiques discrètes ayant un bonne connaissance de la programmation sécurisée, du reverse engineering et de l'analyse de malware et de programmes. Le poste comporte une mission d'enseignement, de recherche et d'animation scientifique. La préparation d'une HDR sera un des objectif à moyen terme pour ce poste. Sans renier l'approche académique, le recrutement privilégiera une pré-disposition pour l'approche technique de type Hacker. Une bonne connaissance de l'anglais (écrit/parlé) est obligatoire.
  • Un ingénieur ou titulaire d'un master 2 en informatique/sécurité/cryptologie souhaitant en parallèle préparer une thèse. Bonne maitrise de la programmation (C, C++, python), des outils de calcul formel (Magma, Mathematica...). Le poste comporte une mission d'enseignement, de recherche et de développement. Une bonne connaissance de l'anglais (écrit/parlé) est obligatoire.
Du fait de l'environnement de travail du laboratoire, les candidats devront se soumettre à une enquête de sécurité.

Les candidats intéressés enverront un CV et une lettre de motivation à

Bonne journée à tous.


Cyberwarfare book

Hi to all of you

We have the pleasure to announce the availibility of the book entitled "Cyberwar and Information Warfare" published by Wiley.

Our laboratory has written the chapter entitled "Operational Aspects of a Cyberattack: Intelligence, Planning and Conduct". This chapter is used as the basis of our course in Cyberwarfare techniques given at ESIEA Laval.

Have a nice reading.


Thursday, June 23, 2011

LibPerseus Challenge Results

Hi to all

We have the pleasure to announce that Guillaume Delugré and Gabriel Campana from Sogeti/ESEC France (a really nice R&D company in Security) has won the challenge. They have sent the plaintext text corresponding to the chall3.coded file. Congratulations to them. They did a really nice work which will be very useful for the Perseus project. They will be recently awarded with the prize.

Their attack (more details here) is a clever and nice implementation attack which does not hence put the Perseus (mathematical) concept into question. Their attack shows that going from the theory to implementation is always complex and prone to security weakness.

The attack exploits the fact that
  • the plaintext is split into blocks of constant size (for performance purposes, it is more practical to consider this approach since forthcoming parallel decoding of blocks will overcome the complexity of the Viterbi decoding) each block being encoded with the same encoder.
  • due to a bad (and stupid) bug in our implementation the noise pattern was always the same (by mistake we forgot to declare a few variables as static and then each call to the noise generator resets its state). Ironically, this dramatic weakness could have been detected by our cryptanalysis library Mediggo (tool detectsinglefile.c) which precisely has been designed to detect this kind of flaw. But development speed and security are seldom compatible (shoemakers are often the worst shod -:))
  • It seems that implementation of the puncturing is a little faulty as well.
What is clear is that without the help of Guillaume and Gabriel, we would probably never detect this (infamous) bugs. Thousands thanks to them and to their contribution.

The bugs will be of course corrected in the new implementations of the Perseus lib which is under currentl development with the help of DFT-Technologies (which has performed the industrial specifications of LibPerseus and will perform the final code auditing). This implementation is about to be made public and officially presented during the RMLL 2011 in July in Strasbourg. Here are the new features that takes Guillaume and Gabriel's attack into account:
  • This implementation considers blocks of variable sizes (ranging from 512 to 4096).
  • Each block is encoded with a different encoder.
  • The noise pattern of course will be variable itself.
As originally implemented in the Perseus library itself, normally the message should be a single block. We are presently developping a polynomial-memory decoder that will make decoding very quick and will enable to consider message as a single block. More to come...

Of course, we hope that contributors will volunteer to evaluate this implementation. Once again congratulations to Guillaume and Gabriel. We would like also thank all people who support, sponsor the Perseus project and all those who contribute with comments and feedbacks.


Friday, June 17, 2011

LibPerseus Challenge Reset

Hi to all

Following a number of requests (especially from our sponsors and our supporting partners regarding the Perseus project), feedbacks and critics about the (obvious) lack of precision and data with respect to the LibPerseus challenge, we were strongly advised to reset this challenge today in order to offer more precise and thorough conditions:
  • files and binaries have been reset (the previous version was inappropriate since it made encoder collision possible thus providing different possible solutions while only one should exist within the parameter space considered).
  • More info given on plaintext files to recover
  • binary program that produced the new challenge files is provided (beta version at the present time). The source code will be made public as soon as possible.
  • Legal aspects of the challenge checked and clarified (thanks to Mr Auger, esquirre, bailiff in Laval, France who has pointed to us a few legal imprecision).
  • Time limit of the challenge and award have been consequently extended for fairness.
The link to the challenge page is here
We apologize for the inconvenience. Thanks to all who make us aware of the necessity to reset this challenge and help us to improve it. Thanks to our sponsors and partners (mainly DFT-Technologies).


Sunday, June 5, 2011

PERSEUS Principles


A few recent comments seem to prove that people speak a lot about Perseus without a clear knowledge of what it is and claim that the mathematical principles are not neither known nor published. Well. This is not the case (otherwise the challenge would not be fair and would not comply to Kerckhoffs' laws).
Here are the main technical data (published for more than one year):
Moreover the industrial support and development (secure implementations for example) is provided by DFT Technologies.

Due to some misunderstanding about the challenge conditions and the fact that no binaries are provided (we wish to make the concept to be tested/evaluated and not a particular implementation), we have just issued a new version of the PERSEUS Lib which uses random generation by means of the /dev/random primitives (in your application just remind that /dev/random is a blocking device and the kernel will have to be helped eventually during the encoder generation).

Of course, that does not affect the conditions and validity of the challenge but we just want to calm down and take into account some wise comments and feedbacks (and we need constructive feedbacks all the time). Once again the use of rand() was far from being optimal (we plead guilty since we were aware of this weakness and even exploit it in the past) but by laziness or lack of care we concentrated on the concept rather on the security of the implementation. Now it is fixed as well as the x00 bug (that was relevant for the python version only). We hope that now people will concentrate on the concept security itself. The PERSEUS concept can be very useful to many people as confirmed by many feedbacks.

For people who use personal attacks against my work, I will not make any comment. They do not deserve it. They have just to keep in mind that it is far easier to criticize than taking risks by fighting in the arena, trying to make security progress. and proposing new trends in data security. For those who pointed out our lack of care with the rand() primitive, well they were right so thanks to them. They did their job.

Now let us go ahead.


Thursday, May 26, 2011

Additional information about the libperseus challenge

Hi guys

(French version below)

I have received (strange) questions about the Perseus lib chalenge asking to provide the binaries/source code that has been used to produce the two files for the challenge. Well,
the source code is for months available here. And the binaries have been produced from it directly.

It is important to stress on the fact that the problem is algorithmic by nature (mathematical problem) and that you will have to do more than simply trying to base your attack on flaws or anything like that. It is here useless. It would be simple. Just consider that you have wiretapped the files (this is the operational reality) and you have the source code (Kerckhoffs conditions).

Indeed security is a little bit more difficult to overcome when there is no flaw.

(French version)

J'ai eu des questions récemment (étranges) concernant le challenge Perseus me demandant de fournir le code source et les binaires ayant servi à produire les deux fichiers du challenge. Le code source est disponible depuis des mois sur le site de la librairie et le binaire a été produit directement à partir de ce code source.

Il est important de rappeler que le problème est par nature algorithmique et que vous devrez faire une peu plus que de chercher à fonder une attaque sur une vulnérabilité (qui en l'espèce n'existe pas). Cela n'a ici pas de sens. Considérez que vous avez intercepté les fichiers (cas des conditions opérationnelles) et que vous connaissez le procédé (règle de Kerckhoffs). C'est suffisant.

Contourner la sécurité quand il n'y a pas de faille d'implémentation est certes plus dur mais c'est plus excitant.
Bon courage à tous et à samedi aux RSSIL


Wednesday, May 25, 2011

iAWACS/RSSIL 2011 LibPerseus challenge

Hi to all

(French version below)

The LibPerseus challenge purpose is to evaluate the Perseus technology and to prove/show that it is indeed unbreakable unless having tremendous time/computing resources at one's disposal. Hence the aim is to test Perseus technology strength and security in a real context (and not with respect to academic conditions).

Technical scheme: three files have been protected by means of the Perseus library. They have been eavesdrop. No information about the computer from which they have been produced is available.
  • File 1 protected by an random punctured convolutional encoder E1. SHA-1 Digest 5628084D6EF360406B19C6E57F5F4BD0CF019910. Size 190,986 bytes.
  • File 2 protected by an random punctured convolutional encoder E2. SHA-1 Digest 7C5F5BE3F8C3143D428402C8B6B01C04033DEA0B. Size 263,996 bytes
  • File 3 protected by an random punctured convolutional encoder E3. SHA-1 Digest CAE5BF0CD032EBC9652CE3B3318ACD500BEE84D6. Size 26,482,752 bytes
  • Binary file (windows) of the program (warning: this is a beta version which is non optimized and that may contain residual bugs to be reported. As soon as frozen, source code and documentation will be published). SHA-1 Digest value 20CEF319E3D209D6EC288998F90C0E737720ED17. Size 5,022,669 bytes. A Linux version of the binaries can be provided upon request.
  • The solution E1, E2 and E3 are UNIQUE and the files (before protection by Perseus) to recover are plaintext (not encrypted). So anyone finding a solution is able to determine whether it is the correct one or not. Since E1, E2 and E3 are unique, the files to recover are also unique (no encoder collision).
  • Solution (plaintext file) 1 has the SHA-1 Digest value AAE42E6E0F80B1803A218CB1BE7A1ED12AD29B06
  • Solution (plaintext file) 2 has the SHA-1 Digest value F35BBE9B4754DE431FA1C45C96C2561282679D84
  • Solution (plaintext file) 3 has the SHA-1 Digest value 0F03FF24CC007A37DE82BB567674CEBCDF9FE4DE

Here are the condition for the challenge:
  • Opening date: May 25th, 2011. Reset on June 17th, 2011.
  • End of the challenge: March 31st, 2012.
  • The solution (plaintext file) must sent to
  • There is only one prize (award) of 4,000 euros which cannot be divided. One prize, one winner only.
Rules of the challenge:
  • The prize (4,000 euros) will be awarded to the first people (internet time will be taken as reference in case of multiple answers) only who is able to recover at least one of the t hree documents protected with Perseus.
  • The method used will have to be described on a technical basis and the source of the attack algroithm provided to the organizers of the challenge.
  • Any partial solution, hint or valuable information will be considered for a honor award.
  • Results and solutions will be published on this blog.
Have a nice challenge and good luck guys!

Version française

Le challenge Perseus vise à évaluer la technologie Perseus en la soumettant à l'analyse de tous. Il s'agit de démontrer qu'à moins de disposer de ressources temps/mémoire exorbitantes, il est effectivement impossible de casser en pratique cette technologie. Le but au travers de ce challenge est de tester la force et la sécurité de Perseus en conditions opérationnelles (et non académique).

Thème technique : trois fichiers ont été protégés avec la librairie Perseus. Ils doivent être considérés comme le produit d'une interception et par conséquent aucune information relative à l'ordinateur les ayant produit n'est disponible.
  • File 1 protégé par un codeur convolutif poinçonné bruité E1. SHA-1 Digest 5628084D6EF360406B19C6E57F5F4BD0CF019910. Taille 190,986 octets.
  • File 2 protégé par un codeur convolutif poinçonné bruité E2. SHA-1 Digest 7C5F5BE3F8C3143D428402C8B6B01C04033DEA0B. Taille 263,996 octets.
  • File 3 protégé par un codeur convolutif poinçonné bruité E3. SHA-1 Digest CAE5BF0CD032EBC9652CE3B3318ACD500BEE84D6. Taille 26,482,752 octets
  • Binaires Windows du programme ayant généré ces fichiers (attention il s'agit d'une version bêta, non optimisée, susceptible de faire l'objet d'une remontée de bugs ; cette application, son code source et sa documentation seront publiés prochainement une fois le code stabilisé). Empreinte SHA-1 20CEF319E3D209D6EC288998F90C0E737720ED17. Taille 5 022 669 octets. Une version Linux peut être fournie sur demande.
  • Les solutions E1, E2 et E3 sont UNIQUES et les fichiers (avant protection par Perseus) à retrouver sont des fichiers en clair (non chiffrés). Ainsi, toute personne pensant avoir une solution peut elle-même déterminer si cette solution est la bonne ou non. Comme E1, E2 et E3 sont uniques, les fichiers à retrouver le sont aussi. (aucune collision de codeur possible dans l'espace des paramètres imposés).
  • Solution (fichier clair) 1 a pour valeur d'empreinte SHA-1 AAE42E6E0F80B1803A218CB1BE7A1ED12AD29B06
  • Solution (fichier clair) 2 a pour valeur d'empreinte SHA-1 F35BBE9B4754DE431FA1C45C96C2561282679D84
  • Solution (fichier clair) 3 a pour valeur d'empreinte SHA-1 0F03FF24CC007A37DE82BB567674CEBCDF9FE4DE

Conditions du challenge:
  • Ouverture : 25 mai 2011. Réinitialisé le 17 juin 2011.
  • Fin du challenge : 31 mars 2012.
  • La solution (un des trois fichiers en clair définis ci-dessus au moins) doit être envoyée à
  • Un seul prix de 4000 euros, indivisible (un seul prix, un seul gagnant possible) sera attribué.

Règles du challenge :
  • Le prix (4000 euros) sera attribué à la première personne qui enverra au moins l'un des trois documents protégés par Perseus (document original AVANT codage tel que définis supra). Le temps Internet (date du mail) sera utilisé pour départager les éventuels concurrents ayant fourni une solution correcte.
  • Le procédé utilisé devra faire l'objet d'une description technique et le code source devra être communiqué aux organisateurs.
  • Toute information technique partielle sera étudiée et pourra faire l'objet d'un prix d'honneur.
  • Les résultats seront publiés sur ce blog.
Bonne chance à tous


Sunday, May 22, 2011

iAWACS 2011 Forensics challenge

Hi to all

(French version below)

The Forensics challenge for iAWACS 2011 is now open. It is inspired from a real case on which a new information hiding techniques has been created. The aim is to test its strength and its security on a almost real implementation (and not with respect to academic conditions).

Tactical scheme: a terrorist attack against the RSSIL 2011 event has been prepared according to some intelligence reports. A terrorist has been caught by the French police forces while he was about to recuperate a cell phone hidden in a geocache. Despite the efforts of the Police forensics and technical teams, the analysis of the cell phone has not been successful yet. However, the analysis proved that the Dcim directory is containing a secret message hidden.
The terrorist confessed that he was waiting for a call to him on this cell phone to receive instructions about another geocache. This second one contains a SD card with the application to access the secret message. Unfortunately, this call will never happen (newspapers have leaked on this arrest).

So will you be clever and imaginative enough to recover the secret message and prevent the attack against RSSIL 2011?

Here are the condition for the challenge:
  • Opening date: May 22nd, 2011. The file dcim.tgz contains the Camera directory (the phone is a Samsung Galaxy S).
  • Award ceremony (if any winner) or technical hints at the RSSIL 2011 event to go on with the challenge.
  • End of the challenge: December 31st, 2011.
  • The solution must sent to
Rules of the challenge:
  • The prize (5000 euros) will be awarded to anyone able to recover the message and the hiding mechanism only.
  • The technical mechanism will not be disclosed (unless by a potential winner who is free to publish any information with respect to it) by the organizers of the challenge. Only the secret message will be published once the challenge is closed.
  • Any partial solution, hint or valuable information will be considered for a honor award.
Have a nice challenge and good luck guys!

Version française

Le challenge forensics d'iAWACS 2011 est maintenant ouvert. Ce challenge est inspiré d'un cas réel à partir duquel une nouvelle technique de dissimulation d'information a été conçue. Le but au travers de ce challenge est de tester la force et la sécurité de ce procédé sur une implémentation en conditions opérationnelles (et non académique).

Thème tactique : une attaque terroriste contre RSSIL 2011 est en préparation selon des rapports des services de renseignement. Un terroriste a été arrêté par les forces de police au moment où il récupérait un téléphone mobile dans une géocache. Malgré les efforts de la police scientifique, l'analyse du téléphone a échoué. Toutefois, certaines pistes ayant été pu être écartées avec raison, les experts sont convaincus que le répertoire Dcim contient un message secret.

Le terroriste a avoué qu'il attendait un appel sur ce portable qui devait lui indiquer l'emplacement d'une seconde géocache. Cette dernière devait lui permettre via une application sur une SD card d'accéder au message secret et donc à ses instructions. Malheureusement ce appel n'arrivera maintenant plus, les journalistes ayant révélé la capture du terroriste.

Serez vous assez malin et imaginatif pour trouver ce message secret et ainsi empêcher l'attentat contre les RSSIL 2011 ?

Conditions du challenge:
  • Ouverture : 22 mai 2011. Le fichier dcim.tgz contient le répertoire "Camera" (le téléphone est un Samsung Galaxy S).
  • Remise du prix (s'il y a un gagnant) ou indices techniques pour prolonger le challenge durant les RSSIL 2011.
  • Fin du challenge : 31 décembre 2011.
  • La solution doit être envoyée à
Règles du challenge :
  • Le prix (5000 euros) sera attribué à la première personne qui enverra le message secret avec une description du mécanisme de dissimulation des données.
  • Ce procédé ne sera pas rendu public par les organisateurs (en revanche le gagnant est libre de publier toute information technique à ce sujet). Seule la solution (le message secret) sera publique.
  • Toute information technique partielle sera étudiée et pourra faire l'objet d'un prix d'honneur.
Bonne chance à tous


Tuesday, May 17, 2011

Specialized master in Cyberwarfare

You are interested in pentesting or want to become a cyber warrior. Our N&IS (Network and Information Security) specialized master is for you. Visit this link, read and enlist.
The scientific support is ensured by our lab.

E. F.

Post-doc or junior researchers positions


Well sometimes Christmas comes sooner than expected. I have three potential positions for post-doc or junior researchers for a period ranging from 12 to 24 months.
The conditions are the following:
  • Non-French nationality
  • Having a PhD
  • Being less than 38 years old
We are looking for researchers having the following profile:
  • Computer science with a good level in discrete mathematics
  • Skills in programming (C, python)
  • Hacker approach and mind strongly appreciated
  • Strong sense of contact and friendship
The research can be either in operational cryptology, computer virology or cyberwarfare.

If you are interested, please send an email with CV at

Have a nice day

E. F.

EICAR 2011 Paper on Mobile Botnets

Many people ask us why the EICAR 2011 paper on "Mobile Botnet" was announced but not presented. Well the two Chinese authors cancelled at the very last minute. "Visa problem" was the official reason.
Read the paper and make your own advice

Have a nice reading
E.F. (EICAR 2011 Program Chair)

Monday, May 16, 2011

McAfee Quarantine file and sequels from our EICAR 2011 paper

Following our talk at EICAR 2011 (first day), we have announced the release of some technical data. Of course, for fairness Peter Szor at McAFee has been contacted about our paper and the present post and his feedback and comments have been very constructive. In this respect, McAfee decision to recruit Peter is likely to be a wise and strategic decision which could result in a significantly better AV. Wait and see...

We would like address the problem of the quarantine file (referring to Section Wake up! in the paper)

Why the McAfee Quarantine Wake-up Proof of Concept happened? Our PoC relies on two factors:
  • The McAfee Quarantine Directory is accessible to ALL users. It can be read and by the fact extracted to other directories.
  • The McAfee Quarantined files are protected by a weak key encryption
Our Proof of Concept is based on the EICAR test file (to avoid working with real malware):
  1. As soon as the EICAR is detected by the McAfee Antivirus protection software, it is moved to the Quarantine directory and deleted.
  2. All McAfee Quarantine files are under the BUP extension which in fact “extractable” from the 7zip open source software.
  3. As soon as you can extract it with 7zip file, you still not able to restore the original file.
  4. Details gives you all the information to restore the file (name and extension of the original virus).
  5. You need to XOR all the files previously extracted by the key “0x6A”
Our PoC consists in reading the content of BUP file and recovering the virus under the File_0. We have demonstrated that it was clearly possible to activate all quarantined files and thus performed a lot of different attack scenarii (from DoS to covering a new viral attack).

McAfee has been informed, through its Indian development team at Tata, India, during the EICAR 2011 conference and will fix as soon as possible this critical issue (probably in the next McAfee Roadmap). It is worth mentionning that weak management in quarantine directories and weak encryption has been identified for a few other AV vendors and products. To be continues then...

Source code (PERL):



# Date: EICAR 2011 (Austria)

# Description: It is a Proof Of Concept of decoding the McAfee VirusScan Quarantine BUP files (All McAfee versions)

# Requirements: It uses open-source 7zip compression tool

# Todo: Implement the 7zip decompression algorithm to avoid using 7zip program

# This program should parse the Details file to be able to name File_x with their original names

my $BUPFILE = $ARGV[0] or die "BUP File is required\n";

my $cmd = `7z e $BUPFILE -oBUP/`;

opendir(DBUP, "./BUP/");

while (my $ditem = readdir(DBUP)) {

# Extract the information of infected file (Details file stores product version, detected virus, DAT signature us


if ((-f "./BUP/$ditem") && ($ditem =~ m/details/i)) {

open(fd, "<./BUP/$ditem") or die "File error $!\n";

open(fout, ">./BUP/$ditem.details") or die "File error $!\n";

while() {

print fout map { pack("c", 0x6A ^ ord($_)) } split (//, $_);



seek(fout, 0, 0);

while() {






# Decoding the infected files if they are present.

if ((-f "./BUP/$ditem") && ($ditem =~ /File/i)) {

my $vir = rand(10) . ".vir";

open(fd, "<./BUP/$ditem") or die "File error $!\n";

open(fout, ">./BUP/$vir") or die "Error file vir";

while() {

print fout map { pack("c", 0x6A ^ ord($_)) } split(//, $_);







Regarding the ZouAV detection issues and concerns. Since our talk, this code has now two additional names. More to come in a forthcoming post.


Android zsone malware

The original article is here.

Thursday, May 5, 2011

EICAR 2011 Conference in Krems

Hi to all

We are leaving to tomorrow to Krems in Austria where the 20th edition of the EICAR conference will take place. This conference is the oldest one in Computer Virology and this year many critical topics will be addressed, especially about Cyberwarfare, the role of AV software with respect to the use of malware techniques by Police/Intelligence/Defense organizations and many other technical topics. The main theme for this jubilee edition is “New trends in Malware and Antimalware techniques: myths, reality and context - What will be the AV role in a Cyber War scenario?A really hot issue indeed!

The technical program is here. Slides and papers will be available on the conference website by mid May.


Our research guest from Thailand

Hi to all

We have the great pleasure and honour to welcome Dr Bhume Bhumiratana from the Department of Computer Engineering, King Monkut's University of Technology, Thonburi, Thailand. He will stay in our lab for three months to discover the formal aspects of computer virology and especially the use of formal grammars in metamorphic techniques with application to the Android bytecode.

His webpage is here.
Welcome to Dr Bhume Bhumiratana

Monday, March 21, 2011

Honeynet Project : Day 1 (Public)

Efficient Bytecode Analysis : Linespeed Shellcode Detection (Georg Wicherski - McAfee)
  • GetPC sequences ((call $+5, pop r32), (fnop, fnstenv [esp+0x0c], pop r32), structured exception handling)
  • detecting shellcodes (static) (eg: markov chains)
  • detecting shellcodes (getpc + backtraking + emulation)
  • libscizzle : identification of possible getpc sequences, bruteforce possible starting location around sequence, use efficient sandbox
  • libscizzle Code Execution (disassemble guest code, execute one basic blocks, emulate all other instructions, exception)
  • Performance of libscizzle : 99 MiB/sec to 795 MiB/sec, 1000x faster than libemu
  • Evaluation of libscizzle : no false positives, no false negatives
High performance packet sniffing and traffic mining(Tillmann Wener)
  • pcap file format (straight-forward file format)
  • packet drops (sniffer too slow, lost information cannot be recovered), sniffing performance
  • multicap : minimiez memory allocations, no system calls to get packet times, memory-mapped dump files
  • streams : reassembly tcp streams
  • tools available @
Reversing android malware (Mahmud Ab rahman)
  • Dalvik VM : registered based
  • Dex file format (odex : optimized dex)
  • infection methods : remote install (victim's gmail credential is required, browser market and install)
  • dex (baksmali)-> class (jad)-> java
  • SMS.trojan : oldest android malware
  • Geinimi : infecting legitimate software, C&C server, encrypted data, steal data
  • DroidDream : infecting legitimate software, android official market
  • Need new tools (GSOC Honeynet ?)
VOIP Security (Sjur Usken and Ben Reardon)
  • SIP, request and response type, same familiar status codes as HTTP
  • Major difference between SIP and HTTP (in SIP, all devices are both server and client)
  • used to connect to the PSTN network
Glastopf - Looking for trouble ? (Lukas Rist)
  • Web application honeypot
  • collecting attacks
  • gain intelligence

Sunday, March 20, 2011

iAWACS 2011

Hi !!

The CFP of iAWACS 2011 is here.

This year, we have 2 challenges :
  • LibPerseus challenge. A file protected by the PERSEUS technology will be proposed for analysis. The aim is to recover the underlying file. Award 3000 euros.
  • Forensics challenge. The content of an Android Phone will be given (as an iso image). In the tactical context of a terrorist attack to be prepared, the aim will be to discover the critical information regarding this attack in order to make it fail. Award 5000 euros.

See ya !

Friday, March 18, 2011


Following the Stuxnet conference (see previous post in March), a number of sequels and reaction have been made with interesting feedbacks from various speakers (e.g. Jeffrey Carr). You will find everything here. You can also read a report in the Globes online journal.

I do not agree on Jeffrey Carr's comments, at least for some of them. He seems not to be aware of how the hackers community is thinking, working and sharing things. More concerning, he seems to ignore most of the operational stuff when designing and deploying real attacks.

However the echange of ideas was great. Thanks to him and to the organizers of this event.
Have a nice day

Tuesday, March 15, 2011

Friday, March 11, 2011

Feedbacks from CanSecWest 2011


CanSecWest 2011 is nearly over. It is a very exciting place for hacking stuff. Without doubt it is one the very few hacking events that everyone concerned with operational IT security should attend. Thanks to Dragos and all the SecWest team. Perfect job and the party.... waouuuh what a party!!!! Just the kind of pure moment of pleasure that deserves to work hard on technical stuff during the year.

As usual the technical program is rich and of a very high level. But no comment can replace reading the slides of the different talks. One of the strong point of CanSecWest up to me lies in the fact that the attendees are not just passive. They ask questions and are really interested. So sharing and exchanging ideas has been intense and constructive.

After my talk on Dynamic Cryptographic Backdoors, I had very interesting feedback from OpenBSD developpers. Regarding the second technique I have presented (patching and modifying encryption algorithms in memory to weaken them on-the-fly), they make a very interesting comment about encryption systems like Blowfish or Twofish. These two algorithms have some sort of polymorphism that makes almost impossible to use S-box signature. Well, it is partly true but using some local entropy measure should help to locate area to patch (or special functions like the PHT).

But it is sure that this is a challenging problem. So we are going to address the particular case of Blowfish and Twofish. So to be continued...

From that exchange I draw the conclusion that "polymorphic, design" in cryptographic algorithms provide more security against applied cryptanalysis techniques like that I have presented. In this respect, aside the fact that Twofish was not significantly weaker than Rijndael (damned academic research!), I am more than ever surprised about the fact that NIST did not select Twofish.


Wednesday, March 9, 2011

Voting machine attack


Here is a prospective paper describing an unconventional yet efficient attack again voting machines, perverting the precautionary principle.
Paper here.
Have a nice reading


Monday, March 7, 2011

Saturday, March 5, 2011

CanSecWest 2011

Hi to all

I will give a talk at CanSecWest 2011 in Vancouver (a very nice, among the best hacking conference) entitled "Dynamic cryptographic trapdoors". Here is the conference abstracts.

Come and learn how to
  • make data evade from {vpn, ipsec, tor...}-protected networks
  • dynamically weaken strong cryptosystem for a limited period of time only (dynamic trapdoors) to enable easier cryptanalysis
  • how mathematical trapdoors could also be imagined and implemented.
Have a nice week end

Stuxnet conference

Hi to all/bonjour a tous

Here is the video teaser of the Stuxnet conference on March 8th, 2011.

Voici la vidéo d'annonce de la conférence Stuxnet à Paris le 8 mars 2011.



Thursday, February 24, 2011

Tuesday, February 1, 2011

Libperseus now in Ruby

The Perseus library is now available as a Ruby binding written by Fabien Jobin.
It is based on ffi.

The archive contains two files:
* ffi-perseus.rb
* perseus_test.rb

The binding is made by ffi-perseus. It contains four functions only (to make its
use as simple as possible):
* perseus_init
* perseus_code
* perseus_decode
* perseus_destroy
as well as the parameter structure.

The perseus_test.rb file shows how to use everything.

Have fun with it

Saturday, January 29, 2011

libperseus 1.0.1 (python + java binding)

Hi !

We have updated libperseus library, and now you can use it with python (with ctypes) and java (with jni). The new stable version is now available.

So, if you would like to use Perseus technology, the first thing to do is to compile the library :
desnos@cvo:~/$ tar xvzf libperseus-1.0.1.tgz
desnos@cvo:~/$ cd libperseus-1.0.1
desnos@cvo:~/libperseus-1.0.1/$ make
To use Perseus with >= Python 2.5, you must have the shared library in your path and the perseus python module (see the "python" directory for examples) which encapsulate all stuff.

The first thing to do is to create a new Perseus object, with four float (0.0 to 1.0) numbers to generate noise (if you don't specify these numbers, the module will do it) :
from random import random
from perseus import Perseus

p = Perseus(aleas=[ random() for i in range(0,4) ])
and after you can code or decode your string with the code and decode methods of the Perseus object :
encoded_data = p.code( "CVO BLOGSPOT" )
decoded_data = p.decode( encoded_data )
About the java binding (see the "java" directory for examples) , we have written a class to use it more easily. But the first thing to do before is to compile it (you must edit the Makefile to setup the jni headers of your java installation : JAVA_INCLUDE) :
desnos@cvo:~/libperseus-1.0.1/java/$ make
Next you can create a Perseus object (as in the Python module, you can specify or not the noise numbers) into a new class file :
Perseus p = new Perseus();
And you can use Code and Decode methods of the object :
String data = new String( "CVO BLOGSPOT" );

String encoded_data = p.Code( data );
String decoded_data = p.Decode( encoded_data );
Easy, no ? ;)

Have fun !