I am enamoured with all things Google. Especially the new Google Cloud Endpoints that run on Google App Engine for Java. Its magnificent. All I need to do is write my Entities and then write my end point classes that simply contain a get, insert, update or remove method. App Engine Cloud Endpoints does the heavy lifting and routing to give me a REST API that responds in JSON. I find it ideal when I am on a project and have a hard time recruiting Java developers.

I write the back end myself on GAE/J using Cloud Endpoints. Then I document my API in as close a look and feel to the Twitter API documentation. Then I ask search for skilled developers who have coded Twitter or Facebook apps who are familiar with using the respective REST API. For authentication, I can easily use OAuth2 and the GAE Users Service. This approach is great to build apps quickly and to not have to worry about handling and storing credentials. My users simply need a Gmail account or an OpenID account. But what of those times when you want to give your end-users a bigger choice? What if you DO want to handle and store user credentials? Well, then you’re kinda out of luck because there is still no support for handling custom authentication with GAE/J and Cloud Endpoints. You can, however, write your own authentication mechanism. This post is an attempt to get you started on this path.

Looking at the Java Source of Cloud Endpoints you will notice that your API method will receive the raw HTTPServletRequest object. This is a great start. With this, you can grab a hold of HTTP_COOKIE header variables.

public Food getFood(@Named("name") String name, HttpServletRequest req){
    Cookie[] cookies = req.getCookies();
}

It would be so awesome if we had access to the

req.getSession()

package net.zenconsult.server.model;

import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
import java.security.SecureRandom;
import java.util.ArrayList;
import java.util.Date;
import java.util.List;

import lombok.Data;
import lombok.Getter;

import org.apache.commons.codec.binary.Hex;

import com.googlecode.objectify.annotation.Cache;
import com.googlecode.objectify.annotation.Entity;
import com.googlecode.objectify.annotation.Id;
import com.googlecode.objectify.annotation.Index;
import com.googlecode.objectify.annotation.Serialize;

@Entity
@Cache
@Data
public class Session {
	private long expirySeconds = 5 * 60 * 1000;
	@Id @Getter String id;

	@Index
	@Getter
	Date created;

	@Index
	@Getter
	Date expiry;

	@Getter
	@Serialize List<Attribute> attributes = new ArrayList<Attribute>();

	public Session(){
		try {
			MessageDigest md = MessageDigest.getInstance("SHA");
			SecureRandom rnd = new SecureRandom();
			byte bytes[] = new byte[20];
			rnd.nextBytes(bytes);
			md.update(bytes);
			String id = Hex.encodeHexString(md.digest());
			this.id = id;
		} catch (NoSuchAlgorithmException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}
		this.created = new Date();
		this.expiry =  new Date( created.getTime() + expirySeconds );
	}

	public void setAttribute(String name, Object value){
		if(!this.isExpired()){
			attributes.add(new Attribute(name, value));
		}
	}

	public Object getAttribute(String name){
		if(!this.isExpired()){
			for(int x=0; x < attributes.size(); ++x){
				if(name.equals(attributes.get(x).getName())){
					return attributes.get(x).getValue();
				}
			}
		}
		return null;
	}

	public boolean isExpired(){
		return (new Date().after(expiry));
	}
}

Note that I’m using Project Lombok to handle the Getter and Setter creation for my Session object. Now to create a Session, I will need to first authenticate against something. At this time, I’m using a very simple User object of my own that stores a user password in plaintext. You should ideally just want to store a hash of the password so that even if compromised, your user passwords are safe. I’ll leave that up to you to figure out. My User object looks a bit like this:

package net.zenconsult.server.model;

import java.util.Date;

import lombok.Data;
import lombok.Getter;

import com.googlecode.objectify.Key;
import com.googlecode.objectify.annotation.Entity;
import com.googlecode.objectify.annotation.Id;
import com.googlecode.objectify.annotation.Index;

@Entity
@Data
public class Customer {
	public static Key<Customer> key(String email) {
		return Key.create(Customer.class, email);
	}

	@Id @Getter String email;

	@Index @Getter
	String name;

	@Getter
	String phone;

	@Index @Getter
	Date created;

	@Getter
	String password;

}

I write a simple HTTPServlet to handle my login authentication like so:

