Introduction Continuing the series of summarizing the themes in “Secure Coding in C and C++” by Robert C. Seacord, we will discuss freeing pointers. The title of this section is specifically about setting to NULL after calling free, but this post will cover a lot more than that. Here we will discuss the problems with forgetting to free, functions whose return value needs to be freed, and freeing without allocating/double free.

Introduction Series on summarizing themes in “Secure Coding in C and C++” by Robert C. Seacord, part 2. Find part 1 here Always null Terminate (Part 1). We are currently going through this book in our work book club and there are a lot of good themes that seem to be threaded through the book. These are my notes, thoughts, and summaries on some of what I’ve read and our book club have discussed.

Introduction Welcome to the next series, summarizing themes in “Secure Coding in C and C++” by Robert C. Seacord. We are currently going through this book in our work book club and there are a lot of good themes that seem to be threaded through the book. These are my notes, thoughts, and summaries on some of what I’ve read and our book club have discussed. This is written for an audience that has a broad overview of security concepts.

Introduction For this episode of bad analysis, we are going to be looking at word frequency in passwords. Overall this isn’t terrible analysis, but what makes it bad is I’m just looking for the first occurrence of a dictionary word in each password. This will miss a lot of words in passwords. Additionally we will miss words because: Only the first dictionary word in each password is used Only American English words found in the Linux American English dictionary are used No common replacements are used for numbers or symbols (all of those are just blanked out) No common misspellings are corrected Plurals are considered unique words We are missing a lot of words in these passwords, but that is why this is bad analysis.

Introduction Next up in bad malware analysis is comparing the size of a file to the output of of the command strings. The idea here is that malware may contain less strings per KB than benign binaries. This would make logical sense as many malware samples are packed, encrypted, and/or stored in the data section of the binary, to be extracted later. This is done to help obfuscate them from hash signatures.