07 - Just Another OSCE Review

CTP and the OSCE

"The OSCE exam is really hard" 
                  - Everyone, probably

As anyone who has attempted an OffSec certification knows, they're hard as nails.  I've taken the OSCP and now the OSCE, so I can attest to their difficulty.  I'm also not the type of person who can just "pass" these tests.  I took the OSCP multiple times, consistently overthinking the solutions to tasks that, once solved, were much simpler than I initially thought.  I also took the OSCE exam twice, with a month's separation between exams, so I'm no savant.  

One of my coworkers inquired if I'd write a blog post about how I prepared, and how I went from OSCP to OSCE.  What I did, resources I used, etc.  As far as a prep guide goes, I think you'd be better off looking elsewhere.  This has a lot of info in it, but I'm not going to talk about what you should and shouldn't focus on to pass the test, that's not the point.  This post is more or less a straight up review of the course and my experiences with it.

If you'd like to do some more exam-prep / guided studying, I'd check out Tulpa Security's OSCE Prep Guide.  Read on and you'll hear about my experience with the course.

01 - The journey (sort of) begins

I acquired my OSCP in 2016.  Prior to taking it the only other certification I had done was the Security+.  Doing the OSCP was eye opening-- not just to the reality of the information security and pentesting worlds, but to the sheer difficulty involved in the material.  I breezed through most of life, not really applying myself, as I suspect many reading this have done.  I didn't fail things unless I wanted to and I guess I never really felt challenged, primarily because I never challenged myself.  Doing the OSCP was a... novel... experience.

I took the OSCP multiple times.  I'd applied myself 100%, but somehow was unable to make it to the summit of this mountain of an exam.  It was disheartening, as coworkers who had less than a third of the lab machines compromised had passed their first time.  What was I doing wrong?  I had 90% of all the lab machines compromised, why couldn't I pass?

Well for one thing, I was overthinking things.  Immensely.  This is probably the bane of my existence and in the infosec world, I don't believe it's a unique issue.

The reason I am talking about my OSCP experience, albeit briefly, is merely to reiterate my familiarity with the difficulty the Offensive Security exams present to students.  They aren't gimmes.  These exams are arduous and have the reputation to prove it.  I also wanted to bring attention to my 'failures' and how I didn't let them stop me.  I would've taken this exam until I passed, no matter how many times it took.  Failure's really what you make of it.

A year after my OSCP, I took the SEC542 course through SANS (work paid, thankssss) and obtained my GWAPT certification.  That test, although well made and certainly difficult, left something to be desired.  I had the itch again for something more.  Six months after obtaining my GWAPT I started researching the OSCE and found the first part of the puzzle that would start consuming me.

02 - Registration

My first real experience with assembly was in the OSCP, the buffer overflow module.  That's where I really found that I was super, super interested in doing more than firing off someone else's exploit, or escalating privileges on a machine via someone else's code.  I wanted to know how it worked.  To understand exactly what was happening behind the scenes, learn how to manipulate it or do it myself.  Of course, it wasn't for another year and a half after OSCP that I'd start to buckle down and face the music that this shit's hard as hell and the only way to learn it was, well, by doing it.

To register for the OSCE, one must first solve a challenge which lives at fc4.me  It's a neat concept, as it forces a prospective student to really take the time to come up with a solution, prior to even allowing them to register for the course.  For those of us who are puzzle solvers, which I'd assume you are if you're taking OffSec certs, this is fitting and OffSec really is doing us a favor here.  It's not too hard, but it takes a bit of time.

The whole idea is: "if you can't solve the challenge yet, you're not ready for the course".  That's fine, honest.  Do a little bit of studying and try to figure it out-- you'll get there, eventually.

Sadly, if you type fc4.me into the URL bar:

So yeah, don't be that person.  If you are the type of person that looks up the solutions because you are unable to solve the problem, this is absolutely not the course for you, as many others have stated.  You will not have a good time. I cannot stress this enough, though I've attempted with the big letters.

Once registered, sign up, pay your dues, and await the materials.

03 - The Course / Material

Not sure how long it took, but I was stoked when the materials came.  I immediately began reading and watching videos and tried to follow along as suggested.  Once you've finished going through a module, give it a shot without following along and see how far you can get.

It is a good idea to go through the whole course prior to doing anything hands on, just to get a feel for what it expects and the scaling difficulty.  Plus, you'll be exposed to more advanced techniques as it continues along, which could help some of the more basic concepts sink in a bit.  There's no 'wrong way' to go about studying, unless you just don't, but even in that case if you have enough experience you'll be fine.

