Hack the virtual memory: the stack, registers and assembly code

hack the virtual memory, the stack, registers and assembly code

This is the fifth chapter in a series about virtual memory. The goal is to learn some CS basics in a different and more practical way.

If you missed the previous chapters, you should probably start there:

The Stack

As we have seen in chapter 2, the stack resides at the high end of memory and grows downward. But how does it work exactly? How does it translate into assembly code? What are the registers used? In this chapter we will have a closer look at how the stack works, and how the program automatically allocates and de-allocates local variables.

Once we understand this, we will be able to play a bit with it, and hijack the flow of our program. Ready? Let’s start!

Note: We will talk only about the user stack, as opposed to the kernel stack

Prerequisites

In order to fully understand this article, you will need to know:

  • The basics of the C programming language (especially pointers)

Environment

All scripts and programs have been tested on the following system:

  • Ubuntu
    • Linux ubuntu 4.4.0-31-generic #50~14.04.1-Ubuntu SMP Wed Jul 13 01:07:32 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
  • Tools used:
    • gcc
    • gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4
    • objdump
    • GNU objdump (GNU Binutils for Ubuntu) 2.2

Everything we cover will be true for this system/environment, but may be different on another system

Automatic allocation

Let’s first look at a very simple program that has one function that uses one variable (0-main.c):

#include <stdio.h>

int main(void)
{
    int a;

    a = 972;
    printf("a = %d\n", a);
    return (0);
}

Let’s compile this program and disassemble it using objdump:

holberton$ gcc 0-main.c
holberton$ objdump -d -j .text -M intel

The assembly code produced for our main function is the following:

000000000040052d <main>:
  40052d:       55                      push   rbp
  40052e:       48 89 e5                mov    rbp,rsp
  400531:       48 83 ec 10             sub    rsp,0x10
  400535:       c7 45 fc cc 03 00 00    mov    DWORD PTR [rbp-0x4],0x3cc
  40053c:       8b 45 fc                mov    eax,DWORD PTR [rbp-0x4]
  40053f:       89 c6                   mov    esi,eax
  400541:       bf e4 05 40 00          mov    edi,0x4005e4
  400546:       b8 00 00 00 00          mov    eax,0x0
  40054b:       e8 c0 fe ff ff          call   400410 <printf@plt>
  400550:       b8 00 00 00 00          mov    eax,0x0
  400555:       c9                      leave  
  400556:       c3                      ret    
  400557:       66 0f 1f 84 00 00 00    nop    WORD PTR [rax+rax*1+0x0]
  40055e:       00 00 

Let’s focus on the first three lines for now:

000000000040052d <main>:
  40052d:       55                      push   rbp
  40052e:       48 89 e5                mov    rbp,rsp
  400531:       48 83 ec 10             sub    rsp,0x10

The first lines of the function main refers to rbp and rsp; these are special purpose registers. rbp is the base pointer, which points to the base of the current stack frame, and rsp is the stack pointer, which points to the top of the current stack frame.

Let’s decompose step by step what is happening here. This is the state of the stack when we enter the function main before the first instruction is run:

the stack

  • push rbp instruction pushes the value of the register rbp onto the stack. Because it “pushes” onto the stack, now the value of rsp is the memory address of the new top of the stack. The stack and the registers now look like this:

the stack

  • mov rbp, rsp copies the value of the stack pointer rsp to the base pointer rbp -> rpb and rsp now both point to the top of the stack

the stack

  • sub rsp, 0x10 creates a space to store values of local variables. The space between rbp and rsp is this space. Note that this space is large enough to store our variable of type integer

the stack

We have just created a space in memory – on the stack – for our local variables. This space is called a stack frame. Every function that has local variables will use a stack frame to store those variables.

Using local variables

The fourth line of assembly code of our main function is the following:

  400535:       c7 45 fc cc 03 00 00    mov    DWORD PTR [rbp-0x4],0x3cc

0x3cc is actually the value 972 in hexadecimal. This line corresponds to our C-code line:

a = 972;

mov DWORD PTR [rbp-0x4],0x3cc is setting the memory at address rbp - 4 to 972. [rbp - 4] IS our local variable a. The computer doesn’t actually know the name of the variable we use in our code, it simply refers to memory addresses on the stack.

This is the state of the stack and the registers after this operation:

the stack

leave, Automatic de-allocation

If we look now at the end of the function, we will find this:

  400555:       c9                      leave  

The instruction leave sets rsp to rbp, and then pops the top of the stack into rbp.

the stack

the stack

Because we pushed the previous value of rbp onto the stack when we entered the function, rbp is now set to the previous value of rbp. This is how:

  • The local variables are “de-allocated”, and
  • the stack frame of the previous function is restored before we leave the current function.

The state of the stack and the registers rbp and rsp are restored to the same state as when we entered our main function.

Playing with the stack

When the variables are automatically de-allocated from the stack, they are not completely “destroyed”. Their values are still in memory, and this space will potentially be used by other functions.

This is why it is important to initialize your variables when you write your code, because otherwise, they will take whatever value there is on the stack at the moment when the program is running.

Let’s consider the following C code (1-main.c):

#include <stdio.h>

void func1(void)
{
     int a;
     int b;
     int c;

     a = 98;
     b = 972;
     c = a + b;
     printf("a = %d, b = %d, c = %d\n", a, b, c);
}

void func2(void)
{
     int a;
     int b;
     int c;

     printf("a = %d, b = %d, c = %d\n", a, b, c);
}