public void doPost(HttpServletRequest req, HttpServletResponse resp)
			throws IOException {

		// Le horrible parameter fetching with NO validation
		String email = req.getParameter("email");
		String pass = req.getParameter("pass");

		Customer cust = ofy.load().key(Key.create(Customer.class, email)).now();

		if(cust != null && cust.getPassword().equals(pass)) {
			Session a = new Session();
			a.setAttribute("user", cust.getEmail());
			a.setAttribute("time",new Date());
			Key<Session> sess = ofy.save().entity(a).now();
			resp.addCookie(new Cookie("cookeh",a.getId()));

			resp.sendRedirect("/loggedin.html");

		} else {
			resp.setContentType("text/plain");
			resp.getWriter().println("Failed to login");
		}

For the love of God, please make your version better than mine. Ok, so now we’ve got to the point where we’ve validated our end user and have set an HTTP_COOKIE header called “cookeh”. The browser should do the rest, sending this cookie with each subsequent request that is made. All that’s left to do is to handle the requests made to our endpoints. I would do it something like this:

public Food getFood(@Named("email") String email, HttpServletRequest req){
		Food food = null;
		Cookie authCookie = getAuthCookie(req.getCookies());
		if(authCookie != null){
			Session sess = ofy.load().key(Key.create(Session.class,authCookie.getValue())).now();
			if(!sess.isExpired()){
				System.out.println(sess.getAttribute("user"));
				food = ofy.load().key(Key.create(Food.class, email)).now();
			}
		}		
		return food;
	}

	private Cookie getAuthCookie(Cookie[] cookies){
		for(int x=0; x < cookies.length; ++x){
			if(cookies[x].getName().equals("cookeh"))
				return cookies[x];
		}
		return null;
	}

That’s pretty much it. I now have my own Session management in place that I can use to provide my own custom authentication scheme when using Cloud Endpoints. One thing you may want to do is to kill the Session object when a user logs out. Also, you may want to remove stale cookies that have expired using a scavenger process that is setup to run periodically by using GAE’s Cron Service. I guess you would write something like this:

package net.zenconsult.server.servlets;

import java.util.Date;
import java.util.List;

import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import net.zenconsult.server.model.OfyService;
import net.zenconsult.server.model.Session;

import com.googlecode.objectify.Key;
import com.googlecode.objectify.Objectify;

@SuppressWarnings("serial")
public class ScavengerServlet extends HttpServlet{
	private static final Objectify ofy = OfyService.ofy();

	public void doGet(HttpServletRequest req, HttpServletResponse resp){
		Date now = new Date();
		List<Session> sessions = ofy.load().type(Session.class).filter("expiry <", now).list();
		for(int x=0; x < sessions.size(); ++x){
			ofy.delete().key(Key.create(Session.class,sessions.get(x).getId())).now();
		}
	}
}

That’s it. This is obviously my first attempt at this and I will be polishing it off as much as possible. Once I do, I’ll most likely upload the code to github; unless the folks at Cloud Endpoints hook up the HTTPSession object and my code is no longer needed. Until then, happy coding!

Today, girls and boys, we’re going to look at the second utility I released that helps with analyzing BlackBerry data. Behold! ConParse!

ConParse

ConParse is a utility that helps you take a look inside a BlackBerry .con file. The .con file is generated when you choose to backup your BBM contacts on your device. These days, RIM allows you to back your BlackBerry Messenger (5 and above) contacts up to some remote location that we will henceforth refer to as the cloud. But if you fancied, you could also back up your BBM contact list to your device memory or SD Card. I present the obligatory screenshots below, thereby providing you with both hands and a flashlight. Access the screens by selecting Options from your BlackBerry messenger application.

Now then. If we take a quick peek inside the .con file it looks a right mess of randomly placed hexadecimal characters and readable text, much like most other binary files. Since not everyone is able to grok raw hex data when they look at it and because no prior documentation existed for it, I set out to make sense of this beast. If prior documentation did exist, then will the person who wrote it please speak with their SEO provider? Because you’re getting ripped off big time. If you care to dig through my source code, you may find some details on the file structure itself. If looking at badly written source code gives you hives, then I will try to explain it here.

The .con file header is interesting. The first byte tells you the size of a unique string of bytes to follow. So far it has always been 32 bytes. This 32 byte string is a signature or hash of your .con file. Its sole purpose is to ensure that you do not import .con files belonging to other devices. I haven’t bothered reverse engineering the .cod files yet to see what they use to generate this signature. In the tests I did, however, it is evident that the signature differs each time you generate a backup file and swapping signatures from other devices will render your backup file invalid.

20 C3DCA86024DCCC531A96199327B7F4E7224EF4FF52E7C0978C02C9E5F347D87F 7F80 00 00 70 05

In the byte sequence above (all hex), the first byte indicates the size of the signature (32 bytes), then the signature of 32 bytes follows.

Now that the signature is out of the way, the actual file header begins. The bytes 0x7F 0×80 indicate the start of the .con file. After this, the next 4 bytes indicate the size of the remaining data in the file. In this case it is 28677 bytes.

Immediately after this, the records start. You can find some of the following types of records in a .con file:

• Your name and device PIN
• All your contacts and groups (their PINS, names, custom names you’ve chosen for them, status messages, etc)
• Your profile picture
• Timezone and Country flag image filename
• Base64 Code and Hex Code (Haven’t looked at these extensively yet, but could have something to do with an authorization code and/or the string used to generate your QR Code)

00 08 0A 32 31 30 30 30 30 41

The record above is a device PIN record. The first two bytes indicate the size of the record, then third byte indicates the record type and the remaining bytes (up to the record size) contain the data. RIM follows the same principle of storing size and type before data as it did in the IPD databases.

That’s it. You’re now a .con file expert. Go forth and dissect the crap out of the file. Use ConParse as a guideline or just use it to parse out .con files at your next party — guaranteed to get you laid.

Here’s another screenshot of the type of output you can expect from ConParse. Admittedly, it is just a couple of steps away from raw hex.

Today, I’m releasing source code to three of my projects that I’ve been incubating.  1) bbt 2) evt2sqlite  3) ConParse Take! Build! Enjoy! At some point or another, I may just split them up into their own repos.  For now, they all live in the bb-tools repository down at github. Update: I’ve split them up now

