On Thu, 21 Jan 2010 09:09:22 -0500 Ted Unangst <ted.unan...@gmail.com> wrote:
> On Thu, Jan 21, 2010 at 5:55 AM, Tomas Bodzar > <tomas.bod...@gmail.com> wrote: > > On Thu, Jan 21, 2010 at 9:42 AM, Tobias Ulmer <tobi...@tmux.org> > > wrote: > >> - ability to research stuff yourself, without asking on a ml > >> - etc > >> > >> Your question is naive. If you were up to it, you wouldn't have to > >> ask the equivalent of "How do I become an awesome hacker?". > > Very true. The one thing you didn't mention, and may not be obvious > to an outsider trying to get in, is go to a conference. There's a > cheap local one everywhere (ruxcon, toorcon, shmoocon, ccc). Just go > and see what tools people use (but don't talk to anyone unless you're > dying to be embarrassed by how much more a 16 year knows than you :)). > If you can't do that, the speakers have blogs. Read them. > > > There is similar manual available :-) > > http://catb.org/~esr/faqs/hacker-howto.html > > Like a lot of his writing, it's mostly crap. I stopped reading after > this. > > "Real hackers call these people crackers and want nothing to do with > them. Real hackers mostly think crackers are lazy, irresponsible, and > not very bright, and object that being able to break security doesn't > make you a hacker any more than being able to hotwire cars makes you > an automotive engineer." > > For the purposes of our discussion, reversing drivers, turns out that > those naughty "crackers" are the people with the best tools and skill > sets. Reversing a driver is like reversing skype, only about 100x > easier because even the evil driver writers don't try that hard to > obfuscate their code. > I agree with Ted completely. One can learn a great deal from the so called "crackers" and they do have some amazing methods. The key to remember is, "crackers" tend to target a particular subset of an executable such as copyright protection, while in contrast, full reverse engineering of an executable intends to have (more) complete comprehension and coverage, such as documenting unknown hardware. At present, James only asked the question of "How?" but skipped over the far more important question of "Why?" I've been a DataRescue/HexRays customer for over a decade, and I have a full licenses for the IDA Pro disassembler and the HexRays decompiler. I am certainly not "great" at reverse engineering, but I can usually do well enough. When I see the constant complaints from the open source world about closed hardware, in particular nVidia, my personal thought processes is very consistent... 1.) Get Angry. 2.) Say to myself, "I could fix this," since disassembling and/or decompiling the closed source nVida drivers is certainly possible. 3.) I ponder how long it would take to do, and how much time I would sink into supporting it. 4.) And finally I get to the rational conclusion; I SHOULD NOT HELP A HARDWARE VENDOR WHO REFUSES TO RELEASE DOCUMENTATION! The reality of "why?" is truly ugly; If I spend my time supporting undocumented hardware, then I am only encouraging vendors to refuse to provide documentation. It actually makes more sense to throw away the undocumented hardware and replace it with well documented hardware. As you can see, the challenge of getting something to work is not the most important consideration. The most important thing is the precedence you set by helping hardware vendors to remain closed. James would do more good by "stomping" on the device as he mentioned, taking pictures of the destruction, putting up his poor experience up on a blog, and mail the link to the VP of Marketing at the vendor. Being nice with vendors seldom works. -- jon