Alright so, let's talk about the materials OffSec provides students with.  A student will be provided with the following:
  • A PDF containing the course modules and some exercises
  • Videos covering each module, plus some stuff not in the PDF
  • A lab network containing a few pre-configured machines
I've read many OSCE reviews and I dare say that most, if not all, are enamored with the materials OffSec provides.  My opinion... differs.  While I enjoyed reading the PDF, and found it useful to follow along, I also found it lacking.  It's certainly a large step up from trying to learn exploit development merely by utilizing Exploit-DB, but it's definitely not as in-depth as something like Corelan tutorials.

Substance of the material

In all honesty, it's a bit lackluster.  The OSCE employs a module based structure, where each module is a specific topic and 'case study' you could say.  Rather than a lot of explanation of the core concepts, a student will essentially walk through the process of building out harder and harder exploits.  Very cool, as it allows a student to jump right in and start doing, but it also leaves many, many questions unanswered.  I found myself following along, wondering what I was doing and why I was required to do it.

I absolutely understand OffSec's approach and respect it, at that.  To pass their certifications, you must, must, must do your homework.  The OSCE is certainly no exception to this.  Some modules were quite interesting, while others left much to be desired in terms teaching.  That's sort of the OffSec way though, and again, can be what's so enticing about it.

I've read a lot of reviews that state that the materials provide everything you need to know to pass the exam.  I once read a tweet that stated something along the lines of the following regarding that assertion:

"Saying that the OSCE materials contain all you need to pass the exam is like saying that a junkyard contains everything you need to build a plane"

While technically true, that would take a great deal of time / effort and be quite the feat.  The material does many things very well, I think it could just have some substance added to it.

Are the materials really outdated?

Many people have maintained that the OSCE material is out of date and have pushed for updates.  It's not that they're wrong, so much as just that they're sorta missing the point.  While I agree that some updates could be in order, it's important to learn the basics.  Even if a student is primarily teaching oneself, the basics are the foundation that all other material will reside upon.

Although I do believe the material could use a bit of polishing and be a bit more robust, the topics covered were awesome, and really showcased the process involved in a way that was easily digestible.  Really, it comes down to the old saying: "Gotta walk before you can run".

Had the materials gotten too much harder / newer, I would've had a more difficult time with the course as I had zero exploit dev foundation.

Here's a video from DEFCON 16 (16!) of one of the exploits the course walks through:

That's a great example of why it doesn't really matter that some of the techniques taught aren't as effective anymore on modern day operating systems.  What the course 'teaches' (I use that word rather generously here) is to have the creativity and problem solving skills to come up with interesting solutions.

The course focuses on Windows exploit development

Yeah, so the primary focus is on exploit development, so you'll want to get comfortable using debuggers (you will) and assembly (you will).  Although that's the main objective of the course, it actually starts and finishes in different areas.  The syllabus is available online, here and written out, below:
  1. The Web Application Angle
    • XSS
    • Directory Traversals
  2. The Backdoor Angle
    • Backdooring PE Files
    • Bypassing AV
  3. Advanced Exploitation Techniques
    • MS07-017 .ani Exploit (ASLR Bypass)
    • Egghunters
  4. The 0day Angle
    • Windows TFTP Server
    • HP Openview NNM
  5. The Networking Angle
    • Bypassing Cisco ACLs using Spoofed SNMP
    • GRE Attacks

04 - Modules

So, the modules are mostly just case studies / scenarios that a student will walk through.  Each module aims to teach a specific skill, perhaps multiple, and introduce students to new methods and clever out-of-the-box ideas.

The Web App Angle

The web application angle is important and highly relevant to this course.  Although when I think about the OSCE, I think "exploit dev", typically an organization's perimeter is gonna be a webapp.

OffSec does a good job showing off a couple pretty clever attacks and displays that the attack surface of webapps can be larger than what we might expect.  It's novel thinking and clever execution.  Personally, I felt pretty comfortable with this module from the beginning so I didn't spend much time on it.  It certainly gave me new ideas though, so it's absolutely worth it to spend time here if you are unsure.

The Backdoor Angle

This module focuses on techniques for backdooring PE files.  It's pretty neat stuff, as it exposes the ease of which executable files can be compromised if you have access to them.  It's a relatively simple exercise, but it's a nice introduction to ASM and teaches some core concepts.

