Nothing surprising

I've been waiting for this: http://www.nytimes.com/2008/03/12/business/12heart-web.html?_r=2&ref=technology&oref=slogin&oref=slogin

Certain pacemakers (Medtronic in this case) are easy to reprogram without any useful authentication. The result is that an attacker can kill someone remotely by modifying their pacemaker.

This certainly will not be the first time this happens. The response from Medtronic is idiotic:

"To our knowledge there has not been a single reported incident of such an event in more than 30 years of device telemetry use, which includes millions of implants worldwide"

It's funny seeing industries that typically have little to no security requirements in their products get rudely awakened. Another vendor, St. Jude, says something equally scary:

"used “proprietary techniques” to protect the security of its implants and had not heard of any unauthorized or illegal manipulation of them"

Who wants to bet there's some globally shared key at work? At any rate, we expected this kind of stuff because too many people can't think clearly about security (I'll be writing about [the lack of] VoIP security soon).

A growing problem

How should these devices secured in the first place? I'm not talking specifically about pacemakers, but all sorts of implants and enhancements that we will have during the next years, using security technology today.

First, they need to be remotely monitored. This is relatively easy to secure, as the risk is considerably less: information disclosure. For example, if each monitoring device had to have it's public key explicitly trusted for a particular patient, that'd be pretty easy. In the case that a key was disclosed (say, by capturing and attacking a monitoring device), the only access gained is read-only.

Making it even less risk, it's possible that the amount of effort required for such an attack exceeds the value of the information gained. For example, if an attacker can access a target's house, they could steal identification and request medical records be sent to them.

More importantly is editing of configuration. How do we determine who has access? In theory, we want any qualified medical professional to be able to change configuration in case of an emergency. Without a global network connected to the device, the device has no way to validate credentials, particularly revocation. Additionally, even assuming that every device has access to a global database, there would be too many authorised users to ensure security. (Just like large government databases.)

Is this a threat? Some people may think this is a far fetched idea. Certainly today this is not a widespread fear. It may be a neat way to carry off a attack against a single target, but I doubt it'd be effective for major attacks. But how long will it be until a large percentage of the population carries some kind of embedded device? Pacemakers, medicine delivery systems, vision implants, hearing, digestive -- the list goes on.

The bottom line is that humans will carry more embedded technology, and this technology must be secure *and* accessible. A system where losing your private key means surgery is not usuable.

The easy solution

As far as I can tell, the only solid way to ensure security with today's technology is to add a hard link. In order for anyone to modify configuration, the configuration device must establish itself over a physical connection. This ensures no remote attacks are possible. This would take away little to no convenience -- before editing yourself, you'd have to let them physically connect a device to you.

The same could be done for remote devices. Let's say your doctor wants to adjust your body remotely. You'd simply key the remote device[s] to your doctor, and key yourself to the remote device[s]. You've established a chain of trust that's easy to clear and recreate later. There is no global database, simply yourself and devices you touch.

This mimics what you have in the real world: You trust your doctor after you establish a relationship with him. You can then call him on the phone and you trust his advice to take more or less of the medicine.

A quick note on the details: The medical devices themselves don't need hard lines to the hard configuration interface. Indeed, your "hard link" could be a special device keyed to yourself. However, embedding this device into the body means you won't lose it and it'll be readily accessible to medical teams, even if you're unconscious.

To protect against damage to the hard link device, I suppose a backup key could be made authorized. You could then store it safe, by yourself (as in, with a bank's security deposit box, not the database of the device manufacturer).

The general solution

However, this only secures us as much as we can trust the authentication. But it still relies on manual revocation and trust editing. It may be acceptable to Verisign when they accidentally issue a certificate in Microsoft's name to an attacker, but it is not acceptable for humans. Specifically, in a short vulnerability window, you could die.

The real solution, and one that we're going to need eventually across all technology, is intelligence. Specifically, a machine intelligence that determines if what is happening or what is requested is dangerous. This is the only way that we will have security moving forward.

This kind of intelligence is what we use to protect ourselves now. If the water comes out glowing green, we decide we won't trust it, even though we do trust (in general) our public water system. If you see your doctor and he recommends moving from 5mg to 500mg of Xanax a day, you'll immediately revoke his trust.

Attacks will adopt this kind of intelligence. A hacker uses a vulnerability to gain access and then attack other systems from there. How long will it be until attacking programs themselves replace the work done by the hacker?

Our software and machines will have to adopt this kind of intelligence to thwart such attacks. It will no longer be "oh, sorry you got hit by malicious code from clicking on a hyperlink, please reinstall your OS". As long as humans can be killed by the devices in use, the stakes are too high for even tiny vulnerability windows.

Well, after almost exactly 6 hours, I've succeeded at installing SQL Server 2005 Reporting Services on a server with more than one website.

We're running Reporting Services on separate web servers. So, after the install of reporting services, you run their little configuration tool. This of course, accomplishes very little :). See, apparently Reporting Services wasn't designed to work on a server running, *gasp*, more than one application.

If you have a decent IIS install, the default website isn't there and thus requests to http://localhost/ aren't gonna work. Reporting Services doesn't take this into consideration, and happily tries to request http://localhost/ReportServer/ even after you've specified this in the config tool. If this is your issue, you'll get a “HTTP Error 400: Bad Request“ when trying to access the ReportManager (/Reports/) website.

You'll need to edit the config files in Program Files\.....\ReportManager and ReportServer. rsreportserver.config needs to point to http://the.reporting.host.name/ReportServer in the UrlRoot element. In RSWebApplication.config, ReportServerUrl will need to have the same value. The ReportServerVirtualDirectory element must be deleted. You will get a “The configuration file contains an element that is not valid. The ReportServerUrl element is not a configuration file element. “ message. This is because the config reading code apparently doesn't fail gracefully. What it's trying to say is “the ReportServerUrl and ReportServerVirtualDirectory elements are mutually exclusive”. I'm still unsure why there should be anything besides a URL...

Around here, you might notice a bunch of DCOM errors in your Event Log (or before this point). To fix these, you'll need to go into dcomcnfg and edit the COM security for My Computer. Give the account you're using (like Network Service or “MyReportingServicesAccount“) permissions for local activation and local launch. You need to reboot for these changes to take effect (I think). But don't reboot just yet...

Finally, you end up with a 401 Unauthorized when accessing the Reports site. You might have also noticed you are also unable to authenticate when browsing the Reports or ReportServer sites from your the local server. Why?
“Windows XP SP2 and Windows Server 2003 SP1 include a loopback check security feature that is designed to help prevent reflection attacks on your computer. Therefore, authentication fails if the FQDN or the custom host header that you use does not match the local computer name.” So I'm guessing NTLM susceptible to this type of attack, and Microsoft is saving us from it. Well, it also hoses us in this case because from what I can tell, ReportManager (the thing in the Reports vdir -- why it wasn't called ReportManager by default...) needs to connect to ReportServer. It sends a request, which is denied because of the loopback protection above. A quick registry edit fixes this: http://support.microsoft.com/default.aspx?scid=kb;en-us;896861

After that... you might have a working SQL Reporting Services 2005 install! (Next up: Getting it to work with SSL...)

Really, apart from the horrible setup/configuration, it's a very very fine product. I'm actually pretty impressed. The report I wanted to setup (and the subscription so it's mailed out) only took about 10 minutes (first time I've ever used RS)! I'm just at a loss why Microsoft makes it so hard to setup. This configuration can't be that unusual. And, even stranger, most (if not all) of this configuration issues could take care of these problems. In other words, their little configuration app should automatically fix this stuff (or at least give explicit instructions on how to do so). Or maybe I just didn't RTFM that well... but this is a Microsoft product... you're supposed to just shove the DVD in the drive and click next, right? <g>

P.S., if you're getting a “Object Reference not set to an Instance of an Object“ when you add a new subscription, ensuring everything else is 100% working should make it go away...

I've spent a few hours trying to get the secure TCP (based on NegotiateStream) integrated security in .NET 2.0 working. While there is a page on this (Authentication with the TCP Channel), it fails to mention that you need one more property in addition to encrypt, impersonationLevel and authenticationMode. It's called “secure”, and it must be “true”. I didn't see it mentioned anywhere, except when I happened to browse the MSDN Forums: http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=55225

I looked at his config, and realised I didn't have this “secure” property. Problem solved. Also, I recommend checking out http://pluralsight.com/wiki/default.aspx/Keith.GuideBook/HowToAddCIAToDotNETRemoting.html, which has a lot of information about Windows security in general, apart from some specifics of remoting and Kerberos. And, finally, yes, there's one more page where the secure attribute is listed (with some other docs) http://blogs.msdn.com/manishg/archive/2005/04/22/410879.aspx

OK, so perhaps there was some error between the user and the keyboard... but I'm very very excited to see this feature running.

Apparently this was recently published: http://www.securityinnovation.com/resources/linux_windows.shtml

To summarize, RedHat Enterprise Linux 3 had 132 security issues (with a minimal configuration), whereas Windows 2003 had 52 for calendar year 2004, *when configured as web servers*. This includes a webserver (Apache/IIS), app platform (PHP/ASP.NET), and DB (MySQL/MSSQL). Only issues fixed in 2004 were counted.

A few points:
 - They took a default install of Windows 2003, stating that it's too hard to get rid of stuff like IE. Thus, any patches applying to Windows2003 were included, regardless of if they could be exploited or not. This of course affects Windows' rating.

 - Same for RHEL. RHEL installs a lot of stuff that might not be in use and not exploitable. I'm guessing that what accounts for the very high numbers on RHEL. Then again, it's a fair comparison for average users (like myself, who just installs RHEL/Windows out of the box and doesn't really screw around with a lot of stuff).

 - However, assuming super-competent admins on both platforms, I'd expect the exploitable vulnerabilities to be close to zero on both platforms. I.e., if admins took precautions to install patches quickly as well as lock down services/systems as soon as a vulnerability was discovered. However, that's not realistic at all, and that's why a study that just takes a standard install is needed.

 - They used MySQL on RHEL. While this might be correct since people use it... MySQL is junk. Seeing as how it could be barely considered a DB and how poor it is overall, I wouldn't be surprised if MySQL accounted for a large amounts of vulnerabilities.

I think the study should have broken down where the vulnerabilities were in the product. Not knowing what was the fault of IIS, or MySQL, etc. makes it hard for people to compare the products for their own usage.

The study also mentioned the “Days of Risk“, i.e., from when the vulnerability was first publically reported to when it was fixed. RHEL will always have an instrinsic disadvantage here. Since most issues are related to open source, it's harder to do private reporting.

Second, there are vulnerabilities in Microsoft software that are fixed, but never reported. For instance, IIRC, the “GIF Integer Overflow” problem that was found after some Windows source was leaked was fixed in newer versions of IE/Windows, but never reported (until the source was leaked). I also know that from personal experience, you can report a bug to MS, and if you don't go public with it, they'll roll it up in an SP or next release. These issues are just [almost] intrinsics of open vs. closed source.

Some might say, “Oh no, there are issues in Windows 2000 that aren't publically published!“, but the same exists for RHEL. The difference is that some of these “private“ issues can get fixed in newer versions without ever becoming public, while in open source, it is much harder to do so.

Now, some people are up in arms since it was not disclosed that the funding came from Microsoft. Bruce Schneier, for instance, is saying that people will just ignore the results and focus on this possible bias. That's BS. Since the methodology is published, it's not exceedingly difficult to recreate the results. People should do that instead of bitching about who funded the research. My guess is that people who are satisfied with the results don't care to go recreate them, and those who aren't are afraid that they'll find the same results and thus have no argument.

CNN has a story about american high school kids who don't know what free speech is. (Thanks BoingBoing!) 

Wow. Double wow. Are kids really this clueless? Are they really such idiotic sheep? Through an intense, multi-year study* that I've done, I know that many kids are idiots. But now they're just gonna go and screw themselves over? Maybe these kids LIKE CSS and Region Encoding? Perhaps the MPAA are visionaries and are actually marketing to these people?

Sigh... I'm frightened by the attitude and lack of critical thinking I see in most adults in the states these days. I'm surprised that most americans do not know what made their idea of government any good. Here's a hint: It's not poor cars and bad food. The USA started out as a good idea because it had a government that was built to limit itself. These days, people just think it's about capitalism, immoral behaviour, and whatever other base thing that comes to mind.

The thought of these children growing up, and from an early age thinking that the government HAS or SHOULD HAVE more power... that's simply chilling.

So, Pulver launched a great new marketing campaign called Bellster. People are hyping this up as “Peer to Peer telephony”. I'm tired of P2P being abused as buzzword. The entire freaking Internet is a peer to peer system. But that's not what I really care about. People are joining up to Bellster without thinking what it means. There are two primary problems with Bellster.

1. *Most likely* your phone company has it outlawed, since you are reselling your service. In some countries, this might even be illegal, and in violation of local laws, in addition to your own contract. There is no such thing as “unlimited” calling (except perhaps, inside a certain network). If you go over what your telco thinks is acceptable for “unlimited” calling (somewhere between 1000-5000 minutes probably), you'll get charged, or cut off, or something. Other telco's might notice your calling pattern has significantly changed. If you use your phone normally, and then all of a sudden it jumps to 4 times volume and calls a wide range of numbers at a wide selection of times... software can flag that down, and you can get your line cut (it's called bypass). This will depend on each telco/country. Then again, maybe you hate the telco and want to stick it to 'em. If you get away with it... good for you.

2. It's all fun and games 'till someone gets hurt. (And then it's fun for one less person.) Sooner or later, someone's going to make bad phone calls via Bellster. The problem is that these phone calls come from YOUR phone line. So, when the SS investigates the latest terrorist threat, and finds it came from your line... ouch. I'd expect nothing less than a personal visit. Depending on how that goes... good luck. In the USA, I can only imagine what would happen. Sure, eventually you will probably get cleared and be OK. Meanwhile, are you willing to risk being imprisioned, questioned, perhaps having your computers confiscated, etc. etc.?

In light of those two things, who on Earth would use Bellster? My local calls are more money than what I pay to call half the world with VoIP (yes, even at my commercial, retail rates, not wholesale carrier rates). So *I'm* not going to share my line to call Canada when I can already do that for very cheap (not to mention that if I did share my line, within a month or two it'd be cut). Plus, I'm at the whim of whoever is running the service. I doubt the service level is gonna be that great.

So... potential risk... zero benefit... why would I do this? THINK people, THINK!

I hope the days of running arbitrary CPU instructions to perform every single task come to an end soon.

I hear people complaining about how MS doesn't make them secure enough. I hear from the other end (i.e., the pros) that we have to have user education. I read about parents having to filter their kids' computers, ensuring they don't run malicious code (not “bad content“, such as pro-Bush propaganda, but code to take over a PC). People run anti-virus software. People are now running Anti-unwanted-commercial-software programs. Heck, in some cases, there's even Anti-anti-spyware code out there.

We hear about having to “ensure we trust the source”, as in, “do I trust Bob to send me a web site link”? Not even a program, *just a link*! We have the “don't execute attachments” and “don't install code from websites”, on and on and on. Some people even think there should be a “Internet drivers license” or even some sort of basic PC user training/license.

This has got to stop. It's been shown that we'll never be able to get average people to make correct trust decisions. It's also stupid to want to do that. If someone writes up a cute “Flying Bunnies.exe” game, I WANT to be able to run it, without worrying that it's some kind of attempt to hack me.

.NET gives us the first level. We have code access security, which can ensure that certain code running can't do certain things. Next, we need an OS that takes this home.

It looks as if we'll be having a little girl this May. By the time she's old enough to have her own real PC, I hope these things will be an issue of the past. When I got my first computer, I was 5. I was already somewhat familiar with DOS; I knew my way around. How different would that have been, had I have to understand a full set of security and trust related data? How much slower would I have gotten into things if it had to be accompanied by a ton of overhead just so that I wouldn't get hacked?

If Microsoft embraces managed code fully (and it looks like they are), this should not be hard. Managed programs should just run. Get an email attachment? Just run it! See a cute game that needs rich UI controls from the web? Should be automatic. Only when an unmanaged EXE comes along should we run into roadblocks. Indeed, any program requiring trust should require us to login as admin (or elevate to admin) and allow it.

So, in about 5 years, I hope to be buying a nice little PC for my child. I want to flip it on, use biometrics as her password, and LET HER PLAY dammit! If she finds a bunny program, I want her to be able to run it. Now, I'm hoping my kids will follow after me and understand computers enough to make those decisions for themselves (heck, and for other people :)), but I sure don't want that to get in the way.

The same applies to pretty much everyone else (yea, I'm saying a lot of users aren't much more advanced than a 5-yr-old). We can't expect people to make security decisions. We simply MUST have a way for things to get done, without security implications. I think at this stage, this is entirely possible.

MVP Patrick MacKay down in Chile has finally gotten his Spanish primer on encryption up on the MSDN site. Check it out here: Desmitificando la Encriptación (Parte I). Not to boast or to brag, but I drew the little face that's used to show off the cipher modes :).

It appears as if Microsoft's Windows Media DRM protection sucks in yet another way. Some evil people are using Windows Media files to open popups, which then try to confuse users into installing spyware and so on. I can imagine that perhaps this is even by design (when you try play protected media, it wants to send you to a website so you can purchase a license).

Some companies are now trying to trick users into downloading these files, and then take advantage of the extra confusion since the Windows open from WMP (”What the... I have to click this? Huh? Must be related to this new Windows Media Player...”).

While this “hole“ isn't *that bad*, since, AFAIK, all it does is fire up a browser (ok, that can be pretty risky, depending on the circumstance, and perhaps it can easily be used to escalate?), why is this even happening in the first place?

  1: Microsoft builds DRM into it's media system, even though no users are asking for it.
  2: Microsoft then turns ON these features by default -- features that connect to arbitrary sites without the user doing any action remotely related to Internet access.
  3: User gets burned, and some crafty devil-developers are happy.

How is this good? If MS would just wake the hell up and do what's right, instead of continuing to cater to media executives, we'd all be a lot better off.

Patrick Mac Kay, a Chilean MVP, gets into IL cracking fun, en español. He says he wasn't sure how to do it before, but after my quick tutorial, had “enhanced” a program to handle more data. What have I done? :)

MVP Valery just wrote a cool little utility to assist people running as non-admin. A little key icon that sits in your notification area, and allows you to escalate your privs. Similar (in some ways) to how Gnome handles running admin things. Very nice.

I came across this program, called “Hector Protector”, created by the NetSafe Programme of New Zealand. It's to “help keep kids safe online”. What does this program actually do? It puts an image of a dolphin on-screen. Kids who run into materials that frighten them should click the dolphin. At that point, a congratulations message and picture of a dolphin fill the screen, protecting the poor child. The idea is that kids can do this and then run and find their parents or teacher to help them with the bad things on the computer.

Are kids these days really so helpless that they need a bloody dedicated program just to hide a window? I've been using computers since before I can remember. I never needed a system to hide stuff from me. I was on BBSs since I was 8 or 9 or something. Hell, when I was 13, my friend and I ran a BBS, complete with an “elite” section of programs, images, etc. He even worked as a sysop for other places, checking out all uploads and adding descriptions. He didn't need a stupid program to keep him safe. Why is it that kids now have turned into (or people think they are) such wussies when it comes to computers and networks?

Also, what's wrong with “If you see something wrong, minimize the window and go get help.”? Are kids going into such a bloody panic they need a damn dolphin there to click on? They're so offended and frightened they can't hit the minimize button? Also seems like a missed opportunity to teach keyboard shortcuts (say, Win+D). Or, what's wrong with just standing up and going to get help?

I'm not against helping kids deal with things. But technology isn't the answer. That's what parents and teachers are there for. Providing crutches like this? Please.

And... what happens when kids stuble across bad animations of Hector doing things he shouldn't? Won't this confuse and scar kids even more? Or what happens if kids happen to stumble upon some dolphin + redhead footage? Just think how many kids' lives are been wrecked by trusting hector, only to find he scares them later!

Security sells quite now, and lots of companies like to cash in by making up fake security threats, and then selling a “solution“. One such company is the “Internet Security Foundation“ which is just a clever marketing name for “Some Lame Company Trying to Sell Free Tools“.

When you goto the site (InternetSecurityFoundation.org), they make a big deal and a fake security alert from Sept. 2004 that you can see the text in a textbox, even if Windows renders it as asterisks. Anyone who programs understands this. These people pretend it's some kind of new threat and that terrorists are using it over the Internet to rob bank acounts. What a load of crap!

Why do they do this? They want to sell you “SeePassword“ (SeePassword.com), a $20 utility to do the same thing as the free Glow Password Recovery Util (download: Glow.exe (14.5 KB)) -- or similar programs, which have been around for YEARS.

The REAL issue lies in each individual program passing around passwords in plaintext. If a password is sitting in a user's memory space, in plain text, then why is it a surprise that it can be seen? Oh wait, it's not a surprise. This company is just using security for marketing.

Oh, and interesting info on their domain name registration. Perhaps I shall give them a call.

Registrant:
   KMGI Corp.
   119 72 St., 339
   New York, New York 10023
   United States

   Registered through: GoDaddy.com (http://www.godaddy.com)
   Domain Name: INTERNETSECURITYFOUNDATION.ORG
      Created on: 29-Oct-04
      Expires on: 29-Oct-05
      Last Updated on: 29-Oct-04

   Administrative Contact:
      Corp., KMGI  ak@kmgi.com
      119 72 St., 339
      New York, New York 10023
      United States
      17032427114      Fax -- 12122024982
   Technical Contact:
      Corp., KMGI  ak@kmgi.com
      119 72 St., 339
      New York, New York 10023
      United States
      17032427114      Fax -- 12122024982

   Domain servers in listed order:
      NS2.KMGI.BIZ
      NS3.KMGI.BIZ

Edit: Fix .com to .org (Although both appeared to be registered by the same thing).

Intro
It's been a while since I wrote anything that interesting, so I figured for Thanksgiving, I'd go ahead and do so. Merry Thanksgiving. The first article in this “series“ is here.

Cracking .NET programs can be just like cracking any other program. In this article, I'm going to use the same approach as I did last time. I threw together a quick little program called CrackMe2. CrackMe2 has a really cool feature called “Reverse Text”, however, it's only available to registered users. What's a poor boy to do?

Target
First, we try registering. Since we don't have a valid code (we don't even know what one looks like), we get an “Invalid serial.“ MessageBox. OK, so now we know that the program does something when we click a button, and if the serial is wrong, we get a MessageBox.


Darn, 123 didn't work.

Well, the first step in cracking is defining our target and it's location. Our target is the code that's deciding to say “Invalid serial.” instead of “You're registered!”. Where's the “bad code“ that needs to be fixed? Well, with a .NET assembly, our first information is gained by taking a look with IL DASM.


View of the obfuscated CrackMe2 assembly

Oh no! It's obfuscated (thanks to Ivan Medvedev's Mangler). Let's assume this is a big application and that we'll never find what we're looking for just by going through the IL. Just by glancing at the hierarchy, we don't know that much more than when we started: There's a form with code.

Seeing past the names
Now certainly, we can do static analysis and try to find out where the bad code is. One way would be by getting the strings (Ctrl+M in IL DASM, scroll to the bottom), and then grep the IL for ldstr , and work from there. In fact, that's a pretty quick and easy way to locate certain parts. However, lets pretend the strings are encrypted/dynamically generated, and that's not viable. So, let's start debugging.

[Michael@MAO C:\]$ cordbg CrackMe2.exe
Microsoft (R) Common Language Runtime Test Debugger Shell Version 1.1.4322.573
Copyright (C) Microsoft Corporation 1998-2002. All rights reserved.

(cordbg) run CrackMe2.exe
Process 4488/0x1188 created.
Warning: couldn't load symbols for c:\windows\microsoft.net\framework\v1.1.4322\mscorlib.dll
[thread 0x1510] Thread created.
Warning: couldn't load symbols for C:\CrackMe2.exe
Warning: couldn't load symbols for c:\windows\assembly\gac\system.windows.forms\1.0.5000.0__b77a5c561934e089\system.windows.forms.dll
Warning: couldn't load symbols for c:\windows\assembly\gac\system\1.0.5000.0__b77a5c561934e089\system.dll

[0004] mov         ecx,98543Ch
(cordbg)

cordbg is a command line debugger that ships with the .NET Framework SDK, and it's just loaded the CrackMe2.exe and related assemblies. Just like before, we're going to go ahead and set a breakpoint and find out where we are in the program, and work from there. So, let's breakpoint the MessageBox.Show function. We use IL-similar syntax to specify the function name: NameSpace.ClassName::Method.

(cordbg) b System.Windows.Forms.MessageBox::Show
Breakpoint #1 has bound to c:\windows\assembly\gac\system.windows.forms\1.0.5000.0__b77a5c561934e089\system.windows.forms.dll.
#1      c:\windows\assembly\gac\system.windows.forms\1.0.5000.0__b77a5c561934e089\system.windows.forms.dll!System.Windows.Forms.MessageBox::Show:0      Show+0x0(native) [active]
(cordbg)

Then, we tell cordbg to go until it breaks by typing go. The form comes up, and we enter a serial number: 123.

(cordbg) go
Warning: couldn't load symbols for c:\windows\assembly\gac\system.drawing\1.0.5000.0__b03f5f7f11d50a3a\system.drawing.dll
break at #1     c:\windows\assembly\gac\system.windows.forms\1.0.5000.0__b77a5c561934e089\system.windows.forms.dll!System.Windows.Forms.MessageBox::Show:0      Show+0x0(native) [active]
Source not available when in the prolog of a function(offset 0x0)

[0000] push        edi
(cordbg)

Bingo, we're stopped at a MessageBox. We want to know who called this function, since most likely, that will lead us to the critical code section we need to fix. So, we ask cordbg where are we?

(cordbg) where
Thread 0x1510 Current State:Normal
0)* system.windows.forms!System.Windows.Forms.MessageBox::Show +0000 [no source information available]
                owner=(0x00ac36b0)
                text=(0x00ad5854) "Invalid serial."
1)  CrackMe2!CrackMe2.Form1::AAAAAAAAAAAAAAAAAAAA +0070 [no source information available]
                AAAAAA=(0x00ac8400)
                A=(0x00aca86c)