int main(void)
{
    func1();
    func2();
    return (0);
}

As you can see, func2 does not set the values of its local vaiables a, b and c, yet if we compile and run this program it will print…

holberton$ gcc 1-main.c && ./a.out 
a = 98, b = 972, c = 1070
a = 98, b = 972, c = 1070
holberton$ 

… the same variable values of func1! This is because of how the stack works. The two functions declared the same amount of variables, with the same type, in the same order. Their stack frames are exactly the same. When func1 ends, the memory where the values of its local variables reside are not cleared – only rsp is incremented.
As a consequence, when we call func2 its stack frame sits at exactly the same place of the previous func1 stack frame, and the local variables of func2 have the same values of the local variables of func1 when we left func1.

Let’s examine the assembly code to prove it:

holberton$ objdump -d -j .text -M intel
000000000040052d <func1>:
  40052d:       55                      push   rbp
  40052e:       48 89 e5                mov    rbp,rsp
  400531:       48 83 ec 10             sub    rsp,0x10
  400535:       c7 45 f4 62 00 00 00    mov    DWORD PTR [rbp-0xc],0x62
  40053c:       c7 45 f8 cc 03 00 00    mov    DWORD PTR [rbp-0x8],0x3cc
  400543:       8b 45 f8                mov    eax,DWORD PTR [rbp-0x8]
  400546:       8b 55 f4                mov    edx,DWORD PTR [rbp-0xc]
  400549:       01 d0                   add    eax,edx
  40054b:       89 45 fc                mov    DWORD PTR [rbp-0x4],eax
  40054e:       8b 4d fc                mov    ecx,DWORD PTR [rbp-0x4]
  400551:       8b 55 f8                mov    edx,DWORD PTR [rbp-0x8]
  400554:       8b 45 f4                mov    eax,DWORD PTR [rbp-0xc]
  400557:       89 c6                   mov    esi,eax
  400559:       bf 34 06 40 00          mov    edi,0x400634
  40055e:       b8 00 00 00 00          mov    eax,0x0
  400563:       e8 a8 fe ff ff          call   400410 <printf@plt>
  400568:       c9                      leave  
  400569:       c3                      ret    

000000000040056a <func2>:
  40056a:       55                      push   rbp
  40056b:       48 89 e5                mov    rbp,rsp
  40056e:       48 83 ec 10             sub    rsp,0x10
  400572:       8b 4d fc                mov    ecx,DWORD PTR [rbp-0x4]
  400575:       8b 55 f8                mov    edx,DWORD PTR [rbp-0x8]
  400578:       8b 45 f4                mov    eax,DWORD PTR [rbp-0xc]
  40057b:       89 c6                   mov    esi,eax
  40057d:       bf 34 06 40 00          mov    edi,0x400634
  400582:       b8 00 00 00 00          mov    eax,0x0
  400587:       e8 84 fe ff ff          call   400410 <printf@plt>
  40058c:       c9                      leave  
  40058d:       c3                      ret  

000000000040058e <main>:
  40058e:       55                      push   rbp
  40058f:       48 89 e5                mov    rbp,rsp
  400592:       e8 96 ff ff ff          call   40052d <func1>
  400597:       e8 ce ff ff ff          call   40056a <func2>
  40059c:       b8 00 00 00 00          mov    eax,0x0
  4005a1:       5d                      pop    rbp
  4005a2:       c3                      ret    
  4005a3:       66 2e 0f 1f 84 00 00    nop    WORD PTR cs:[rax+rax*1+0x0]
  4005aa:       00 00 00 
  4005ad:       0f 1f 00                nop    DWORD PTR [rax]

As you can see, the way the stack frame is formed is always consistent. In our two functions, the size of the stack frame is the same since the local variables are the same.

push   rbp
mov    rbp,rsp
sub    rsp,0x10

And both functions end with the leave statement.

The variables a, b and c are referenced the same way in the two functions:

  • a lies at memory address rbp - 0xc
  • b lies at memory address rbp - 0x8
  • c lies at memory address rbp - 0x4

Note that the order of those variables on the stack is not the same as the order of those variables in our code. The compiler orders them as it wants, so you should never assume the order of your local variables in the stack.

So, this is the state of the stack and the registers rbp and rsp before we leave func1:

the stack

When we leave the function func1, we hit the instruction leave; as previously explained, this is the state of the stack, rbp and rsp right before returning to the function main:

the stack

So when we enter func2, the local variables are set to whatever sits in memory on the stack, and that is why their values are the same as the local variables of the function func1.

the stack

ret

You might have noticed that all our example functions end with the instruction ret. ret pops the return address from stack and jumps there. When functions are called the program uses the instruction call to push the return address before it jumps to the first instruction of the function called.
This is how the program is able to call a function and then return from said function the calling function to execute its next instruction.

So this means that there are more than just variables on the stack, there are also memory addresses of instructions. Let’s revisit our 1-main.c code.

When the main function calls func1,

  400592:       e8 96 ff ff ff          call   40052d <func1>

it pushes the memory address of the next instruction onto the stack, and then jumps to func1.
As a consequence, before executing any instructions in func1, the top of the stack contains this address, so rsp points to this value.

the stack

After the stack frame of func1 is formed, the stack looks like this:

the stack

Wrapping everything up

Given what we just learned, we can directly use rbp to directly access all our local variables (without using the C variables!), as well as the saved rbp value on the stack and the return address values of our functions.