In today’s post, I’ll cover the first tool, bbt.

bbt

bbt is a python script that analyzes the thumbnail cache from a BlackBerry.  The purpose of a thumbnail cache in any system, is generally to speed up the browsing of large numbers of graphic or video files.  Instead of presenting a static icon to the user, a small thumbnail of the picture or frame of the video file is shown.  Apparently this is a good thing, because  you can see an icon of the image that you’re clicking on and will hopefully be able to find the file you’re looking for quicker.  Typically, the Operating System will find and shrink pictures found in directories of the filesystem.  These shrunk pictures will then be placed inside the thumbnail cache.

When conducting a digital forensics analysis of a computer, looking for these thumbnail caches often provide clues as to what files may have existed before they were deleted off the file system.  The thumbnail cache is important enough to warrant its own entry on the Forensics Wiki (albeit only the Windows thumbnail cache is spoken about).  The principle generally remains the same when extended to the BlackBerry device as well.  So, bottom line: being able to analyze this file is useful.

bbt will do just that for thumbnail cache files found on BlackBerry devices.  There are two types of thumbnail caches on the BlackBerry device: 1) BBThumbs.dat format 2) key/dat format.

Format 1 is pre OS 5.0 and the key/dat format is post OS 5.0  The key/dat combination is interesting because it uses two files to keep track of thumbnails.  They look something like thumbs86x86.key and thumbs86x86.dat (the 86×86 indicates the size of the thumbnail – 86 pixels by 86 pixels).  I’ve noticed quite a few interesting things in these files and no doubt, you will too after you look through the source or play around with them long enough:

1. The BBThumbs.dat header is 0×24052003 (which is a hex number)
2. The thumbs.dat file header is 0×22062009 (hex again)
3. The thumbs.key file header is 0×08062009 (hex)

This is pure speculation, but if you took those hexadecimal representations and looked at just the numbers, don’t they look like dates?

• 0×24052003 –> 24 05 2003
• 0×22062009 –> 22 06 2009
• 0×08062009 –> 08 06 2009

Maybe birth dates of the file format itself or someone significant to someone who wrote it? Dunno.

Another interesting observation of the key/dat thumbnail cache is that it not only stores image thumbnails, but also stores details of all types of media including ‘wav’, ‘mp3′, and ‘mid’.  It doesn’t store any content inside it though.  The only content stored inside the files is image data.