2)  system.windows.forms!System.Windows.Forms.Control::OnClick +005e [no source information available]
                e=(0x00aca86c)

9)  system.windows.forms!ControlNativeWindow::OnMessage +0013 [no source information available]
                m=(0x0012ef04)
--- Managed transition ---

We see what's expected. Somewhere in Win32 code, a message was sent, and we see the OnMessage called and bubbling up all the way to the Control::OnClick, and then user code. We can look at all the arguments along the way, and that's useful for more complex scenarios (say, when a registration function calls another passing the serial number or validation code).

At any rate, we've got something to go on: The name of the function that calls the MessageBox: CrackMe2.Form1::AAAAAAAAAAAAAAAAAAAA (20 A's). We're done with cordbg (quit). Our next stop is to read the bad code.

Looking at the bad code
Using IL DASM (see above), I navigate to the CrackMe2.Form1::AAAAAAAAAAAAAAAAAAAA method. Inside is relatively straighforward code. First, there's a try/catch that has an Int32::Parse call in it. The result is stored in local 0. So we now know the code is numeric. Immediately after the catch handler, we have this snippet:
  IL_0022:  ldloc.0
  IL_0023:  ldc.i4.1
  IL_0024:  and
  IL_0025:  ldc.i4.1
  IL_0026:  bne.un.s   IL_0035
  IL_0028:  ldarg.0
  IL_0029:  ldstr      "Invalid serial."
  IL_002e:  call       valuetype [System.Windows.Forms]System.Windows.Forms.DialogResult [System.Windows.Forms]System.Windows.Forms.MessageBox::Show(class [System.Windows.Forms]System.Windows.Forms.IWin32Window, string)

