Browsing Posts published in April, 2007

A few days ago, I read Kyle Baley’s post about learning Rhino Mocks. Like many folks, he initially had trouble understanding Rhino Mocks’ record/playback metaphor. Then during the Calgary Code Camp, an attendee kindly pointed out that I had forgotten mockRepository.ReplayAll() in my unit test – fortunately before I actually ran it. Then yesterday I was catching up on my blog reading and saw this post from Oren discussing various people forgetting to call mockRepository.ReplayAll(), including Oren himself.

I thought to myself, Rhino Mocks has a very nice fluent interface, but doesn’t make its Record/Playback explicit. What would I want my code to look like if it did support explicit Record/Playback? So I grabbed the source from Subversion, put on my TDD hat, and came up with this failing test:

[Test]
public void CanRecordPlayback() {
    MockRepository mockRepository = new MockRepository();
    IFoo mockedFoo = mockRepository.CreateMock<IFoo>();
    using(mockRepository.Record()) {
        Expect.Call(mockedFoo.Bar()).Return(42);
    }
    using(mockRepository.Playback()) {
        Fooz fooz = new Fooz(mockedFoo);
        fooz.Barz();
    }
}

A few minutes later, I had working code for the Record and Playback methods, all the unit tests passed, I created a patch, and emailed it to Oren for his thoughts on the new syntax. He liked it so much that he included the new syntax in Rhino Mocks 3.0.5, which he just released today.

A few things to note about the new syntax. Expectations are grouped in the Record block. Exercising the mocks occurs in the Playback() block. ReplayAll() and VerifyAll() are called implicitly after the Playback() and Record() blocks, respectively.

Time between initial idea and production deployment: Less than 24 hours. How is that for great turn-around? Thanks, Oren. I’m proud to have committed to such a widely-used (and respected) project!

The Calgary Code Camp is this Saturday! If you haven’t already registered, head over to the site and do so. (If you are reading this after April 28, 2007, you missed it.) Here are some stats for the curious:

Number of tracks: 3
Number of speakers: 13
Number of sponsors: 14
Number of sessions: 15
Number of prizes: Over 60
Value of prizes: Approximately $20,000 CAD
Being there: Priceless

Last year the delegates from Edmonton walked away with a disproportionate number of prizes. This year we’ve worked with our sponsors to thwart the Edmonton contingent by bringing in more prizes than the Edmontonians can carry home. Let me say that our sponsors have been awesome. We’ve got over 60 door prizes worth around $20,000 CAD. Prizes include component packages from Dundas, ComponentArt, and Nevron; books from Addison-Wesley and Apress; a free registration to DevTeach Montreal 2007; copies of JetBrains .NET Productivity Pack; and lots of hardware. There is even rumour of an XBox 360 among the loot.

All the sponsors have been very supportive, but I want to say that JetBrains has gone above and beyond the call of duty. The JetBrains .NET Productivity Pack includes both ReSharper and dotTrace and retails for $600 USD. One in twenty attendees will walk away with this prize! That’s right. You’ve got a 1 in 20 chance of taking home two of the best .NET tools on the market. Awesome!

Thanks go to all the sponsors for their support and I hope to see you at the Calgary Code Camp on Saturday!

I would like to thank everyone who voted for my TechEd 2007 Bird of a Feather (BoF) session. The votes have been tallied and my session has been accepted. So I will be leading a lively discussion on:

Creating Flexible Software: TDD, Mocking, and Dependency Injection

There has been much discussion of agile development techniques, but what do they really mean? How can they help you develop better software that is more flexible in the face of change? What does it mean for software to be flexible? This Birds of a Feather session will promote a lively discussion of how to be successful in creating software that is resilient in the face of ever-changing business requirements.

Just like Spring, it seems that Agile is in the air as Jeffrey Palermo had his two agile BoFs accepted too. Congratulations, Jeffrey! I’m looking forward to Partying with Palermo at TechEd 2007 (and attending his BoFs).

What can I say? I love ReSharper. I bought a copy with my own hard-earned cash because it made my life as a developer easier. TDD development without ReSharper is like GUI development in notepad. It can be done, but it ain’t pretty.

The JetBrains team, the folks behind ReSharper, is also incredibly helpful and open. When I was developing the VstsUnit Plugin for ReSharper, Oleg Stepanov – JetBrains’ Head .NET Project Manager – was kind enough to answer my questions about some integration challenges I was experiencing. His assistance saved me days of head-scratching, trying to figure out what exactly was going on.

So it’s pay-back time.  JetBrains is looking for feedback on ReSharper to help drive the product’s direction. How can JetBrains make ReSharper even better than it already is? Is there a killer feature you’d love them to implement? Thinking of buying ReSharper, but it’s missing your must-have feature? Take a few minutes and fill out their survey.

If you’re not a ReSharper user and are wondering what all of us TDDers are blithering about, come to the Calgary Code Camp on Saturday, April 28, 2007 and you’ll not only see ReSharper in action,* you could win a free copy! JetBrains is one of our sponsors and has graciously donated copies of their .NET Productivity Pack, which includes ReSharper and dotTrace**, as door prizes. You could be one of the lucky few to walk away with these great products.

* All the speakers in the Agile track are avid ReSharper users. So you’ll get a chance to see fingers and code flying. True art is watching Jean-Paul Boodhoo at the keyboard with ReSharper. He is THE master.

** dotTrace is a performance and memory profiling tool. I’ve tried out many of the major profiling tools on the market and dotTrace is definitely the easiest to use and has consistently provided great results. Straightforward answers with a minimum of fuss. Highly recommended.

Ever had the trial version of an application run just fine, but fail horribly when you register a license key? I’ve had this happen with two different and completely unrelated software products – FLStudio (awesome music authoring application) and FinalBuilder (a NAnt/MSBuild replacement). In both cases, the cause was a Data Execution Prevention (DEP) violation. (DEP is on by default in 64-bit versions of Windows, which is why it is most often encountered there. On 32-bit Windows, DEP is enabled only for critical operating system files, though it is simple to turn it on for all files.) I suspect that the licensing scheme generates code from the license key, which is then executed. The code will be generated in a data region, which is marked with the NX (No eXecute) flag on modern processors. When a modern processor tries to execute code in a portion of memory marked with the NX flag, DEP kicks in and tears down the process. The rationale behind this is that you’re not supposed to be executing data! (Apologies to the LISP folks out there.) If you need to dynamically generate code on the heap, clear the NX flag to mark it as executable.

Now you may be wondering about the .NET Framework because the CLR takes MSIL and JITs it to native code, which lives on the unmanaged heap. The CLR clears the NX flag for the regions of the heap where JIT’d methods live. The same applies to JVMs in the Java world and any other JIT’d language.

The Fix

If you’re an end user, there is no (easy) way to mark the generated code as executable. (I suppose you could hook a debugger up to the process every time you launch the application and manually clear the NX flag in the correct region. Thanks, but no.) So the solution is to exempt the executable in question from data execution prevention (DEP). On Vista, go to Computer… Properties… Advanced system settings… Performance Settings… Data Execution Prevention tab… and add the EXE to the exception list. (You should find the DEP tab in a similar place on Longhorn Server, Windows XP SP2, and Windows Server 2003.) The process doesn’t have DEP protection, but at least you can run it.

The Real Fix

If you actually wrote the software, you can really fix the issue. You must clear the NX bit in the regions where you generate code to prevent DEP from tearing down your process. Rather than using malloc or HeapAlloc, you must use VirtualAlloc or VirtualProtect with one of the following flags: PAGE_EXECUTE, PAGE_EXECUTE_READ, PAGE_EXECUTE_READWRITE, or PAGE_EXECUTE_WRITECOPY.

Why Malware Can’t Sidestep DEP

Now you may think that this opens a security hole. Can’t malware simply clear the NX flag itself? Let’s walk through the hypothetical exploit:

  1. You have an unexploited application with an undiscovered buffer overflow bug.
  2. Your application gets a malformed request attempting to exploit the bug.
  3. The buffer is overflown and return address of the current function is set to somewhere in the buffer. (This is how a typical buffer overflow exploit occurs.)
  4. The processor tries to execute the data in the buffer, which would contain the attack code. The buffer is marked NX because it is part of the current thread’s stack (or less often, the heap).
  5. DEP kicks in and tears down the process.

At no time has the attacker’s code been given a chance to run. The only way that the attacker’s code could run and call VirtualAlloc/Protect is if your code called VirtualAlloc/Protect on the buffer, which would be a pretty silly thing to do. So if malware can call VirtualAlloc/Protect, it can already run code in your process and do much worse things than dynamically generate code and mark it as executable.

Hopefully this helps some folks solve mysterious licensing failures and software authors make their code work on DEP-enabled systems, which are being more and more common.

For those of you who noticed, my site was down for the past week due to hardware and DNS issues. To avoid similar problems in the future, I’ve moved my hosting to GoDaddy.com. During the move, I encountered some “technical difficulties” – namely DasBlog not running in a medium trust hosting environment. (Running ASP.NET in full trust mode in a shared web hosting environment is a plain bad idea.) GoDaddy’s support staff were excellent – friendly, knowledgeable, and courteous. I was able to upgrade from shared web hosting to a virtual dedicated server by just paying the difference. (It was either that or port everything to SubText, which does run in medium trust. I didn’t have the time to undertake that at the moment.) Anyway, I’m back and blogging. I now return you to your regularly scheduled program…