We LOVE interns! Really. We love them because they bring fresh air to the company and because we see them grow, not only during the internship but also after, when they are hired and can get to work on so many other topics. There are 2 goals for us in every internship we offer:

  • Explore a topic we don't necessarily know very well, hence train the new expert on the topic,

  • Hire you after the internship to keep and share your new expertise with colleagues.

Our offers at a glance:
  • Unpacking firmwares

  • HarmonyOS and the raiders of the lost Ark

  • Fuzzing like a mad monkey

  • Kubernetes: building a rootkit for the next cloudOS

  • Packer across multiple stages of the compilation pipeline

  • Research vulnerabilities in hardware emulation on virtualization platforms

We are also welcoming people with a wide but realistic creativity, so if you have an idea and want to join the team, dont hesitate (we might even be the ones offering you the croissants ;)

Training and growing people in the security industry is part of the company's DNA. That is why we provide in-depth blogposts, tools, trainings, weekly internal conferences (called fridaycon, guess why), we teach in universities and schools, write articles in tech magazines and send our less experienced hires to a 6-month intensive training program (BADGE-RE or BADGE-SO). Sharing is caring, but sharing is also learning. We provide the environment for that, the remaining relies on you.

With the COVID pandemic, we have to reinvent our ways. Fortunately the team has been used to work remotely from day 1, it is how we grew. But for interns, having the possibility to chat in real life with other people is necessary. We have offices in Paris, Rennes and Buenos Aires, and we would prefer you to spend some time there, likely 1-2 days per week in the office, in accordance with your tutor. We might consider remote internships too [1], depending on the topic and your ability to have a “remote social life” and be a bit more autonomous. This might change with the pandemic, and of course will have to be discussed in due time. In any case, discussing on a daily basis with the tutor is important and this will happen either in real life or virtually.

Intern package in France:

  • Salary: 1800€ gross / month (1550€ net)

  • "Tickets restaurant" (restaurant coupons)

  • In-depth and challenging topics

  • After the internship:

    • Permanent position (CDI in French)

    • Bad ass trainings

[1]For legal reasons, the remote work needs to be in the country where offices exist, which means either France or Argentina.

How to apply for an internship position at Quarkslab?

To apply for an internship position, you have to send:

  • a CV;

  • a cover letter: avoid the generic letter saying that you are so motivated and that we are so interesting. We welcome a more personal letter which explains why the topic is of particular interest to you, why you, why us :)

  • your proposed solution to the assignment attached to the offer you are interested in,

  • all this can be sent in French or in English.

Send this little package to internship-AT-quarkslab-DOT-com, with the subject field containing the internship reference mentioned in the respective offer.

Do not forget that the secret of a good application is to show what you have already achieved (related to the topic or not).

Each internship offer comes with a little assignment that should not require too much time to be completed. The result will show us not only the type of skills and knowledge you already possess, but also how ingenious you are and how well you can present your reasoning. It will serve as the basis for the interview you will have in the selection process.

For all its internships, Quarkslab is looking for highly motivated, curious and autonomous people who are also structured, creative and team players. You will evolve in a dynamic and easygoing environment where ideas spring from everywhere...

We consider internships as opportunities to spot profiles that match how we work. They are intended to guide students to enter the professional world as potential future colleagues if they feel like it and find convincing arguments [2]

Do not be shy, send an application, otherwise you will never know if you would have been selected...

Contact : internship-AT-quarkslab-DOT-com

Please note that:

  • Only students are eligible

  • Candidates must carefully select if they prefer pains au chocolat or chocolatines.

[2]also called croissants...

Unpacking firmware


Nowadays, firmware are everywhere: mobiles, routers, ECU, IoT devices, Set-Top boxes, … Sometimes, they are as simple as a filesystem, which can just be accessed like every other filesystem. But most of the time, they are compressed and encrypted, sometimes using custom algorithms.

However, when one wants to analyze what is inside the firmware, the first step is always to reach its inside, hence opening it.

The goal of the internship is to work on a generic engine able to deal with multiple kinds of firmware to access the files it contains.

  • Improve our framework to handle file systems

  • We will select multiple firmware, and you will have to support them in the framework

    • Study encryption and compression if any

    • Develop the appropriate unpacking capabilities

    • Test on various firmware of the same family (yes, sometimes, there are surprises ;)

  • Automate unpacking based on our Irma framework

Required skills

  • Fluent in Python

  • Good knowledge in cryptography and algorithms

  • Preferably some experience in reverse engineering in ARM and/or unpacking malware


The Android OTA Package Tools [3] support building full and incremental updates, that can later be applied to a device. Take a look at the building tool from the AOSP source tree [4] and implement your own unpacker for this format, preferably using Python.

You can use the building script to make your own packages, but your tool should be able to extract at least the following packages: [5] (full update) and [6] (incremental update that should be applied on top of the other one).

Once you are satisfied with your unpacking script and are ready to show it to us, please also write a small report explaining how you designed it.





6 months



HarmonyOS and the raiders of the lost Ark


