OSCP and some DVR reversing.

Hello everyone!

Sorry I have not been posting much recently.As you may know, I have been undertaking the OSCP course. Sadly, I failed the exam.

Or not really sadly at all. I hear that a lot of people fail the first time, and I pretty much expected to fail too. For me it was far more about the journey, rather than the destination. I learnt such a huge amount in the build up to the course and during it too. I also now have a very focused list of study areas to delve into further, which you will be accompanying me along, as I blog about the results. Also exam re-takes are pretty cheap, at around $60, so I will try again in a few months.

The OSCP itself is a pretty intense 2 month (or more/less depending on what you opt for) training course. I think I might have described it earlier, but in case I have not, here is a brief rundown.

There are a five sections to the course. The book, the videos, the exercises, labs and the exam.

The exercises, video and the book are really good. There are many hours of video tutorials, teaching you how to attack various operating systems, software and vulnerability types. The videos are accompanied by a 350 page pdf (book) that covers the topics in greater detail.

The exercises are part of the book, but really make you get your hands dirty and “learn by doing”. This is pretty much the mantra of the course.

The lab is hands down the best part though. It is a network of more than 50 virtual machines. You can reset the machines at any point to a “known good” configuration, so you never need to worry about breaking or erasing anything.

The machines are organised into a network that simulates a company. Essentially it is a pretend pentest environment. Your objective is to root as many of the boxes as possible, and practise your craft.

I think around 90% of the machines that I rooted required me to leverage more than one vulnerability, often times four or five steps! Frequently I would have to leverage a Local file inclusion vulnerability to trigger something I managed to get onto the box by a Remote file inclusion.

The exam is 48 hours long. The first 24 hours are all hacking. The last 24 hours are all reporting. During the first 24 hours you have access to a virtual network again, this time only a limited number of machines are available.

You have to get 70 points to pass. The machines are worth varying levels of points.The reporting section is pretty much what it sounds like. You have 24 hours to professionally report your findings.

It is also possible to walk into the exam with 10 points in the bag. This is achieved by preparing a pentest report from your time in the lab, on at least 10 machines and how you rooted them (5 points) and by appending the completed exercises from the book to your lab report (an additional 5 points).

I spent a good portion of my time making sure that I would have 10 points going in.
I have pretty much been off all forms of social media, blogging, email etc for the time that I have been doing this, apologies if I have not gotten back to you, this has consumed my life pretty much.

It has been a huge learning experience. There are programs that I know inside out that I never even knew existed going into this. I also did a lot of buffer overflow exploitation, which for me is still the most “movie-hacking” thing. Even after writing my own exploits for vulnerable programs (I have a blog post about one in draft form and will publish it next week.) it still seems somewhat akin to magic.

If you are into hacking, then I would highly recommend the course. If you are considering some other course, like CEH, I would urge you to try out the PWK/OSCP course instead. It’s not a panacea, but it is super good for learning. You do, however, have to be willing to dedicate the time required to it.

I put in several hours each day, as I was lucky enough that my job paid for the training, so could hack away at work, and at home. I would also put in 8 hours a day on the weekends too.

Most people interested in this course are more skilled than I am at this kind of work, so require less time. If you are relatively new to all this, you may need more time in the lab.
You can always buy extra lab time if you want to.

Enough about that though, let’s get onto some-thing blog-post worthy! One of the fields of study I found I lacked in was general “reverse engineering”, so I figured that I would start out with something small.

A was given a DVR recently. Not as a present, more along the lines of “Here, hack this thing”. I plugged it in, and started an nmap scan against it. This DVR had a telnet server running, which did not seem to respond to the default admin credentials for the box, which were admin/admin when logging into the web interface.

It was an Identivision DVR, and looks like this.

screen-shot-2016-10-05-at-11-23-43-amPretty beautiful, huh?

Now beyond simply brute-forcing the login credentials, which could take forever, I was not really sure how to attack the problem. I eventually settled on trying to reverse engineer the operating system. How to get hold of it though?