I’m not actually going to tell you what is found inside the thumbs files in this post, but instead, I am going to tell you how to run bbt.  bbt is a python script and as such will require that you have python installed on your system.  I’d always recommend cloning my repository on github so that you can easily pull any updates.  You may also want to sign up for a github account and watch the repository so that you will be notified of any commits I make.  You could also fork the project and get to work on it yourself.

azazel:Device sheran$ ~/github/bb-tools/bbt/bbt.py
Usage: bbt.py [options]
  -h, --help: This cruft
  -k, --key <bbthumbs key file>: Process post OS5 thumbs.key file (requires thumbs.dat file in same directory)
  -b, --bbthumbs <old bbthumbs file>: Process pre OS5 BBThumbs.dat file
  -x, --extract: Extracts the thumbnails into directory specified by -o
  -o, --output <output directory>: Directory to extract thumbs to (used only with -x)
azazel:Device sheran$

The output above is what you will receive if you run bbt without options.  As of the latest release (0.3b), the most magical thing you can do with this tool is to extract the thumbs into a specific output directory.  Additionally, bbt will parse out information about 1) What thumbnails are stored in the file (filename) for BBThumbs.dat files or 2) Where at what offset in a ‘dat’ file a specific record id is stored.  Here’s some example output when parsing a key/dat pair:

azazel:Device sheran$ ~/github/bb-tools/bbt/bbt.py -k thumbs116x116.key -x -o out
*** Processing thumbs116x116.key on 2011-07-22 21:50:48.156899
Record ID C620B80A is at offset 7 in 'dat' file // [1306132653179.jpeg]
Record ID DB0B7CA3 is at offset 25930 in 'dat' file // [1306492410606.jpeg]
Record ID D2EC23E3 is at offset 52123 in 'dat' file // [1306732433796.jpeg]
*** thumbs116x116.key has 9 records
*** Processed 3 records
azazel:Device sheran$

When you parse a key/dat file combination, you need to make sure that both the ‘key’ and ‘dat’ file are in the same directory.  When you run bbt, you will point it to the location of the ‘key’ file.  From the output above, you can see that it has discovered 3 records, corresponding record ids and offsets where they are stored in the ‘dat’ file.  Also, the filename of the thumbnail is provided.  What do the offsets mean?  Well, if you were to take the numbers and open up the ‘dat’ file in a hex editor, then you would land on the location where that specific record began.  This is what it looks like:

The highlighted portion is the first part of the record with the correct starting offset.  You may also notice that the ‘key’ file supposedly has 9 records but only 3 were processed.  This happens because the ‘key’ file holds 9 record ids and 9 offsets, but only 3 of those actually match up in the ‘dat’ file.  One assumption that can be made is that the files were deleted from the ‘dat’ file, but the ids and offsets still remained in the ‘key’ file.

bbt also has the ‘-x’ option which allows you to extract the thumbnails that are inside either the BBThumbs.dat file or the key/dat files.  You do this by specifying the ‘-x’ option along with the ‘-o’ option to tell bbt where to extract the thumbnails to.  You will need to make sure that the output directory specified by the ‘-o’ option does not already exist.

For now, that’s as much as you’re going to get out of bbt.  Some features that are planned in the roadmap for bbt are:

• HTML Reporting
• Identification of Exif data within thumbnails
• Completely parsing some of the header and record bytes that are as yet unknown

I’ll cover the other tools in subsequent posts.  For now, though, the tools are all live in the github repository.  All of the tools contain a basic README doc that tells you how to get started with each of the tools.

Having said this, though, adapting to XCode 4 is a bit of a challenge after using XCode 3 for a while.  Have a look at this awesome review of XCode 4.  It helped me make some sense of the new features and how to wrap my head around using this magnificent beast.  As of this post, the one major point that I absolutely hated about XCode 4 is the actual purchase/download process.  It took me about 10 hours to download its gargantuan 4.5GB on a 6Mbit line.

Now that that’s out of the way, I wanted to get down to one of the front-page features of XCode 4: LLVM.  The Apple XCode page states:

