Written Oct 8 - 26, 2008
Research Done Apr 27 - May 25, 2008
Reverse Engineering 1 version 0.1
[sig]
Linux Kernel drivers are very important this year and will continue to be in the coming years. Multiple kernel driver projects are underway and multiple methods are being used to develop them. As a software developer and hacker, I find that reverse engineering is one of the most important methods in writing kernel drivers for devices that currently lack open source drivers. Whether the method is snooping in on communication, brute forcing data, or analysis of driver state, reverse engineering tactics are employed. In this essay I will be reverse engineering a binary kernel driver, which is protected under copyright law as a fair use of copyrighted material. If you feel that I am violating your copyright during the production of this, please feel free to contact me and I will be glad to discuss this. Note however on the other hand that currently several Linux copyright holders consider binary blobs to be violations of their GPL copyright. These issues are connected and yet immaterial at this point. Let's just write the code.
Read more »
jvoss@altsci.com
June 2, 2008
Can I do base N math without zero? Of course. We just pretend that zero doesn't exist. Let's do base 10 without zero.
1 2 3 4 5 6 7 8 9 11The first thing I notice is that there are only 9 in the first set and no ten. So we end up skipping 10. it becomes a base-9 setup, right? 11 is the 10th number. But 11 means 10 * 1 + 1. If it's base 9 it's 9 * 1 + 1 = 10. Does this make sense?
Thesis: It is possible to create a valid mathematical representation of numbers without the use of zero.
The roman numeral is base 10 without a zero, right?
i ii iii iv v vi vii viii ix x xi xii xiii xiv xv xvi xvii xviii xix xxThe above does make sense. Each row has 10 and each row makes sense. Read more »
April 22, 2008
Updated: May 24, 2008
No source code yet.
This lecture was given at LinuxFest Northwest 2008. Due to issues with transportation, I skipped into a demo of how to write some Python code and finished by telling everyone the url of my TCPDump Watch. I wrote the hard disk encryption gui I had meant to on the bus (in 1.5 hours) and was able to give a demo.
If you want I can read this list of todos for the next hour OR
I can post it on the board and we can start working on them together.
Learning to code requires a project, a set of source code, and an aha moment.
Guess what we've got right here and now?
Who here thinks we can write 100 lines of code in an hour?
1000 lines?
How about 5000 lines?
jvoss@altsci.com
jvoss@myuw.net
April 18, 2008
AltSci IAX2 0.7
[sig]
AltSci IAX2 0.6
[sig]
UPDATE May 24, 2008
I have done a mildly thorough investigation of 1.4.19.1 (the fixed version) and I understand their solution (verify a pseudo-random call number). The solution is as good as I recommended. It does not solve the non-spoofed DoS attack since the attacker can use the call number it receives from the accept packet, but it does make the spoofed DoS attack much less useful (1:5 amplification is practically worthless). I consider this grevious security bug to be fixed. I have not tested backwards compatibility of devices and software versions. I plan to test whether this can be recreated via uncommon use cases such as psuedorandom guessing, sending random commands, etc. I hope that Asterisk will accept my apologies for releasing the exploit before they had a chance to respond. I plan to disclose all future vulnerabilities full disclosure after a timely opportunity for the vendor to respond. I encourage all other security researchers who use my tools to release the vulnerabilities that they find in a similar manner for the benefit of the community.
UPDATE April 24, 2008
Asterisk has responded to the release of my second exploit and framework with a set of patches to SVN. They have made the bug report above publicly available which pleases me. I haven't tested this to make sure that it isn't vulnerable, but I can assure you that I will. I will also spend time to see if their patch is backwards compatible with other versions of Asterisk and soft phones. I applaud Asterisk for their work toward fixing this obvious flaw. Together I believe that we can write and test a good VoIP protocol.