To do so in C, we can use:

    register long rsp asm ("rsp");
    register long rbp asm ("rbp");

Here is the listing of the program 2-main.c:

#include <stdio.h>

void func1(void)
{
    int a;
    int b;
    int c;
    register long rsp asm ("rsp");
    register long rbp asm ("rbp");

    a = 98;
    b = 972;
    c = a + b;
    printf("a = %d, b = %d, c = %d\n", a, b, c);
    printf("func1, rpb = %lx\n", rbp);
    printf("func1, rsp = %lx\n", rsp);
    printf("func1, a = %d\n", *(int *)(((char *)rbp) - 0xc) );
    printf("func1, b = %d\n", *(int *)(((char *)rbp) - 0x8) );
    printf("func1, c = %d\n", *(int *)(((char *)rbp) - 0x4) );
    printf("func1, previous rbp value = %lx\n", *(unsigned long int *)rbp );
    printf("func1, return address value = %lx\n", *(unsigned long int *)((char *)rbp + 8) );
}

void func2(void)
{
    int a;
    int b;
    int c;
    register long rsp asm ("rsp");
    register long rbp asm ("rbp");

    printf("func2, a = %d, b = %d, c = %d\n", a, b, c);
    printf("func2, rpb = %lx\n", rbp);
    printf("func2, rsp = %lx\n", rsp);
}

int main(void)
{
    register long rsp asm ("rsp");
    register long rbp asm ("rbp");

    printf("main, rpb = %lx\n", rbp);
    printf("main, rsp = %lx\n", rsp);
    func1();
    func2();
    return (0);
}

Getting the values of the variables

the stack

From our previous discoveries, we know that our variables are referenced via rbp – 0xX:

  • a is at rbp - 0xc
  • b is at rbp - 0x8
  • c is at rbp - 0x4

So in order to get the values of those variables, we need to dereference rbp. For the variable a:

  • cast our variable rbp to a char *: (char *)rbp
  • subtract the correct amount of bytes to get the address of where the variable is in memory: (char *)rbp) - 0xc
  • cast it again to a pointer pointing to an int since a is of type int: (int *)(((char *)rbp) - 0xc)
  • and dereference it to get the value sitting at this address: *(int *)(((char *)rbp) - 0xc)

The saved rbp value

the stack

Looking at the above diagram, the current rbp directly points to the saved rbp, so we simply have to cast our variable rbp to a pointer to an unsigned long int and dereference it: *(unsigned long int *)rbp.

The return address value

the stack

The return address value is right before the saved previous rbp on the stack. rbp is 8 bytes long, so we simply need to add 8 to the current value of rbp to get the address where this return value is on the stack. This is how we do it:

  • cast our variable rbp to a char *: (char *)rbp
  • add 8 to this value: ((char *)rbp + 8)
  • cast it to point to an unsigned long int: (unsigned long int *)((char *)rbp + 8)
  • dereference it to get the value at this address: *(unsigned long int *)((char *)rbp + 8)

The output of our program

holberton$ gcc 2-main.c && ./a.out 
main, rpb = 7ffc78e71b70
main, rsp = 7ffc78e71b70
a = 98, b = 972, c = 1070
func1, rpb = 7ffc78e71b60
func1, rsp = 7ffc78e71b50
func1, a = 98
func1, b = 972
func1, c = 1070
func1, previous rbp value = 7ffc78e71b70
func1, return address value = 400697
func2, a = 98, b = 972, c = 1070
func2, rpb = 7ffc78e71b60
func2, rsp = 7ffc78e71b50
holberton$

We can see that:

  • from func1 we can access all our variables correctly via rbp
  • from func1 we can get the rbp of the function main
  • we confirm that func1 and func2 do have the same rbp and rsp values
  • the difference between rsp and rbp is 0x10, as seen in the assembly code (sub rsp,0x10)
  • in the main function, rsp == rbp because there are no local variables

The return address from func1 is 0x400697. Let’s double check this assumption by disassembling the program. If we are correct, this should be the address of the instruction right after the call of func1 in the main function.

holberton$ objdump -d -j .text -M intel | less
0000000000400664 <main>:
  400664:       55                      push   rbp
  400665:       48 89 e5                mov    rbp,rsp
  400668:       48 89 e8                mov    rax,rbp
  40066b:       48 89 c6                mov    rsi,rax
  40066e:       bf 3b 08 40 00          mov    edi,0x40083b
  400673:       b8 00 00 00 00          mov    eax,0x0
  400678:       e8 93 fd ff ff          call   400410 <printf@plt>
  40067d:       48 89 e0                mov    rax,rsp
  400680:       48 89 c6                mov    rsi,rax
  400683:       bf 4c 08 40 00          mov    edi,0x40084c
  400688:       b8 00 00 00 00          mov    eax,0x0
  40068d:       e8 7e fd ff ff          call   400410 <printf@plt>
  400692:       e8 96 fe ff ff          call   40052d <func1>
  400697:       e8 7a ff ff ff          call   400616 <func2>
  40069c:       b8 00 00 00 00          mov    eax,0x0
  4006a1:       5d                      pop    rbp
  4006a2:       c3                      ret    
  4006a3:       66 2e 0f 1f 84 00 00    nop    WORD PTR cs:[rax+rax*1+0x0]
  4006aa:       00 00 00 
  4006ad:       0f 1f 00                nop    DWORD PTR [rax]