“Apple’s next generation compiler technology, the Apple LLVM compiler, does more than build your app. Apple LLVM technology is integrated into the entire development experience. The same parser used to build C/C++ and Objective-C powers Xcode’s indexing engine, providing incredibly accurate code completions. As you work, Apple LLVM is constantly evaluating what you type, identifying coding mistakes that Xcode shows as Live Issues, and thinking ahead for ways to Fix-it for you. Other compilers can tell you what is wrong — Apple LLVM can make it right.”

Being the curious type, I thought I’d give LLVM, or more specifically Clang, a try.  I figured the best way to do this is to compare a program compiled with Clang against the same one compiled with the venerable GCC compiler.  While there are benchmarks that were done in 2010 (here and here), I wanted to verify how the latest version of Clang would perform.

My test environment:

1. OS X 10.6.8 running on a Core 2 Duo 13″ MacBook
2. Clang version 2.0 based on LLVM 2.9svn
3. GCC version 4.2.1 build 5666
4. John the Ripper 1.7.8 Jumbo 2 from source

To start off, I thought I’d test how long each compiler would take to build JTR.  I made two copies of the JTR source under “john-llvm” and “john-gcc”.  Then I edited the “john-llvm” Makefile and changed the “CC” parameter to “clang” from the default value of “gcc”.  I ran “make macosx-x86-64″ on both directories after that.  Here are the respective build times (I used “time” to time the builds):

Clang:

1. real 0m41.382s
2. user 0m37.316s
3. sys 0m2.648s

GCC:

1. real 0m38.721s
2. user 0m34.067s
3. sys 0m3.540s

I then ran “john –test” on each build.  Here are the results for the “OpenBSD Blowfish (x32) [32/64 X2]” test:

Clang:

260 c/s real, 257 c/s virtual

GCC:

410 c/s real, 410 c/s virtual

Conclusion

Admittedly, I haven’t used any sophisticated test frameworks, and I’ve done more or less a “layman’s” set of tests.  But the results are clear: JTR compiled with GCC will crack your Blowfish password in half the time it would take for JTR compiled with Clang to do so.  It also takes less time to build JTR using GCC than it does to build it with Clang.

Obviously the hardware has a lot to do with test results and also the OS.  It would be interesting to see what the results look like when Lion is released this month.

With all this popularity, the inner workings of SQLite have held a sense of mystery and intrigue.  But not anymore.  We’ve cracked the internals of how an SQLite database stores and handles its data.  We know where your unreferenced data hides and we know how to recover it.  So the next best thing? Write a tool for it.  Thus this post serves to introduce our new tool – SQLUn, or simply the SQLite Undeleter.  The tool is very ideally suited to Forensics Analysts and investigators who focus on smartphones – most notably iPhones.

SQLUn successfully recovers data from not only unreferenced areas of the database, but also from the slack space of referenced records.  In this manner, a Forensic Analyst is certain that data is recovered from every nook and cranny of the database and no area is left unturned.  To aid Law Enforcement analysts, SQLUn also has the ability to manage information based on a specific case number.  Additionally, data integrity is maintained by conducting SHA1 hashes of all relevant records and databases.  Data is further protected by disabling writes to the database and working off a duplicate copy rather than the database file itself.  This feature is added to ensure that the database remains intact even if the operator forgets to take a backup.

By now, I’m pretty sure that you’re dying to get your hands on this little gem and I don’t blame you.  If you want to become a beta tester for the application, email us at sql-beta@zenconsult.net and we will take it from there.  Please provide some details about yourself including where you work and why we should consider you for beta testing the product.  If you work in the Law Enforcement industry, please mail us from your agency email address for expedited handling of your beta tester request.

The fundamental thing about reverse engineering is that you absolutely need to know how things work in forward first.  You cannot reverse without knowing how things go forwards.  So I studied the compilation process in depth and discovered that the compilation is a three-step process.  The BlackBerry compile process is not, in actuality, something magical.  It first runs javac on a plain old .java file.  The resulting .class file is then preverified (a process by which you alter the class file in a way that you save the device JVM significant processing time).  After this, the BlackBerry compiler (rapc.jar) is executed to covert the .class file into a .cod file.  This .cod file is significantly smaller than the .class file.  It also appears to be compressed.  It is not a simple task to reverse this process.  Primarily because rapc.jar is obfuscated like a mofo and you need to spend countless hours refactoring and getting things to play well together.  But you don’t want to hear that do you?  No, instead you want to hear that I am able to reverse .cod files to the point at which I have pristine .java source code, right?  Well, yes.  I can do that.