Load the local (the number entered), then load the number 1, and AND them. Then, load one, and if they are not equal, jump to IL_0035. If they are equal, execute the following instructions, which quite obviously say “Invalid serial.”. AND'ing a number with 1 and comparing to 1 is a check to see if the number is odd. So, at this point, we can write a keygenerator that produces... even numbers. A keygenerator is always preferred to a patch, however, generally speaking, finding the algorithm might be a bit harder. Then, there's always the possibility that the check actually does something hard to fake (i.e., uses RSA or talks to a hardware dongle/web service). So, let's go on and patch this code.

At IL_0035 (the target of the branch if the number is even), we have some code that does activation work and then proceeds to say “Thank you...”. Simple sample. Now, let's make the fix.

Simple Patching
With IL DASM and IL ASM, we have a really easy way to make patches. Simply run ildasm /out=CrackMe2.il CrackMe2.exe, and IL DASM will dump all the IL required for that assembly to a nicely formatted file. All we have to do is goto the bad method and fix up the IL. I think the most unintrusive fix would be to add “br IL_0035” to the top of the method. That would branch immediately to the good code, and the product would activate on any serial number entered.

However, some obfuscators try to stop IL DASM round tripping, and that might stop some posers in their tracks. The IL obfuscator I'm going to give away for free will do this, for example. (Actually, my free obfuscator would make this tutorial a bit harder because of how it handles names -- we'd have to actually get a token instead.)

