Software Engineer: In search

Adjunct Researcher, CSRC

About Me

Another happy geek: I love learning new skills and enjoy building large systems, almost just for the sake of it.

After graduating from Télécom ParisTech in 2016, I worked three years in Korea as a Software Security Researcher. This gave me the opportunity to develop my ability to understand and solve abstract problems. I work one year on a project enhancing the Linux Kernel security before pivoting to fuzzing. I always pushed for my project to have high quality prototypes. This way I became comfortable with several system languages: Go, C, C++. Recently, one of my project was merged into the LLVM project, one of the largest C++ code bases, and heavily relied on by Google. In 2020 I returned to France and worked at PacketAI, a young startup, to build a cloud monitoring platform: I was in charge of the agent producing data, and all the microservices treating it before handing either the UI or the ML services.

Interests

  • Software Engineering
  • Machine Learning
  • Software Security

Education

  • Master in Computer Science, 2016

    Télécom ParisTech

  • Preparatory School in Physics and Chemestry, 2013

    Lycée Lakanal

Experience

 
 
 
 
 

Software Engineer

In search

Aug 2020 – Present Paris, France
 
 
 
 
 

Software Engineer

PacketAI

Jan 2020 – Jul 2020 Paris, France
PacketAI aims to predict cloud infrastructure incidents and identify their root cause. I was developing the agent, a software running on client hosts collecting events and metrics, and sending them to PacketAI servers via Kafka pipes. I was also in charge of the microservices, developed in Go, treating this data.
 
 
 
 
 

Software Security Researcher

CSRC - KAIST

Oct 2016 – Dec 2019 Daejeon, Korea
During my first year, I worked on developing a kernel hardening solution by limiting the kernel attack surface. Then, I reoriented myself towards Automatic Software Testing (also called fuzzing). Fuzzers generate inputs with the intent of causing the software under test to misbehave. Specifically, I investigated the usage of machine learning techniques to improve fuzzers bug finding ability.

Publications

Boosting Fuzzer Efficiency: An Information Theoretic Perspective

Entropic is an information-theoretic power schedule implemented based on LibFuzzer. It boosts performance by changing weights assigned to the seeds in the corpus. Seeds revealing more “information” are assigned a higher weight. Entropic has been independently evaluated by a team at Google and invited for integration into mainline LibFuzzer @ LLVM (C++ code base), whereupon Entropic was subject to a substantial code reviewing process.

Ankou: Guiding Grey-box Fuzzing towards Combinatorial Difference

Grey-box fuzzing is an evolutionary process, which maintains and evolves a population of test cases with the help of a fitness function. Fitness functions used by current grey-box fuzzers are not informative in that they cannot distinguish different program executions as long as those executions achieve the same coverage. The problem is that current fitness functions only consider a union of data, but not their combination. As such, fuzzers often get stuck in a local optimum during their search. In this paper, we introduce Ankou, the first grey-box fuzzer that recognizes different combinations of execution information, and present several scalability challenges encountered while designing and implementing Ankou. Our experimental results show that Ankou is 1.94× and 8.0× more effective in finding bugs than AFL and Angora, respectively.

The Art, Science, and Engineering of Fuzzing: A Survey

This paper surveys both the academic papers and the open-sourced tools in the field of fuzzing. We present a unified, general-purpose model to better understand the design and trade-offs of fuzzers.

Domain Isolated Kernel: A lightweight sandbox for untrusted kernel extensions

Monolithic kernel is one of the prevalent configurations out of various kernel design models. While monolithic kernel excels in performance and management, they are unequipped forruntime system update; and this brings the need for kernel extension. Although kernel extensions are a convenient measure for system management, it is well established that they make the system prone to rootkit attacks and kernel exploitation as they share the single memory space with the rest of the kernel. To address this problem, various forms of isolation (e.g., making into a process), are so far proposed, yet their performance overhead is often too high or incompatible for a general purpose kernel. In this paper, we propose Domain Isolated Kernel (DIKernel), a new kernel architecture which securely isolates the untrustedkernel extensions with minimal performance overhead. DIKernel leverages hardware-based memory domain feature in ARM architecture; and prevents system manipulation attacks originated from kernel extensions, such as rootkits and exploits caused by buggy kernel extensions. We implemented DIKernel on top of Linux 4.13 kernel with 1500 LOC. Performance evaluation indicates that DIKernel imposes negligible overhead which is observed by cycle level microbenchmark.

Recent Posts

Compiling Linux Kernel with Clang

Hi everyone. This is my first ‘technical’ blog post. I saw some people saying it helps growing your explanation skills which I sincerely lack. Thus, I decided next I struggle doing something because I feel it’s quite undocumented, I’ll try to make a post and explain how I did it. If even one person reads this and it’s even remotely useful to them, I’ll consider the job done. Ask any question, I’ll be happy to answer.