Drew: The Security Geek

Note to Self

2006-12-06T01:42:00.000-08:00

I should probably also post about a bug's (or in Joel's terms "a case's") lifecycle, too. I sent out an email internally at work a while ago but I should probably follow up on that and post it for the intarweb to see, too.

I'll try to cover what fits my work environment and also what is generally true elsewhere.

I can find so many things to talk about to avoid trying to explain how the SRM works in Windows kernel-land, can't I? I've tried a couple of drafts, but it's not easy to just give the basic info instead of trying to explain the whole geeky picture. I obviously don't have the gift of technical writing. :-(

Bug vs Feature

2006-12-06T00:57:00.000-08:00

I recently read this and was appalled. Why would any company intentionally seek out testers who enjoyed "a good debate about whether something is a 'feature' or a 'bug'"? (Neverminding that the OP's final quoted remark didn't actually ever have end quotes. And also never mind why I was looking at that - just keeping my options open, but I'm way too stubborn to quit my current job yet.) What a *total* waste of time. I'd rather have someone on my team whose hobby was counting ceiling tiles. At least that's meaninful. To someone. I would guess.

Much to my chagrin (or in the case of the link, Ohio's), I'm in that situation now, though. I sat in a meeting with person X who claimed that to his/her mind a "bug" is something that takes a little time to fix and a "feature request" is something that takes more time. I'm beginning to wonder where American (in this case) software engineers learn to speak English.

If you're playing along at home, please use your own Google-fu to verify these common definitions as they apply to software:

bug - a software defect

feature request - I'm gonna have to break this down a little. It's evidently not immediately obvious. A feature is a prominent aspect of something. Hmm. Not a very solid definition. Google-fo doesn't really get me much in the way of a meaty definition for "feature request" or "software feature". I guess I'll just try to make up a definition. Clearly a feature isn't a bug, right? So a feature request IMO is a request for a design change. Further, it must be not because of a defect in the software or the design. It's a request for extra originally unintended functionality. E.g. "Please make my blender also function as an AM/FM radio so that I can blend tasty smoothies while I listen to my favorite morning shock jocks."

I'm not even going to touch the "is it a bug or a feature" debate. The only important question there is "what's best for the customers?" and if there's enough data there should be no argument.

So I've put off my screed on (the next links mostly suck - don't bother) DACLs/SACLs/MACLs and also MIC (new in Vista, though the idea's been around for a while) until next time. Unless I get sidetracked again.

Actually, I might get sidetracked. I think I might need to explain threat modeling and even more so the terminology used ("threat", "DREAD rating", &c.). I keep running into "define that term" roadblocks at work. Rather than invest in dead trees, I think I might blog it.

Strongly Considering Resigning . . . (and a bit of swearing)

2006-12-02T02:05:00.000-08:00

(No linkies in this one. I'm too pissed off to bother. Next up (really) - a little more on the NT object manager and an intro to security descriptors/ACLs.)

Ick!

After recent work experiences I'm very strongly considering resigning. (No - really. Very seriously. And wondering where I could go right now.) And wondering why I didn't apply for that Principal QA job at Symantec. Damn. That's right up my alley. And in the bay area no less. I'm such a sucker.

It doesn't seem to matter how many bugs I file. Nobody fixes them. (That's an exaggeration - out of the 100+ bugs open against our last release 2 or maybe 3 were fixed. The rest were punted to our new release. Forgive me please for exaggerating.) Even when I explain in *great* detail how to fix (step by step how to goddamned write the code) the bugs nobody bothers. Why do I do it? I really don't know any more.

It doesn't seem to matter when I find serious security holes in our product. I guess they'll be fixed in version 2.x . . . Maybe. If the customers are lucky. Or if that ever ships. I can only hope that customer X (that I don't think I can mention yet) *demands* a higher quality of crap than the current ESS anus spews. Maybe then quality will matter . . .

It also doesn't even seem to matter when I point out to our IT guy that one of our public-facing servers have *many* known vulnerabilities, at least one of which allows any unauthenticated attacker to shove arbitrary data onto the stack and overflow it. *grumble* That's almost surely exploitable and would give the attacker root on the box in our case. Worse yet, I hear that all of the accounts used to attach to those boxen use same/similar passwords. Our entire extranet is compromised. And maybe our intranet, too. Who's losing sleep over this? Maybe only I am. Goodbye, my sleep!

I'm this far from writing 'sploit code so that someone will listen to me: '-----'

I don't believe in ever writing 'sploit code. Ever. That's not only illegal (unless contractual and even then iffy) but immoral. But I'm at the point that I'm not sure how else anyone would ever listen to me when I say "this is a bug - please fix it ASAP".

Damn. Sometimes it sucks to be a (the only?) security geek at a "security" company. At an alleged "security" company, that is. Working on an alleged "security" product.

:-(

Shit! Part of me misses Microsoft . . .

(P.S. For anyone reading this internally at ESS, there are bugs filed. I can provide links if you can't find them.)

(P.P.S. Ray - about that alleged penetration tester who tried to attack us - EVERYONE who wants to take over a box knows about the app I used - it's been around forever. Please please please let me know what he tried. I think whatever it was it's severely lacking. I finally tried the most obvious test and found ways to break into all of out public-facing servers. This is *scary*.)

File under: What WebSVN should have shipped with for Windows.

2006-11-30T19:49:00.000-08:00

(Edit: adding links)

I recently deployed FogBugZ and got it integrated with my company's Subversion server. A piece of this was installing WebSVN so that the cool automagically-appearing links to sources and diffs would take users to useful web pages. I noticed the other day when I tried to diff versions of an RTF file that I got all kinds of formatting goo in my diff. That didn't make me happy. The solution was to set the svn:mime-type property on non-text files in our repository.

In the interests of community, I give you my batch file to automate those changes. It doesn't do the svn commit - you'll have to do that yourself or modify the batch file.

If anyone knows how to automatically have this happen on new files (autoprops is a per-client setting in the config file), please let me know.

----------snip----------

@echo off
'
' This batch file adds svn:mime-type properties on non-text files.
'
' NB: The lines with file extension and mime types must start with two apostrophes
' and must have spaces between the apostrophe and the extension and between the extension
' and the mime type.
'
' Drew 11/30/06
'
'' 323 text/h323
'' acx application/internet-property-stream
'' ai application/postscript
'' aif audio/x-aiff
'' aifc audio/x-aiff
'' aiff audio/x-aiff
'' asf video/x-ms-asf
'' asr video/x-ms-asf
'' asx video/x-ms-asf
'' au audio/basic
'' avi video/x-msvideo
'' axs application/olescript
'' bcpio application/x-bcpio
'' bin application/octet-stream
'' bmp image/bmp
'' cat application/vnd.ms-pkiseccat
'' cdf application/x-cdf
'' cer application/x-x509-ca-cert
'' class application/octet-stream
'' clp application/x-msclip
'' cmx image/x-cmx
'' cod image/cis-cod
'' cpio application/x-cpio
'' crd application/x-mscardfile
'' crl application/pkix-crl
'' crt application/x-x509-ca-cert
'' csh application/x-csh
'' css text/css
'' dcr application/x-director
'' der application/x-x509-ca-cert
'' dir application/x-director
'' dll application/x-msdownload
'' dms application/octet-stream
'' doc application/msword
'' dot application/msword
'' dvi application/x-dvi
'' dxr application/x-director
'' eps application/postscript
'' etx text/x-setext
'' evy application/envoy
'' exe application/octet-stream
'' fif application/fractals
'' flr x-world/x-vrml
'' gif image/gif
'' gtar application/x-gtar
'' gz application/x-gzip
'' hdf application/x-hdf
'' hlp application/winhlp
'' hqx application/mac-binhex40
'' hta application/hta
'' htc text/x-component
'' htm text/html
'' html text/html
'' htt text/webviewhtml
'' ico image/x-icon
'' ief image/ief
'' iii application/x-iphone
'' ins application/x-internet-signup
'' isp application/x-internet-signup
'' jfif image/pipeg
'' jpe image/jpeg
'' jpeg image/jpeg
'' jpg image/jpeg
'' js application/x-javascript
'' latex application/x-latex
'' lha application/octet-stream
'' lsf video/x-la-asf
'' lsx video/x-la-asf
'' lzh application/octet-stream
'' m13 application/x-msmediaview
'' m14 application/x-msmediaview
'' m3u audio/x-mpegurl
'' man application/x-troff-man
'' mdb application/x-msaccess
'' me application/x-troff-me
'' mht message/rfc822
'' mhtml message/rfc822
'' mid audio/mid
'' mny application/x-msmoney
'' mov video/quicktime
'' movie video/x-sgi-movie
'' mp2 video/mpeg
'' mp3 audio/mpeg
'' mpa video/mpeg
'' mpe video/mpeg
'' mpeg video/mpeg
'' mpg video/mpeg
'' mpp application/vnd.ms-project
'' mpv2 video/mpeg
'' ms application/x-troff-ms
'' mvb application/x-msmediaview
'' nws message/rfc822
'' oda application/oda
'' p10 application/pkcs10
'' p12 application/x-pkcs12
'' p7b application/x-pkcs7-certificates
'' p7c application/x-pkcs7-mime
'' p7m application/x-pkcs7-mime
'' p7r application/x-pkcs7-certreqresp
'' p7s application/x-pkcs7-signature
'' pbm image/x-portable-bitmap
'' pdf application/pdf
'' pfx application/x-pkcs12
'' pgm image/x-portable-graymap
'' pko application/ynd.ms-pkipko
'' pma application/x-perfmon
'' pmc application/x-perfmon
'' pml application/x-perfmon
'' pmr application/x-perfmon
'' pmw application/x-perfmon
'' pnm image/x-portable-anymap
'' pot, application/vnd.ms-powerpoint
'' ppm image/x-portable-pixmap
'' pps application/vnd.ms-powerpoint
'' ppt application/vnd.ms-powerpoint
'' prf application/pics-rules
'' ps application/postscript
'' pub application/x-mspublisher
'' qt video/quicktime
'' ra audio/x-pn-realaudio
'' ram audio/x-pn-realaudio
'' ras image/x-cmu-raster
'' rgb image/x-rgb
'' rmi audio/mid
'' roff application/x-troff
'' rtf application/rtf
'' rtx text/richtext
'' scd application/x-msschedule
'' sct text/scriptlet
'' setpay application/set-payment-initiation
'' setreg application/set-registration-initiation
'' sh application/x-sh
'' shar application/x-shar
'' sit application/x-stuffit
'' snd audio/basic
'' spc application/x-pkcs7-certificates
'' spl application/futuresplash
'' src application/x-wais-source
'' sst application/vnd.ms-pkicertstore
'' stl application/vnd.ms-pkistl
'' stm text/html
'' svg image/svg+xml
'' sv4cpio application/x-sv4cpio
'' sv4crc application/x-sv4crc
'' t application/x-troff
'' tar application/x-tar
'' tcl application/x-tcl
'' tex application/x-tex
'' texi application/x-texinfo
'' texinfo application/x-texinfo
'' tgz application/x-compressed
'' tif image/tiff
'' tiff image/tiff
'' tr application/x-troff
'' trm application/x-msterminal
'' tsv text/tab-separated-values
'' uls text/iuls
'' ustar application/x-ustar
'' vcf text/x-vcard
'' vrml x-world/x-vrml
'' wav audio/x-wav
'' wcm application/vnd.ms-works
'' wdb application/vnd.ms-works
'' wks application/vnd.ms-works
'' wmf application/x-msmetafile
'' wps application/vnd.ms-works
'' wri application/x-mswrite
'' wrl x-world/x-vrml
'' wrz x-world/x-vrml
'' xaf x-world/x-vrml
'' xbm image/x-xbitmap
'' xla application/vnd.ms-excel
'' xlc application/vnd.ms-excel
'' xlm application/vnd.ms-excel
'' xls application/vnd.ms-excel
'' xlt application/vnd.ms-excel
'' xlw application/vnd.ms-excel
'' xof x-world/x-vrml
'' xpm image/x-xpixmap
'' xwd image/x-xwindowdump
'' z application/x-compress
'' zip application/zip

' If svn.exe isn't in the %path%, bail out.
svn.exe help >nul
if 0 neq %errorlevel% (
echo You must have svn.exe in your path to use this batch file.
goto EOF
)

' The evil for loops that do all the work (including parsing this batch file).
for /f "usebackq tokens=1,2,3" %%i in (`type %0`) do (
if "''"=="%%i" (
for /f "usebackq tokens=*" %%l in (`dir /s /b *.%%j`) do svn ps svn:mime-type %%k "%%l"
)
)
:EOF

A Post Without Substance

2006-11-30T19:33:00.000-08:00

I keep either forgetting to write something here or I'm too busy/distracted/in need of non-computer-related activity that I've been ignoring my blog. :-(

So even though I don't have anything of substance to post right now, I thought I'd put this up. It's my latest get rich quick scheme. I was reading Joel's blog and I found inspiration. Pretend I'm E. F. Hutton. Here we go . . .

[drumroll]

I can get rich by shorting spam stock. Not only is it a foolproof investment, but I'll actually have a way to make money *from* annoying spammers! Sweet, eh?

Am I brilliant or what?

Yeah. I know: what.

So Finally Something About Security? The NT Object Model.

2006-11-07T21:48:00.000-08:00

I keep meaning to start a series abut security. At least on Windows (NT family).

First, I should start by explaining the object manager. Then again, let's let someone else do it. Adrian groks this stuff. Check it out:
http://channel9.msdn.com/ShowPost.aspx?PostID=73995

(off topic) If you enjoy that you may enjoy Adrian's explanation of the NT heap manager:
http://channel9.msdn.com/ShowPost.aspx?PostID=207162

And if you want to kill some trees, I strongly recommend this for anyone into how Windows does its thing:
http://www.powells.com/biblio?show=HARDCOVER:NEW:0735619174:59.99;show_locs=no

Tomorrow: a recap of what to know about the object manager as far as security goes, then an intro to access control lists (ACLs).
Day after tomorrow: I'm planning a dive deeper into ACLs - ACEs.

Please, someone, give me some feedback if you want to see how this relates to Unix, Unix-based systems (Linux, OSX, etc.) or to the NT predecessor (VMS (link is to Open VMS)).

Put Away the Crayons

2006-10-25T21:07:00.000-07:00

After that initial blue sky period which I prefer to think of as "huffing ether", we start to get down to the nity gritty. PMs drive writing functional specs. They *must* have buy in from dev and test, of course - t's that three legged stool thing). At that point, devs can ground the pm wish lists in reality and testers can try to find spec bugs before any code is ever written. Then simultaneously (ideally) dev writes up a more technical spec and test writes a test plan.

This is subject to a great deal of debate right now. There are many people calling for "agile development methods". Frankly, everyone I've ever known has used some of those agile methodologies whether they called them that or not. As someone focused on quality, I see the advantage in test driven development. And I've certainly led scrums in the past, though we didn't call them that. Whatever it takes to get a cohesive team building kick-ass software (just kidding with that last link). I'm not going to argue or belabor the point any longer. These things are as trendy in software as cargo cult efficiency methodologies are in *real* engineering.

While the devs and testers are busy trying to find ways to implement the master spec in their own realms, the pms try to guide them and start to push for schedule SWAGs (not those SWAGs, but these). Oh - and don't forget prioritization. Somewhere in this mess of people scurrying about, the pms drive prioritizing the work that will need to be done both in terms of the features set forth in the pm's (pms'?) spec and in terms of the actual work items for everyone involved (called out by dev and test in their docs).

Sometime soon after this, the devs and testers start coding. I'm not sure what the pms do at that point except keep asking more questions about schedule and priority. Oh - actually I *do* know. The pms do what they're infamous for - they try to push new features into the product. This is a continual process for them. It's why they're paid. Or why they seem to think they are. Frankly, feature creep seems like a sign of too many pms late in the cycle or too little pm thought early in the cycle to me. The venerable Brian Valentine is known within Microsoft's Windows division for the times during the product cycle when he declared that (my paraphrasing) "developers should fix bugs, testers should verify fixes and continue to find new bugs, and pms should get the hell out of the way". (Yes, any other fans of Patton out there might recognize this as being similar to "lead me, follow me, or get the hell out of the way". I leave it as an exercise for the reader to determine how close or distant BrianV was to/from Patton.)

Additionally, pms will drive cross-team initiatives. This is generally good news because it means that they're trying to make work for other teams and not yours. And if it's a pm from another team it's pretty easy to duck the work. Win-win for the people actually producing the software. If you're lucky your pm will prove to be a wonderful asset during this make-work phase because (s)he can be the bulldog that fights off other pms who try to take your time away from the job at hand: making all those new features work in less time than it is probably humanly possible. In a shop as small as mine is, that's not as likely, of course. But I'm writing mostly about economies of scale.

I should probably call out an assumption at this point: testers contribute to the bottom line. In many places testing is an afterthought. Preferably (IMO) not an after-market thought. In others, testers are integral to producing a product. In some (and I've seen/heard about them - they exist) testers are little more than a drain on everyone else's resources.

When things are balanced, I see it this way:

PMs - Gather requirements and drive prioritization and scheduling. They're the connection to marketing and customers when people wish for new features. They are primarily motivated by making "cool things" (which may or may not even be technically possible) happen.

Devs - Write the code. They are concerned with maintainability of their code base and understanding the deeper knowledge of what all their code does. They are primarily motivated by making "cool code" (which may or may not correspond to what customers need or want) happen.

Testers - Test the code. They are concerned with the stability/quality of the product and how it interacts with anything else out there. They are primarily motivated by not letting customers ever see any bugs (which is both impossible and tends to be contrary to adding the changes that devs and pms want).

Why do I start out with more silly links than I have toward the end? I think I usually begin in a whimsical mood and end on a much less whimsical one. I should think about this a little more and maybe change up my style . . .

Stupid sbemail link.

Crayons on the Tablecloth

2006-10-22T23:21:00.000-07:00

After a hiatus (much needed both because of worky work stress and my first cold of the season), I'm back. On the topic of worky work, we shipped Taceo 1.7. It sucks a lot less now. It's still kind of nasty but so much better that I'm not so embarrassed if you try it. I should blog a little about what we actually sell and why consumers might want it, but I'll leave that until later. Maybe when I need a break from working on my Halloween costume.

I decided that before defining each job function more clearly I'd walk through a typical development cycle and try to point out everyone's roles. This installment is about that initial pre-pre-pre-design phase. Or maybe it's still design. Either way, it's the thing that comes before people even start to write specs or plans or schedules. Consider writing a rougher than rough outline of an idea on a tablecloth. In crayon. It's like that.

Yes, usually the concept is supposed to happen from napkins but I want to emphasize something beyond that. It's BIGGER than a napkin. It's more substantial. Ok, so who am I kidding? This is all about designs on a napkin. (Why is it that GOOG can't find any of the Picasso napkin sketches I wanted to use as links here? *grrr*)

Typically a PM has some idea of the product, the market, and how to help the product suit the market better. To the PM this is the goal. Fairly close, but there can be a lot of impossible demands from the blue sky PM.

Typically (after v. 1, at least) a dev has some idea of how to beautify and/or extend his/her code. And to the dev this is the goal. This is technologically possible but often totally disregards the customers.

These are two goals.

Two entirely different goals.

. . .

?

If you work where I work, this may seem all too familiar. It's not exactly desirable. But it's a common pattern. I know I saw it when I was borg, too.

Typically, test comes in after this point. I don't think it should but it does. I won't press this point but suffice it to say that there's something wrong with the pattern.

During the blue sky phase of a project lots of ideas are bandied about. Pm typically has a wishlist from particular customers and/or marketing. Most of which aren't feasible as written. Dev typically has some desire to refactor the code they've been saddled with supporting during the last release (because refactoring *always* makes everything better to the devs). Most of those cosmetic changes will take a very long time and add little value to the product. And test is usually left out. Mostly because it's still busy finding the bugs that the devs left in the last version of the product.

Right.

So that's how it usually goes. But how *should* it go?

It should be a partnership from the start. And PM/dev/test should approach a new problem with open eyes but with full knowledge of the limitations of whatever existing system. PMs specialize in being a cross-group/customer/marketing bridge. They do personal politics that are tempered with a fairly solid understanding, technically, of the product/component they own. Devs approach things from a more pragmatic code-focused point of view. They want to make the best software that they can to meet customer needs while requiring as little of their time later in the cycle to support it. Cleverness up-front will be rewarded by less scutwork later. Testers start to test every assumption made about customer demands or the market or some dev's idea of time-saving or even what group X *really* wanted. This saves them (and the rest of the team) time and money later. Together, all three flesh out what the spec should look like before the spec is ever written.

But, obviously, this doesn't always happen.

(P.S. Sorry if I'm a bit test-centric. That's my world at the moment. I've worn different hats in the past and I'm sure I will in the future, but at this time I'm a little too focused on being a tester at my startup.)

The Three Legged Stool of Software Development

2006-10-07T14:19:00.000-07:00

I gave up on "trinity" as the analogy pretty early on. "Tricorn hat" also didn't work. Nor did "three bowling ball holes" of software development. "Threepenny Opera" also didn't cut it. "3 Inches of Blood", while it had a certain appeal, also didn't quite work. So I finally settled upon the "three legged stool", so this blogpost is now hereby about the three legged stool of software development.

Why a three legged stool? There are three disciplines typically involved in the process: development, program/project management, and testing. Each of those disciplines has a role and each of those roles need to 1) exist and 2) be balanced with the others. Imagine a two-legged stool. For whatever reason, Google Images has failed me, so you'll have to imagine it instead of looking at a pretty picture. Without the third leg (you wouldn't believe the GOOG hits for "third leg" - unpublishable!), that stool is either going to fall over or have some outside force to keep it upright. Now imagine a three legged stool with legs of unequal size. All legs touch the ground, but the seat of the stool just isn't level (forgive me for the cheesy link, but I love that about SF!). In software development that just can't be right. So we try to have a stool with equal legs of dev, pm, and test holding up the seat of the software, of the customer. Keeping things on the level.

Synopses (I'll probably post more detail about these later):
Developers - write the code, fix the bugs.
PMs - drive cross-team collaboration, drive the design and the schedule.
Testers - test the code, file bugs, confirm fixes.

Those synopses leave out a lot of details. Everyone has equal input at all stages of the product cycle, for example (thank me later for no prescriptive/proscriptive PLC links so far). I should probably explain the product cycle and the duties within it before I go on too far. I really need to get into granularity of duties among leads, senior staff, and junior staff, too.

I'll just leave you with one of my favorite Patton quotes for now:
Lead me, follow me, or get out of my way.

Next up: Either a better definition on disciple duties, an overview of the product cycle, or my thoughts on leading vs being an individual contributor.

Sorry to anyone expecting more security geekery so far. If you want that, look only here and here. :-) My head has been too wrapped up in procedural junk at work to be worried much about security lately. Eventually I really will get around to the NT security model and how it compares to others in the industry or even to ideals.

2006-10-04T20:20:00.000-07:00

I was going to post about my thoughts on developers, program managers, testers and how those disciplines fit together and I was going to entitle the blogpost "The Trinity of Software Development". Then I thought about it. On the bus. That's where I do my best thinking.

Why "trinity"? That has obvious religious overtones. And it would only be a matter of time until some atheist[1] came along and claimed it could all be done without any of the three. Not to mention the polytheists[2]. Really. I'm not going to mention them. Why "trinity" indeed?

So I decided not to post that long screed here. Instead, this is a placeholder for what I had intended to write. I think I'll pick some other tortured analogy instead. I think I'll go scribble something out on dead trees and post it later tonight.

[1] actually, from what I gather this was very similar to the early development org on the product I work on now. That's a long story and I don't want to paint too many black eyes on my workplace, though, so I'll skip it.
[2] I could start to make an argument that either consulting or working at a large software company might fit polytheism to varying degrees, but again I'll skip it.

Back to Real Life

2006-10-03T19:56:00.000-07:00

This post wanders all over the place and has no real theme. Please forgive me. I'll post a more coherent post next.

I'm back from Ashland and I'm recharged. Mostly. The Shakespeare festival was wonderful. So was Mike's homebrew, despite its name (Goat Scrotum Ale).

Back here at work, we have about a week until we ship the new version of Taceo. There's a bunch of bugfixing, customer-pleasing (or at least customer-not-too-terribly-annoying-anymore) goodness in the internal builds. There are some really scary code-churning changes afoot now in the thirteenth hour, but with any luck everything will work out. Or we'll back the changes out and still be better off than our last release. Either way it's much better than what you might have already tried.

No surprise that nobody at work was celebrating today's holiday. I didn't want to mention it. I thought I'd seem too flip.

I recently found out that back at the borg the internal transfer process is now easier. That would have been nice during my time there. I can only hope that changes like that won't stop the hemorrhaging of talent that provides such well-trained, highly-skilled, industry-savvy staff for startups like ours.

For anyone in dev or test who happens to be reading my blog, you may want to check out Steve Pietrek's blog. He does a great job of collecting dev-interesting links daily, focusing mostly on managed code.

Since I'm rambling about almost anything, I'll also ask when the heck Terry Gilliam's new movie is finally going to open here in the US. Ok. Here goes . . . When? (Answer: October 6.) Days are getting darker here in Seattle and I'm shifting back into filmgoing mode. I've been waiting for a chance to see that film all summer.

End of rambles. Thanks for reading all the way to the end.

Time to Recharge

2006-09-28T17:20:00.000-07:00

It's time for me to go relax for a long weekend now.

Roadtrip Checklist:
Toothbrush? Check. No, I don't really have a Civil War reproduction toothbrush, but that's kinda cool isn't it?
Change of Clothes? Check.
Diet Pepsi? Check.
New Neil Gaiman book? Check.
New Tom Waits CD? No. That won't be released until November. Oh, well.
Stop thinking about work? Check. (Thus no link to work.)

Great. Looks like everything's in order. I'm outta here until next week.

It feels a little strange to leave without having today's Marmaduke explanation, but I'll find some way to deal with it.

Ugh!

2006-09-27T01:51:00.000-07:00

Haven't been posting as regularly as I had wanted to. I've been a little too wrapped up in propane and propane accessories. Yeah - work. And when I haven't been at work I've been really busy trying not to be at work. Hitting that wall of crunchiness that says I have to slow down or I'll start to burn out.

So not much blog posting. Oops. So much for personal goals . . .

Yes, I'll get back to my security primer. Give me a week or so.

Current state of the Drew: Crunchy.

In the last few weeks I think I've pretty much found every way I can (short of checking in my own damned fixes into the source tree (which I might start doing if those guys can't get their shit together)) to piss off my devs. Mostly, I'm just looking for ways to better manage our project. I want us all to be open and accountable. Is that so wrong? Well . . . maybe. I admit that I tend to forget that there are egos involved. I just look at an engineering problem as a problem with known parameters and find a way to solve it.

So here I am. *sigh* At the very least, I know that Taceo 1.7 will suck less than the previous release (And what the crap is a DCenter? Is that what passes for the new cool? I'm so outta touch.) In fact, it will suck so much less that I would encourage you, my few (one?) readers (reader?), to try it out. In about two weeks or so. I'll let you know.

For right now, I'm mostly considering my plans for changing process at ESS and my wonderful 3 day weekend in Ashland, OR for the Shakespeare Festival. I really need that break. And more time with that W woman. *sigh* (reprise)

Also on the up-side, I'm really looking forward to the new SDET lead who accepted our offer. I need to share my work stress. Um . . . duties. I hope he really knows he's in for startup-land. It's a wild ride compared to Microsoft. Not so many superstars here. Hell, it makes *me* seem like some kind of superstar, but I'm not.

Actually there are many upsides. I'm just feeling a bit burnt and crunchy, so I'm probably coming off more negatively than I should. Apologies.

(P.S. Why does Blogger's spell-checker suck so much? Is it because people expect so little of Google that they can keep shipping total crap?)

(P.P.S. How many days does it take Google to realize that Blogger's certificate is expired? Is it more or fewer days than the number that it takes for me to figure out how the hell to send their tech support a mail to tell them that there's a problem and how to fix it? *grumble* Answer: less. It took a few days. In those few days I didn't know how to let Google know there was a problem. I tried. Multiple times. Customer service these days . . . Then again, I guess everything from Google is always in Beta, so it's not a problem.)

(P.P.P.S. Whenever Google decides to 1. get serious about security and 2. get serious about customer sat, please someone let me know. I hear it's a great place to work. If you don't care about those things.)

Bug Meanings: Priority and Severity

2006-09-23T01:41:00.000-07:00

With bugs there is a kind of cost-benefit-style analysis that happens. Bugs typically have a severity rating and a priority rating. Severity ranges from "let's make a small feature change to make things 'better'" to "OMG . . . this totally kills the app and users lose data - Armageddon!" Priority (which IMHO is misnamed and should be called something more like "frequency" or "likelihood") ranges from "almost never happens" to "a customer is always going to hit this bug no matter what". Based on those things, we analyze.

Depending on the time we're at in the ship cycle, some of those bugs might not be severe enough or high-pri enough to fix. Ok. We all ship with bugs. That's standard practice.

The hard part is defining those cutoff choke points and what they mean in sev and pri numbers.

If I were really smart, I'd propose an algorithm and then also a follow-up graph of some sort that would explain how software works through its lifecycle. I'm not so smart. I don't know how to do it. Every piece of software is different. It seems that as software engineers we're lacking here. Someone should be able to define these things and tie them to milestones in the product. If we were *real* engineers . . .

Expect a "part two" to this post in the next couple of weeks as I digest and expel ideas.

DRM Is Evil!

2006-09-21T01:55:00.000-07:00

Well . . . I obviously don't quite believe that. If I did I wouldn't be working at a company (caution: blindingly new burgundy scheme!) whose current sole product was a DRM app (yeah -same link). But in many senses the ways that DRM is applied to things like music in not exactly kind ways for the consumer (and moreover the way the rabid, frothing lawyers treat ownership of Intellectual Property and enforcement of that) make DRM seem kinda bad. At best. Or maybe even just plain evil (NSFW - or anywhere with decency standards - just "no").

Check out this interesting anti-DRM blog:
http://www.uninnovate.com/feed/

I'll get back to DRM probably sometime next week. I'll explain my insider's view of what it offers, how it falls short, and how it is seen (or misperceived).

I should also add that this is my own personal blog and my opinions are my own. They are not necessarily those of my employer (ESS) or anyone in any way associated with the company. If that wasn't already clear from the get-go, then for the sake of that guy who could fire me at a whim, please let it be clear now. Here are photos of him with the rest of the gang. I think they were all high on nitrous in front of some shrubbery at the time. I dunno. I wasn't there. LINK Also - ignore the text about them. Notice that they all have the same toothy smile. Could this explain the strange set of false teeth I happened upon in the storage room or are they actually all the same person (thus same teeth)? Oh, the mystery! Anywho . . . these opinions are my own and not those of the mothership (which my want to beam me up for refactoring or somesuch after reading this blogpost).

Security Primer in No Particular Order - preamble

2006-09-21T01:32:00.000-07:00

I've decided that I haven't really blogged enough about security yet. And to really get into the issues, I need to be sure that anyone reading my blog has the background info before I just dive into some more in-depth topic. Because of these factors, I've decided to start a series: "Security Primer in No Particular Order".

Why no particular order? Well . . . let's face it - I'm just not that organized [1]. And I'm sure that even if I were something would occur to me out of order after I'd published it. So no particular order.

This is the "why I'm bothering to post the series and sorry it's not more helpful" post that kicks off the (at least) week or so of basic security know-how. I may amend this post or any of the ones to follow to add useful info.

Maybe after that I expound on useful tools or even sneaky tester tricks. I think I should run with themes.

So how do I explain computer security to my mom? Or my brother? Or some stranger on a bus who insists on talking to me despite that I'm trying to read a book? Hmmm. We'll see . . .

Most certainly I'm going to refer often to places like SANS and RSA and others. Of course there will be some nod to gov't standards like FIPS, too. And because I'm primarily focused on working on Windows ('cause most folks are), you'll get a fistful of links to MSDN content and KB articles (why doesn't MSFT offer something like KBAlertz?).

[1] I couldn't find it online, but I seem to remember some (translated) Pablo Neruda poem that began something like (in English translation, and this misses a lot of the meaning): "All the fishes in the sees are all organized". Having grown up in a union town, it speaks to me. But in the non-union way it also speaks to me. Then again, it's not Google-able, so maybe I imagined it.

Obscurity Rode in on a Dead Horse

2006-09-19T19:51:00.000-07:00

"Security by obscurity is not security."

I don't know who originated that mantra, but if I did, I'd sign that person up for lots of spam. Because I'm not a nice person. And because there's almost no one more worthy of useless, repetitive garbage clogging up the daily works than the person who first said those words. I would consider it to be a kind of poetic justice. We need more poetic justice in the world.

In and of itself, there's nothing wrong with the *intent* of the statement. Regarding crypto algorithms, just not divulging the algo isn't as safe as using one with a known, tested strength. Ok. Fine. I accept that.

The problem is that the statement has been so often misapplied to anything in the security realm that it loses its meaning. It becomes often wrong. Much in the same way that as it is repeated ad infinitum it becomes nothing more than a mantra. Mere dogma. Dogma that kind of rhymes. It rings through with the mellifluous tones of a dead horse being beaten. Repeatedly.

How is it misapplied? Imagine that you stashed an extra house key in one of those fake rocks. (Who buys all of those anyway?) Is it obscurity to hide the keys there? Sure. Is it security? If it mitigates against easy compromise of the key, then I'd claim it is.

Security isn't just some academic thing. It's about mitigating against real risks in real life. This ain't rocket science. Anybody should be able to understand it. Risk: key compromise. Our chosen mitigation: fake rock.

Perhaps a better mitigation would have been to not leave a key outside your house in the first place. But what if you had a requirement to be able to get into your house even if you had locked your keys inside the house? In real life there are other concerns than one would find in a strict academic (read "not real world") scenario. Maybe . . . just maybe . . . that "obscurity" was just the security that you needed to meet all of your requirements and still mitigate against easy key compromise.

Sometimes obscurity *is* security. Conversely, the lack of obscurity may sometimes also be security. But that's another blogpost entirely.

I wonder if I'll need to explain next how Heisenberg's Uncertainty Principle doesn't apply to prime time network TV programming . . .

File.Exists Is Evil

2006-09-19T00:03:00.000-07:00

For whatever reason, most colleges' computer science departments hate software. I don't know why. They just do. They seem to only teach single-threaded logic. Ok, so maybe it's not animosity, but laziness. Who am I to say? Nah . . . they hate software.

File.Exists. If you code to the CLR you're probably familiar with that. What does it mean?

You call File.Exists and you find out that it exists. What does that mean?

It means that at some point between the time that you called the function and the time it returned that file existed. Or didn't. That's it. That's all you know.

Why is this bad?

It's bad because people tend to take for granted that the result from File.Exists is always *still* true. This is a problem mostly because the function should have been called File.Existed. That's all you really know. It used to be there. No promise about its current availability. Period.

Ok, so let's dig into it deeper. Why is this "evil" and not just "kinda wrong"?

Because devs build assumptions. Developer assumptions often translate into bugs. (Trust me - I'm a tester!) Developers often assume that the result of File.Exists tells them whether or not a file exists. That's not what it does. It only says whether or not in some past time that file existed. Thus, there's an assumption. Thus, a (probable) bug. Ick!

This is a race condition magnet. If you're reading this and you're a tester, then look for File.Exists in your devs' code. It's almost certainly the source of a bug. If you're a developer, ask yourself why you'd ever use File.Exists.

1) Can I do X with the file?
If this is your question, I recommend just trying to do X. Even if File.Exists works most of the time, those other times probably need to deal with whatever exception is thrown. Relying on File.Exists probably puts an implicit race in your code. Just don't go there.

2) Did FOO write something?
If it did, that log may not exist now. Chances are that you want something useful NOW and not a few milliseconds ago. Counting on FOO's file to have existed again introduces a race condition and there's probably an exception you're not wanting to handle. Just catch the exception and skip File.Exists. Make it simple. And robust. Write good code.

3) Should I overwrite or delete BAR?
Um . . . same as the other stuff I just said. Don't. Just don't. Make your code thread-safe. Reliance on File.Exists doesn't do that.

4+) Yes, there are more, but they're similar. I'll skip them.

At best, File.Exists can be a fairly reliable way to know that something *didn't* exist. Even then, there's a race and you're not being threadsafe. At worst, you've opened your code to Heisenbugs that you may not be able to diagnose.

I have no idea why anyone ever introduced such a construct as File.Exists. I can only tell you that it's evil. Avoid it. It only leads to bad code. Let's hope that saner heads prevail in DevDiv and this goes the way of the Democrats^H^H^H^H^H^H^H^H^Hdinosaurs.

Ok, I got a bit glib there. I meant to show examples of crap code that counted (unreliably) on File.Exists. I couldn't do it. It was too painful. Please forgive me.

(P.S. I lean a bit left, politically. Shut up already, lefties! It's a joke.)

2006-09-14T01:29:00.000-07:00

Scoble makes me react again. This reaction isn't that uncommon for me. I'm just blogging about it for the first time now. *sigh*

Sweet! I have my gag feather poised carefully near Robert Scoble's uvula. Now all I have to mention is how Microsoft apes Apple and . . .

*splut*

Oh! It's all over now, folks. What a messy ending!

(This is why nobody lets me make movies.)

Um . . . who the heck cares? Technology feeds on its own and spawns better. Or sometimes worse. What prevails prevails.

I don't really care whether my iNewFancyWidget came from Steve Jobs or Stevie Wonder as long as it's easy to use, makes me happier, and lasts until Stevie puts out a new album. I hope the iNewFancyWidget is accessible for blind folks . . .

I don't really care who first invented the iNewFancyWidget as long as I can use it. If possible, for free. And to communicate with my friends and loved ones. Or to see pretty women naked in some more realistic way (pr0n drives tech).

I just don't care. Gimme what I want. I don't care about its provenance. I'm like a pawn shop in that way, I suppose . . .

(P.S. Yes, I'm skipping the technical post again tonight. I'll do it tomorrow.)

Sleepy

2006-09-12T22:04:00.000-07:00

I've already posted something today and I'm getting sleepy. I think I'll skip what I was going to post until tomorrow.

The teaser is this, though: Tomorrow: File.Exists - File.Existed?

Oooh . . . quite the cliff-hanger, eh? Yeah, you're right. It's going to be boring and geeky(yeah and so what if I like BOFH?). And existential. Oh, deeeeeeeep, man, you might be thinking after I dropped a word like "existential". Well . . . no. Not really. It's pretty common sense (not quite like that, actually) once you understand the sense of it. Just like all other common sense. And still boring and geeky.

So check in tomorrow as we delve into the horrible development practices encouraged by File.Exists and the nasty nasty bugs that come of it. [Queue spooky music. I'm outta here.]

Storing Credentials on Windows

2006-09-12T20:18:00.000-07:00

I was about to add a question to Raymond's queue so that I could get a definitive answer from one of the Windows shell gurus when I noticed this question posted June 26, 2004 (Over two years ago??? Does Raymond ever clean that thing out?):

How do I store a user's credentials (username/password for a web site or ftp site) securely?

The typical answer on Windows is to use DPAPI. Namely, the CryptProtectData and CryptUnrprotectData APIs. And store the blob wherever you like. Registry, file system, in your left shoe, whatever. The up-side is that Windows takes care of all of the crypto mess. The down-side is that the key is derived from the user’s SID and password hash, so the encryption is only as strong as the user’s password and possibly a really inept attacker's inability to guess a SID (because any ept hacker could easily either figure it out or start enumerating).

I was the (then later "a") EFS tester at Microsoft for about 3 years. EFS is probably still the primary consumer of DPAPI within the OS. During that time I was also the backup tester for DPAPI.

Spelling Mistakes

2006-09-11T21:35:00.000-07:00

Drat! Someone brought some of the previous posts' spelling mistakes to light. Thanks, someone! I'll put scrubbing my content on my to-do list.

On a related note, why isn't "Google" in Blogger's dictionary? Is it because Google claims that Google shouldn't be used as a verb even though the OED and Webster's say it's kosher now?

Pesky Salesmen (Or Maybe Support Reps)

2006-09-11T20:38:00.000-07:00

I'm posting this so that I can point an unnamed person who keeps emailing me at it and then reuse the same response the next time this happens to me. Feel free to cut and paste this or send a link to your own pesky salesman.

Not-so-dear stranger:

I tried out several competing applications recently. I had a need that they all claimed to fill. They were each top hits when I searched for applications of that type. Your application was one of them.

After evaluating them, I determined which one I wanted to use. Yours wasn't it.

Before I had even finished my evaluation, I received an email from you thanking me for evaluating your product and telling me what it did. This struck me as odd, because if I hadn't already known what it claimed to do I wouldn't have downloaded it now would I?

A few days later you emailed me again with an offer to help me in my evaluation. Persistent bugger, aren't you?

A few days after that, yet another mail to see if I needed more time to evaluate your app. Trust me, I don't.

Moreover, maybe it's just me, but I absolutely hate people trying to sell me things. Yes, I had shown some kind of interest by downloading the software in the first place, but that doesn't mean I wanted to talk to any sales or support staff. If I had, I would have taken the initiative (the same kind of initiative it took to understand what your product does and to download it) to either email or call your company. I'm not shy. Honest.

Frankly, I wasn't intending to respond at all. I felt I'd already invested enough of my own time in using your software and determining that there are better products on the market. I felt that it wasn't worth spending more of my personal time dealing with you.

The more I thought about it, though, the more I empathized with you. You're probably a nice enough fellow. You probably believe in your product and just want to show everyone how wonderful it is (or isn't). At the very least, I owe you this bit of advice: please don't sell so hard to me. Or anyone else who only downloads your app. We don't expect or want that. It's the kind of behavior that entirely sours people on a company.

If you really want to be personally available to help me when I evaluate your product, I suggest you talk to your developers and have them make your contact information easily accessible through the application. The phone numbers and email address you sent me so that I could contact you with any questions? Put them in the app! For that matter, this is the 21st century - give me some IM contact info, too. Let me know up-front that my *personal* support or sales (or whatever your position is) representative for my trial of the product is Bill Smith (not his real name). But stay out of my face with it until I actually want help, please.

Ok, that's enough ranting from me. I'm not trying to ruin your day. I was just hoping to provide some insight on this particular customer and give you some personal feedback. We only grow as people by helping other people grow, right?

Thanks for your time and good luck in the future!

Impress Your Coworkers!

2006-09-11T19:29:00.000-07:00

When I arrived at work today I was surprised by a mail from the CEO telling me that he liked my blog. I wondered how he had even found it.

Then I got an email from marketing telling me that I did a great job in driving traffic toward the company's website. Huh? The morning was only getting weirder.

The marketing folks (whom I can't ever call "marketroids" here now because they'd know I said it) monitor the hits the ESS website gets. Apparently some people followed links from this blogpost and visited the site. So everyone in marketing read my blog. And the CEO found it, too. That explained everything.

I'd like to explain that I'm not in marketing, I'm not trying to shill anything here, and this blog is in no way attempting to represent that company I work for. So any claims that me putting in links like this one are really just some kind of marketing ploy are patently untrue. Seriously, though, this is my blog and it's about whatever I want to write. I don't want anyone to think otherwise.

Moreover, if you visited ESS and downloaded Taceo, I'd like to let you know that I know that 1.6.5 is buggy. Lots of known bugs. We released it just after I was hired. Don't think for even a second that our up-coming 1.7 release (early October?) is going to be such crap. It will, of course, still be software. I'll even go so far as to say that if you haven't tried Taceo yet but you've been wondering about it . . . wait until October.

Because I'd like tomorrow to be just as exciting as today was, I wrote that previous paragraph. I wonder who will say something to me about it. I wonder what those folks will say.

Someone who shall remain nameless also requested that I not blog about anything too negative like KILLING THE PRESIDENT because it might cast a bad light on ESS. The sentence you just read was intended for that nameless person and for the wonder that is the Google search engine, which should make it easy to find my blog by searching for the phrase KILLING THE PRESIDENT. Luckily, Google knows about alternate forms that some words can have and can substitute them, so I shouldn't have to include phrases like TERMINATE THE LIFE OF THE CHIEF EXECUTIVE or DEAD-IFY DUBYA, but I'll include them anyway.

On a side note, this means that some strangers have actually been reading my blog. Cool! Hello, strangers from the intarweb! Please make yourselves at home.

Note to self: Archive a copy of Taceo 1.6.5 and 1.7 when it ships. These could be very useful in a few years when it's job hunt time again, assuming my next gig is also in test. What did I do at ESS? Well, in the first couple I months I helped shake bugs out so that this [point to 1.6.5 while making a disgusting face] worked like this [point to 1.7 accompanied by a less disgusting face].

Software Sucks - But Why?

2006-09-10T04:07:00.000-07:00

Scoble always makes me react somehow. He makes me think. Sometimes I think he's brilliant; sometimes totally full of crap. But however he does it, he evokes a response from me. That's wonderful!

One of those thought-invoking posts has been haunting me for over a day now. He visited Seagate and blogged about it. What really grabbed me was this offhand comment:

You rarely think about drives or storage media until they fail.

And you don't, do you? But what's the implication therein? Think about it . . . ok, had some thinking time? Right! What about the things you worry about that haven't entirely crapped out? Things like software?

Why does software suck?

As a tester, this question is dear to me. I am constantly surrounded by software that sucks. A lot. I have no idea why. It is my own personal hell. Welcome to my world: software.

Software sucks because people expect it to. Why code to a higher standard when everyone knows that the UX is gonna be crap? People expect it. Give them the status quo.

Software sucks because (good?) developers are lazy. Make more with less. That's what they do. And the "with less" means it's gonna suck.

Software sucks because testers don't bother to find the bugs. Ok, so I'm guilty of letting a few bugs ship, but not out of laziness or ennui. It happens.

Are any of those good answers? I don't think so.

In the case of something like Windows or Office, software sucks because 1) it has all kinds of compatibility problems and 2) because they're both expected to ship with *known* bugs (let alone the unknown ones), but more so because 3) they're not stable long-term. Those hard drives from Seagate are pretty stable technology. Seagate might make them larger. Or faster. But they aren't always trying to rearchitect the HDD with every release to make it "exciting". Hardware (once it is fairly venerable) is interested only in *working*. Software is far too experimental.

Ok, so to build on that, why is software so pliable when hardware isn't? By its very nature, it's easier to change software than hardware. Even firmware updates are really software. Once the beige box is in someone's home it's going to be years untl that person buys a new beige box. Software is highly available as download from any number of sources.

Let's try this from another angle. Software "engineers" aren't really engineers. They're hackers (in the older, less pergorative sense of the word). And worse, they're almost always playing with their code. They want to keep producing as much as possible. This is almost entirely antithetical to the hardware folks (measure a bunch of times; build once).

Then again, maybe software sucks because the market bears it.

*grumble*

I'm sure I can come up with more. I've really only started to rant on the topic recently.

Fixing the problem that DevDiv has with Authenticode

2006-09-10T03:15:00.000-07:00

Someone(s) in the developer division at Microsoft do strong name signing. And they don't get Authenticode signing. Authenticode signing is the underlying junk that causes those popups you get in IE about whether or not to trust some publisher when you download an app. Strong name signing is about managed code and CLR stuffs. How does DevDiv not get Authenticode? Well . . . at some point in their building and strong name signing process, they remove the Authenticode signature from an EXE, but leave the info in the file's header that says an Authenticode signature is present. Result? A file that can no longer be Authenticode-signed, so the app either 1) can't ship or 2) will have some popup about an unknown publisher.

Bummer.

Here's code for a simple command line app that strips out all Authenticode signature info from a file, including just the entries in the file's header in case Visual Studio worked some nasty mojo on it. Enjoy!

// delcert.cpp
//
// An app to make hiterto unsignable file signable again.
//
// 8/10/2006 - Drew
//
#define WIN32_LEAN_AND_MEAN
#include
#include
#include
#include

int wmain(DWORD argc, LPWSTR argv[])
{
HANDLE hFile = INVALID_HANDLE_VALUE;
LOADED_IMAGE image;
DWORD dwResult = ERROR_SUCCESS;
LPSTR lpszImageName = NULL;
size_t cchImageName = 0;

wprintf(L"\n");
if(2 != argc 0 == wcscmp(L"-?",argv[1]) 0 == wcscmp(L"/?",argv[1]))
{
wprintf(L"%s takes one parameter - a file name to strip of its embedded Authenticode signature.\n\n", argv[0]);
return 0;
}

hFile = CreateFile(argv[1], GENERIC_READ GENERIC_WRITE, FILE_SHARE_READ FILE_SHARE_DELETE, NULL, OPEN_EXISTING, 0, NULL);
if (INVALID_HANDLE_VALUE == hFile)
{
dwResult = GetLastError();
wprintf(L"CreateFile failed with error 0x%08x\n", dwResult);
goto cleanupAndExit;
}

if(ImageRemoveCertificate(hFile,0))
{
goto cleanupAndExit;
}
else
{
dwResult = GetLastError();
wprintf(L"ImageRemoveCertificate failed with error 0x%08x\n", dwResult);
if(ERROR_INVALID_PARAMETER != dwResult)
{
goto cleanupAndExit;
}
else
{
wprintf(L"This happens when there's a listing in IMAGE_DIRECTORY_SECURITY\nin the PE's header, but the acutal Authenticode signature has been stripped.\nLet's fix that . . .\n");
dwResult = ERROR_SUCCESS;
}
}
if(CloseHandle(hFile)) hFile = INVALID_HANDLE_VALUE;

// This is somewhat sloppy, but if we're here we've almost certainly found a PE with an
// IMAGE_DIRECTORY_SECURITY that has nonzero SizeOfRawData and/or PointerToRawData,
// but the actual signature (that raw data) has been removed.
//
// What causes this? IIRC, strong name signing something that's already been Authenticode-signed.
//
// The workaround is to crack open the PE and write zeros into the directory entry so that everything
// that eventually calls through the Image*Certificate* APIs won't choke.

cchImageName = wcslen(argv[1]) +1;
lpszImageName = (LPSTR)malloc(cchImageName); // Yeah - so I'm all old-school mallocy!
if(!lpszImageName)
{
dwResult = GetLastError();
wprintf(L"Malloc failed. GLE == 0x%08x\n", dwResult);
goto cleanupAndExit;
}

if (-1 == sprintf_s(lpszImageName, cchImageName, "%S", argv[1]))
{
dwResult = GetLastError();
wprintf(L"Failed to copy argv[1] to string of chars. GLE == x0%08x\n", dwResult);
goto cleanupAndExit;
}

if(! MapAndLoad(lpszImageName, NULL, &image, FALSE, FALSE))
{
dwResult = GetLastError();
wprintf(L"MapAndLoad failed. GLE == 0x%08x", dwResult);
goto cleanupAndExit;
}

wprintf(L"certificates->Size == 0x%08x\n", image.FileHeader->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_SECURITY].Size);
wprintf(L"certificates->VA == 0x%08x\n", image.FileHeader->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_SECURITY].VirtualAddress);
wprintf(L"Setting both fields to zero . . .\n");
image.FileHeader->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_SECURITY].Size = 0;
image.FileHeader->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_SECURITY].VirtualAddress = 0;