And yes! \o/

Hack the stack!

Now that we know where to find the return address on the stack, what if we were to modify this value? Could we alter the flow of a program and make func1 return to somewhere else? Let’s add a new function, called bye to our program (3-main.c):

#include <stdio.h>
#include <stdlib.h>

void bye(void)
{
    printf("[x] I am in the function bye!\n");
    exit(98);
}

void func1(void)
{
    int a;
    int b;
    int c;
    register long rsp asm ("rsp");
    register long rbp asm ("rbp");

    a = 98;
    b = 972;
    c = a + b;
    printf("a = %d, b = %d, c = %d\n", a, b, c);
    printf("func1, rpb = %lx\n", rbp);
    printf("func1, rsp = %lx\n", rsp);
    printf("func1, a = %d\n", *(int *)(((char *)rbp) - 0xc) );
    printf("func1, b = %d\n", *(int *)(((char *)rbp) - 0x8) );
    printf("func1, c = %d\n", *(int *)(((char *)rbp) - 0x4) );
    printf("func1, previous rbp value = %lx\n", *(unsigned long int *)rbp );
    printf("func1, return address value = %lx\n", *(unsigned long int *)((char *)rbp + 8) );
}

void func2(void)
{
    int a;
    int b;
    int c;
    register long rsp asm ("rsp");
    register long rbp asm ("rbp");

    printf("func2, a = %d, b = %d, c = %d\n", a, b, c);
    printf("func2, rpb = %lx\n", rbp);
    printf("func2, rsp = %lx\n", rsp);
}

int main(void)
{
    register long rsp asm ("rsp");
    register long rbp asm ("rbp");

    printf("main, rpb = %lx\n", rbp);
    printf("main, rsp = %lx\n", rsp);
    func1();
    func2();
    return (0);
}

Let’s see at which address the code of this function starts:

holberton$ gcc 3-main.c && objdump -d -j .text -M intel | less
00000000004005bd <bye>:
  4005bd:       55                      push   rbp
  4005be:       48 89 e5                mov    rbp,rsp
  4005c1:       bf d8 07 40 00          mov    edi,0x4007d8
  4005c6:       e8 b5 fe ff ff          call   400480 <puts@plt>
  4005cb:       bf 62 00 00 00          mov    edi,0x62
  4005d0:       e8 eb fe ff ff          call   4004c0 <exit@plt>

Now let’s replace the return address on the stack from the func1 function with the address of the beginning of the function bye, 4005bd (4-main.c):

#include <stdio.h>
#include <stdlib.h>

void bye(void)
{
    printf("[x] I am in the function bye!\n");
    exit(98);
}

void func1(void)
{
    int a;
    int b;
    int c;
    register long rsp asm ("rsp");
    register long rbp asm ("rbp");

    a = 98;
    b = 972;
    c = a + b;
    printf("a = %d, b = %d, c = %d\n", a, b, c);
    printf("func1, rpb = %lx\n", rbp);
    printf("func1, rsp = %lx\n", rsp);
    printf("func1, a = %d\n", *(int *)(((char *)rbp) - 0xc) );
    printf("func1, b = %d\n", *(int *)(((char *)rbp) - 0x8) );
    printf("func1, c = %d\n", *(int *)(((char *)rbp) - 0x4) );
    printf("func1, previous rbp value = %lx\n", *(unsigned long int *)rbp );
    printf("func1, return address value = %lx\n", *(unsigned long int *)((char *)rbp + 8) );
    /* hack the stack! */
    *(unsigned long int *)((char *)rbp + 8) = 0x4005bd;
}

void func2(void)
{
    int a;
    int b;
    int c;
    register long rsp asm ("rsp");
    register long rbp asm ("rbp");

    printf("func2, a = %d, b = %d, c = %d\n", a, b, c);
    printf("func2, rpb = %lx\n", rbp);
    printf("func2, rsp = %lx\n", rsp);
}

int main(void)
{
    register long rsp asm ("rsp");
    register long rbp asm ("rbp");

    printf("main, rpb = %lx\n", rbp);
    printf("main, rsp = %lx\n", rsp);
    func1();
    func2();
    return (0);
}
holberton$ gcc 4-main.c && ./a.out
main, rpb = 7fff62ef1b60
main, rsp = 7fff62ef1b60
a = 98, b = 972, c = 1070
func1, rpb = 7fff62ef1b50
func1, rsp = 7fff62ef1b40
func1, a = 98
func1, b = 972
func1, c = 1070
func1, previous rbp value = 7fff62ef1b60
func1, return address value = 40074d
[x] I am in the function bye!
holberton$ echo $?
98
holberton$ 

We have called the function bye, without calling it! 🙂

Outro

I hope that you enjoyed this and learned a couple of things about the stack. As usual, this will be continued! Let me know if you have anything you would like me to cover in the next chapter.

Questions? Feedback?

If you have questions or feedback don’t hesitate to ping us on Twitter at @holbertonschool or @julienbarbier42.
Haters, please send your comments to /dev/null.

Happy Hacking!

Thank you for reading!

As always, no one is perfect (except Chuck of course), so don’t hesitate to contribute or send me your comments if you find anything I missed.

Files

This repo contains the source code (X-main.c files) for programs created in this tutorial.

Read more about the virtual memory

Follow @holbertonschool or @julienbarbier42 on Twitter to get the next chapters! This was the fifth chapter in our series on the virtual memory. If you missed the previous ones, here are the links to them:

