It’s been a few months since I’ve posted anything. This is not to mean I have been idle. Indeed, rainbowsandpwnies has launched the haxathon, a challenge-based CTF type event that lasts more than 48 hours. I’ve begun a rewrite of Rainbows-And-Pwnies-Tools and a symbolic execution engine. To be fair, I’ve, “Started,” the symbolic execution a good four of five times now. Among other things, here are a few lessons, in no particular order, learnt over the past few months.

• I should full-disk-encrypt my laptop/netbook hard drives because I will lose them and then worry about what was on them.
• I should read the notices that pop up after performing ‘pacman -Syu’ in arch linux.
• I shouldn’t plan on reverse autossh-tunneling into a box to finish configuring it because the connection will die as soon as I leave the room.
• coroutines != threads
• I should make sure my demos work before running them.
• If I encourage people to use any legal means necessary to obtain flags for the haxathon, they will learn my schedule and come in to my room when I’m not there to attack my computers physically.
• I should lock my computers when not in the room.
• I should make sure I’m in the terminal for my local machine, and not root on the server with a dozen other people logged in, before typing, “poweroff.”
• 50 lines of HTML is worth more than 500 lines of PHP.
• Just because I’ve rooted the department’s linux servers does not mean I can kill a hundred errant processes that are sucking up all the CPUs.
• Trying to fund awesome is impossible, because awesome people fund themselves.
• I should just write my own build scripts and stop wasting time trying to adapt other people’s build systems to my own projects. Have lua? Good to go.
• DNS is everything to Active Directory
• Planning on doing LDAP Auth? Actual_Time = Initial_Time * 10.
• Ada has multiple packages representing strings. Good luck!
• Those who can’t do are still making policy. Policy making is still a good indicator of technical ability. +
• There is a small percentage of people who still add large quantities of value with relatively small amounts of technical knowledge.
• If I seek to inspire underclassmen to be more like myself, I should remember that I’m a self-centered asshole. +
• 24gb is not enough disk space for my win7 VM. This is three times more than all my linux VMs. 8gb is enough space for my linux VMs.
• DOS executables should only, ever, always, under all circumstances, without exception, be debugged in DOS. Use DOSBOX and find something similar to debug.com. This was a very dumb mistake.
• I may be able to single-handedly beat a bunch of underclassmen in a CTF, but we’ll still score better if we work together.
• Installing Mac OS X on a macbook without the original install discs is like trying to install Windows 7 on a VAX. Good luck with that.
• There is a tendency to think that people who, “work hard,” and do well in CS classes will be able to comprehend, manage and accomplish technical tasks despite their relative knowledge in all things technical. Fight this urge. They usually think python is really cool and are interested in learning linux. +
• It’s worth taking the time to explain to someone the reason task X is, “Easy,” to you is because you spent three weeks struggling to figure out how to accomplish it two years ago.
• Stop trying to do everything in C. No one cares. +
• Those who post to reddit.com/r/programming, r/netsec and r/reverseengineering are mere mortals. I’ve posted there, so obviously we’re talking falliable people.

That seems like enough for now.

This is in response to an email I recently received (edited a bit for clarity)

With our current resources we can test passwords to their hash in fractions of a second allowing for well resourced groups to test thousands of passwords every second. This means, given enough time and resources, you can crack any password within a reasonable length and as you increase length you increase the likelihood of people resorting to identifiable patterns in order to remember it.

Solution idea (not unique but not used from what I can tell): Use the hashing function 1000 times on the password. The hash is not any more secure but the time to brute force would change from hours to years. From what I can gather online I heard that multiple hashing creates larger hashes which lead to collisions. This doesn’t make sense to me because I created the example below and I don’t see how it would lead to a change in collision frequency. I do understand that it would guarantee someone the opportunity to “know” the size of the input and do 999 hashes to find the final but considering the size of the hash and the fact that it still doesn’t give you the original input I fail to see how it would matter. Additionally, if there is something I am missing about the collision frequency increasing could we not add a different salt between each function … what are your thoughts?

Continue Reading »

This post really isn’t up to the standard of most others here. However, there comes a time when writing anything is better than nothing. I’m also glazing over a lot of details that would be important in implementing a Symbolic Execution Engine.