On 9 August 2019, Huawei officially unveiled Harmony OS. Huawei described Harmony as an open source, microkernel-based distributed operating system for various types of hardware, like smart TV, in-car entertainment or wearable devices. Huawei launched Harmony OS 2.0 at the Huawei Developer Conference on 10 September 2020 and intends to ship the operating system in smartphones in 2021.

Another critical piece of what Huawei is building is Ark, a compiler allowing, among other things, to port Android applications natively to HarmonyOS, removing the need of an interpreter. This compiler is open source, and supposed to help Huawei to build its own environment if they were banned from working with US companies. So far, the expectations put in it might not exactly meet the actual results.

The internship intends to dive deep into both HarmonyOS and the Ark compiler:

  • Set up a working environment to play with a running instance of HarmonyOS

  • Describe the security model both in userland and kernel.

  • Map code base: identify new components, or code reuse, as open source libraries for instance

  • Implement some tools (IDA/Ghidra plugins) or adapt (some of) ours to that environment (QBDI, LIEF, Triton, ...)

  • Fuzz "interesting" components

Of course, depending on the stage of reliability of HarmonyOS, other tasks could be explored more deeply: how to gain persistence on the system, boot process, hooking the kernel or critical part of the OS, ...

The goal for the intern is to gain extensive knowledge on the OS while it is still young, and be creative.

Required skills

  • Good understanding of how an OS works (no matter which one)

  • Good knowledge of C/C++

  • Knowledge in vulnerability research in source code OR fuzzing OR Android malware.


  • Choose between CVE-2020-0245 and CVE-2020-0408

  • Analyze the bug: find the root cause, explain why there is a bug

  • Trigger the bug: build the appropriate code, and explain how / why the bug is triggered

  • Send us a report in English explaining all that

  • Note that we are more interested in your approach than by the result itself




6 months



Fuzzing like a mad monkey


At Quarkslab, it is quite common that we need to do some fuzzing campaigns either for clients or for our internal needs.

Fuzzing should be simple to integrate and be a no-brainer when you need to use it during a constraint timeframe.

We are looking for someone who likes to code and do fuzzing (and want to take that knowledge to the next level). Being familiar with the container ecosystem (docker and kubernetes) is recommended.

The purpose of this internship is to improve various tools used during a fuzzing campaign. Depending on the desires and knowledge of the candidate, it can go from developing or improving fuzzing tools (crash triaging, coverage visualization, snapshot-based coverage-guided fuzzing, ...) to tackle continuous fuzzing issues (scaling, corpus sharing, ...).

