In recent weeks, Confide, a secure instant messaging application, has gained popularity in some circles. This article presents a quick assessment of the security of this application. The official website boasts the confidentiality provided by the product through three qualifiers: encrypted, ephemeral and screenshot protected. Each of these aspects will be studied.

The encryption protocol will be particularly detailed because it is tagged as battle tested, military grade cryptography. We already knew about military grade cryptography, which seems to be a synonym of put AES-256 somewhere, no matter how you use it in many applications, but we had never heard of battle tested cryptography. This article is an opportunity to present this technology.

Developing properly end-to-end communication systems is complex. As we have seen in the past with iMessage, even if cryptographic primitives are correctly implemented and encryption keys are correctly generated and protected, the design is critical to forbid the service operator from being able to eavesdrop messages.

Various Samsung Exynos based smartphones use a proprietary bootloader named SBOOT. It is the case for the Samsung Galaxy S7, Galaxy S6 and Galaxy A3, and probably many more smartphones listed on Samsung Exynos Showcase [1]. I had the opportunity to reverse engineer pieces of this bootloader while assessing various TEE implementations. This article is the first from a series about SBOOT. It recalls some ARMv8 concepts, discusses the methodology I followed and the right and wrong assumptions I made while analyzing this undocumented proprietary blob used on the Samsung Galaxy S6.

On September 13th, 2016 Microsoft released security bulletin MS16-104 [1], which addresses several vulnerabilities affecting Internet Explorer. One of those vulnerabilities is CVE-2016-3353, a security feature bypass bug in the way .URL files are handled. This security issue does not allow for remote code execution by itself; instead, it allows attackers to bypass a security warning in attacks involving user interaction. In this blogpost we discuss the whole process, from reverse engineering the patch to building a Proof-of-Concept for this vulnerability.

While building an LLVM-based obfuscator, we explore some unexpected code areas. For instance, what happens when you try to optimize a single function that holds millions of instructions? Some LLVM passes start to suffer, including an unexpected one: Global Dead Code Elimination. Let's investigate!

With the Differential Computation Analysis (DCA) presented at CHES 2016, we have shown that side-channel techniques developed to break hardware cryptographic implementations can be adapted successfully to break white-box implementations. In this post, we will explore another class of hardware attacks: fault injections and how to apply them on white-box implementations.

A binary analysis of CVE-2016-7259: A win32k kernel bug.

EDIT: All positions are filled

Every year, we are looking for young and adventurous students, with promising skills, eager to dig deeper into the field of security through its more technical side. The topics we propose are complex, challenging and will require a lot of efforts and sweat. But in the end, you will get the satisfaction to have learned a lot about security. All this without emphasizing enough the opportunity to work with the sometimes weird but always amazing Qb crew, especially when it comes to humour or training a Padawan.

All trainings are to be done in our main office in Paris, France. We encourage remote working, but that does not apply to trainings where the Padawans need to be among the team. That means the applier will need to have the proper visa to work with us if required.

Last but not least, we usually train Padawans so that they remain with us once the training period is done, even if that does not mean the training is over :)

Cappsule was released a few weeks ago and we're happy of the positive attention received. However, relying on a custom hypervisor make its usage quite difficult across various distros. This blogpost explains how the same goals can be achieved on Linux with usual software. Impatient readers can directly checkout NoFear's GitHub.

Quarkslab made a security assessment of VeraCrypt 1.18. The audit was funded by OSTIF and was performed by two Quarkslab engineers between Aug. 16 and Sep. 14, 2016 for a total of 32 man-days of study. A critical vulnerability, related to cryptography, has been identified. It has been introduced in version 1.18, and will be fixed in version 1.19.

Quarkslab was present at CppCon 2016, presenting general thoughts on the C++ optimization process and how much the so-called zero-cost abstraction relied on the compiler implementation, and not on the standard. Now comes a humble report from this great event!