I am interested in the discovery of memory-corruption vulnerabilities. The two often-used methods for finding these vulnerabilities, fuzzing and reverse-engineering, are producing fewer results, and some people have stopped looking for memory-corruption vulnerabilities altogether. As our mainstream software is coded to higher, and more secure, standards, the identification of these vulnerabilities is becoming harder, and we need new methods to find them.

Enter Symbolic Execution. I’m still learning about this method of vulnerability identification and implementing it into rop_tools (source no longer available), but I thought I would share the basic concepts with you. Know that a joint effort between UC Berkely, Carnegie Mellon and the College of William and Mary has brought us BitBlaze, an academic pursuit using much of the technology I’ll be covering.
Continue Reading »

A couple weeks ago I posted about rop_tools, a tool for quickly finding a variety of rop gadgets in x86 ELF binaries. Well, I decided rop_tools needed an awesome scripting interface, and a couple of weeks later rop_tools emerged into a pretty powerful tool for scripting elf disassembly. Hacking together a disassembler (we’re going to refer to the front-end as the disassembler, not the actual “I’m making sense of bytes” library as the disassembler. Yes, I know some of you are having brain aneurysms right now) in an hour isn’t all that difficult anymore. In fact, I did one tonight. Let’s take a look at the output first.
Continue Reading »

This post is about a new tool I’ve been working on, rop_tools. This is a tool for working with rop gadgets in ELF binaries (currently only 32-bit). But first I’ll talk about the reasons why I wrote the tool.

I was recently working on exploiting a binary in linux. This binary was small, and I needed all the gadgetry I could find. I turned first to msfrop, but it wasn’t hacking it. I needed to look 2, 3, 4, any arbitrary number of instructions back. I was interested in not just ret gadgets, but gadgets that jump to registers and call registers.
Continue Reading »

I read an article last night (this one in fact) which included the following sentence:

“That said, it is no longer secure to hash your passwords with MD5, much less when it is unsalted.”

I cringed. I understand this sentence comes from a common misunderstanding of what security a cryptographic hash brings to your password protection scheme. Today, we’re going to try and understand it. A most basic understanding of password cracking is assumed.
Continue Reading »

This post is not a class on assembly. It is about a tool I use and hope others will find useful. An understanding of x86 assembly will help.

What is the RAVM, and why create it?

Learning how programs work at the assembly level is crucial towards gaining a holistic understanding of modern day computing. While studying Computer Science at the United States Military Academy, I was introduced to a fantastic piece of in-house developed software: the MARC and MARASM (available publicly here). The MARC is a virtual 16-bit CPU programmed in ADA. When paired with the MARASM, an assembler for the MARC, cadets can write, assemble, and run assembly programs with a simplistic toolchain.

The MARC is a perfect example of using simple applications geared towards education to teach concepts, not features. Students trying to learn new concepts need tools that just work. I wanted to borrow the concepts of the MARC and create a piece of software which could be used as a stepping stone towards x86 assembly. More specifically, I wanted:

• A more comprehensive, but not complicated, instruction set which more closely mimicked an x86 instruction set.
• 32-bit, little endian words.
• A way to help students visualize what was happening in memory while their programs were running.
• A code base programmed in C, making it more accessible for expansion and hacking by others.

With these goals in mind, I created the RAVM, the Rainbowsandpwnies Assembler and Virtual Machine. The RAVM comes with three parts: assembler, disassembler, and virtual machine. Here’s how you can grab a copy of the RAVM in Ubuntu:

sudo apt-get install git build-essential libncurses5-dev
git clone git://github.com/endeav0r/ravm.git
cd ravm
make

Continue Reading »

This post is a basic explanation of the concepts behind sending/receiving messages with PGP. This is the basic information I want someone to understand before I start communicating with them. These explanations are fairly simplified.

Infeasible means it is very, very difficult to do something. In cryptology, this usually equates to something along the lines of, “It’s possible with known algorithms and the expected advancements in hardware, but it will take thousands/millions of years.”
Continue Reading »

I just came across this post talking about a reflective XSS attack on google that only worked on IE 6/7. I’m going to make an assumption and assume this is due to Internet Explorer 8′s resistance to reflective XSS. I also came across this issue about a week ago and thought I would share some findings.
Continue Reading »

I know this talk took place at Shmoocon, and though I was not able to attend it, I just stumbled across this write up of the material covered. I believe it’s time to discuss a project of mine from a couple years ago: The Boot and Pwner (affectionately named The Bwner). I’m tired, so we’re going to keep this brief.
Continue Reading »