What is the product exposure if you ship debug symbols?

At some point in the life-cycle of a product being developed it seems like every team ends up trying to decide if they should ship debug symbols with their product. On one side of the discussion are people who perceive that the crown jewels of the company are somehow at risk if the symbols escape from their office. On the other side of the discussion are people who perceive that having matching debug symbols delivered with the shipping product will help with solving the inevitable problems that arise in the field.

So, who is correct here? How much of a risk is there in shipping debug symbols?

My own opinion is that shipping the debug symbols for a release build of a product presents a very small degree of risk. I feel that anyone so inclined can reverse-engineer your product from the shipping executable files, and not having symbol information will not deter them. It may slow them down slightly, but not by a sufficient amount to warrant not shipping symbols.

Since this topic comes up so frequently I figured I would try and collect together various other points of view on the question. First stop; Google!

The quote below is from the project page of the CrashRpt library, found on the Google Code service.

I’ve received several comments/inquiries about shipping debug builds or debug symbols. You should never ship debug builds or debug symbols as they will not only take up more space on your CD/download/client’s workstation, but they will also make reverse engineering your code a trivial exercise. To be clear, what I’m suggesting is modify your release build configuration so that it generates debug symbols, saving both the release builds of your modules and their corresponding debug symbols in your source control system and delivering only the release builds of your modules to clients (as you do today). When a crash report comes in, you use the release build and debug symbols you archived, along with the minidump included in the crash report, to debug the crash.

Microsoft had published a technical article titled Generating and Deploying Debug Symbols with Microsoft Visual C++ 6.0 that goes through some of the options when consdiering if shipping debug symbols is appropriate for your product. From the article …

The first thing you have to do is determine whether you should deploy your debug symbols. In general, you should deploy symbols during most of your internal testing. This will give you better information to track down bugs. But before you deploy debug symbols to your customers, you should consider whether you want them to have access to that level of information about your application and whether they have the extra storage space. You also need to consider the type of customer you are targeting. Many software developers like to have debug symbols. Many end users would rather not use up their hard drive space for something they are unlikely to use.

For instance, Windows NT deploys debug symbols with the operating system. These symbols contain primarily function-level symbols and FPO records. Microsoft Office does not deploy debug symbols.

And then later in the same article…

Deploying debug symbols does not affect the performance or initialization of your application, but does impact available hard drive space. Debug symbols can take up some significant hard drive space, depending on the granularity.

Another terrific article I came across is Release Mode Debugging, published by ACCU in their Overload Journal. I would recommend reading the entire article to gain some perspective on the idea of having a single build for your product instead of separate debug and release builds.

The argument against shipping debug symbols is often that this will make it easier for competitors to gain access to the intellectual property that you hold so dear. While it is true that having the debug symbols (especially for internal private structures) will make the process of reverse engineering your software easier, it by no means prevents it. The application IDA Pro is a commercial disassembler and debugger that would make reverse engineering of any application possible. They call it The most advanced tool for Hostile Code Analysis, Vulnerability Research and Software Reverse Engineering.

Further evidence that a lack of debug symbols is no protection against reverse engineering comes from the article Reverse Engineering Hostile Code, published on the SecurityFocus web site. Anyone who believes that hackers are thwarted from decompiling or reverse engineering your software because they don’t have symbol information will surely change their point of view after reading this article.

In the end, it seems like shipping debug symbols or not is more a “feel good” issue for an organization than it is a way to actually address a security concern.

Use QImage to create a composite image (i.e. One image with another overlaid on top of it.)

qt.pngToday I wanted to combine two images of similar size to create a new image. The new image was going to be used for a toolbar button. I have purchased a set of commercial images in the PNG format for use on application toolbars. The set came with a bunch of overlay images that could be used to modify each of the base images. The overlays included things like arrows, warning signs, arrows, people, etc. My first though for using these images was to fire up Adobe Illustrator and just create a new icon by merging the base and overlay together. Then I realized that Qt could do the job for me at runtime, and with a little work I could dynamically overlay different badges on a base icon.

The code below can be used to construct a composite image. You pass in references to a base image and an overlay image. These images are used to construct a third image, and that is returned to the caller.

QImage createImageWithOverlay(const QImage& baseImage, const QImage& overlayImage)
    QImage imageWithOverlay = QImage(baseImage.size(), QImage::Format_ARGB32_Premultiplied);
    QPainter painter(&imageWithOverlay);

    painter.fillRect(imageWithOverlay.rect(), Qt::transparent);

    painter.drawImage(0, 0, baseImage);

    painter.drawImage(0, 0, overlayImage);


    return imageWithOverlay;

Here is an example of using this routine to create an image that might be used to represent something being transfered from a network attached machine.

    QImage baseImage(":/Resources/connect_pc_64.png");
    QImage overlayLogoff(":/Resources/overlay_arrow_east_64.png");
    QImage logoffImage = createImageWithOverlay(baseImage, overlayLogoff)

The two source images and resulting composite are shown below.

  1. :/Resources/connect_pc_64.png
  2. :/Resources/overlay_arrow_east_64.png
  3. Generated Composite Image

Computer Repair vs Auto Repair — Why they are very different.

Computer repair agreements may not always guarantee that you get the old parts back. They also may not guarantee that the replacement parts are new.

When I go to the auto repair shop the paperwork you are asked to sign before the work is started always has a box on it that you can check if you would like to have all of the replaced parts returned to you. And, you always get new parts put on your car unless you make specific arrangements to okay the use of a remanufactured part.

For a car there really isn’t a security risk associated with not getting the original parts back or using remanufactured parts in a repair. With a computer the story is very different. It is commonplace for people to store sensitive information on their personal computer systems. If the hard-drive fails and the computer needs to be taken into the shop for repairs it should not be acceptable for the company doing the repairs to keep your original hard-drive. After all, it contains all sorts of sensitive information that you did not have an opportunity to erase prior to the repair.

