endeavor

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?

Read More >>

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.

Read More >>

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.

Read More >>

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.

Read More >>

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.

Read More >>

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

Read More >>

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.”

Read More >>

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.

Read More >>

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.

Read More >>

The talks I plan on attending, in chronological order: