I apologize for not being as present as I have been in regard to making posts and answering questions. I recently got a job in a different city so I’ve been in the process of relocating and working full time.  So my life has been pretty hectic, but it’s all very exciting.

When the dust settles I’ll be upgrading to a VPS instead of the shared hosting I’ve been relying on, this should allow for faster response times and less downtime (grrrr shared Apache services).  I’ll also be finishing up the Malware Analysis series, and hopefully answering all the questions I’ve been receiving for the Buffer Overflow Labs. In the meantime I’ll be periodically approving comments but will not have time to answer them, if anyone feels they can answer someones question feel free to do so.

Thank you for your patience,
Kian Malware Analysis [Part 1]


Lately I’ve been hunting for some interesting malware to reverse engineer. That opportunity presented its self in the form of a drive-by exploit being hosted on the popular website around November 10, 2013. The team at Barracuda Labs provided a brief yet very informative article on how a vulnerable machine would have been exploited via the hostile javascript being hosted at the compromised site. In their analysis of the drive-by exploit they also provided a full PCAP of their vulnerable machine being exploited and the  payload being delivered.  The provided PCAP is a goldmine of malicious javascript,  java/PDFs and the malware used post-exploitation, which I’ll be relying on for the majority of my analysis (Thanks Barracuda Lab!).

Continue reading

Buffer Overflow Lab [Level 3]

Continuing from the last lab.

Level 3 of the Buffer Overflow lab is similar to Level 2 of the series in which you still need to push machine instructions onto the stack and include the address of where your injected instructions reside on the stack. But in this level, you have to allow getbuf() to return to the original calling function, test(), and instead of getbuf() returning with a value of 1 in the eax register it would instead hold the value of your cookie, in this case being vedostek or 0x1ee74af1.

Continue reading

Buffer Overflow Lab [Level 2]

Continuing from the last lab.

Level 2 of the bufbomb lab really starts to get interesting. Instead of just supplying a string that pushes values onto the stack and rewriting previous data, in level 2 you have to inject machine instructions onto the stack, have them execute and then redirect function getbuf() to function bang().

Continue reading

Buffer Overflow Lab [Level 1]

Continuing from where I left off in the previous post -

In Level 0 of the buffbomb the goal was just to redirect the program from returning from the function getbuf() and instead direct the flow of the program to function smoke() all via a buffer overflow. For level 1 of this lab, the goal is to not only change the return address but also supply your “id” within the buffer overflow. The id used for the buffbomb lab is determined by the username you will be using when running the buffbomb executable. Using the makecookie executable you determine what your cookie is, in order to achieve successful results from level 1, the variable “cookie” has to be replaced with the correct id, in this case I will be using “vedostek” as one of the arguments when running buffbomb.

Continue reading

Buffer Overflow Lab [Level 0]

As of lately I’ve been absorbed in the book Computer Systems: A Programmers Perspective, part of the books assignments is a buffer overflow lab. In the buffer overflow lab there are five phases, where you have to exploit the getbuf() function of C and manipulate the outcome of bufbomb.  For Level 0 of the bufbomb lab, the goal is to provide a string longer then getbuf can handle, causing an overflow and pushing the rest of the string onto the stack where you can then control where the function getbuf returns after execution. 

Continue reading

Understanding and “cracking” a simple C program.

In an effort to gain an understanding of x86 Assembly Language and how a dissembler such as IDA or OllyDbg can dissect and modify the outcome of a program I decided to disassemble a simple C program I wrote for this purpose. The C program stores user input as an integer for the variable “cdkey” and checks the value against the locally stored integer: 123456789.  If the stored integer turns out to match then it displays the output “CORRECT CDKEY”.

Continue reading

Network Security Lab

Virtual Playground

To gain relevant experience in the vast world of netsec, a lab to experiment with is a necessary prerequisite. Initially, I  would collect old computers and install the desired OS on them to practice on, this was not only time consuming but also rather inefficient when it came to its energy consumption. I decided to invest in a server so I could have a virtual playground, much of the inspiration for the server comes from the Proactive Defense post on his ESXi Security Lab. I have an almost identical set up to his server rack, and so far with a few months of straight up time I have not had any issues and a noticeable decrease in my electricity bill.


Continue reading


A little about VEDOS:

The Sanskrit word véda meaning  “knowledge, wisdom”  is derived from the root vid- “to know”.  [wiki]

VeDOS is a site dedicated to the exploration and hopefully the advancement of knowledge in the blooming field of Network Security. By sharing my experiences with the various fields of netsec, not only does it help solidify my knowledge but I hope that a reader might also glean interesting bits of information that would benefit their understanding as well.

Feel free to comment with suggestions or questions.
Email: Kian[at]


About Kian Movasagi

I’m an enthusiastic geek who is passionate about everything that has to do with network security. On most days you’ll find me in my lab in the Pacific Northwest, where I’ll be practicing network security and administration, and tackling the latest in malware: dissecting it, learning about its exploits and defense mechanisms.