Right about now you might be thinking
Hey, it doesn’t matter to me. The drive is dead. No one can read it, right?
Well, you would be wrong. Companies that repair these drives do exist, and remanufactured drives are used for repairs of other customer computers.

Just imagine your surprise when the computer you just got repaired now has your neighbor’s hard-drive in it, and the shop didn’t even bother to erase their information before installing it in your machine. Now you have all of their data! Ouch!

Also, the repaired drive in your computer may actually be older than the drive you originally had. It may not be new at all. Given that these drives do have a manufacture rated MTBF (mean-time between failures) that seems to be very accurate, you may be in for another repair within a few weeks or months.

All in all, this practice seems unacceptable on many levels. My suggestion is that whenever your hard-drive fails you should destroy it yourself and should replace it with another one from a reputable supplier. And, you should always make sure the drive is new, not remanufactured!

Protect Sensitive Data on your MacBook Pro

One thing I am always nervous about is storing sensitive data on my MacBook Pro. Over the past few years it seems like there are stories popping up in the news about some organization loosing sensitive customer data when a laptop is misplaced. As someone who makes a conscious effort to have only one computer, I am concerned about storing my banking and tax information on a portable computer.

After searching for quite some time I finally settled on a solution that has been working very well for me. My criteria were as follows:

  • Data must be encrypted.
  • Storage device must be removable.
  • Data access should only be permitted once a suitable password has been entered.
  • Password must be required to access data after MacBook Pro comes out of sleep mode.
  • To meet my goals I am using a piece of software called Knox in conjunction with an ExpressCard/34 solid-state disk. I am currently using a Lexar ExpressCard/34 SSD with an 8GB capacity since that is what the local computer store had available at the time, about six months ago. Today it is possible to get a 32GB card from TRANSCEND, so the capacity is ever increasing! logotag.gif

    The card I store my sensitive data on is the Lexar 8GB ExpressCard SSD. It fits in the ExpressCard/34 slot on the left side of my MacBook Pro and is makes for a very convenient place to store all of my Quicken and TurboTax data files. Using Knox I setup the entire Lexar card as an encrypted filesystem.

WinQual Registration Head Aches

In order to digitally sign Windows drivers you need what Microsoft called an Authenticode Digital Certificate. The company I work is creating a number of drivers, so we had a need for an Authenticode Digital Certificate. The certificate would also be used to sign the Microsoft installer packages that we release to customers.

Being a cost conscious group we shopped around and identified two main sources for Authenticode digital certificates.

* VeriSign http://www.verisign.com
* Thawte http://www.thawte.com

Comparing the prices it seemed clear that the Thawte certificate was a better bet so that is what we purchased. Everything appeared to be fine until we tried to join the WinQual program. That is when I started asking myself the following question:

Question: When is an Authenticode Digital Certificate not an Authenticode Digital Certificate?

Answer: When you try and use it in the application process for joining the WinQual program.

In the last couple weeks I have been learning about the requirements to digitally sign Windows device drivers. My strategy has been to take the Toaster sample from Microsoft and try to duplicate all of the steps necessary to build a signed version of the driver. Naively, I figured it should be easy to replicate the steps taken by Microsoft to sign this sample program. Boy was I wrong!

It turns out that there is a utility called inf2cat or something like that. Microsoft recommends using it to create the category file containing hashes of the files you want digitally signed as part of your driver package. So, for me to replicate the Toaster sample signing process I need a copy of inf2cat. This tool is apparently only available to members of the WinQual program that Microsoft runs.

Okay, so I need to join WinQual. How hard could that be. I went to https://winqual.microsoft.com and learned that in order to joint he program you must submit a file to them that is digitally signed with your Authenticode certificate. So off I went to get an Authenticode certificate for my company. After a few google searches I came to the conclusion that VeriSign and Thawte are the two primary sources for these certificates, and Thawte is considerably cheaper. I purchased an Authenticode certificate from Thawte and a few days later the certificate was on my machine and it was time to make the membership request on the WinQual site.

I followed all of the instructions to digitally sign the required file using my new Authenticode certificate. Everything seemed to go smoothly until I tried to upload the signed file to Microsoft. Their web site kept saying that the file was not signed correctly. I went back to the main WinQual web page to try and find an answer to this problem. There was nothing there to help me solve this mystery so I went to the only other resource I could think of. That is the DDK mailing list archives at OSR. These folks have been doing Windows driver work for ages and if anyone knew what was wrong, I was sure the answers would be on their mailing list.

It only took one keyword search of the archives to learn what the problem was. It seems that not all Authenticode digital certificates are created equal, and Microsoft has a predilection to those minted by VeriSign. My new Thawte digital certificate would be just fine for signing my drivers, but it would not be at all useful in joining the WinQual program. It was beginning to look like I needed to buy another Authenticode certificate from VeriSign in order to join the WinQual program.

After carefully re-reading the WinQual page describing the ways to join the program I learned that you could also sign your membership request using something called a Corporate Identifier. It was a cheaper, less capable digital certificate that could be used to sign the file and join the program. This certificate could be purchased from VeriSign for $99.

I waited another couple days and the new Corporate Identifier finally appeared in my inbox. I followed the instructions to sign the file, upload it, and this time I met with success in joining the WinQual program.

So, instead of saving money by using the Thawte certificate I ended up spending roughly the same amount of money that it would have cost to just purchase the Authenticode certificate from VeriSign. The difference was that because the WinQual site was not clear on the specific requirements for using a VeriSign certificate I ended up wasting at least 2 or 3 days trying to join the WinQual program.

In the end it was clear that I should have purchased the “name brand” digital certificate from VeriSign.