Assuming we can't use IL DASM/ASM, what can we do? Use a hex editor.

Binary Patching
When we can't reassemble an entire program, we can patch certain opcodes instead. Tools like OllyDbg have a built-in assembler so we can easily make patches to the x86 code. For IL, I'm not aware of any such tool. Another issue with binary patching IL is that we have to ensure the resulting IL is fully correct and is able to be JIT'd to native code. If our patch ends up screwing with the IL in a way that makes it incorrect, we'll get a runtime exception from the execution engine. Let's try to create a binary patch that jumps from the beginning of the method right to the good code, at IL offset 0x0035.

First, in IL DASM, turn on “Show bytes”, under the View menu. This allows us to see the actual bytes that make up the opcodes. Now, lets look at the beginning of the critical function:

  // Method begins at RVA 0x2434
  // Code size       78 (0x4e)
  .maxstack  2
  .locals init (int32 V_0)
  .try
  {
    IL_0000:  /* 02   |                  */ ldarg.0
    IL_0001:  /* 7B   | (04)000002       */ ldfld      class [System.Windows.Forms]System.Windows.Forms.TextBox CrackMe2.Form1::AAAAAAAAAAAA
    IL_0006:  /* 6F   | (0A)000026       */ callvirt   instance string [System.Windows.Forms]System.Windows.Forms.Control::get_Text()
    IL_000b:  /* 28   | (0A)000027       */ call       int32 [mscorlib]System.Int32::Parse(string)
    IL_0010:  /* 0A   |                  */ stloc.0
    IL_0011:  /* DE   | 0F               */ leave.s    IL_0022
  }  // end .try