Many thanks to Naomi for proof-reading! 🙂

Holberton School & the Three Engineers, Part 3: The Experienced

This is an ongoing series of interviews with Holberton students sharing their journey through the program. Holberton students come from many different backgrounds. These interviews are an inside look at each student’s unique journey into software engineering.

 

Mason: The Experienced, Have Your Cake and Eat It Too
Mason joined Holberton School with considerably more experience in software engineering compared with
Dora and Rona.

 

Q: How did you hear about Holberton School?

Mason: My mother’s friend from work had heard about Holberton and she knew that I was interested in some type of computer science education.

 

Q: What was your experience with computer science?

Mason: I had already been teaching myself computer science for about a full year starting with just html, css, javascript, a little bit of php, and eventually I began studying python. It was just a hobby I had gotten into on the side. I actually had a job teaching guitar.

 

Q: Did you study music in school?

Mason: I did! My bachelor’s and master’s degrees are both from music conservatories. After graduating, I had worked for 5 years as a professional musician. My primary income came from teaching, which I didn’t enjoy nearly as much as the performing I also did, and I figured if I could replace my teaching day job with work as a software engineer then that would be ideal, especially since my interest in that field had already grown so much. Conveniently, San Francisco is a great city to be employed in that kind of work and also offers several educational opportunities for that type of position. I also thought that this career would allow me to maintain the performance side of my music career, which is still very dear to me.

 

Q: Why were you drawn to computer science?
Mason: I was drawn to computer science because the kinds of problems that you solve as a software engineer are actually really, really similar to the problems you solve as a music performer. People tend to think of music as a very right-brain, creative sort of activity and they think of software engineering as a left-brain analytical activity but the truth is that both… are both! I started out teaching myself online. That’s where I first learned about HTML, CSS… just what I needed to know to build a very simple static website.

 

Q: What was the reaction from your friends and family when you made this unexpected career pivot?

Mason: My father is a musician and my mother and my brother are both engineers. My mom is a software engineer and my brother is an electrical engineer. My other brother is a mathematician…so there’s a lot of music, math, and engineering in my family and none of them were terribly surprised, although I think my parents were a little concerned that I was letting go of music. My friends, especially the other members of my ensemble, were especially concerned about disbanding. I just had to explain to them that I was looking to replace the teaching portion of my music, not the performance aspect.

 

Q: Do you think that you’ve been able to maintain a balance between your music and your new career?

Mason: Perhaps these careers are easily balanced by everyone, or I may just be especially lucky that I have been able to keep a balance between the two. My manager I has brought up that it’s really important to her that I’m able to keep a balance between my music and my software careers, and I am very grateful for that.

 

Q: Do you think Holberton was able to dive deeper into languages you had previous experience with?

Mason: There was definitely a lot of validation. When you’re learning stuff all on your own, you don’t know how accurate the information is. Until you’re learning from and talking to industry professionals. Being able to communicate well with other students and mentors was validating in itself. I think that’s one of the strongest aspects of Holberton, and the mentor side of the program really strengthens that. It’s a curriculum that’s very adaptable. There are so many opportunities to go beyond the minimum requirements of an assignment. I tried to do every assignment and optional assignments. I liked that flexibility, and it absolutely enabled me to deepen my previously superficial comp-sci knowledge.

 

Q: Tell me a little about your experience with Holberton School mentor program.

Mason: The biggest benefit I got from the mentor program during my first year was the coordinated events: the fireside chats, and the workshops. Hearing professionals talk about technical knowledge helped me think about technology in a different way. To develop fluency in any field you really need to be immersed around other experts, adopt their language, and to an extent adopt the way they think about the subject. The mentor program facilitates that very well.

 

 

Q: What is your role at Docker?

Mason: I am a full-stack software engineer on the Distribution Services team at Docker, Inc. I help build and maintain the SaaS-related back-end services that enable users to use the Docker platform. I also work on the front-end of the Docker Store.

Holberton School & the Three Engineers, Part 2: The Intermediate

This is an ongoing series of interviews with Holberton students sharing their journey through the program. Holberton students come from many different backgrounds. These interviews are an inside look at each student’s unique journey into software engineering.

 

Rona: The Intermediate, This Could Be a Great Opportunity
Rona comes to Holberton School with a bit more insight into the tech industry than perhaps someone like Dora. Coding had been a hobby of Rona’s younger self, having played around with html and CSS.

Q: How did you find out about Holberton?

Rona: I actually heard of Holberton through word of mouth, from my sister. She knew they were just starting up and she had seen their TechCrunch article. She came back to me and suggested that I apply. There were a few reasons for that, but mainly because I was unemployed and I was still figuring out what my next steps were. When my sister and, in turn, myself, heard  that it was free, it was two years long, and that they had this big, almost radical vision about what they wanted to do and how they wanted to rethink education, specifically educating people for tech careers  it just seemed cool. It seemed hard to turn down.

 

Q: Tell me a bit about the application process.

Rona: It wasn’t that painful. It was a series of challenges to find information. There were two types: going out and finding the information to solve a problem and then sharing information about yourself. I think the biggest part was [building] the website. I remember thinking this is a promising area to go into, because I got really into the project. I took a course for intro to programming when I was in college and it went alright… I managed to learn whatever they were trying to teach me but I wasn’t sure if that meant I was good at coding or I just took a college class.

 

Q: What are the main differences between the previous course you took and Holberton?