The second part of this module focuses on AV evasion.  The technique involved no longer works with modern anti-virus, but that's really no surprise.  The idea behind it is what's important though.  This module teaches the basics and with practice a student will have the ability to do this on their own and transfer it to other applications.  Really, it's very easily expanded upon and is primarily shown to get the creative juices flowing.  Take the time to understand the process, and try applying it to other scenarios.  This is a great module to practice and try to start doing more advanced evasion on.  This won't just be useful in the real world, but will also help hone your assembly skills as your understanding will grow rapidly.

This is a deceptive module, as I found myself having difficulty recreating it as I forgot minor (but important) steps during the process.  Looking back, I think it's important to really understand why some of the actions are taken as soon as you're able to.  Understanding the steps as early as possible will really help build a foundation for the rest of the modules.

Something I also really want to clarify is what I mean when I say that you should 'really try to understand' what is happening.  There's a difference between understanding something and really understanding something.  You can't half-ass this course, nor exam.  The only way to get what you want from it is to buckle down and study.  It's easy to understand the concepts after a bit of studying, but you'll find it takes a bit more to apply them.

Spend time doing the leg work in the course, starting with this module.  Start backdooring other files, etc.  Really nail down why and what you're doing when you're saving stack values, what each jump does, etc.  Try automating it.

Advanced Exploitation Techniques

This is what I came for.  Backdooring the PE files is really cool (and actually more applicable and useful than one might think) but at this module and moving forward is the meat of the course.  The course starts to pick up speed here, as well. This is also where I start to wish there was a bit more foundation and time spent teaching the basics, as OffSec goes straight from backdooring a PE file, to bypassing ASLR.

The ASLR bypass is awesome.  OffSec chose a pretty well known exploit, MS07-17, to showcase how ASLR works and how it could potentially be bypassed.  ASLR isn't a super complex topic to explain; it's easy to visualize and experiment with, but this particular exploit does a good job displaying how this protection can be leveraged in the right situations.

The second topic in this section is the egghunter.  Prior to starting the course, I had heard of egghunters, but really didn't know what they were and especially not how they worked.  This is a good introduction to the utility of an egghunter, although it's going to be up to you as the student to learn what's really happening.

The 0day Angle

As with the previous module, the difficulty of the modules continues to rise, but it's very manageable.  The first case study of this module is against a TFTP server and is a fantastic introduction to the process of locating 0day vulnerabilities-- which let's be real, is why we're all taking this course.  Without getting into too many details of the techniques involved in locating unknown vulns, this module will teach some great foundations and the basic process.

The way it's presented is quite simple and it's easy to understand how one might transfer these skills into other scenarios.  I spoke about OffSec's lack of explanations earlier, but I can certainly give them credit for the subjects and their respective exploits.  Each one tends to focus on one specific technique or basic idea.

Then comes the HP Openview NNM exploit.  This is the flagship exploit for this course and if you watched the video or have taken a look at the exploit, you'll see why.  Every module / task prior to this one made 'enough' sense to continue along and feel like I was getting somewhere, but this one is in another league.  Really, what an incredible display of creativity this exploit was.  It's a great exhibition of perseverance and what it could take to turn a bug into a full blown exploit.  This is certainly the hardest module in the course.

If you read around, you'll find that people spend between a few days to a few weeks going through the modules for the first time.  Up until the HP exploit, most of those modules and tasks are of similar difficulty, as your skills improve while you are presented with harder topics.  The HP module will take a significantly larger investment of time than any of the others.  Really take the time to understand what is happening and why it's happening when you're doing this one.  The techniques involved are stellar, and to really understand them you need to put the time in.  Many different concepts are employed and combined and it's really the culmination of the previous tasks.

The Networking Angle

Alright, so this is where the course deviates from the exploit development stuff and back to advanced pentesting.  I went through this module, but I can say that I just wasn't as interested in it-- especially after the HP exploit of the previous module.  It's definitely important to go through this one and understand what's taking place, but I can't lie any say I was enthralled, because I wasn't.

All in all though, I'm glad they included this in the course, because it makes you switch back to remembering that this isn't just slinging 0days to breach a perimeter and you need to be able to think creatively about the entire attack surface.

05 - After the Modules

As with most other courses with an exam involved, once you've gone through the material provided, it's a good idea to go back through the material until you feel comfortable with it.  In this world though, there's so much more to be done.

