About Punkcoder

I am a Software Developer with a passion for Security, ALM, Agile, and Coding Practices. I have been working in .NET as a developer for over a decade, a network admin for years before that. I have worked for large companies and small ones, many that you would recognize some that you probably interact with. I am opinionated and deeply curious about the world. If you have a problem there is a good chance that I would be interested in hearing about it. More than that I want to help others, mostly because I believe that helping a single person raises the quality for everyone.

This is here instead of ads...

Please Show Some Love...

Chall Profiles



Blog Posts

New Job and the Internet

Published On: Dec 15, 2017

So it’s been a long time since there has been an update.

Prairie.Code() 2017

I wanted to give a big thumbs up to everyone who came out to see me speak at this years prairie.code(). We had a good time talking about Application Security and the joys of softwareconsulting. To everyone out there who missed it this year, You should get on it… see you there next year.


After some heavy contemplation, I ended up leaving my position at BlueBolt, Inc. There comes a point where you realize that because of various forces that you are no longer offering the same level of value that you once were.

Since then I have taken up a developer position with some security tasks as part of my new position with 10-4, coming on about two and a half months into the job and I am finally starting to feel like I’ve got a better handle on the work that they are doing.

Net Neutrality

This one came down the pipe yesterday and the paint isn’t even really dry on this one, so I really can’t say that there is a whole lot to talk about but I am working on some things that might be helpful in the future fight. If you are interested you can find out more infromation here, as it will be better kept up to date. https://github.com/punkcoder/NetNeutrality-BlockList

Rebuild CentOS Environment

Published On: Aug 21, 2017

Today as part of one of the projects that I am working on we needed to rebuild an environment and the hosting provider wouldn’t give us the pieces that we needed, so with a couple of quick min I managed to build a quick script that I thought that I would share. The problem is that we have a client that we are doing work for an one of the modules on thier site isn’t behaving as we would expect. So the first step in this process was going through and making sure that our environment matched as much as possible. We talked with the hosting provider and they were more than happy to sell us another environment.

First I had to get the infromation about all of the packages installed on the server, and where they were coming from.

yum list installed > installed.txt
yum -v repolist > repolist.txt

Once this was done it was easy enough to parse out the infromation and push it to build a build script.

import io
import re

def build_repos(output):
    file = open('repolist.txt')
    print('[+] Reading from the repolist file...')
    repoFileName = ""
    output = output + "# installing repos\n"
    for l in file:
        if l.startswith("Repo-baseurl : "):
            link = l.replace('Repo-baseurl : ','').split(' ')[0].strip()
            output = output + "sudo yum-config-manager --add-repo " + link + " \n"
    print('[+] Writing out to the install.sh')
    output = output + "\n\n"
    return output

def build_install(output):
    file = open('installed.txt','r')
    print('[+] Reading from installed packages file...')
    output = output + "# installing packages \n"
    output = output + "sudo yum install"
    finder = re.compile(r"[0-9]{1,3}:")
    for l in file:
        if l.startswith("Loaded plugins:"):
        if l.startswith("Installed Packages"):
        alllineparts = l.split(' ')
        lineparts = []
        for item in alllineparts:
            if item:
        if len(lineparts) > 2:
            package = finder.sub("", lineparts[0].replace('.x86_64','').replace('.noarch',''))
            version = finder.sub("", lineparts[1])

            # Apparently the MariaDB people are not friendly with old versions
            if (package.startswith("MariaDB")):
                output = output + " " + package + " "
                output = output + " " + package + "-" + version
    output = output + " --nogpgcheck"
    return output

def write_file(output):
    print('[+] Writing install of packages to install.sh...')
    outputfile = open('install.sh', 'w')

output = ""

output = build_repos(output)
output = build_install(output)


At the end of the process I ended up spending more time waiting on the CentOS iso to download than processing and building a build scirpt. Pretty useful stuff. At this point I am trying to figure out if it’s worth the effort for syncing up the configurations, or if I should just use this as a one off.

Anyway thought that I would pass this along in the event that someone finds it useful.

DEFCON 25 Wrap Up

Published On: Aug 7, 2017

Another DEFCON down and I am still trying to process all of the infromation, I love the confrence becuase everytime I go, I end up with more questions and more things to look into than when I went. Overall I would say that the theme of this years confrence was chaos, there were alot of improvements over the past couple of years, but everything seemed a little scattered. This year there was more than enough seating in all of the main tracks, however they were so far apart that you had a tendency to stick close to one of the tracks that had more of the talks that you wanted to see.

One of the better talks that I sat in on was the talk “The Brains Last Stand” which is already available here. But there were alot of other really good talks that I will try to track as they come online. But by far the winner was a talk on digital archeology… it was a great talk and I will try to link to it once it goes online.

