It is also funny you mention Dino Dai Zovi. I am actually trying to enter the CTF competition he is judging @ nyc lol. http://www.poly.edu/csaw-CTF
I was just concerned about the RE side. While we do get to have teamates, I hate the feeling of not being useful; In this case, with RE.
I pester Dino from time to time on email and I can tell you this, he is a really cool guy as is HD Moore, Dave Aitel, Thomas Ptacek, Charlie Miller, Dean DeBeer (another Polytech judge I believe), Ivan @ Core Security. Geez, I wonder who I haven't pestered within the last decade.
One of the things I've found with regards to "the bughunters" is, it is a very tight-knit, closely followed bunch. Now I don't mean tight-knit in the sense that everyone is always hanging out with each other, what I mean by that is when you get involved, depending on who you are, its easy to shoot off an intro to a heavyweight like HD Moore in a respectful manner: "Hi my name is such and such and I've been into RE for some time... I've been reading your work for some time and I'd like to ask you a question or two..." Most are kick ass cool and will actually give you pointers (again depending on who you are, who you know and your gift-of-gab).
As for making a name for yourself "finding something cool", this is what I have my computers do in their spare time (wow sounds almost as if they're humans doesn't it)... Right now I have 4 fuzz stations 2 Windows machines 1 Linux 1 NetBSD station. On my Windows machines (one is 2K3 one is Win7 Ultimate) I run Pai Mei, protos, Klocwork and beStorm for fuzzing for ONLY the top 20 software vendors' applications (Apple, Oracle, MS, SAP, IBM, CA, etc). I pass results to and from my nix machines often with NetBSD doing netflow analysis for network protocol based fuzzing.
While the set up is cool and took some time, the issue is, what the heck to do with all the information I get afterwards. You see, triggering all sorts of bugs isn't a problem, its understanding the program's flow/control/options during the debugging and analysis stage. Hence learning full-blown Windows debugging for me (remember, I posted I understood *nix and I am very comfortable running gdb, etc.).
So few things:
1) Pick your poison Windows/Nix (each will be time consuming)
2) Immerse yourself in not only Assembly, but debugging
3) After your comfortable with debugging, immerse yourself in reversing
4) Refresh yourself with SYSTEMS administrationWHAT THE HECK IS HE TALKING ABOUTWhy the hell would he say Windows?!
Out of the immediate 20 people that come to mind, of those who aren't into security/engineering how many are using something other than Windows? Of the last say 5 companies you've dealt with, how many are all *nix shops?
Understanding how to reverse Windows' compiled applications is a royal PITA not to mention understanding debugging them. Because of the way Windows uses its DLL's, OCX's, legacy code, etc. its a lot more time consuming and "leet" to find bugs on applications. You have to familiarize yourself with a lot more programs to trigger faults, debug those faults, make a weaponized application to target the fault you found. The stakes are higher if you're trying to bypass DEP and ASLR because if you don't understand what they are and how the work, you HAVE TO go back and do a lot of reading.I DON'T REALLY NEED TO KNOW ASSEMBLY DO I?
Yes, you need to understand Assembly to the point where you need to KNOW what the stack is, what the heap is, what the registers are, what they do, how they interact, where they write to, where they push and pop to and from. Otherwise it's all pointless. There is no point and click "fault injection to exploit" program available. SYSTEMS ADMINISTRATION YOU MUST BE JOKING!@
Systems administration IS A MUST. Let's put an exploit into perspective here from a different angle. Using malware as an example, how many malware exploits "pop a rootshell" on a machine? Answer, almost .000001 of them do (don't quote that number!). Most malware end up owning machines using staged exploits:
1) This piece of malware will add an account (usually small space to execute)
2) The new account will download another piece of malware
3) The third piece of malware will punch a hole through a firewall if need be
4) etc. etc
From a systems admin/pentest perspective, you may only have enough space in your shellcode to add an account versus completely making a callback or listener. Do you think the effects are less from a penetration testing perspective?
You to client: "Well I was only able to create an administrator account on 99% of your servers..."
You to client: "Well I was able to jump in and out of your systems with a rootshell"
Notice that the bottom line is almost the same there? Anyway, RE'ing is cool and fun to learn, but it is a serious royal pain and unless you're going to dedicate ALOT of time to it, it will frustrate you. I do it as a hobby not because I have to in my role, but for the sake of understanding it a little better. It IS fun having all sorts of fun with applications but I ended up waiting far too long to take it serious.