Rona: The main difference is that the instructor would walk us through the whole approach from the beginning and you kind of watch and see ‘ohhh, that’s how you do it’ and barely keep up with their problem solving approach… then later when you get to the problem step, you apply that yourself… which is very different from the Holberton style. It worked but I’d have to say that watching someone solve it for you made me insecure around whether I’d be able to come up with the pieces to solve the problem on my own.

 

Q: How does Holberton have you approach a problem

Rona: At Holberton it’s a lot more of an intimate process where it’s you, and the problem, and your peers … I’ve really enjoyed having a lot of freedom in approaching every problem myself. Basically they say ‘this is what we want to see at the end’ and you have to work on the problem from there.

 

Q: When you were applying what was the mood amongst your family and friends?

Rona: We mostly discussed with my mom. We weren’t sure how she would take it since there were no previous students [Batch 0]. She wondered if I was going to be able to get a job. We had to convince her it was the right decision.

 

Q: How did you convince her?

Rona: We just talked about the people who were founding the school, and our brother was in the tech industry so I think we were also relying a bit on knowing that people went into tech that were just self taught and managed to have very good careers. She started off at ‘oh, I don’t know if this is right’ but now she’s happy we did it.

Q: What were you doing at Dropbox?

Rona: I was there under their apprenticeship for SRE so I was embedded in their databases team. I had one real big project in the beginning. It was cool because I got to walk through all of the steps- thinking through how to code, to deployment, then monitoring, and patching when necessary.

 

Q: Walking into Dropbox did you feel confident with your skillset?

Rona: I felt pretty confident. I would almost say I had some hubris because at Holberton we break things down all the time, making me feel like I’m going to do great but, walking into Dropbox I realized the depth of technical knowledge that can be had and how people have an expertise after being in the field for 5-10 years it kind of reset my thinking to realizing there is so much room to grow which is both intimidating and cool. I do think Holberton put me in a good place to tackle the challenges that came, though.

Holberton School & the Three Engineers, Part 1: The Novice

This is an ongoing series of interviews with Holberton students sharing their journey through the program. Holberton students come from many different backgrounds. These interviews are an inside look at each student’s unique journey into software engineering.


Dora: The Novice, Could This Be For Real?
A graduate from a typical four year university with a degree in biology, Dora came to the realization that she no longer wanted to pursue a career in her field. Dora chose to cut her losses, and dive into learning how to code. The bet she made on herself has paid off in a big way, landing a full time software engineering position with Scality.

 

Q: What were the different options you had after you graduated?

Dora: TJ’s was the first job that sprang up and I just kept it because it was convenient because I didn’t really know what I wanted to do. The idea of going to grad school crossed my mind, or even doing another undergrad but it’s just way too much money that I didn’t have. I was fortunate enough to come out of undergrad without any debt and I didn’t want to take any on. It took something like Holberton to help me narrow down my options.

 

Q: Tell me how you heard about Holberton School.

Dora: My friend was having a party and I started talking to this guy that I haven’t seen in years. I asked him what he’s doing now and he said ‘I work at Apple’. I thought he meant in retail… This guy was a philosophy and German double major how did [he] start coding? He told me he learned through online bootcamps. I didn’t even know you could do that! The next day I updated my phone, downloaded the news app and actually saw an article about Holberton School.

 

Q: Tell me about the application process.

Dora: I started getting positive feedback from Julien and Sylvain and I was like woah, this is amazing. I got to the third round; the interview process, and it just so happened I was going to be in San Francisco for Thanksgiving, so I did an onsite interview at the school before anything was set up which was really nice to be able to see the space and everything. They asked me all types of questions like ‘why do you want to be a software engineer’.

 

Q: Walk me through the realization of being accepted and actually moving here.

Dora: I think it took about two weeks of me actually being here for it to set in that this is actually now my life. It did not sink in at all while I was in Minnesota still preparing. My friends all thought I was doing something crazy, but my family was really supportive. Then, about a week before school was about to start I packed everything in my car and headed out here [San Francisco].

 

Q: When was your ah-ha moment, when did you know you had made the right decision with Holberton?

Dora: I remember feeling super accomplished after our hexadecimal table project … since it was more of a logical or algorithmic problem we had to figure out, just gradually building on all of that – I think the pace was good for me. I would struggle just enough but be able to break through and figure it out.

 

Q: Why do you think Holberton is successful in training quality software engineers?

Dora: I think the project based learning style is for me… and apparently other people. It’s so much more efficient than sitting through a lecture. The peer learning obviously is huge. Being able to explain something to somebody is one of the best markers that you actually know it and being able to do that on a regular basis is great practice. The mentors are invaluable and it’s great to get to interact with people who are actually in the industry. Holberton is very reflective of the industry itself; all of that is how you’re going to really be working.

 

Q: Tell me about what you’re doing in your role at Scality?

Dora: We do large scale data storage and I work on the software engineering team. I work on integrating different clouds to communicate with the API. I’m working to match Zenko (Scality’s open source project) to the backend of the cloud.

Upwork CEO Marks Newest Addition to Holberton School’s Board of Trustees

We are excited to be welcoming Stephane Kasriel, Upwork CEO, to the Holberton family as he joins the Board of Trustees. Upwork is the world’s largest freelancing website. Stephane is also the co-chair of the World Economic Forum’s council on the future of education, gender and work.