This code is protected in a try block. We could go and remove the try block, but that's modifying more code. Generally speaking, we should aim to patch as little code as possible to ensure we don't accidentally screw something up. So, we're going to deal with the try block and fix it from within. The ECMA specifications for .NET will come in handy here. Specifically, Partition III, CIL. This can be found in the .NET Framework SDK folder, under “Tool Developers Guide\docs”. It's also available from MSDN, here.

The first instinct is to say, hey, let's change IL_0000 to a br to IL_0035, and NOP out the remainder of the try block. However, that'd create illegal code, since you can't branch out from a try block, you must use the leave opcode instead. So, let's rewrite the method to simply leave to IL_0035. Here's the description of the leave opcode:

The leave instruction unconditionally transfers control to target. Target is represented as a signed offset (4 bytes for leave, 1 byte for leave.s) from the beginning of the instruction following the current instruction.

The formats (in hex) are DD <4 bytes> for leave and DE <1 byte> (as shown above), for leave.s. We'll use leave.s, just to be efficient :). Since the total size for leave.s is 2 bytes, we calculate the offset to 0x35 from 0x02 (since our leave instruction is at 0x00). Subtraction tells us we must have an offset of 0x33. Hence, our leave instruction in hex looks like: DE 33. Since that'd leave the IL in an incorrect state, we must nop out the rest of the try block. The hex for nop is 00.