if(! UnMapAndLoad(&image))
{
dwResult = GetLastError();
wprintf(L"Failed to UnMapAndLoad. GLE == 0x%08x\n", dwResult);
goto cleanupAndExit;
}

cleanupAndExit:
if(INVALID_HANDLE_VALUE != hFile) CloseHandle(hFile);
if(lpszImageName) free(lpszImageName);
if(ERROR_SUCCESS == dwResult) wprintf(L"Succeeded.\n");
wprintf(L"\n");
return dwResult;
}

File Under: Schadenfreude (Warning: I swear in this one!)

2006-09-08T17:09:00.000-07:00

This makes me laugh. Here is it in its full URL-y splendor in case you're a 'softie and don't want to accidentally visit Mini from work:
http://minimsft.blogspot.com/2006/09/kicking-spsa-can-again-raises-and-66th.html#c115749330219999380

I laugh the nervous laughter of an ex-Microsoft's who was increasingly ever more aware of draconian IT practices over the years. Ha. Ha ha. Ha! Ha ha ha ha ha. Oh, dear . . .

I think Microsoft doesn't get it. Again. Surprise! ;-) Tech geeks live and breathe connectivity. They absolutely need their web access. But why? Is it the web? No. It's the information, stupid. Yes, that means Microsoft need to see mine's site. Because THAT'S WHAT PASSES FOR TRANSPARENCY AT MICROSOFT. They need to know what's happening throughout the company. Even if that means watching all the troll food and its inevitable reactions scroll by (PgDn, PgDn, PgDn . . .). Hell, maybe that means getting their pr0n (no link - make your own). Whatever it takes to make them more productive. Who am I to say? Why does MSFT care what their employees read at work? At all? *harrumph*