Stephane’s work with the World Economic Forum gives him perspective when evaluating the state of education today. He recognizes that education is both one of the biggest challenges and one of the biggest opportunities of our time. “It can be a huge source of inequality, or done well, a great equalizer- the true American dream.” The old adage of coming up with a solution and not just a problem applies here. Kasriel believes Holberton could be the solution.

“Holberton has a real shot at building a true alternative to the traditional college degree. One that prepares students for the jobs of today and the jobs of tomorrow.”

Stephane likens Holberton’s project based learning structure to what real life is like. Detailing his own experiences in a traditional education. He notes that while many of the theoretical lessons he learned were interesting, little of it ended up being useful in his day-to-day developer life. “Traditional programs teach Computer Science whereas Holberton teaches Software Engineering. And guess what, the world needs a lot more of the latter than it needs of the former!”

Holberton’s affordability, and above all, quality are two of the factors that attracted Stephane to get involved. “Holberton trains students for what the industry really needs and teaches them not just the science but the art of development, something that most people otherwise learn on the job or through their own open source community involvement.” This practical approach gives students an understanding at what a day-in-the-life of an actual developer is like.

Stephane’s vision for Holberton is to build a truly scalable education system. “In the U.S. alone, we need to train millions of software developers. And if you start looking at regions like Africa, where where there will be a billion more adults by 2040, and where they’re missing at least 25 million teachers, you realize that there is a huge opportunity for Holberton to have a giant impact on society.” We’re glad to have Stephane on the team and look forward to continuing the work of bringing quality tech education to the most.

Docker Founder Joins Holberton School Board of Trustees

We can hardly contain our excitement as we announce the addition of Solomon Hykes, Docker founder and CTO, to the Holberton Board of Trustees. Docker is the world’s leading software container platform.

Solomon made his entry into software engineering through a program that parallels Holberton School’s model. “The first thing that attracted me to Holberton was the idea of it and the people that started it… we experienced this particular style of education together and I think it had a huge impact on how we approach things in our lives.”

Lately, there’s been buzz throughout the tech world in regards to the skills, not degrees approach to recruiting talent. Holberton’s project based learning model stands as a positive example of this recruiting trend.Solomon feels that  “It forces a mindset of being flexible and open minded and acknowledging that theoretical knowledge is temporary, whatever bleeding edge info you get today by the time you’re done with your studies it’s going to be obsolete. So when technology and ideas become obsolete within just a few years, how do you adapt as an individual? How do you stay relevant, and competitive, and valuable? Well I think you focus on the parts that remain the same. How to collaborate, how to learn new things, how to get things done. I think the Holberton model is ideal for that.”

The chance to become involved with Holberton touches close to home for the Docker founder. “If it had not been for a project based, practical education my life would have been so radically different in every way, I can’t even imagine it. I wouldn’t have started my own company… Docker wouldn’t exist.” To provide a bit of perspective, Docker is currently valued at $1.3 billion. Solomon attributes much of his success to the model he was trained under; the same project based method that Holberton prides itself on.

The similarities between Docker and Holberton don’t begin and end with their respective founders going through this type of tech education model.

“We both have this aspect of taking something that’s very closed and breaking down barriers to create opportunity for more people. At Holberton it’s through education, and at Docker we do it with tools.”

Solomon sees the students’ success at Holberton as a collective success across the staff and its students. “I think the team’s experience and the fact that they know what they’re doing and that they’re focused on the right things… not on the superficial signs of success but the true, concrete fundamentals of success. There’s a real willingness to break down barriers and make Holberton truly open to anybody.” With three Holberton students employed at Docker, it is clear the school’s formula is working.

We look forward to working alongside Solomon to continue winning hearts and minds with our project and peer learning based tech education model.

CloudNOW CEO & Founder to Join Holberton Board of Trustees

We are on cloud nine as we welcome Jocelyn DeGance Graham to Holberton School’s Board of Trustees. Jocelyn joins us from CloudNOW; a 501c3 non profit organization she co-founded. CloudNOW is dedicated to women helping other women achieve professional success, and identifying the next generation of female technical leaders through their STEM scholarship fund.

Graham certainly isn’t new to getting involved throughout the tech community. With a résumé boasting credits like being named by the Business Journal as one of the Top 100 Most Influential Women in Silicon Valley and by CRN as one of the 100 Most Influential Women in IT, she brings a lot to the table.

Jocelyn DeGance Graham being interviewed on The Cube

Jocelyn was attracted to Holberton School due to its approach to providing an elite education in the most inclusive way. “The diversity Holberton has been able to achieve is apparent in the composition of the student body. Holberton is just two years old and has already achieved gender and minority parity through a ground-breaking approach to admissions– a blind application process. This is a powerful way to establish equality but it’s not been done by any other academic institutions. I think Holberton is going to set a new standard for non-biased admissions, hiring, and talent recruit.”

CloudNOW embodies the desire to promote diverse groups through technical careers. At Holberton, Jocelyn says

“This is not about lowering the bar. Everyone at Holberton is there by their own merit, everyone has earned their way in. It’s about creating the same amount of opportunity for everyone- everyone gets to apply- and with the Holberton/CloudNOW scholarship program and key corporate partners, we are making sure that economics are no longer a barrier either to getting a top job in tech.”

Jocelyn also recognizes the project based curriculum at Holberton as a benefit to students. “Everything is moving to project based skills, education in general is moving from theory to actual skills and I think that’s because there’s been such a gap of people graduating from universities, crippled with debt and not being able to get jobs.”