I'd take the time to go back through the material at least once at this point and try to do everything without your notes.  See where you get to, take note of the areas where you started to struggle.  Write them down, don't just 'remember' you had difficulty, actually write it down so you have a record of it.  Regardless of whether or not you can breeze through the modules, now it's time for major supplementary reading and practice.


I'd say there are a couple no-brainer things that should be done at this point.  The first thing I'd take the time to do is start reading and following along with the Corelan tutorials, starting with number one.  Corelan really takes the time to explain to readers the core concepts and provides insight that OffSec's material doesn't.  These tutorials are typically extremely long and absolutely packed with information.

Take the time to read through them and definitely follow along.  When I started going through these tutorials, I didn't take the time to read them first, I followed along and found that it took forever to get through them.  Definitely do follow along, but don't be discouraged or think that you shouldn't just read through them on their own, either.  Although some knowledge won't be absorbed, you'll be exposing yourself to advanced techniques, and explanations of the concepts.  A lot of stuff will start to make sense and sink in.

After reading around, I found that people suggested reading / doing the Corelan tutorials up until they get to ROP / heap exploitation, as the course doesn't cover those.  In the effort of studying the course materials it's true, you don't need to go into heap exploitation nor ROP chains, but don't shy away from it either.  The harder the material you learn and understand, the easier it will all become over time.

I found myself referencing Corelan's tutorials just as much as anything else (probably more) in subsequent research as there's just so much information in them.


FuzzySecurity's tutorials are also really good.  They follow along similarly to Corelan's but are much shorter and much more condensed.  I went through Corelan's tutorials first, which helped to cement my foundation.  FuzzySecurity presents the topics well, without all the filler that Corelan provides.  On the same note however, because they are much shorter, they are significantly less detailed.

I enjoyed going through these tutorials very much, as they were faster and still taught all the core information, just less detailed.

With FuzzySecurity's tutorials, I went from part one to part six, more as some reinforcement and to supplement anything I might've missed in the torrent of information Peter Van Eeckhoutte writes on Corelan's site.

Skape's Papers 

This is heavy stuff.  I've read reviews coming from both sides on this one.  People either recommend it, or they say they didn't really learn much from them.  Personally, I think these are a must read, merely to understand what goes into shellcoding and creating reliable exploits for Windows systems.  Regardless if the papers were written a long time ago, the core concepts still apply.

I'd first take the time to read Skape's Understanding Windows Shellcode paper.  You may even want to read this prior to going through some of the more advanced Corelan / FuzzySecurity tutorials.  I think people look too far into this particular paper for it's utility.  It's not so much about absorbing the actual assembly Skape includes, but about the concepts involved and the techniques to determine addresses and load libraries.  This paper in particular put a lot of the missing pieces together for me in how Metasploit shellcode works / what it's doing, as well as finally realizing the simplicity of function calls, and how shellcode is essentially just manipulating and taking advantage of available functionality.

That last part sounds simple when explained, but it wasn't for me.  Once I took the time to really start looking into how to set the stack up for function calls and writing some 'more customized' shellcode and functionality within my exploits it started to really make sense what was happening.

The other paper that's good to go through is Skape's Safely Searching Process Virtual Address Space paper.  This paper focuses on egghunting, and explains some of the nuances and ways that egghunters can work.  Again it's quite old, but these are some of the best egghunters available for the respective operating systems and you'll see / utilize them a lot.

Honestly, there are plenty of good papers out there, but those two were especially useful for me.  Don't be put off by the first one's 94-page's, a lot of that is just assembly!


For those unfamiliar, the SLAE is the 'SecurityTube Linux Assembly Expert'.  Although this course focuses on Linux assembly, assembly is still assembly, and Vivec does a phenomenal job relaying information in an easily understood fashion.  This isn't a free course, but if you have the option to take it, it's most definitely worth it.

You'll feel much more comfortable writing assembly by the end of it, which will certainly come in handy, if only to boost your confidence.  There are many differences in Linux and Windows shellcoding, but there are quite a few similarities as well.  How the stack should be set up for function calls, how strings are pushed to the stack and referenced, encoding and AV evasion techniques, plus a lot more.

I started the SLAE just a week or so before my first OSCE attempt and really wish I had started it earlier.  When I did spend some more time with this material, I watched the videos and followed along, but after a while the following along tapered off in favor of watching and trying to absorb some new techniques.  I'd recommend going through this, whether or not you pursue the certification.  I haven't gone after the cert yet, but plan to this winter to keep my assembly skills fresh.

Mutillidae / DVWA

