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.

Chall Profiles

Developer

Canary

Blog Posts

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:"):
            continue
        if l.startswith("Installed Packages"):
            continue
        alllineparts = l.split(' ')
        lineparts = []
        for item in alllineparts:
            if item:
                lineparts.append(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 + " "
            else:
                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')
    outputfile.writelines(output)
    outputfile.close()

output = ""

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

write_file(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;
                vm.indices.push(data);
                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 ???

Best Of Defcon 24 Villages

Published On: Dec 3, 2016

So I am currently going through and reviewing all of the videos that have dropped from this years defcon, and since I am going through and watching them I thought that I would make an effort to currate the list. So with that I should say that there is nothing against your talk if you don’t appear on the list. It just means that you didn’t speak to me. The best part of DEFCON is that there is a free exchange of Ideas. With that said here is my list:

Biohacking Village

Carhacking Village

Crypto and Privacy Village

Hardware hacking Village

Packet Hacking Village