Lesson learned from Apple banning

Apple kicks out an iOS developer for showcasing a bypass of the code signing mechanism. Is this helping or hurting their cause?

I recently read an article about an iOS developer and hacker, Charlie Miller. It seems Charlie wrote a hack for iOS that infuriated Cupertino and they kicked him out of the developer program in retribution. It makes me ask, is Apple helping or hurting their cause by banning this developer for discovering weaknesses in the iOS platform?

As I read this article, an interesting memory came to me.

Early in my career I worked for a major Telecommunications vendor. At the time this company was pioneering early dial-up eBusiness solutions through a group that focused on State Government contracts.

This company supported many products, including a low cost dialup internet connections to college campuses around the U.S., the California Smog Check and Smog Check II VID (vehicle information database) and the California Department of Corrections dial-up pay-phone services that allowed inmates phone access to the outside world. At this point in the early nineties, they were aggressively expanding their lines, with nationwide Smog Check and Vehicle Safety programs with electronic result transmission in states outside of California and other novel ways to expand their State Government contracts through innovative, early eBusiness solutions.

One of the new systems was the California Firearms Information System .The CFIS system was built around an early All-in-One PC. The PC itself was a square box with an integrated color LCD with the motherboard and other components behind the display. The keyboard attached to the front of the LCD and could be detached for use. It was more or less a luggable, suitcase type of portable PC. It was a IA/86 system running Windows 95. The shell had been replaced so that it bypassed explorer.exe and loaded directly into a custom shell and login screen for the C.F.I.S. program. The CD and Floppy were disabled, and there were no USB or other ports that would allow an end user to bypass the custom login.

This caused us a lot of consternation when machines started being returned by dealers with applications like DOOM 2 loaded, or booting into Windows directly. The individual who was responsible for the design of the CFIS application expressed doubt that this was a software hack, and suggested that somehow the hardware was being hacked to bypass the security.

Eventually, another support engineer and I figured out how these gun-dealers were bypassing the security. If you shut down the system improperly, on a reboot Windows 95 would run a ScanDisk at DOS before loading Windows. If you were quick enough, you could pause the scan, which would give you a number of options, including to <Exit>. Exit did exactly what it sounded like, exiting the ScanDisk and returning you to the DOS prompt. Once there, you could open autoexec.bat file with Edit and modify the script so that instead of the custom shell executable, it would load explorer.exe, restoring full access to the system desktop to the end user.

It was really an elegant little hack. I discovered that I could trigger, pause and exit the scan and then load explorer.exe from the command prompt, and my co-worker assisted me with the final steps of entering the autoexec.bat (or maybe it was config.sys) and modifying the line that was calling the custom shell to load explorer.exe instead. this was something that had deviled and bothered the entire team for months since the release of the C.F.I.S. program. Young and naive, I thought the head developer for the C.F.I.S. program would be glad to hear that we had finally narrowed down what the issue was, so that it could be fixed.

Man was I in for a surprise.

The lead developer was rude, abrasive and disinterested in the discovery. I was young and looked up to this guy, and it was my first professional lesson that people who you admire professionally may actually be small minded, self-absorbed and easily threatened. Instead of moving my career ahead at this company like I thought it would, it actually helped cement my reputation as a trouble-maker who would not play by the rules. In retrospect, this helped launch my career by driving me to other firms that had more respect for out-of-the-box thinkers like myself - but at the time in my early twenties, it was very disappointing. (An interesting side-note is that the engineer who helped me fine-tune the hack also ended up working with me years later at Intel Corp.)

I think there are several lessons here.

Foremost, when someone comes to you trying to help, it is always good form to be gracious - even if they're pointing out something you missed. This can be especially challenging when the course correction comes from someone who seems less "important" in the scheme of things than you. It is easy to get caught up in your place in an organization - as a manager, or a lead or senior position. Frequently, I think we're afraid that if we let someone lower on the totem pole display more knowledge than us on an issue, it threatens our job security. I think the opposite is generally the truth, though. If someone reaches out to assist you and you treat them like dirt - it reflects horribly on your leadership skills. In my example above, the lead developer's response showed a lack of self-confidence and a defensive unwillingness to admit his fault in a design flaw. In the case of Apple, it illustrates the arrogance with which the company operates. Kicking Mr. Miller out of the developer program isn't going to stop him from finding exploits in the iOS platform. In fact, it is likely to make him work harder, and instead of working with Apple directly, Charlie will probably release those exploits to the wild in the future. Apple didn't do anything but make things tougher on themselves through their hubris.

From the other side, don't expect your heroes and idols to match your expectations. Face it, most people are neurotic balls of insecurity who are easily threatened and challenged by any perspective that doesn't align perfectly with their own perspective. Generally, their own perspective is that they're infallible, and everyone else around them are morons. Any evidence you provide to the contrary is likely to be judged as some sort of attempt to undermine their credibility and destroy their career - even if you're really trying to help them.

A great skill to develop is the ability address issues like this while handling the politics gently enough that people higher on the org-chart are not threatened. This is something I think I still struggle with to this day. We want to do the best thing for our organization or firm, but we have to make sure we don't upset or challenge someone higher up by inadvertently making them look bad (generally by solving a problem they can't).

What is your opinion, is Apple helping or hurting their cause by banning this developer for discovering weaknesses in the iOS platform? Do you have any personal examples to share? Let us hear your feedback in the forum.