These may seem odd to include, but if you're feeling weak or less confident about the web application aspect, I'd highly recommend going through the DVWA and/or Mutillidae vulnerable systems.  It's not necessary to touch upon all the topics these both cover, you could just take some time to focus on what the OSCE looks at.

Spend some time trying the XSS modules and think about creative ways to solve them and ways you could apply them, as well.  Go through any modules relevant to directory traversals / local file inclusions, take the time to enumerate as if you weren't aware on what existed on the target machine.  As with most other tasks in this course, spend some time automating it.  If only for fun, every bit of code you write helps to cement that knowledge into your head.


I saw many, many people suggesting going through SecuritySift's tutorials, starting with number one.  Interestingly, when I began my studying for the OSCE, the site had been suspended and wasn't accessible.  I recently tried again to see if it ever came back up, and indeed it has.  I can't personally attest to the actual material as I never actually saw it / used it while studying, but the quantity of it and the amount of folks who have recommended it indicates the quality is quite high.

If it's still up when you are doing your OSCE / CTP course, read through them, even the topics you already know.  I mentioned it towards the beginning of the post, but sometimes just hearing / reading someone's explanation of a topic a slightly different way can be enough to put the pieces together.

WinDbg, GDB, nasm and C

I highly suggest trying to use WinDbg.  It can be a pain in the ass to even get installed sometimes, but grab it from here.  It's a part of the "Debugging Tools for Windows" package now, but you'll figure out a way to get it installed.  WinDbg is a command line debugger and it's much less 'user friendly' than Olly and Immunity are.  By default it isn't set up in a nicely arranged UI, it's very bland.  You can make it look like the other debuggers, though.  

Anyway, once I started using WinDbg, even sparingly, I started to learn quite a bit.  Concepts started ito sink in a bit more.  WinDbg is not easy to use, In fact, it's pretty difficult.  The fact that you need to enter commands for each action you want to take means you need to really start paying attention to what's happening.  You don't have the pretty UI that Immunity / Olly give you, by default you just have a console.  This console can do everything you need it to, give you all the information the others do, but you need to know what to ask and what to tell it to do.  This means you really have to focus and learn the step by step process.  No more nice interface showing you where the ASCII values on the stack are, or where the SEH chain begins and ends-- you can find all that out, but not without intending to.  

The same thing goes for GDB, which is another command line debugger.  It can also disassemble Windows binaries, which is an awesome feature.  Both of these tools force you to pay attention to use them properly.  Especially to write an exploit and step through.  Take the time to learn how to use them, as you might find a lot of missing gaps in information you thought you knew, but really you were just taking the nice UI of Olly / Immunity for granted.  

It'll take some time to learn the commands that WinDbg and GDB use, but spend the time doing it anyway.  It'll slow the process down immensely and sometimes that alone is worth it when you're trying to learn.

Use the nasm-shell, too.  This will mean you'll be writing more assembly, which is exactly what you want to be doing.  On that same note, C.  I wish I had taken the time to learn more C.  People say it's not necessary.  Yeah, they're right that's it's not actually necessary, but I feel like it would have helped me a lot.


ExploitDB is a fantastic resource.  Troll through it and find exploits for SEH, vanilla buffer overflows, with egghunters and/or restricted character sets, etc.  In many cases, it can be difficult to find exploits that are focused on what you want.  Try converting a vanilla buffer overflow into an exploit that uses an egghunter.  Do the same with an SEH exploit.  Although it might be 'unnecessary' the goal is to familiarize yourself with the skillset and to employ them, not just be aware of the concepts.

I found myself reading tutorials left and right, but not following along as I 'understood' what the author was doing.  Funny though, as soon as I tried  to recreate the exploits, I would get stuck over and over in the beginning.  This is because I wasn't putting in the time to do them, just reading and absorbing.  Although that was good and allowed me to learn a lot, my skills weren't being exercised, so when it came time to do it, or to think creatively, all I knew how to do was exactly what I was told in a walkthrough, rather than creatively applying techniques.

Once I really started to spend the time to sit down and do it, I started to become more confident and things started making a lot more sense.  This isn't to say I wasn't doing the exercises / practicing from the beginning, but if you're like me and could relate to the beginning of my post where I said I sort of breezed through life, you may find the laziness can overpower the desire to apply yourself and take action.  I read lots of stuff but again, it wasn't until I started really bearing down and writing exploits that things really started clicking.

Shellcoder's Handbook / WebApp Hacker's Handbook

These are the only two books I'm including in this list, primarily because I didn't use any others and hardly used these.  Let's start with shellcoder's.  