Open the assembly in your favorite hex editor, and let's find the method. IL DASM gives us the RVA, but for now we'll just search for a specific byte sequence. The IL DASM Show bytes allows us to easily find our place. Do note that the way tokens are displayed ((04)000002, for example), is reverse from how they are stored. Depending on the size of the app, you might need to search on quite a large number of bytes, since IL sequences are most likely repeated. For this case, we're going to search on the last bit: “0A DE 0F”. No other matches found, so this is the one.

As when programming, in cracking we have many ways to solve a problem. Many of them can be considered “right”. We could make a simple one-byte patch by allowing any number as a valid serial. This has the merit of ensuring the local int is assigned, and well, being only a one-byte edit. The leave.s opcode is at offset 0x11, so add 2 to that amount and we get 0x13. 0x35 - 0x13 = 0x22. So by changing “0F” to “22”, we'd have our crack. However, let's stick to the original plan and jump right to the good bits from the beginning.

In the hex editor, we back up a bit until we find the 02 7B 02 00 00 04 part (ldarg.0, then load the textbox field). At the 02, we drop our leave.s IL_0035 payload, which is DE 33. Then, we nop out (00) everything until the end of the 0A DE 0F part. The resulting hex for the try block is thus: DE 33 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00. Save the file as CrackMe2.cracked.exe.

