Here at Immersive Labs we want to encourage and foster practical cyber skills development. Thats why we work with industry experts who are at the top of their game. Each month we feature an expert researcher with their history, how they got in to the industry, a technical blog post and an accompanying cyber lab (ninja difficulty level).

This month we feature Pedro Ribeiro – an experienced security researcher who has identified zero-days in multiple routers.

Name: Pedro Ribeiro

Role: Security Researcher



I started playing with computers at a very early age, around 6. But it was just really playing – I played lots of games until I was 20 and went to university to study computer science. I didn’t learn how to code before that, but I had a pretty good knowledge of system administration, networking and computer internals.
However in university I soon learned to love coding, and after I finished by Bachelors, I thought “this cyber security thing (at the time called information security) seems pretty cool and a good career, so I want to follow that” – and I decided to take a Masters on it in the UK. Again, I had very little knowledge about technical security at the time. The Masters was pretty good, but more theorethical than technical.

After finishing my Masters, I joined a very large consulting company as a cyber security auditor. But very quickly I became fed up with all the “business stuff”, such as auditing systems against checklists, architecture reviews, etc. My love for coding had been asleep for years, but it was now coming back. I started getting into more technical projects, penetration testing and from then on it was a rollercoaster – I started my own company, got my own clients and got deep into more technical matters.

Most of my work these days is penetration tests, reverse engineering, code reviews, fuzzing and security analysis of every kind of system, from web applications to smartphones, protocols, network devices, etc. I spend a lot of time looking at assembly, but also at PHP, Java, etc. I debug hardware devices using probes, solder and desolder chips, extract firmware, a lot of fun stuff. I truly love my job.

One of the things people most ask is how to get where I am right now? Is it harder now than a few years ago?

I’ll start by answering the second question. I personally think it’s much easier to get technical knowledge now. Anyone with a computer and Internet these days can download vulnerable virtual machines, read blog posts, understand and apply all kinds of knowledge, and specialise in one of the many areas of technical security. Do you like kernel exploitation? Loads of resources online. Want to become a web penetration testing ninja? Even more resources available.

Which brings us to the answer to the first question – there is no shortcut for a technical cyber security career. You have to spend lots of energy, and lots of free time to learn and do things over and over and over, until you become an expert. You’ll definitely have to sacrifice your free time – the best people I know are the ones who live and breathe cyber security. But the good news is that all of that is free – it just depends on your perseverance, capacity to learn and time available. Not only that, but if you truly love cyber security, you will love your work, no matter how many hours you put into it.

Ok so how do you start?

For this, Immersive Labs provide an invaluable service. Instead of making you look on the Internet for all the available resources, collating them, creating virtual machines, having exercises that do not work (and then you don’t know if it’s your fault or if the exercise is badly designed), etc, it takes all that effort away from you and gives you the perfect sandbox to hone your skills. Again, it all depends on you… Do you have what it takes to spend hours in front of the Immersive Labs and website and finish the challenges? Will you ever truly become a world renowned cyber security ninja or fade into oblivion as a boring security architect?

Go forth and exploit the world!


Technical blog: What is ASLR?

ASLR, Address Space Layout Randomization, is a technique used by modern operating systems to hide where a library or program code is loaded into memory.
This technique provides extra protection from exploits in general, and in particular the ones that leverage code re-use (search for Return Oriented Programming, ROP, for details), as an attacker will not be sure where the code will be loaded.

Let’s consider the following scenario. We have a program that we want to exploit, and for that we need to know where libc is loaded. Imagine that we run the program and analyse its mappings. We know that libc is being loaded at the following at the following 64 bit Linux memory address:


Each byte is two characters of that memory address, meaning at a single character is 4 bits.

The top 3 bytes (24 bits) are fixed – 00007F. This is known by simply analysing the binary.
The bottom 12 lower bits are also fixed, in this case 000.

This leaves us 28 bits, 7 characters, remanining:
00007F XXXXXXX 000

Ok, but as said above, when you run the binary you already know those 28 bits – in this case they are 36C6fEB.

But the catch is… if we run the binary again, those 28 bits will change. It can change to anything, from example from 36C6fEB to 482FF94. Run it again, and the value can be 9F32648

By now you should start to understand how difficult it is to guess that value. In fact, there are roughly 268435456 possibilities (2^28), which is an almost impossible space to bruteforce.

How can it be defeated?

On 64 bit Linux, like in the example above, it’s tough. The easiest way is to get an information leak. This can be for example the value of a pointer that you are able to obtain somehow (through another vulnerability or coding error). By performing some runtime calculations using that pointer value, you can then calculate the load address.
That’s practically the only way, bar bruteforcing and an ASLR implementation vulnerability.

But how about 32 bit Linux?

32 bit Linux systems are still in widespread use, and shall remain for decades. Most typically used in IoT, these systems are everywhere. And the good news is that 32 bit Linux is much easier to defeat.

Recall our earlier example. Given that memory addresses are now 32 bit, our memory address has shrunk to:

Out of these, the first 8 bits and the last 12 bits are fixed, leaving us a search space of only 12 bits:
7F XXX 000

2^12 = 4096 possibilities, which is much easier to bruteforce. Now all you need is to run the same exploit 4096 times (typically half that) and you will hit the right address and exploit your target!

ASLR is also affected by compile time flags such as PIE. Note that this ASLR description is correct at the time of writing, but the Linux kernel evolves very fast. These limitations will soon disappear. But don’t despair, there are still millions of devices using old kernels, ripe for the picking!


Access the Cyber Lab

Want access to Pedro’s cyber lab exercise? Get in touch with us today for pricing.