This is a great book.  It's pretty heavy and relatively dry regular reading material, but overall it's an incredible font of information.  The best way to describe them is that it and the WAHH are truly tomes of knowledge.  As for the utility of the book, it's limited in it's direct application to the course.  It's intent isn't to help you find the one way to jump in a character restricted buffer to move into your second stage shellcode-- it's about the process and educating readers in the subject as a whole.  Personally, I didn't spend much time in the Linux section in the beginning of the book.  I skipped to the Windows section fairly quickly, but after doing some of the SLAE I realize that it would have helped regardless.  As for the Windows section, it taught me a bunch of fundamentals about the process environment block (PEB), how PE files worked, how reliable Windows shellcode works and a bunch more.  This book is pretty heavily assembly focused, so it can be a doozy.

For the WAHH, I recommend this book outright, regardless of it's applicability to the course.  I picked it up a few times, but not too frequently.  I reference this book much more when I'm actually testing web apps, but I'd say this is a must buy.

06 - Links / More Resources

Ok, so there are a ton of resources out there.  Here's a small list of useful sites / pages that will help from the beginning.  Your collection of resources and links will grow, but I can suggest the following to start:

  • Articles
    • This is just a link to his articles section.  Scroll down to "Exploit Writing Tutorials" and just start from the bottom.
  • Tutorials
    • Again, more tutorials!  As explained above, these are the basically condensed versions of Corelan's stuff.  You'll get through them faster, but they contain less information.
  • Tutorials
    • Just go off this link and scroll to the 'Related Posts' section at the end of it to navigate to other walkthroughs.
Skape's Papers:
Web App Resources:
  • Mutillidae
    • Grab it!  Useful to have, regardless.
  • DVWA
    • Another good vulnerable system.
  • LFI Techniques
    • This is a surprisingly good paper focusing on some of the many techniques for exploiting LFI vulnerabilities.  Short and sweet, but this stuff is always good to know and this is a great paper.
  • Excess XSS
    • The title calls this A comprehensive tutorial on cross-site scripting.  I mean, I guess it is?  It's a good article, but I wouldn't go that far.
  • Python Requests
    • I'm a big fan of the Python Requests library.  I found myself constantly writing out raw socket connections to HTTP servers one too many times before finding requests.  It's not perfect and I still write out a raw socket request for exploiting something (usually), but it's a useful library.
Misc Assembly References:
  • ODA (Online Disassembler)
    • This is a slick little tool.  Found myself using it a lot.
  • shell-storm's assembler / disassembler
    • Just another assembler / disassembler
  • x86 Opcode and Instruction Reference
    • I'd just bookmark this-- it's a ton of information, but it's good to have.
  • x86 Instruction Set Reference
    • Another instruction set reference.  This one is less comprehensive, but it has the mnemonics listed, rather than opcodes (or both).  
  • Jasmin
    • This is a pretty cool Java utility for learning assembly.  It's an interactive, java based assembler / CPU emulator (really neat).  Personally, I didn't use it much, but you may find that it will help having something interactive.
  • WinDBG
    • Grab WinDbg.  Try it out.
  • Shellcode Using system()
    • This isn't necessarily a great article, but it's a super quick read and an interesting idea.
  • Do core!
    • Just kidding, but actual exercise is good for you, honest.
  • Protostar /  Fusion
    • I didn't see these recommended until much later into my course, but really wish I had found them earlier.  Neat little CTF-style linux assembly exercises.  
  • Exploit-DB
    • You should be spending as much time as possible here, pulling down exploits and recreating them.
  • HTB
    • Hack the Box isn't just for net pentest-y exercises, there are also a whole bunch of challenges for reversing, webapps, and more.  Plus, it's just a fun resource to have.
  • QuickZip Stack BOF
    • Very specific, but this is quite the exploit and follows an awesome process from start to finish.  It's another Corelan article, but the OffSec site makes it a bit more... legible :P
