Line noise

A technical blog for geeks covering everything from compsec to hardware hacking.

Men and Women with brooms!

Posted by: Brent York

Tagged in: Untagged 

Not too long ago we had a curling event at BSI. Curling was fun, but I think it's safe to say that many of us learned that night it's also extremely challenging. I personally can attest that it indeed confirmed for me that I'm so far out of shape it's not even funny :).

We didn't get any video or shots of games in progress unfortunately, mostly because I was remiss in letting people know I brought my Flip HD with me in the first place, but we did assemble for a final group photo:


So I got bored on the weekend...

Posted by: Brent York

Tagged in: hobby , fun , Electronics

... and I decided since I was stuck in the house (sick) that I might as well do something fun and useful, like perhaps make something :).

        Much like my blogging duties, my bench has been sorely neglected as of late. So I decided to make a DASA programmer for the AVR AtTiny16 microcontroller. After a few minutes of struggling looking at waveforms that looked kind of like this:


The shot heard around the world

Posted by: Brent York

Tagged in: Worm , virus , trojan , malware , Analysis

Viruses and vaccines seem to be all the hot topic lately ;)... Since I'm not a virologist, or a vaccinologist, I'm not overly qualified to discuss them except to say that I and my family have been vaccinated and we're fine. Instead of talking about the subject of viruses in the human body, for which I'm not at all qualified, I instead decided I'd segue into something more my style.

For the next few posts I'm going to examine with you the world of computer viruses, worms, and trojan horses. Hopefully after this we'll get into some malware analysis. I'll get back to the security series after this series.


Welcome back, in this blog post we're going to cover information disclosure vulnerabilities from a couple of different angles. This is the third post in the security blog series that I've been writing. For the previous one, click here .

In this day and age a company lives and dies on the information it holds. If your information isn't safe, then your company isn't safe in many respects. Information disclosure can be something as benign as giving away a list of services running on ports on one of your machines, to something less benign such as internal addressing map for your network, and at worst the release of your intellectual property or your trade secrets.


It slices, it dices, it juliennes fries!

Posted by: Brent York

Tagged in: Untagged 

Welcome back to the fourth and final blog post on the subject of reverse engineering code. Today we're going to be performing some surgery on binaries to change the way they work. You can get today's example here .

We've discussed how reverse engineering relates to debugging code , we've discussed the basics of reverse engineering a small program, we've discussed what reverse engineering entails. Now, lets talk about how this applies to security... Specifically in this case, bypassing code protections such as passworded access in a compiled binary program. Now I hear several of you security pundits out there screaming "Why are you teaching people to crack software protection?".


Hello, and welcome back to the third blog post in the reverse engineering series. In the last two I discussed why someone would want to reverse engineer software. I also gave an example of reverse engineering a small Win32 application. In this one I'm going to show you how to use reverse engineering to find ABEND situations in release software. If you missed the first two, they can be found here and here respectively.

For most intents and purposes you wouldn't analyze a whole program. Well, maybe someone would, but I don't dislike myself that much :). Instead, you would use techniques like we used in the previous blog post, with a smattering of lateral thinking to find the parts of the code you're interested in and you'd analyze those.


The doctor is in...

Posted by: Brent York

On your feet soldier!

Welcome back to the second blog post on reverse engineering... Lets get into the meat of it shall we? In this post we're going to take an executable and disassemble it. We're then going to examine it to see if we can figure out what the program flow is, and come up with a very good idea of what the original source code looked like. If you missed the first one, you can find it here .

An example pack for this scenario is attached to this blog post. I'm not going to give you the IDA file because frankly, I want you to follow along and do this as an exercise :). You learn this stuff by doing, not only by reading.

I suggest you get IDA, MASM32, and WinDBG along with it's associated symbol package. You should also download the example pack and Notepad++ with the hex editor plug-in (available on the download page) as you will want to view the CPP files and the binaries.


010100110110000101111001 what?

Posted by: Brent York

I thought I'd take a slight sideways jaunt from the security list that I was going to post and bring up a topic that seems to have several people I know very curious and interested. That topic is reverse engineering. Fair warning, this topic will be covered in four separate blog posts (including this one) at a rate of 1 per week. After that we'll get back to the previously mentioned topics that I said I would cover.


While the topic is related to security (heavily so), and programming, we won't be concentrating specifically on security related examples. That's because while there's a plethora of security related examples we could go over, and reverse engineering is not just related to security.


Hack me, I'm yours!

Posted by: Brent York

Today’s article covers the concepts of fail closed and fail open design. These two concepts are extremely simple to grasp through example. So, let’s step aside and let the following short story teach us about fail-open systems design:

 


Developing secure software

Posted by: Brent York

 

    In today's software development environment, a developer would be extremely remiss if they did not consider security when designing and implementing applications. Unfortunately, what each developer considers secure programming varies widely. This is partly because when being taught software development (or for you autodidacts, learning it on your own), generally speaking most materials and courses do not cover the information required to make informed security decisions. On top of this, developers are human and do make mistakes, and lets face it guys and gals... we’re lazy. (Excluding Bulletproof developers of course! :)). That is, being human, we sometimes cut corners, and sometimes, they come pre-cut.


About Bulletproof

We've focused on building a company that can offer Atlantic Canada and the Maritimes the type of world-class IT service professionals that would otherwise only be available to the very largest enterprises. We're here when you need us. Read more...

Privacy Policy

Your Privacy is Guaranteed. We will never give, lease or sell your personal information.

Period!

Associate Login