This totally stinks of Microsoft's leadership being afraid of the plebes. And they should be. If they hired right, all of those plebes are smarter and better fit to lead than the senatorial class of 68+ ("partner") folks laying down the laws.

So what happens next, Microsoft? If you want to bleed talent, I'd love to hire some! Give me your smart, your driven, your undervalued masses . . .
[Drew strikes a Statue of Liberty pose.]

We're always hiring talent here at ESS. Even if the job board doesn't say so. Just try us. If you're a superstar we're not gonna say no. Then again, if you're a superstar you don't really need the invitation, do you? Just come on in!

I Resolve . . .

2006-09-08T16:47:00.000-07:00

I resolve to post something at least once a day. Something of content (links, even) at least twice a week.

I need to just state that publicly. Gotta stop the slide into blog netherland.

Ok, so here's something maybe of substance:

I read Joel Spolsky's blog pretty religiously. Meaning the feed shows up in RSS Bandit and eventually I get to it. I somehow ended up being the de facto build engineer a few weeks ago. While I was trying to figure out how to link Subversion, Bugzilla, our couple of email servers (don't even ask why we have separate POP3 *and* Exchange servers - I mean it - don't ask), my nightly build script (yeah, no link there 'cause it's some in-house kludge that I cooked up in a hurry), and product supports software (no name mentioned; nothing linked) I decided to look into that FogBugZ thing Joel's always peddling. Neat! In fact, very very neat. Our product support guy is looking into it right now and he seems impressed, too. I have this crazy feeling that a lot of the infrastructure problems I've been dealing with will go *poof* and I'll only have a few loose ends to tie up.