I ended up getting into two of the workshops which were amazing and I really enjoyed the work that I got to do. I got a lot out of it, one of these years though I really need to dig deeper into the villages. For next year, I think I will only do one of the workshops if possible, it just ends up taking too much of the confrence time.

Bravo to all of the organizers putting everything together, you all do an amazing job year after year, getting the best confrence together with the most passionate people. I will see you all again next year.

Everyone Can Code

Published On: Feb 24, 2017

There is an ongoing movement to try to make software development and coding available to everyone. I completely understand where people are coming from, giving someone the ability to feel the power if bending a computer to their will. I understand the desire to have everyone participate… But I don’t think that anyone has followed through with the real question…

Should everyone be a programmer?

I know that this entry is going to end up coming off elitist, usually this is the argument that comes out when you try to suggest that something is just going to be outside of someone elses skill set. But lets break this down in a way that we can make sense…

In 2012, 3,328 people were killed in distraction-related crashes. About 421,000 people were injured in crashes involving a distracted driver.

Programming is hard. Programming requires focus and attention to detail. It requires thoughtful planning, to do it right. The above statement is a point where people are doing something that they know could cause the death of themselves and others, in a task that they do every day, simply because they through that their hair, cellphone, or newspaper were more more important than the ton of metal that they were driving. Assuming that not everyone that drives distracted is going to die every time that they do it, it’s safe to assume that the number of people who do it is much higher than the statistics provided.

For years I have heard people who are super proud of the fact that they didn’t need a degree in computer science and are doing just fine working as developers, and sometimes thats the case. Occasionally you find someone who really just gets it, but more than likely these were people who were drawn to computers in a way that they don’t teach in school. But more often than not we see that there are people who were never really trained, still super proud of their work, who are fucking it up for those of us who really do know what we are talking about. One of the most important things that my college degree taught me wasn’t the ability to write code, I could do that before I walked in the door. It was the ability to look at a problem and understand the inherent problems that exist there in. The ability to spot a good idea from a bad one, and the ability to look at something that is hard but doable.

In the end it is important to find those people who do have the flare, because we do need people, smart people, to fill roles. This is already a problem and with the declining state of education in the United States, paired with the general repulsing of reality that seems to be going on right now. But for the love of god, just because you built a login page doesn’t make you a programmer, neither does moving a turtle around a screen.

Negative work

Published On: Dec 29, 2016

Every once in a while you get the opportunity to work with people who really make the process of writing software really nice. People who know the right patterns to build the right type of software, those are the projects that are almost over as quickly as they start, if you have never had the experience of working with one of these people you are really missing out… but this post isn’t about them.

This post is about the people whose contribution to a project can be felt in a negative way long after they are gone. These are the people who leave little treats all over the code base just waiting for someone to trip up on their code. The find the worst parts that you have been trying to phase out and make them the core components of their new work. They are the people who never submit code reviews, the people who never right unit tests, the developers who think that they should just write the bare minimum needed to get the code to execute then they call their work done, assuming that the person who is going to be dealing with their code when it goes to production will be long gone.

In the past I have worked on projects where the mentality is that everyone needs to be working, so when there is availability they move developers to projects to make them chargeable. The problem is that you never pick up good developers this way, why? The answer is simple, good developers are usually struggling to keep the broken project that they are working on together. Talented developers get into a habit of moving from one fire storm to another in the consulting world, because of their skill they usually demand a higher bill rate which means that when things are going well most businesses see them as the first thing to cut, since they are so expensive. At least thats how it works in the consulting world. But I digress…

The problem is that when you take a bad developer and add them to a system that either has a lot of problems (that are in the process of being fixed) or is in the early stages. Both of these are extremely dangerous in the fact that their impact unchecked can have disastrous consequences downstream… take this as an example found in the code of a peer.

    var loadIndices = function() {
        indexFactory.get(function (data) {
            var firstIdx = true;
            data = data || {};
            data.indexDetails = data.indexDetails || {};
            angular.forEach(data.indexDetails, function (data) {
                data.isOpen = firstIdx;
                data.isDisabled = false;
                indexFactory.getFields(function (returnData) {
                    data.fields = returnData.fields;
                }, data.indexName);
                firstIdx = false;

Example #1: Wait so where is data scoped ???

The reality is explained in the breakdown of time for another item that was included in the same project.

Time for developer to do work: 16 hours
Time for me to code review: 1 hours
Time for developer to update bad code: 3 hours
Time for me to track down bug that slipped past: 4 hours
Time for me to track down bug related to settings not being configurable: 4 hours
Time for me to change Dictionary<string,string> to message: 15 hours

Example #2: Actual time spent cleaning up a poor design choice ???