Misc Links:
  • Understanding Windows at a Deeper Level (Sessions, Stations Desktops)
    • This was a pretty killer article that helped me to understand some odd behavior I'd periodically notice.  Maybe it'll help you, too.
  • WinDbg Commands
    • Just a list of some of the available functionality of WinDbg.
  • Scapy Cheatsheet
    • A neat little cheat sheet from SANS for Scapy.  Try using it!
  • g0tmi1k's OSCE Review
    • This is a nice review, he does justice to the exam's difficulty and includes a lot of references, as well.
  • Tulpa Security's OSCE Review
    • I'm a huge fan of this post and it's also one of the main reasons I haven't given a 'prep-guide' so much as a 'here's some stuff I used and here's what happened' guide.  I can't say I followed along regarding the 'Watch SLAE videos X-Y now' aspect of Tulpa's review, but I'm sure it's useful.
  • CNIT 127
    • This is an entire course on Exploit Dev, using the Shellcoder's Handbook as it's assigned textbook.  It's really rad.  Put it on in the background, or follow along, but it is quite a bit of info / very long.
  • Hacking, the Art of Exploitation
    • I have heard good things about this book.  In fact, I just ordered it.  I can't personally attest to it's content, but judging by the synopsis and what folks have said, it's useful.
  • The Shellcoder's Handbook
    • A great reference, or ballast weight, to have.
  • The Web Application Hacker's Handbook
    • Another great ballast weight for winter driving.  But in all seriousness this book is amazing. I need a new one because my copy is so worn out.
This list is just a handful of the resources I found myself using.  I've also neglected to include some links that helped in specific situations.  Read lots of OSCE reviews; many of them will focus down on specific topics covered in the course and exam if that's what you're interested in seeing.

The point is, if you're looking for links to help pass the exam, you're doing it wrong.  This course isn't as much about passing the exam and obtaining the certification as it is about the learning experience, process, and forcing people to learn by doing.  Passing the exam is awesome and you will pass it if you take the time to do the work.

07 - My Exam Experiences

As I've spoken briefly about, I took the exam twice.  The first time was hard, the second time was almost harder, even though I'd studied so much more and had a 'good gauge' of what struggled with.  I think the hardest bit of the OffSec exams is when you fail, you generally don't know what you need to study-- it's not as if you fail on a certain test question; you fail because you don't know what to do.  It sounds simple, but it makes studying pretty hard.

I don't / didn't know anyone who had taken the CTP course, so the first time I scheduled my exam left me with mixed feelings.  A bit of excitement mixed with anxiety, as well as some pride thrown in, too.  Being the first (of my group) to venture into the unknown made me feel like a guinea pig in an experiment, but it also made me a bit less nervous weirdly, I suppose because there was no way of knowing what was on the exam.  I was either prepared or I wasn't and I would pass or I wouldn't.

Attempt One

I had studied, went far beyond the scope of the material and now was the time to put everything to the test.  The exam is broken down into separate challenges each worth a certain point value.  These point values add up to a maximum of 90 available points, with a total of 75 needed to pass.  The real kicker however, is that the points are dispersed in such a way that means you are required to complete or partially complete all challenges in order to get enough points.  It's not like the OSCP.

The test was not what I'd expected.  It was certainly far more difficult than I'd expected, as well.  I basically spent  the first day floundering-- I made progress here, made progress there, but I just couldn't go all the way.  Towards the end of the first day, I slowed down and took a step back.  I re-read directions and took some time to think about what I must be missing.  An hour later later I had my first points on the board and a renewed confidence.  It was pretty wild how foolish I was being and as it turns out, I had wasted a lot of time.  Either way, I felt much better :]

It was pretty late on the first day when I decided to get some sleep.  Honestly, there's no way you're gonna make it through this exam without taking breaks and sleeping, if you use the full 48, that is.  I got some rest (not enough) and got right back to it the next morning.  That morning proved a bit more fruitful, although I was still making up lost time.  I figured out another very, very silly mistake I was making the previous day and got another one on the board. I definitely felt a bit renewed at that point, but still had a long way to go.

I spent the next ~24 hours or so fighting the next challenges.  All of which I had located vectors that could be exploited to gain control of the machines, but I was unable to capitalize on them.  It was pretty wild actually-- I knew where the vulnerabilities lie, could partially exploit them, but was unable to progress.  That's a terrible feeling and one I had to fight through.  I stayed up all night the second day, trying in vain to complete the remaining challenges.  I was able to partially exploit each, but, it wasn't going to be enough to pass, nor at that point did I really want to.

Honestly, I didn't want to pass this exam unless I got it all.  I'm not a completionist, but had I passed that first time I would've been disappointed.  In fact, I didn't even submit my report.  It was 9AM on a Friday morning, after a grueling 48 hour exam with six hours of sleep that I walked to the corner store, got a beer, went home, put on shitty TV, drank a beer and passed out for eight hours on the couch.  It was actually pretty stellar.

Attempt Two (one month later)