Jocelyn notes the overall sense of community fostered by Co-Founders Julien Barbier and Sylvain Kalache is the driving force behind the school’s success thus far. “Students are cared for on an individual level and students that require coaching and additional help are able to get it. Holberton is really focused on the success of the individual.”

A diverse board of trustees is essential in following through on Holberton’s mission. “To me, it speaks volumes that at every level of this school the equality and fairness is reiterated.” notes Graham. We are as excited as Jocelyn about her addition to the Holberton School Board of Trustees and look forward to furthering our progress on our mission to provide quality education to the most.

Mentor Spotlight: Neha Jain

Neha Jain, Senior Software Engineer at LinkedIn, definitively sets the example of how the tech community should mature. Neha’s résumé is impressive, and once you add on initiatives she’s contributing to outside of her 9-5 at LinkedIn, her work ethic becomes very apparent. Neha’s journey to tech was hard fought and well earned and it is her belief that if she doesn’t provide for aspiring software engineers the way her mentors did for her, then really… what’s the point?

Neha presents to Holberton School students and guests at a Meetup.

Neha very strongly believes in democratizing the knowledge and sharing the information across the industry and the world. “it’s important to me to pay forward what I received.” explains Neha. This notion coupled with her admiration for project-based learning made her a fit for Holberton School’s mentor program. Neha was attracted to Holberton’s curriculum in addition to its business model; no upfront tuition costs. Jain points out the benefit that “students are free to learn without the looming financial stress” and as she explains her draw to learning by doing, you could say that Holberton and Neha are a perfect match.

She shares how mentoring is gratifying in itself, but also mutually beneficial. When posed with the question – Have you grown professionally due to mentorship? – Neha emphatically explains how mentoring is a way for her to grow personally and professionally. Neha sets a scene where mentees are asking questions she never even thought to ask, or proposes a solution to a problem she had never considered. All of these things are of added benefit to Neha; tools and information to be stored in her toolbox of professional development. Framing her experience by stating “Mentoring has helped me to unlock the other side of my career” is perhaps the biggest example of this symbiotic mentor/mentee relationship. Through mentoring, Neha further developed her management and leadership skills bolstering her already glowing personal brand.

 

Neha participating in a Q&A with Holberton School students


By modeling the mentor behavior and cultivating a transparent view of her journey, Neha’s success is a roadmap for the next class of software engineers. Neha demonstrates that your education does not and should not end after your classes are complete. This type of example enriches the tech community on a broader scale, allowing future engineers to strive for the type of leadership Neha has displayed throughout her career.

LinkedIn CEO to Join Holberton as Investing Advisor

Exciting news is not in short supply at Holberton School. We are proud to welcome Jeff Weiner, Linkedin CEO, as an individual investor and advisor.

 

Image sourced from www.whartonmagazine.com

Jeff was attracted to Holberton’s dedication to producing quality engineers. “Holberton is producing remarkable, Ivy League-caliber graduates, without the costs, the time or the prerequisites. I should know, we hired two of them before they even graduated,” said the LinkedIn CEO. Holberton School’s mission is to provide quality tech education to the most and it would seem the quality portion is already being noticed in the industry.

The symbiotic relationship is not lost on Holberton School co-founder, Julien Barbier. “When you think of jobs and networking, you think LinkedIn, and with Jeff’s long-standing commitment to education, he will be a valuable asset to the school and of course, our students,” Holberton students learn that networking and relationships are just as important to master as the technical skills.

Jeff’s views on recruitment strongly align with the Holberton model. Recently, Weiner voiced his opinion on the “skills, not degrees” mantra floating around the tech industry:

“These are qualities that you don’t necessarily pick up from a degree. There are qualities…that have a tendency to be completely overlooked when people are sifting through résumés or LinkedIn profiles. And yet, increasingly, we find that these are the kinds of people that make the biggest difference within our organization.

Increasingly I hear this mantra: Skills, not degrees. It’s not skills at the exclusion of degrees. It’s just expanding our perspective to go beyond degrees.”

Jeff also shares Holberton School’s passion for the peer and project based learning format. “Talent is everywhere, but with our education system stuck in a centuries-old training format, many are not even given the chance to try. And a lot of graduates are having a hard time keeping up with the rate of change once they become professionals. Holberton’s education model is attracting students from all walks of life, and is providing them with the skills they need to take on a job after graduation, and more importantly to be able to continually retrain their entire life to take on new opportunities.”

We are excited at the addition of Jeff to our team of investors working towards our mission of bringing high quality education to the most!

Who Run The World? Ada!

Happy Ada Lovelace Day, everyone! Software engineers, computer programmers, UX designers… you name the tech position, and chances are you wouldn’t have it without Ada Lovelace’s design of the first computer implemented algorithm. This makes Ada the first ever computer programmer.

Ada Lovelace Day is meant to recognize and honor the various women across STEM. Lovelace was a visionary; and her legacy is being used to inspire the current tech landscape. Ada’s ideas serve as a reminder that innovation is always happening. It was the 1800s when Ada was contemplating the idea behind the computer, pontificating a machine that would one day be able to react to things like ideas and opinions, not just numbers and letters.

The organization Finding Ada holds an annual event on the second Tuesday in October. The event is centered around women in STEM and features talks, workshops, and even entertainment. The main event is produced in London, but many individual ALD celebrations happen all over the globe. To find out what events are happening around you, click here.