In the Massei report there is a ton of wild conjecture that passes for proven fact. In the section dealing with the computer forensics however we run into statements that are
reproducibly falsifiable. That is Massei has findings of fact in his report which are not only contrary to literally thousands of pages of documentation published by Apple computer on how their operating systems work, but in fact can be falsified easily with every Macintosh computer sold in the last decade. This is the very height of exculpatory evidence, it is evidence that can be infinitely attested to. It is from an empiricist definition the very definition of a false statement. Now this attack on the computer forensics, may sound like me getting on a high horse and nitpicking. You might say something like "
sure Massei is an arrogant buffoon for claiming as a matter of law that he understands OSX better than Apple computer, but he was deciding a murder case not a computer case" and you would be right. But the computer forensics came up for very good reasons. The false forensics were the means by which the police convinced Raffaele to give an alternate alibi to his original one. That is without the computer forensics there is no reason to suppose that Raffaele and Amanda were not in his apartment watching Amelie at 11:00 when the prosecution believes that Meredith Kercher was killed. They have an alibi again and we can go back to trying to decide this case on the facts on not on Mignini's hunch. Moreover, if Raffaele has his 11:00 PM alibi then the prosecution doesn't have to argue their own medical examiner botched the autopsy to get their theory of the timeline to match what they consider the key material evidence. Suddenly we are back to the murder happening at 9:00, Amanda and Raffaele being blocks away, and if they were involved at all only being involved in the clean up. So this is a very big deal. I'm going to do my best to try and make the debate between the prosecution and the defense on the computer forensics understandable, so you can follow as much of this as you can take and at least people have a reference they link off of. The actual documentation submitted is very difficult to read because, IMHO, whoever wrote the documentation is parroting things they heard rather than understanding what they are writing.
The core argument between the prosecution and the defense has been regarding the use of
Encase which is a computer forensics tool. Encase was used to interact with Macs, running the OSX operating system on the
POSIX level, the stuff common to every
UNIX. So the prosecution did not look at anything which is OSX specific, for example the defense objected to the fact that the prosecution only examined the 3 types of timestamps used by POSIX vs. all 5 types of timestamps that OSX supports. The defense argues that there is evidence in some of the OSX files and flags showing signs of human activity, and that these signs are not present in the POSIX things that the prosecution examined. To give you an analogy If I were describing a book in Chinese I might have to talk about its color, its weight, the front cover illustration if there is one, the number of pages. That's a limited amount of information. While if I were talking about a book in English I could talk about its title, the description on the back or dust jacket, other books by the same author. And the defense's argument is that they have found evidence in that additional information proving human activity at the time of the murder.
Getting more specific the defense argues that there is exactly the kind of exculpatory evidence that could have been missed via. inappropriate methodologies in the windowserver.log file. Windowserver.log is part of OSX's
NeXTSTEP heritage. On most POSIX systems the sorts of messages in the Windowserver.log file would have been caught at the
X11 level, not by the windowserver and thus wouldn't have been logged. Since this is one of the key points in the appeal it is worth answering the questions:
- What does the Mac's windowserver do?
- What sorts of things does it log?
Take a quick peek at this diagram to the left. You can see basic I/O actions like typing on your keyboard or moving your mouse get dealt with at the lowest level by Kernel drivers these can also basic translations So user
hold shift - a - release shift - n - g - e - l - space - f becomes user
types "Angel f". Then the system needs context if the system is booting or in some sort of single user mode you don't want to send messages to a complicated GUI. The context determination is done by "Core Services". For hardware actions that are going to require interaction with end user applications, like spreadsheets, web browsers or games the message is passed through to the Windows Server. It then can handle the message itself, which is generally the case with mouse movements; or it can pass the message onto the correct application depending on where various things are on the screen, which is generally the case with keyboard input. Lets see an example of both. Microsoft Windows machines also have window servers and while things don't work quite the same, but close enough for this demonstation.
I want you to grab another window other than this web browser and move your mouse really quickly so that you keep covering and uncovering this line from various angles. Next I'd like you to reload this webpage and have the browser's rendering engine redraw everything. The first kind of redraw was fast. What happened was your window server saw the two windows were going to overlap, had already buffered what the applications wanted in their windows broke everything down into primitives and fed it to the your graphics card. When you changed your mouse direction the window server used the relative eternity of those hundredths of a second to repeat this process and the two windows passed smoothly. The second time we had the application actually redraw everything and let the window server know what was needed. Orders of magnitude slower.
So hopefully I've convinced you:
- To be grateful to your window server for the years of eye strain it has saved you from suffering
- Why the window server is a very credible witness to a human interaction with a computer. Exactly the sort of process that would know when Raffaele (or another user) was clicking his mouse or banging on his keyboard.
So you might think "perfect, we just ask the WindowServer what it was doing at the time of the murder and we either confirm or refute Raffaele's alibi". Oh if only it was that easy. WindowServer listened to your childhood coach about focusing on this play "keeping your head in the game". It is fast it lives unencumbered by the past, existing in a permanent now. Your obnoxiousness with the mouse and the two windows is forgotten. WindowServer itself is the perfect witness with an amazingly bad case of Alzheimer's. Oh but it does keep a log book a place where it writes down some important stuff, called windowserver.log.
I've highlighted where the Window Server sits on the OS side. This is just like our other picture but with more stuff on it, you still see hardware, kernel, core services, the window server, the application environments and the applications themselves. The point I wanted to make is where this plugs into on the OS side, the
Quartz system, if you are a Mac user this is probably not your first time hearing about "Quartz" the part of the OS that handles graphics for applications and hopefully seeing Window Server in this context helps you make the mental shift to thinking of this from the application's perspective. If you start to think in terms of Quartz then you can think of this as the applications make calls to the Window server to draw, resize, hide, and move windows using Quartz graphics primitives. It also handles extraneous interactions like the screen passing over, from the previous example. What you would expect Quartz to do. If you haven't heard of Quartz don't worry about it, The main thing you need to understand is that it sits in the Quartz layer that most applications use to handle the screen. If you look directly above WindowServer, you'll see references to Carbon, Classic... the various applications environments.
Cocoa has the best support for Window Server so lets look at this from Cocoa's perspective rather than the Window Server's as we switch over to the logging.
I've highlighted the NSWindow binding which is where Window Server interactions will occur. You can see it is inside of NSResponder, which makes sense, this is how the system is going to pass events to you as an application that it believes you need to respond to. Conversely creating a Window needs to create a reference with Window Server so it can manage it....
It is this interaction between NSWindow as an abstract binding and WindowServer as an actual entity that will generate log. Anytime for example an application requests something impossible, like a window bigger than the screen it is on, if an applications reports that it has no idea what do with a message that was passed to it, etc... Window Server writes a short message in windowserver.log recording this failure and then "uses its judgement" about how to handle the problem. If you look at your own windowserver.log (if you are on a mac) you'll see that depending on your applications somewhere from every few seconds to every ten minutes something like this happens and a note is recorded. They may seem a bit cryptic but they are designed for the applications programmers to see where and when these times when windowserver had to guess occurred.
Apple's documentation for the NSWindow class, discusses in detail what sorts of events specifically will generate log. For example in the section on setBackingType Apple indicates that if buffering is changed after initialization that will generate an error, a log entry in windowserver.log. I don't see any advantage in going another level deep but I hope the discussion above makes it clear what the connection is between NSWindow and Window Server, and why that documentation should be taken as authoritative on Cocoa applications generating windowserver.log entries.
For the other environments:
- Carbon the default is to register windows and get messages more or less like the OS9 windowserver unless kOSAModeNeverInteract is set.
- Java the interaction happens at the JRE level.
- Quartz-wm: handles the interaction for X11 applications.
- Quicktime has a lower level primitive that can peer with windowserver (this is complex)
- Classic didn't run on Raffaele's computer so we can ignore.
And that's basically it. Most every application uses Quartz, Quartz uses Window Server to manager the windows, Window Server logs all errors or anytime an application doesn't know how to respond to but mostly when they make an invalid request. Common invalid requests are documented. That is the defense's theory and it is fully 100% supported by Apple. I leave it to you whether you consider Apple or Massei/Mignini more credible on what generates log. Needless to say everything in this post is reproducible and verifiable on any Apple computer running OSX.
_
Let me move away for teaching for a second, and do a pure editorial. I've never personally done forensics in a case involving violence; when I've done it has always been theft or fraud or mostly just trying to figure out and reverse the cause of corrupted data that is driving the investigation. That being said a programmer's laptop should be analyzed more like you would a server and less like you would a general end user's. Encase is fine for Amanda or Meredith's laptops had the prosecution not "accidentally" destroyed them. I don't think it is appropriate at all for Raffaele's. Since he was doing a computer science thesis he's a programmer it is going to require a skilled operator to do the investigation things are not going to in most obvious places or setup in the most obvious way and your typical forensic analysis will be wrong. For example the prosecution focuses heavily on cache data, and that is exactly the sort of thing you would typically check on an end user's laptop to look for activity. I agree with the prosecution's thinking. Most end users on a Mac would have their cache's in /Users/[Raf's username]/Library/Caches and /Library/Caches. But on Raf's machine I'd want to check places like /opt/local/var/cache (Apple's Darwinports default cache location), /sw/var/cache (Fink's default cache location) and he might even have a personal one like ~/caches. Encase won't check for those sorts of caches and thus the investigators won't find these in a cache's report. I agree with Raffaele's defense's intuitively, professionally, the examination the defense argues should have occurred, is exactly what I would have done were I investigating. I do consider this to have been a mistake.
Moreover, I'll say it is the sort of mistake that a forensic accountant / examiner is likely to make; so at least on this point I don't see evidence of an intent to mislead the court. I think the prosecution is innocently incorrect. I hate to take Mignini off the hook ever, but I don't see signs of the prosecution deliberately lying on this point.
There is one another bad news for the defense. Raffaele being a programmer cuts both ways. Because he programs we can assume he knows or can easily learn how to have programs generate events that look like interactions with hardware. He also knows how to change the windowserver.log file. Which means on his system we have to consider the contents of these files less definitive than they otherwise would be. I'd want to look at samples of his code from that time to get a grasp on whether the computer is telling me is likely to be true at worst or highly likely to be true at best. I would scratch definite however in either direction.
