Hello everyone; hope your summer is going well. I continue to await moving into our new home, so I'm not doing much in the way of testing or working on things for new blog posts. I should be all set up in my new home lab in about 6 weeks. In the meantime, I've been given some exciting opportunities that I'll be blogging about in the near future. Can't tell you what they are yet, but when I'm allowed to do so I'll be posting.
I received a quite pleasant and unexpected surprise Tuesday when I learned this blog won the Forensic 4cast Award for Digital Forensic Blog of the Year. I want to thank everyone who voted for me and congratulate all the other winners and nominees. I especially want to thank Lee Whitfield for putting the awards together each year. I know it's a lot of stress and work and I know the entire community appreciates your efforts.
Finally, I wanted to provide links to several blog posts of interest I've read recently. Harlan has been hitting quite a few home runs lately with his HowTo series of posts. I love posts like these, as they provide information you can put to use right now.
The most recent post on Harlan's blog is Programming and DFIR. He talks about why having at least a basic level of programming knowledge can be so helpful to a DFIR analyst. He points out how having that understanding can help you break down the goals of your case into smaller, achievable tasks. Furthermore, coding allows you to automate some of your regular tasks; something I think we could all benefit from.
I'll admit, I've promised myself on a number of occasions that I was going to learn to program. Back in high school, I had a Radio Shack Color Computer 2 (and later the 3) and I did a little BASIC programming. I later became interested in traffic crash reconstruction and I wrote a BASIC program to calculate a vehicle's speed from its skid marks, based on the distance of the skid, the drag factor of the roadway and some other data I've long since forgotten. What was cool was that after writing that little program, I didn't have to manually calculate the speed anymore. The point is, writing one simple little program automated the calculation process every single time. No more algebra. I never liked algebra anyway ;-)
I've known for a long time that learning to script/code could help me do my work faster and with more efficiency, but for whatever reason I just never have stuck with it. I've started trying to learn Perl and Python, but seem to always get lost and give up after a time. I'm going to give it another try, I think, and hopefully stick with it.
David Cowen has started a blog a day for a year challenge on his Hacking Exposed Computer Forensics Blog. He's been doing a DFIR career milestones series, as well as talking about the NTFS TriForce research he's been doing. The milestone posts, along with Harlan's post are what have inspired me to once again try my hand at coding. David's posts are always very interesting. Also, congratulations to him for his 4cast award for Blog Post of the Year.
Dan has a great new post on UserAssist artifacts in forensic analysis. His posts are always well researched and written. He does a great job explaining (in all his posts) why the material is important and how it can be of use in your investigations.
Adam has a very well researched and explained post on his blog on GPS forensics. He details his examination of Garmin NĂ¼vi 1490 and all the artifacts he found. I found the information presented on his research to be very interesting. I recently attended the BlackThorn GPS Forensics course and learned quite a bit, but I found Adam's post definitely helped me understand some areas better, especially with regard to the structure of the gpx files and their timestamps.
The SANS Digital Forensic and Incident Response Summit in Austin, Tx just concluded. I had to miss it this year, unfortunately. The speaker lineup looked phenomenal and the networking is always fantastic. Rob Lee and the SANS crew do a fantastic job with the Summit each year. Hope I can return next year.
That's all I have for now. Thank you again to all who voted in the 4cast awards, whether you voted for me or not. The awards are a great thing for our little community and I'm glad to see them continue.
Ken,
ReplyDeleteThanks for the mention.
I love posts like these...
Have you considered...
Commenting on any of the posts? Or perhaps offering up your own thoughts or processes, or suggestions for topics that you'd like to see addressed?
Have any of the posts proven useful to you?
... I just never have stuck with it
Programming isn't for everyone...not everyone enjoys doing it. However, even if you don't actually program, the principles and thought processes are greatly beneficial to analysts.
I would stick with python if you are starting out. has support for everything and runs everywhere.
ReplyDeleteThe best way to learn programming is to have a task to solve. learning for learning sake, as you have seen, often goes by the wayside when real life kicks in. if you have a work problem to solve with programming you can focus the efforts on solving that.
Along the lines of what Eric said...sometimes you don't have a choice but to learn to program. For something you need that doesn't exist like a simple batch file, forces you to learn right then. Add some stress like a deadline and I think the learning sticks faster. That's probably the best way to learn anyway when you don't have options in existing software to solve a problem :)
ReplyDelete(this comes from someone that loves batch files...)