Coding for Penetration Testers is a good read. I'm on my second pass, now. (I read through once, just to get a good overview, then a second time for in-depth study.) I haven't been disappointed by it, yet.

~ hayabusa ~

"All men can see these tactics whereby I conquer, but what none can see is the strategy out of which victory is evolved." - Sun Tzu, 'The Art of War'

I didn't read it, but looking at the table of contents it seems over half the book is just being used as an intro to various scripting languages. There are plenty of other books and resources that cover how to program in whatever language, I wish it chose a specific language like Python and explained how to use it for pentesting.

Eleven writes: I didn't read it, but looking at the table of contents it seems over half the book is just being used as an intro to various scripting languages. There are plenty of other books and resources that cover how to program in whatever language, I wish it chose a specific language like Python and explained how to use it for pentesting.

In the interest of full disclosure: I'm Ryan Linn's gf.

I thought the same thing when Ryan was writing it. I actually said almost exactly this, in fact. I said "You know, the world doesn't need yet another intro to <insert scripting language here>. Boring."

Fortunately, in addition to being a respected penetration tester, Ryan is a saint. Not only did he tolerate my (in hindsight) less than supportive feedback, he listened to me and educated me about a few things I didn't know.

So, here's what I learned:

1) While there is some Hello World, it's actually much less prevalent than I thought. Each "intro" is penetration testing focused. The text and the examples pertain specifically to scenarios where you might use them during a pentest. For example, building a port scanner using the language of choice at the end of chapter 1, using scapy to exfiltrate data using icmp in Chapter 2, etc. etc. etc. Even the context builds around examples of things you might find useful during discovery or recon, for example.

2) The book highlights the strengths of each language, noting that there are circumstances where one language is much better than another language at accomplishing a particular task. This got driven home when I tried to do the Ruby examples using my knowledge of Python... This isn't something I could easily gather from online resources specific to one language or another. Python doesn't say "hey, doing this in Python stinks, do it in Ruby, you'll spend less on Xanax and save hundreds of innocent kittens."

3) Having a broad knowledge base is very useful, because flexibility can make you better. Being a pro at Python is great, but if Metasploit breaks, Ruby is how you fix it. And, honestly, there's always something that will take seconds in a restricted shell that would take many minutes to work around with something more complex.

So, even though I have absolutely no interest in the financial success of the book, when I read the finished product, I genuinely felt like Jason and Ryan did a bang up job. And I'm both dreading and looking forward to their next book - whatever the scope.