Satisfaction
Run the program. Type in anything for the serial. “Thank you for registering.” The second textbox activates. We've won access to the coveted “Reverse Text” function. Write up an .NFO, ensuring to remind people to purchase software to support the authors. Then kick back and play a game of KSpaceDuel.

Download the program itself (Right click and save as, since it's a .NET assembly and IEExec will try to run it otherwise): CrackMe2.exe (24 KB). Or, download the source: CrackMe2.cs.txt (4.81 KB).

Was this post interesting, helpful, stupid, or lame? Leave a comment and help me improve.

Digital Rights Management has been and will continue to be a hot topic for a while. On the one end we have the MPAA and the RIAA who are stuck in the early 1900s, and intelligent consumers. In the middle, we have people like Microsoft, who have to try to satisfy both ends of the scale. Then, there's some lesser companies that make DRM (like MacroVision) who even beyond the MPAA and RIAA, in the sense that they try to propogate the need for their useless technology.

Why is DRM bad? Because it hurts the customer. It takes the flexibility and usefulness of a technology away. It's anti-innovation. No one wakes up in the morning and says “Hmm, I'd like to pay money to do less than I can do for free.” That's exactly what DRM does for consumers.

Some people defend DRM, saying that if there was no DRM, then people would copy things left and right and collapse their industry. Apparently these people have never heard of eMule or Kazaa. Crackers and pirates are going to bypass whatever system you have installed anyways. Except for simple protections (say, an easy-to-use activation system that doesn't require an Internet connection), putting extra runtime checks in that interefere with operation makes things worse for your customers.

This doesn't mean you shouldn't encrypt your binaries or run them through an obfuscator. It means you shouldn't have software that polls in the background for debuggers that might be running, or secret checks on the CD to ensure it is legitimate.

For instance, take my post about stupid copy protection like SafeDisc: Here, a legit customer is suffering from the stupidity imposed by the corporation: You MUST SafeDisc all releases. In fact, me, a legitimate customer, had to turn to getting a pirate crack to be able to use the software I purchased. Had I pirated it to begin with, I'd have never run into trouble. In fact, check that link out, and look at all the search referrals. A LOT of people are having the same problems. The solution? Don't pay, just get a crack. Again, DRM messing things up.

Same thing for some of those dongle-based protection systems. If the software is worth it, it'll get cracked. However, legit customers don't get a crack. So, when their dongle fails, they get rather annoyed. Ask some Autodesk/discreet customers about that, and I'm sure you'll hear some great stories. Nothing like shelling out $$$$$ to get a top-of-the-line system, only to have your software say “Hey, you don't have a dongle. Theif! Call and buy our software!” a day before deadlines.

So, besides pissing customers off, does it hurt companies? Well, yes, and quite directly. An average user, say, someone with an Autodesk product, might not go into cracks, thinking every crack download has a virus and whatnot. They might not want to/care to/be able to install them. However, when the company FORCES the customer to figure it out (i.e., to meet your deadline, or to copy some music in time for a party, or to just bloody use the software you paid for), that customer now KNOWS how to work the pirate scene. The customer sees that well, no, cracks down erase your hard disk and delete your work while infecting every machine on the network with a virus. In fact, in some cases, things might work even better (like a SafeDisc game that pauses the game every few minutes to search for the CD).

Now what? Well, you've taken an innocent customer, and forced him into piracy once. Next time he needs 1 more license, he's got one less reason to purchase it. Next time there's a choice between running down and buying a DVD, or downloading a rip from the net (and avoiding region issues), there's less incentive to buy. “Average Joe” customers who would never have used a crack before (even if they wanted to), now might go ahead and do that. And recommend/show to their “Average Jane” friends.

And unlike earlier MacroVision stuff that protected analog tapes (ever try to copy a rental to VHS?) that required small $10 hardware cleaners to fix, things in the digital domain and on the Internet don't require any special hardware. Installing a crack can be as easy as 3 clicks. Deprotecting content can be done with a single click. Hell, Windows even asks me to decrypt DVDs when inserted in the drive -- no clicks required if I so desired!

I wonder how long it'll take people holding IP to realise that working WITH their customers instead of treating everyone like the devil will help them. It seems pretty obvious to me and everyone I've talked to. I wonder why it's so hard for them?

BroadVoice released a patch for Asterisk that fixes some issues with SIP registration. They hired people and made a commercial patch. Way to go.

Then, they decided to *email* it to customers. Yes. In 2004. A company emailing patches to customers. Apparently they didn't think this was dumb. No link to their web site, no secure download from their website, nothing. In fact, the email was signed “The BroadVoice Team”, which is the signature I remember seeing on a few virus emails.

So, I responded to the Asterisk-users mailing list about this patch, saying how it was utterly ridiculous to do this, as it teaches customers to not be secure and go blindly installing stuff. Here are some of the comments I got back (and they aren't sarcastic either!):

“the patch is pure c code. it took me 5 mins to read & understand it. is very simple (but useful).
Simply that patch (apart from adding some logs, comments and little code formatting) simply caches auth data AND let * manage 403 responses from the server, and this last one perhaps is the issue that was overloading BV .
so, just read it (or let someone do for it) and understand that's not a problem :)“

“I don't see a security issue with his method. If you (a) read the entire patch and (b) comprehend fully everything that it does, then there's nothing to worry about. Fear comes from the unknown, and if you know everything in the patch, there's nothing to fear. “

“To claim that someone opens a security hole by accepting a verified patch via email, is the same as claiming that you never have a security hole just because you download from "trusted" sites. Webservers can be hacked, you know. And not every buffer-overflow will lead to a security issue -- many just crash the system. “

So, I think this goes some way towards showing that all is not well as far as security mentality in open-source land. I pointed out to them that “even Microsoft does it right” :). Didn't seem to make me popular.

Thinking that you can just read the code and be set is equivalent to saying there should never be any security holes in any code because people will just read and know. Add to the fact that what you're combating is a possible *malicious* security hole, not just an accident, and I think most devs would pass things right over.

Windows decided not to load 2 of my hard disks (yes, I'm buying a RAID 1 setup tomorrow -- yikes!), so I wasn't able to access my music collection. I can't work at all without some sound. So I found a shared folder from KCeasy and lo and behold, it had a few interesting things in it, so I queue'd them up.

Well, one track was by Ayumi Hamasaki, and I quite liked it. So I thought, hey, I'll go buy the CD. $28, not that bad. Oh wait, what's this?

Shopping Note:
· This CD is copyright-protected. The tracks on the CD can be played on PC running Windows operation system, but cannot be copied onto any PC nor can they be played on Macintosh operation system.

Can be played on a PC, but can't be copied? Huh? That means they do Some Very Evil Stuff. If a CD can't be copied, then something seriously wrong is going on. Now, the only thing I've heard of is it that lame technology that puts a driver on your system to screw things up and then gives you access to WMA only. I think it comes from a company that has the word “Sun” in their name. The one that you can bypass by disabling Autoload.

Well, I don't play CDs, period. My playlists are huge, I'm using my DVD drive for other things, and I hate the idea of passing physical media around for no reason. I also despise any company that tries to covertly install drivers to destroy my computer.

So, what's the outcome here? Well, I'm not gonna buy the CD. The artist loses $3? Oh no. I'll still get the music (gonna queue it up right now), and if I like it, I'll be a fan and if I happen to be around where a concert is, perhaps I'll go. But as far as paying for locked down media? Screw 'em. In fact, if I'm going to PAY for the media, I'd like them to ship a professionaly encoded set of WMA tracks at 256Kbps along with the CD audio. Actually, heck, just send me the WMA files. I don't need CD-audio. Send me higher quality WMA files (higher sampling, higher bit depth, WMA Pro codec, lossless compression). Oh yea, and get rid of the lame attempt to use DRM. Then I'll buy.

I chose MySQL to use as my database, since I was writing on Linux, in C, and it just seemed like the easiest path. Can someone please say “you were so wrong”? MySQL has to the worst DB engine out there. It doesn't (ok, just added) even have support for SUBQUERIES! Barely has support for multiple charsets. And... binary(20) is NOT a binary field 20 bytes long. It's a char(20). You can't execute multiple commands in a single query. It's embarrassing to open source really. I don't know who could argue that MySQL is competition for SQL Server or Oracle and keep a straight face. Check this list out: http://sql-info.de/mysql/gotchas.html (I really love the part about date handling.)

On the other hand, it's very secure. www.kalea.com.gt <-- No checking of user input whatsoever. (BTW, my little article about Kalea made me a top search result for Kalea Guatemala -- while their site doesn't even show up.)  They take your querystring, concat it to their query, and off it goes. But guess what? Good luck trying to hack it. MySQL is so poor, doing SQL injection and achieving anything fun is nearly impossible. So much for adding prices to their site :). Oh wait, you can do a DoS by using the BENCHMARK expression and then encode/Sha1/etc.

So what am I going to do? Switch to SQL Server as soon as I get a release candidate done. I'm going to load Mono into my C app, and then transition into managed code and use some nice TDS libraries and have a good day with a database that actually works well. Had I done that to begin with, I'd be a few hours ahead of schedule instead of behind schedule...

Today I was coding a site, and I realised I needed an easy way to avoid automatic signups. So, I did what everyone else does: added a Turing image. Since I was coding in ASP.NET 2.0, I thought it'd be nice to try out the new ASIX image generator type page.

It's pretty nifty. Nothing that you couldn't do with an ASHX in about 5 minutes, but still pretty cool. What I like is that the template starts you off right where you can start coding against the Graphics object. This will definately make entry much easier for people who aren't as comfortable with these classes. In the past I've normally been against things like this (i.e., a whole set of code just to save some minor work for one specific case), but I think this was a pretty good thing to add.

Download the code here: Turing.cs.txt. This is for ASP.NET 2.0 -- just create a new ASIX and point it at the Turing class. But, it should be pretty simple to hook it up into ASP.NET 1.1. If anyone seems interested, or somehow I get more free time, I'll post the required ASHX handler. Anyways, from ASP.NET 2, all you need in your main page is this code: