Scoble linked to me!  Around 2AM or so.  And now by 11AM, I've had over 500 visits (and some new subscribers)!  And this is on a Sunday.  Very cool.  Time to turn on the caching.

I use intraVnews (www.intraVnews.com) to read RSS feeds.  It's free, and most importantly, it's integrated into Outlook.  However, I was having trouble getting intraVnews to read my blog's RSS feed.  I emailed intraVnews support (which is VERY good) and found out that intraVnews DOES have a problem with some dasBlog feeds.

The issue is that intraVnews sends an HTTP HEAD request to the RSS feed first, to see if it has changed.  A HEAD request is just like a GET, except that only the HTTP headers are returned.  Well, dasBlog uses a web service (.ASMX) to render the XML.  ASP.NET doesn't allow HEAD requests to ASMX files and will error.  If you have customErrors on (I think this is the default for dasBlog?), instead of a 500 internal service error, you get a 302 Found -- a redirection to an error page.  intraVnews then decides to throw this out.

Just by turning customErrors off in the web.config, the normal HTTP error will be returned, and intraVnews treats this just fine.  Thanks to intraVnews for pointing this out, and Rex Swain, for his cool HTTPView page, which lets you see exactly what's coming back in an HTTP response.

Update 2004-03-07: Added screenshots.

Read the intro to find out why I'm writing this.

Alright, before we get into attacking .NET, let's see how it's done against common Win32 programs in x86.  First, you'll need a good disassembler/debugger.  I recommend OllyDbg.  It's very easy to use, and does a good analysis of the code, which helps us out quite a bit.  SoftICE is another alternative, but it's low-level, harder to use, and it costs $1000.  People tend to use this when they want to debug something like a device driver, or make a patch for Windows.

Here's the executable I wrote for this sample: SimpleCode.exe (44 KB) and if you feel like cheating, the source code: SimpleCode.cpp.txt (1.28 KB).  It's very simple.  In fact, the whole purpose is to validate the user code -- there's no real content that's protected.  However, it will be enough to learn from.  Also note that it only runs on Windows 2000 and above.  If you aren't using that OS, upgrade :), or get the code and fix it, or email me for a version you can use.

So, let's open OllyDbg and make sure the analysis options are on (Alt-O, check all of them out).  Now, load SimpleCode.exe.  OllyDbg loads and disassembles the code.  You now have a console window open, and a bunch of x86 on your screen.  Let's run through the program (F9).  Enter 4 chars for your serial, and 4 for your activation code (no checking is done, so you'll screw up the program if you enter more data).  A message box appears telling us the code is invalid:


That's our way in, for this example.  We know that somewhere before the message box was shown, our activation code was tested.  So, let's go breakpoint at the message box.  Restart SimpleCode (Ctrl-F2).  Right click in the main window and select Search for -> All intermodule calls.  In the new window, type MessageBox.  You'll see two calls to MessageBoxA.  A real program would have many more.  Right click one of the calls and select “Set breakpoint on every call to MessageBoxA”. 


Run the program and enter fake serial/activation again.  The program breaks at “00401163  |.  FF15 DC804000 CALL DWORD PTR DS:[<&USER32.MessageBoxA>>; \MessageBoxA“.  If we look up a bit, we can see that the arguments loaded are for the invalid serial.  This is the message box we want.  Go into breakpoints (Alt-B) and disable both breakpoints.  Now, the opcode right after the MessageBoxA call is C3, RETN, the end of the function.  Considering the code for this function is very short (21 lines), it should contain only the “bad” code -- code we don't want executing.  Press F8 to step over that call.  Dismiss the message box.  Notice you can press “;“ to add comments to lines.  It'd be good to mark this line with something like “Return from displaying bad message box.“, just in case we get lost later on.  In many programs, there will be many interesting points, so good commenting is key.


If you're going to be doing real attacking, you need to learn some X86.  Important things are CALL, RETN, the various jumps, and comparisons.  Because most likely, somewhere inside your target program, a check is performed and then a corresponding action is taken.  If we can reverse the logic, then we can make the program think correct data was entered when it wasn't (and the opposite: correct data will be considered incorrect).

Now we're about to return to the point that called this function.  Press F7 to see where that takes us.  Now we're on “00401274  |.  8B4C24 3C     MOV ECX,DWORD PTR SS:[ESP+3C]“.  The line above that is the callsite of the “bad display function“.  Comment it as such.  Look around.  OllyDbg should display some arrows indicating jumps and targets.  If it doesn't go into debugging options and check your settings. 

Notice that the callsite of the bad function is a jump target from “00401259  |. /74 14         JE SHORT SimpleCo.0040126F“.  If we take the jump, we end up calling the bad function.  If we don't we RETN (look at the line right above the bad callsite).  Sounds interesting.  Set a breakpoint on that JE instruction, restart, run and enter the data.


JE means “jump if equal“.  It's opposite is JNE (jump if not equal).  Our program is stopped right now at a JE, and OllyDbg says the jump will be taken.  Since the jump goes someplace bad, we don't want it to happen.  Press space.  This opens the reassembler.  Change the JE to JNE and press assemble.  OllyDbg patches the in-memory executable. 


Let's see what happens.  If we're lucky, this will call the “good“ code.  If not, we just patched something else and the program at the best is going to do something strange, but most likely will crash and burn.  Press F9.



What's that?  Thanks for activating?  Why, you're quite welcome!  That jump did it.  Wasn't that easy?  And we didn't have to learn much X86 at all.  To save your changes, we'll need to restart (OllyDbg will complain since the breakpoint code was patched and changed) and goto the breakpoint and re-patch.  This time, right click and select “Copy to executable -> All modifications”.  Now we've got a patched program.

This was extremely easy (it was a very simple program!), and just demonstrates one way that someone could attack your code.  It's also an inflexible attack (a binary patch, versus finding the algorithm), so if a new version is released, we need to debug and patch it again.  Hope you learned something!

Update 2004-3-8: Part 2 now available.

To defend, you must have some idea of what you're defending, and who and what you're defending against, specifically, which attacks.  Failure do understand and know these things means that your defense will most likely not be effective, and could in fact decrease your security.  Here's an example:

Near where I live, thieves were stealing cars that people parked in the street.  The neighbourhood committee decided that they'd stop this.  The solution they implemented was to put gates at all entrances and exits of their area, and have guards that only allow cars with a particular sticker get through.  This makes people FEEL more secure.  However, for the cost (guardhouses and gates construction, guard salaries), it's not as effective as it could be.  A thief can still walk in just as easily (gates only block roads), and when driving a stolen car out, the guards will see the car and sticker, recognize it, and let them leave.  If they had thought about how thieves operated, then they would have realised this and done something more effective, perhaps hiring the same number of guards, but setting them on a patrol, instead of just sitting at their posts.  With unlimited resources, they could do both things, and give each member a special remote key-code to unlock the gate when they are driving.  However, the tradeoff in cost and convenience is too high for them.

This is how security is, in the physical and electronic worlds.  We have many possibilities, each with their tradeoffs.  Deciding which measures to implement requires us to understand how our opponent is going to operate, as well as the details of how exactly our defenses work.

In this series, I'm going to show you how to crack simple code.  I'm going to make a series of samples to try this out on (to avoid DMCA problems with real code), so as to get a feel of what crackers do to code.  It is not going to be in-depth or show how to become a master cracker.  Just enough so that we could attack a simple Windows/.NET program's licensing key system, which is a common theme in software protection.

Continue to Part 1, where we'll crack some simple code...

Now that I've decided on which library to use, I'll describe the actual code.

We already know that HTML, esp. in Internet Explorer, provides many attack vectors.  And new versions of the browser could add another tag or attribute that can execute code.  So we need to use a whitelist, not a blacklist.

Next, there are many more legit users than attackers.  So when dangerous content is detected, it needs to be removed -- we can't just blow up and tell the user not to hack us.  The number of false positives could actually be rather high, since some people are going to use Word and end up with a lot of tags and who knows what else.  And finally, users could accidentally paste something that's potentially dangerous.  Yelling at them, or even telling them to fix their code isn't going to work, since they're maybe not even aware that HTML exists.

So, here's the code: SafeHtml.cs.txt (3.28 KB).  It's very short and easy, thanks to the HtmlAgilityPack.  The processing of style tags is pretty weak (simple replacements), but should do the trick.  Enjoy!

Update 2004-Mar-04: Forgot to handle <A href=”scriptType:code...”>.  Be sure to add that if you use this code in production.

Following up from part 1, I reviewed three different libraries:

• HtmlAgilityPack
• HTMLDocument
• SgmlReader

• Inconsistency when loading data into the HtmlDocument.  If you have a string, it needs to go in the constructor, otherwise, use an instance method.
• Enums (both of them) are prefixed with “e”.  Why?
• Lack of types.  There are four types total.  That's all.  No HtmlAttribute.  No HtmlElementCollection.  Nothing like that.
• Weak-typed collections.  ArrayLists and HashTables are used as the collections, instead of strongly-typed collections.  So you must cast, and if you insert an unsupported object, then it will throw an exception  when writing the HTML.  Not very robust.
• And the silliest thing of all: No encoding support.  Worse than that, FORCED ASCII.  If you open a file, their code opens a stream, manually passing ASCII encoding.  No BOM detection, no system default, just ASCII.  Ouch.

Since I'm about to leave Guatemala after living here for over six years, I thought I'd jot down some experiences as to remember them.  I'm not making this up.

At a store, my father asked for some soap.  He was told that they currently did not have any, and that they wouldn't for two weeks.  My father suggested that if they were selling so much soap, perhaps they'd order more.  The storekeep smiled and said “Well actually, we never sell soap for the second half of the month.  Our records show that we only sell soap for the first two weeks and then none for the rest of the month.  So, we only buy for the first two weeks.”

I went to buy a microwave at the biggest Sony distributor in the country.  In the front of the store they had a very interesting microwave with some really advanced features.  I asked how much it was, and was told that I couldn't buy it, since they didn't have any.  When I pointed out to the salesperson that they did, in fact, have one, and it was right there, he said “That's our display unit.  If we sold that, we wouldn't be able to show it to other customers.”

I was going to write a series about learning MSIL (Microsoft Intermediate Language, or simply “IL“), and then get into more advanced topics.  However, I found a good tutorial (and no doubt there's more if I use Google for am minute) at CodeGuru, called MSIL Tutorial.  It should be enough to get people up to some speed.

I'll be writing some articles about how people actually attack programs, starting with nice x86 assembler, and then showing how attacks against .NET programs can use many of the same vectors.  I'll show how, even with some weak obfuscation (and by weak I mean pretty much every product currently available), crackers still have an easier time on .NET than on native x86/Win32.  Then I'll talk about some mitigation techniques that can be used to make things somewhat harder.

One thing about living in Guatemala is that McDonalds has a delivery service.  I don't think they do in Canada or the states.  I wouldn't usually write this, but they had some awesome service today.  My nephew stayed at my house last night, and this morning we called for a Happy Meal.  He is collecting the current toy line, so we asked for a specific part. 

Well, when the delivery guy showed up, they had the wrong one.  I figured we'd go later and change it.  A few minutes later, McDonalds calls to apologize for the mistake and invites us to come by to change the toy.  An hour later, they show up at my house, just to deliver the new toy and apolgize again.  WOW!  That'd be impressive in most countries, but it's doubly so in Guatemala, where the concept of customer service is pretty much non-existant.

Every day I get a few hits from people using Google to find information on IMEs.  Judging from their search queries, I'm guessing they want to install an IME.  If you are one of these people, try this to start off:
http://www.google.com/search?hl=en&lr=&ie=UTF-8&oe=UTF-8&q=site%3Amicrosoft.com+IME

MUIs (Multilingual User Interace) Packs are extremely awesome.  They REALLY enhance Office.  However for some <adjective> reason, you can't easily get them.  I have them since they're included in my MSDN subscription.  Otherwise, see these links for requirements:
http://www.google.com/search?hl=en&lr=&ie=UTF-8&oe=UTF-8&q=site%3Amicrosoft.com+MUI

Hopefully someday Microsoft will make ONLY English language versions, depending on enhanced MUI packs for localization.

The other day I got an interesting email.  A client who we had written a payment processing system was having trouble with MQSeries (shudder), and was pinning the blame on our system.  The issue was that when MQSeries dispatched a message that eventually timed out (30 seconds), the payment server blocked until the timeout was returned.

At first, we thought that MQSeries was to blame.  After all, it's a most annoying piece of software (it starts up around 30 processes for some reason).  There's a reason that IBM's consulting division makes so much money :).  But we thought that serializing all connections was a bit bad, even for IBM.

Remoting seemed unlikely.  After all, how could anything be scalable if remoting used only one thread?  After some tests, we found out the cause.

Apparently there is a bug in remoting.  Or perhaps it's by design.  The result is that it appears as if remoting tries to keep one and only one thread per CPU active.  This could be a performance benefit, assuming your thread is using the CPU.  However, when your thread blocks, for instance, calling Thread.Sleep for more than a few hundred miliseconds, or calling WaitOne with an indefinite timout, remoting releases a new thread.  This is actually a decent scenario for most things, since it assures your CPUs are operating at the highest efficiency.

The problem was the MQSeries was being called via a MC++ interop library.  (IBM didn't have a .NET library when we wrote this, and apparently their new .NET library for MQSeries is pretty bad.)  Since it's unknown what happens inside of a P/Invoke request, no thread is released.

The ideal workaround would be to let remoting know that a new thread should be released.  However, I'm unsure of how to do this (or if it's even possible), and thus, the workaround is to manually multithread your server-side code where needed.

In an application I'm currently writing, we allow users to write messages with HTML markup in them, to deliver a rich experience.  The obvious problem is making this secure.  We don't want UserA to write a malicious script and steal some of UserB's data.  IE provides some cross-site scripting defense, but defense-in-depth (well, not even that deep in this case) would want to make us ensure that the HTML doesn't contain anything executable.  I've seen some samples that claim to clean the HTML with not much code at all.  They check a few tags, and they think they're done.  Of course, they aren't.

The problem is that IE is extremely powerful.  While this is great when developing an intranet application, it makes finding all the attack vectors nearly impossible.  For instance, we might think that a style attribute is ok, right?  Wrong.  There are two problems that I can think of (without thinking too hard).  First, someone could use styles to “overwrite” links on the page by using absolute positioning.  They could then change the “My Account” link into a link that goes to their own server, and steal the user's information.  Second, the style attribute can be used to load an HTML Component (.HTC).  This can contain lots of script.  That's bad.  And this is just in one little attribute!

Needless to say, there are many, many more attack vectors.  Even if we could find them all, that doesn't help users when they get a new browser with upgraded and different capabilities.  So, we're going to have to resort to a “safe” HTML subset.  We'll go though the MSDN reference and pick out the tags and attributes that we consider safe, and anything else will simply get deleted.

Sounds easy enough, except we've got to parse the HTML.  Not fun.  Fortunately, I've found two libraries that do this.  The HtmlAgilityPack, written in C# by Simon Mourier from Microsoft (source included), and DevComponents.com's HTMLDocument, a commercial but inexpensive library.  If anyone knows of other HTML parsing libraries, please leave a comment.  In part 2, I'm going to review the APIs of the different libraries.

Well, for the last two weeks I've been using some shade of gray (205,205,205) as my Window colour (all backgrounds).  And for the most part, applications have worked just fine, not like my last experience.  Perhaps I need a darker shade, but I'm worried that the reduced contrast will start straining my eyes and negate the benefit of non-white background to begin with.

Of course, I could change the text colours to white, but I really doubt anything would look good then...  Anyways, give it a spin!  Turn down the amount of energy that your display is emitting and see how it feels.

In the comments for my post, “Some colour tips for Visual Studio .NET“, Michael Carter writes:

“I'm also using Lucida Sans Typewriter as my default font. I think it's much easier to read than Courier. “

Easier than Courier [New]?  I had to try.  Well, after playing with Lucida Sans Typewriter for about 5 minutes, I found that going back to Courier New was impossible.  Thanks for the tip Michael!

My earlier post about thinking abstractly in relation to language to text works because when a user is put through something, and must deal with it for a bit, hopefully they will be more sensitive to others who might deal with a circumstance all the time.

Case-in-point:  Colours.  Why is it that so many developers just ASSUME I'm going to use the standard Windows colour scheme, and then decide that using system colours or transparent colour is too much work, and that they'll just set it to White, since it works?

While talking about background colours in VS.NET, I remembered that this of course applies to many applications.  In fact, a while back, I tried to switch the background text color to a nice gray.  I found out that my system looked like crap, since over half of the apps I use don't play nice.  Some are unreadable, others hurt a LOT to read.  I think it was a version of some CD burning software that decided to use Red (FF0000) for some text.  Red next to the gray I used turned out to be an optical illusion of pain.

Websites have the same problem too, although most of them have the inverse problem.  The designers want the background to be white, and rely on the default.  This is NOT necessarily a bad thing.  If I set my colour scheme for a dark background, I'd enjoy reading/writing text on a site with a dark background (all the white on my own site is starting to annoy me...).

Eventually, I ended up going back to a white background, painful as it is.  But, it's been a while, and perhaps devs are smarter now?  I'm going to go switch now and see how things work out.