Fortunately, after only an hour of searching the internet, I found a version of the firmware. Identivision don’t release the firmware on their website like many manufacturers to for “Internet of Things (IoT) do.

I transferred it over to my Kali box in the hopes of being able to dig into it and find out how it worked.

screen-shot-2016-10-05-at-10-25-08-amFirst things first, is to run the file command on it, as we are just assuming that it is a zip, even though it tells us that it is.screen-shot-2016-10-05-at-3-24-15-pm

So it’s a zip file, lets unzip it and keep digging.


Now we are getting somewhere. That really long name and the .bin extension are indicative of the real firmware.


We run the file command again and find out this is yet another ZIP archive. Upon unzipping, we find that it contains a few .img files, and one called InstallDesc. As we can see below, the InstallDesc seems just to be this DVR’s equivalent of a shell script for installing the firmware.screen-shot-2016-10-05-at-3-26-03-pm

As there is no “logo-x.cramfs.img” file mentioned in the upgrading command, I am assuming that it is whatever logo is displayed on the DVR whilst the firmware actually updates itself. It is pretty small too (17k) which would jive with this assumption.

Next, to explore the image files, we can use a program called binwalk. I had only once or twice heard about binwalk before, and pretty much guessed that it might work. There was one command line flag we needed to use with it along with the filename, the -e for extract flag.screen-shot-2016-10-05-at-3-46-35-pm

The “custom-x.cramfs.img” didn’t have much exciting in it, although there were several of what appeared to be font files, and menu items, such as arrows, buttons etc.screen-shot-2016-10-05-at-3-49-32-pm

Also it seemed to have all the localisation files, I guess for all the DVR menus.


Also, super strangely,  in the English version of the file, was this gem.


If you can’t read that, it says:

“The power of car battery may be used up because the too long shutdown delay time, and the suggested time is less than 63 minutes.”


Also this cloud service help info. Both of those url’s seem unresponsive at the time of writing though.


The next file I tried, the “user-x.cramfs.img” did not seem to have much else in it. There were a few directories that I would expect to see on a linux system, such as lib and sbin, but not really anything remarkable.


The last one, “rom-x.cramfs.img” was exactly what I had been looking for.


As you can see, this is a small linux image.screen-shot-2016-10-05-at-4-17-31-pm

Navigating the file system, I am naturally drawn towards the /etc/passwd file, so that I can see which users are on this OS. It turns out, that there were two passwd files, one normal one, and one called “passwd-“. I’ve never seen this before, so I don’t know how common it is. Only reversing more firmware will tell me.

There was also no shadow file. Again, this is something I am not used to. I am used to having to get both of the files, unshadow them, then crack them offline. I fed these two files into John the Ripper to see what would pop out, and the first file was discovered in under a second. It was the password of “helpme” from the standard passwd file.

The other password from the passwd- file took a little longer, and was not in any of my wordlists. It was “xc3511”. Googling around a bit, it seems that this is a pretty standard password for rubbish embedded devices. True Internet of Things style security.

It also turned out that there has recently been a record DDOS attack against an infosec journalist called Brian Krebs. I would highly recommend his site, as he is a great journalist, and writes about cyber crime, with the lay person in mind. This DDOS attack against Krebs was performed mainly by Internet of Things devices that have not had their default credentials changed.

Crooks will scan the internet for devices that are using a service like the telnet one in this DVR, and try to use the default credentials on it. If they succeed then they will recruit the device into their botnet, and use it in attacks.

There is a screenshot of the most common username and passwords on his site, which looks like this.

You might be able to see our device in there with username/password of “root/xc3511”. It is apparently a H.264 Chinese DVR.

Well that is it for this post. The one coming next week will most likely be a lot longer, as I am going to show how to write a buffer overflow exploit for a program called SLMail that was an email application.

Over the next few weeks I will be gradually re-introducing myself into society and will try to catch up on all the missed emails and texts I may or may not have received.

I hope you all have an awesome week!

Leave a Reply

Your email address will not be published. Required fields are marked *