As I often need to appease my evil personality, I did what most anyone else in my position would do.  I looked at a few programs out there to see if I can bypass their license key requirements.  The result?  Can you say “Shooting fish in a barrel”?  Ordinarily, I would take this moment to chide all the developers out there to use better protection, I am not going to do this today.  These days, any capable person with a laptop can write and sell applications for the iPhone or the BlackBerry.  Gone are the days where you see only larger software houses publishing commercial applications.  Now just about anyone can do it.  What each individual is willing to lose to piracy and the amount of effort they wish to spend on writing software protection is entirely up to them.  All I’m going to do today is say this: Everything can be reversed.  Everything.

Don’t be lulled into a false sense of security that when you write an app for the BlackBerry, your code is safe; it is not.  Your commercial protections CAN and WILL be broken.  Unless you want to lose money to this problem, the only suggestion I can offer is to consider spending more effort in designing better protections.  If not, then just forget it and go about your business as you normally would.  But be aware that an increasing number of people have the means to reverse your code.  It will only be a matter of time before sites will pop up with real working keygens that you can run on your BlackBerry device.  It will be like the second coming of the PC era where good old DOS games had keygens and keygenning groups flourished.  For those interested, what would good protection consist of?

• Don’t do any calculations within your app that you can compare to.
• Consider activating your app over the internet.
• When activating your app over the internet, use SSL, and more important, VERIFY your server certificate.
• If you need to offer trials, write two separate programs: 1 less functional trial and 1 full featured version.

To sum up, make sure that you protect what is important to you.  If your application generates revenue for you, then you will want to protect it.  Spend a little extra effort on designing a better software protection framework.  To everyone those who don’t know where to start, the company I work for offers consulting on this subject.  Get in touch with me if you’re serious about it.

So what’s the deal?  It appears that Greg Evans and Ligatt are suing a number of people for “stock bashing”.  The blog post goes on to detail that a group of people have posted comments on various investor websites in the hopes of influencing the Ligatt stock price.  Apparently, they were doing this for “their own personal reasons”.  Among the people who engaged in this activity are Chris Riley, Nisha Kappor, Ben Rothke, Randolph Morris.  On the blog post, a tiny image of the document filed in courts is provided.  While the document is indeed small, it was easy to make out the case number: 10-A-06012-5.  Further, the post says that the suit was filed in the Gwinnet Courts of Georgia.  A quick run to http://www.gwinnettcourts.com and a search for the case number reveals a bit more information.

The defendants in this case are filed as John Doe 1-25 and Grey McKenzie.  The John Doe’s are presumably to indicate that the real name of the defendant is unknown.  It would be likely though, that they use aliases or a.k.a’s in the court document.

Ligatt’s retained attorney is also from Georgia – John A. Moore from The Moore Law Group LLC.  Mr. Moore represents Ligatt in most of its cases in Gwinnet Courts.

What is most interesting to me is the other cases that come up when searching the court records.  The categories include “General Civil-Other”, “Small Claims General Civil” and “Contract”.  Looking at the cases, 1 has been filed in 2008, 4 in 2009 and 2 in 2010.  The cases for 2010 include the recent one against 25 John Doe’s and Grey McKenzie and another interesting case:  One against LaKesha Wilson.  Why interesting?  LaKesha Wilson was the President & COO of Ligatt Security International and posted an investor video blog on YouTube.  Guess what? Lakesha had already filed a case of her own against Gregory D Evans for Stalking.  Search through the cases with first name Gregory and last name Evans for some more fun.

Other people Ligatt has filed cases against include: John Doe in 2008, Joseph Nemetz, Paul S Radich, John Doe, Jason Perry in 2009.

Sadly, I can’t seem to access any of the documents that are filed online.  I would need to visit the court records office physically to do so.  Also, in most of the cases, either there is an order for dismissal or cases have been dismissed.  I’m not a lawyer, so I cannot comment any further than what I see.  I guess we’ll just see where this latest case goes.  I dunno, but to me it looks like a colossal waste of the court’s time and resources in hearing these cases.  Just sayin’.

Update: If you want to contribute more information regarding the lawsuits related to Evans and Ligatt, please mail errata[at]attrition.org.  They are working on a summary.