Required skills

  • Be familiar with fuzzers

  • Be familiar with docker

  • Some knowledge of kubernetes would be great too.

  • Fluent in either Python or Rust


  • Write a fuzzing harness for a publicly available software on github by using either libfuzzer, afl, or honggfuzz (don't take one with harnesses already available)

  • Explain why you choose this target. A particular attention will be paid to the quality and reproducibility of the results. (e.g: it can be for example in a docker container)

  • Explain how you would address the main difficulties encountered if you were fuzzing this target for a long time. For example how you would do crashes triaging, how you would scale to one or multiples machines, how you would proceed to reproduce the bugs, how you would find the root cause of the bug, ...




6 months



Kubernetes: building a rootkit for the next cloudOS


Cloud is everywhere offering more and more services to build applications. Devops tools are building the future as applications are continously deployed. But "cloud tools" are seriously changing the landscape of applications allowing to build them with microservices on top of cloud infrastructure. This trend will not slow down.

Clouds and systems to operate them like Kubernetes have become the new operating system. At Quarkslab, we use some tools like Kubernetes, Docker, Vagrant, Ansible, ... either to run or build our own products or to run fuzzing campaigns. When a new "Operating System" emerges, we are obviously curious about the security model it brings.

The goal of this internship is to study in depth how Kubernetes (and likely some of its friends) works and build a rootkit (persistant, stealthy, ...) to maintain an access to such an infrastructure. You will start by gathering information about CVEs and likely try to exploit a few of them in order to understand the internals of the systems. We will then assume you are in position to control the k8s infrastructure (directly or through the tools used by it). You will have to work on maintaining your access in a stealthy way: how to maintain access with either a normal or an admin access? how to steal secrets and eavesdrop everything happening in the infrastructure?

To summarize, you will have to :

  • Study known vulnerabilities in these tools

  • Learn how they work from the inside and manipulate them

  • Be creative in order to find unexpected ways to have them misbehave

  • Look at how the main cloud providers are working with these tools

At the end of your internship, you will have built a set of tools to "play" with a Kubernetes infrastructure. The multiple tools (payloads) will allow various actions on the infrastructure (dump secrets or whatever a compromised pod can access, eavesdrop some encrypted communications, and so on).


Required skills

  • Development in Python or Go

  • Go knowledge

  • Good Linux understanding (possibly with experience in sysadmin)

  • Some knowledge of Docker or Kubernetes is obviously a bonus


Provide your own security analysis of a CVE in Kubernetes or Docker: explain the root cause, and your own exploitation way.




6 months



Packer across multiple stages of the compilation pipeline


Writing a packer that interacts correctly with other obfuscations is far from easy. Where should the packing be done? In the compiler intermediate representation? Before obfuscations? Afterwards? If it's done too early, the packed code won't benefit from other obfuscations. If it's done too late, the code may be too obscure to identify a single piece of code for packing. In the first scenario, it's enough for the attacker to collect traces of the code during the execution to recover the un-obfuscated code, while in the latter, the whole application must be packed as a single piece, which incurs a big performance hit.

A better approach is to span the packing strategy across several levels, doing a part of the work in the intermediate representation, and another part in the binary code. This allows to inject unpacking code early enough, so that it can be obfuscated together with the user's code, and to inject placeholders that will be later filled by a later transformation directly on the binary code.

The objective of this internship is to do a first implementation of this strategy, and explore some improvements to this protection.

Required Skills

  • C++ programming

  • Low-level and systems interest

  • Knowledge of the internals of LLVM is a plus !


The machine

This is an informal design for a stack interpreter that manipulates 32 bit signed integers and understands a few instructions instructions.

In the following TOP denotes the element on top of the stack, and SECOND the second element on top of the stack.

Each instruction has an index in the code, starting from 0, and an optional integer argument, as in 3 POP 2 which is the forth instruction of the listing, named POP with a single argument 2.


READ: reads an integer on stdin and push the value on the stack, or exit if input is invalid

WRITE: pops the top value of the stack, and prints it on stdout

DUP: duplicate the value on top of the stack

MUL: pops the two top value of the stack, multiply them and push the result on top of the stack

ADD: pops the two top value of the stack, add them and push the result on top of the stack

SUB: pops the two top value of the stack, sub the TOP with the SECOND and push the result on the stack

GT: LT: EQ: pops the two top values from the stack, compare them for TOP > SECOND, TOP < SECOND or TOP == SECOND and push the result as 0 or 1 on the stack

JMPZ: pops the two top value of the stack. Jump to the <n>th instruction, where <n> was the first value on the stack, if the top value is null. Otherwise just drop these two values

PUSH <n>: push the integer value <n> on the stack

POP <n>: pop n value from the stack

ROT <n>: perform a circular rotation on the first n value of the stack toward the top for instance the stack : BOTTOM [1,2,4,8] TOP becomes BOTTOM [1, 8, 2, 4] TOP after ROT 3


The following program reads a number and prints its value squared if the value is positive or null, and 0 otherwise.

2 PUSH 0
3 GT
4 PUSH 8
6 POP 1
7 PUSH 0

What to do ?

  • Using this language, write an implementation of the factorial function that reads a number from stdin and outputs its result on stdout.

  • Provide an interpreter that can interpret your code, written in C++.

It's not mandatory to write the parser for the assembly, a global array will also be fine.




6 months



Research vulnerabilities in hardware emulation on virtualization platforms


Virtualization solutions such as Microsoft Hyper-V, VMWare Workstation, Virtual Box, etc. provide isolation from the outside world and everything is executed inside the limits of the virtual machine. However, can these limits be bypassed from a malicious guest? How difficult is it to interact with the outside world and escape from the matrix? That's what our intern will find out by focusing on the emulation of hardware components.

The purpose of this internship is to study in-depth how virtualization platforms handle the emulation of hardware components (low level) to understand how secure they are.

Of course, the topic is broad and the first task will be to choose a virtualization solution (Hyper-V, VirtualBox, VMWare, QEMU, etc.), depending on the intern experience, existing work and discussions with the team. Then the intern will study its ecosystem, the different components composing it and how they interact between each other. These first steps should give them an overall understanding about how things work and how to tackle the rest of the topic.

Then, they will have to conduct a more in-depth analysis of how the virtualization solution handles the emulation of hardware. There are three possibilities: full emulation of the devices, para-virtualization and direct access (passthrough) to the guest. They will choose with the team one of these mechanisms for further research.

Finally, they will use all the knowledge gained during the research phase in order to attack the studied emulation mechanism. Different approaches such as fuzzing, manual reverse engineering or whatever techniques they can think of can be used in order to test the strength of the virtualization platform and try to escape from the matrix by exploiting the hardware emulation interface.

At the end of the internship, we should have an in-depth knowledge (and documentation) of the hardware emulation mechanisms of the chosen virtualization solution and an evaluation of the possibilities to escape this virtualized environment by exploiting the hardware emulation interface.


You have the choice between the two following exercises:

  • Choose two virtualization platforms (for example Microsoft Hyper-V and Virtual Box) and

    • describe succinctly their overall architectures,

    • compare them and comment on their advantages and drawbacks.

  • Mount a USB key in a virtual machine (either Microsoft Hyper-V or VMWare Workstation) and explains how the virtual machine is able to see the files in the key. The level of details expected is at the binaries or modules level (not functions). Describe the set up you use for your experiment and your analysis.

Required skills

  • Curiosity

  • Ability to understand C or C++

  • Experience with OS internals

  • Understanding in reading assembly language and using debugging tools

  • Ability to use a programming language

  • Experience working with disassemblers such as IDA Pro


Buenos Aires


6 months



If you would like to learn more about our security audits and explore how we can help you, get in touch with us!