Having the knowledge of what the test was like didn't make me feel better.  Honestly, it made the anxiety go up.  Between the two attempts not much changed.  I kept studying, used the resources I've linked plus many more and just kept learning.  The first time, in retrospect, I really just wasn't prepared.  All the practice and effort I had put in was all well and good, but there were still some major gaps in my knowledge that I had to address.  These gaps aren't even things I could necessarily qualify or write out, so much as just conceptualize and now look back on and think "yeah, that makes sense".  ¯\_(ツ)_/¯

I blazed through the beginning of the exam, which boosted my confidence immensely.  After some easy challenges, I spent the next six hours smashing my head against the keyboard until I was able to leverage a vulnerability and get some progress.  Unfortunately, OffSec is a cheeky bunch of nerds and it was still hard after that. Another three hours and I had it!  More progress in substantially less time than the previous attempt.  

Most of the way through the exam and still not enough points to pass, I went for my... fifth walk of the day?  I had taken plenty of breaks this time and eaten lots of great food and snacks.  Plus, it had only been about 10 hours and I was almost there.

I walked around my neighborhood and tried to talk out the last challenge that I had been bouncing around on earlier.  I had the basic idea, the basic concept and even a vector to exploit  I just couldn't put the final pieces together to capitalize on it any more than what I had done so far.  I wish I could say the talking about it finally made something click, or the drawings and ways I wrote it out on paper.

I spent the next couple hours working on it before I decided that the day went well and to let myself rest.  I crawled into bed at midnight, 14 hours in and slept about five.  I woke up, made some coffee, then went back to the grind.  At this point, it had been about 20 hours, not even a day had passed and I felt pretty good.

I spent the next few hours making absolutely no progress.  Stuck in the same spot the whole time, I took a few breaks and really wore out my desk's motors, too.  After about five hours, plus about seven the previous day with no progress, I didn't just feel stumped-- I felt defeated.  This was hard.  I wasn't sure if I actually could do it at one point and almost left and just went to work.  I felt like I had enough time to leave and come back because I didn't know what to do anyway and just got tired of taking the exam.  When you do something for such a long period of time without making any progress it doesn't feel good, it feels really shitty.

I sat back down after complaining for a little while and decided to try something new.  This was really my last ditch effort.  I started testing some things and then got major progress.  It's funny, but at first I didn't even realize how much progress I'd just made, I just thought that if it didn't work, I'd give up.  Simple.  I noticed something interesting and found it's exactly what I wanted to do, so I just experimented.  An hour or so later I had the first signs that I'd be victorious.

It was marvelous and made perfect sense.  So much time spent thinking in a box.  I got it working, then completed the challenge.  I wanted to make sure it actually worked, so I ran it about six times.  Then, a few more for good measure.

The rest of my time was spent taking screenshots, an over abundance of them in fact, and noting everything I did.  The last thing I could think of to be anxious about was flunking the reporting part, so obviously my brain couldn't just celebrate.  I took a break later on and ended up at a baseball game with my friends and girlfriend Big shoutout to her for putting up with me failing OffSec exams and been nothing but supportive for the past few years.  Can't brag about failing the exams but I can sure as hell brag about that.

Some more time reporting that night, some sleep, and then more reporting in the morning finished the documentation up.  I followed the instructions and sent it.  A bit over 24 hours later, I got the news that I had passed.

My birthday was the day after I submitted the report.  Earlier in the week I had questioned the wisdom of such a decision but had decided not to question my past self, as so far it had done a pretty good job.

08 - Takeaways

Really, what is comes down to is your ability and aptitude to focus.  If you can focus and do the exercises and study and recreate exploits and not shy away from trying complicated stuff, you can succeed.  The biggest thing is to meet challenges you're presented with and not back off, you're going to be presented with trying hard things.  The more hard things you do, the easier those things get.

This is a hard course and a harder exam.  I'm proud to have passed it. I recommend the course purely for the exam, but not necessarily the materials.

There are a lot of reviews out there detailing the OSCE and many of those are from people who have passed their first times.  I'm not one of those people, I'm just a curious person.  Don't be afraid to take the course or the test.  There's no shame in taking it multiple times, you'll still learn a ton and that's what it's about.

After the OSCE you'll probably want to do the OSEE.  Fair warning.


Popular posts from this blog

06 - How to maybe not be so bad at fuzzing, Part 2

04 - DiskSavvy Enterprise 10.4.18 BoF SEH (and how I finally became not so bad at it)