Does anyone (if you're reading this) have any opinions about FogBugZ? Frankly, it makes that crapola I was using at Microsoft look like . . . ok, crapola. I'm not sure it scales to the level of Microsoft's money-making divisions (all two of them), mind you, but ESS isn't Microsoft. There are pluses and minuses in that, but so far I think I'm in the black.

Man, I Gotta Get Better at This

2006-09-08T16:33:00.000-07:00

It's been waaaaaay too long since my last post. I really need to post some poop about work. I'm sleep-deprived now from thinking through work-related stuff all night. My brain just wouldn't let me rest. I promise some more substantive post this weekend. (As if anyone is reading anyway.) Maybe I'll post that Authenticode signature pruning source code. Still have to get the ok from the CEO (my fault, not his).

Too Busy to Blog? Say It Ain't So.

2006-08-19T17:15:00.000-07:00

Nope. It's so. I've had a pretty busy last ten (ten???) days. Lots of hat-swapping as I got to play tester, developer, IT guy, and PM among other sundry duties. Here are some highlights:

- I wrote a tool to work around a problem that Visual Studio can create with Authenticode signatures on EXEs and DLLs. Given that I was the Authenticode tester in my previous life at Microsoft and I understood the problem, I was the one to write an app to get around the Microsoft cruft. I'll blog about that soon and I'll ask Ray (our CEO) if he's cool with me even posting source code for the app.

- I got to write a build script so that our devs could stop spending so much time manually doing different tasks to get a build out. Next week, I'll work on setting up a scheduled task to check Subversion for source changes and automagically build, share out the build MSIs, and send everyone a build mail. Maybe I'll even have the test machines automatically install the new build overnight so that I have shiny new bits waiting for me in the mornings.

- I hacked an MSI to change the installer's behavior. Being able to continue the install even though files were in use and couldn't be updated hosed everything. Because we were about to release, the decision was to remove that option. Unfortunately this wasted some time for the folks in marketing who were nice enough to install the new build for us. I should really figure out some way to repay them for their kindness in helping test the software.

- I got Bugzilla to mail people when bugs were updated. It was all new to me. Luckily it was in Perl, so it wasn't that difficult to understand. I guess that functionality had been broken since late April. Sheesh! No wonder the PM and the devs *and* Nan (the head of creative marketing) had all complained to me about how it didn't seem to work any more. Part of me wonders why nobody else bothered looking into the problem for the last 4 months, but I don't want to point fingers or throw stones, so I'll just shut up about that.

- Did I mention that I'm *still* working on that spec for our product that should have existed eons ago? I got too sidetracked with testing and reproducing customer problems to put enough time into it so far. Progress: sluggish.

- There was also a little management hat goin' on. I met with some recruiters to help determine what I'm looking for in a boss for me ('cause who in his or her right mind wants to be an SDET Lead?). And I also set up some phone screens with candidates to be my SDET peers. Based on their resumes, those should be fun. I hate to say it, but having recently gone through so many interviews myself, I started to enjoy interviews. Yeah - I know - weird.

Lotsa stuff. I don't even think that covers everything. It definitely leaves out the near-daily fire drills. Those have to stop. Soon. Once I get a little more process in place.

I think my next work-related blogpost will be about our product: what it does, what it doesn't do, how it helps people, and a bird's eye architectural overview. That might help my only reader so far that I know of understand what I'm working on now and it will also keep my focus on cranking out that spec. After that maybe I'll drill down into the technical, social, and general business worldy kind of problems with the model. Or maybe I won't. I suppose I should get Ray's ok first for that, too.

Security-related Daily WTF Post

2006-08-09T20:39:00.000-07:00

I've been too wrapped up in both work and personal stuff lately. I've been behind in my news- and blog-reading. It's about sunset and I finally read today's Daily WTF post. (I should really link to them in that "links" sidebar when I have more time to pimp out my blog next weekend.)

Anywho . . . here's the Daily WTF post. Enjoy!
http://thedailywtf.com/forums/thread/85272.aspx

Pop quiz: What wasn't right about that email? Try answering *before* reading the comments on the original blogpost. Ouch.!Just . . . ouch.

- Drew

Ramping Up on Everything

2006-08-09T19:30:00.000-07:00

For the past several weeks I've been busy ramping up on everything at ESS. How does the product actually work? What . . . no spec? What's the codebase look like? How 'bout the build process? What's the release cycle like? Who the heck are the customers and how are we meeting their desires (or not)? All those things and more.

After a great deal of ad hoc testing trying to figure out how things work (or should), I think I have a pretty good grip on what an end user would/should expect. So it's time for a test plan. ESS had nada for testing before I showed up. Nothing. Zip. This will be the first attempt anyone's made at a test plan. Ideally, I could start with a spec and build the plan from there, but things aren't always ideal.

Luckily, the job of writing a spec has fallen to me, so the world is more ideal than I had thought. Or is it? I'm just some test schlub and I'm new to the product, but I'm the one expected to write the spec? Aaaaargh! And there's a crapstorm of testing that needs doing NOW because we're about to put out another dot release? Double aaaaargh! I'm just hoping to muddle through and have draft one ready for lots of red ink from the rest of the team by the end of the week.

I'll drill down into what the product is, who the customers are, et al. in later posts.

- Drew

(P.S. I wonder whether or not I should actually use the spell-checker that Blogger offers. It's a cool feature, no doubt, but I want this to be off the cuff. Maybe a few misspellings work better than dictionary-perfect blogposts. I dunno.)

Intro

2006-08-09T00:18:00.000-07:00

So this is my frist p0st . . .

Who I am:
An ex-Microsoft dev in test. This means I live and breathe code. The sole tester at a startup. This means I'm interested or at least willing to take some chances and play "business". A total security geek. This means I'm all about either breaking into some system or securing it. That's the most interesting game of all . . . (Hack my blog - dare ya - go ' head - it's worth a laugh!)

What this is all about:
I'd ideally like to explain my job to my mom. Beyond that, it would be nice to explain it to all y'all, too . . .

My sitch:
After 7 years of Microsoft (test dev in Windows security), I'm now a (*the*) tester at a startup doing DRM stuffs. We're "Essential Security Software" in case you're keeping score at home. This is my blog about the trials and tribulations of making a startup start up. In the security space. As some insider. That's it. My schtick. Not so sexy, maybe, but it's *mine*.

More on the trials and tribulations of my job later. And probably also more about past things I should do even if the official documentation didn't.

- Drew