The overview of my “NIT” is this: The disclosed NIT source code consisted of gallery.php, gallery.swf & cornhusker.py. All of this code is parallel construction. And it’s “normal” for two sites and “fabricated” for my case (TB2). Both types of parallel construction are serious Brady Violations.
Normal parallel construction consists of creating criminal cases against defendants that are based on illegal surveillance. They then conceal that original source with parallel construction that allows the prosecution to conceal the original illegal source of the evidence against the defendant, and pretend that they found the suspect through legal investigation techniques. Fabricated parallel construction consists of concealing the original illegal source of the evidence with a totally fabricated parallel source.
Parallel Construction is a serious problem in the United States because as Mark Rumold, a staff attorney at the EFF, put it: “It does a disservice to our criminal justice system when the government hides the techniques of investigations from the public and criminal defendants. Oftentimes, the reason they do this is because the technique is of questionable legality or might raise questions in the public’s mind about why they were doing it. While it’s common for them to do this, I don’t think it benefits anyone.” Because “we cannot have a world where a government is allowed to use black box of technology” to prosecute criminal defendants.
The parallel construction in my case was ridiculously egregious. It likely emanated from an XSS attack on a “is Tor working site”. So here is what probably happened on November 18, 2012 @ 8:12 and 8:15PM; for unknown reasons, Becker’s minions attacked my Rekonq browser with an XSS attack on the “is Tor working” website I visited. (It was a website that inspected your browser’s configuration and then made various recommendations) It told me to turn off javascript and turn off the cache. (Note: they may have also installed a Remote Access Trojan (RAT) at this time.)
Anyway, the XSS attack loaded those two pages in the IP Activity table in a hidden iframe (located on the “is Tor working” site). That hidden iframe then loaded another hidden iframe that loaded “gallery.php”. Galley.php (located on TB2) then populated the IP Activity table with falsified data, BUT it needed Javascript to load the flash app, so that stopped working when I turned Javascript off.
The reason they had to plant evidence on April 9, 2013 was because; 1) they knew that the cache was off (Rekonq reports that it’s off in its headers) and 2) they couldn’t arrest me without finding “something”. They weren’t able to finding anything during their first hour of triage because all the home directories were encrypted. So, after that first hour, they looked at my laptop’s lock screen and saw my picture next to the user named Adama. They then planted the evidence in Adama’s home directory on my linux computer, overwriting its encrypted folder.
This FBI misconduct was exposed by their own Tech when he made an image of the linux drive and booted it. The OS then locked Adama’s account in the shadow file because it detected an error with its home directory (its encryption link was missing). Had any defense expert examined that drive they would have found that it didn’t have any other files to indicate it had ever been used by a human because the triage agent just “dumped” the thumbnail files in it and nothing else. That’s why (I suspect) none of my experts actually examined the drive, and that’s why the FBI refuses to share any information about their X-ways logs of their triage on April 9, 2013. (X-ways has extensive logging capability, since it’s not uncommon for defendants to claim the FBI planted evidence they are required by DOJ policy to turn this logging on. I suspect they didn’t turn it on, because planting evidence is career ending and illegal so why would the triage agent make a log of his crime?)
There are many more technical problems, but the final one I’d like to address here is the implausibility of the NIT on TB2. Becker’s narrative and the provided “parallel construction” code, indicates that the flash app (downloaded to my computer) must have executed in less than 3 seconds (flash terminates after 3 seconds). Yet as you can see from comparing Figure I to Figure H, it took the 8:12PM flash 39 seconds to execute and the 8:15PM execution took 63 seconds. Those are ridiculously long execution times, when my experts (the shills) report that their flash ”testing” executions times were in milliseconds. Of course, the information that could clear up this anomaly was destroyed. Here is how the parallel construction code must have worked:
- When my browser loaded those two html files at the designated times, gallery.php (running from a hidden iframe embedded in those html files) generated those two random “session ids”, populated a row of Figure I with falsified data & loaded gallery.swf (the flash app) in less than a second.
- Gallery.swf made a DNS query for ridiculously-long-cipher-code.cpimagegallery.com in a fraction of a second
- Cornhusker.py (allegedly running on the destroyed server) took forever to answer gallery.swf’s DNS query. It’s unclear how long flash will wait for a DNS response, so this is the only step where this time gap could occur because flash will only wait 3 seconds for the server (cornhusker.py) to give it permission to communicate. This presents another problem because this step isn’t necessary, if you know the IP of the server you just put that on. In other words, this is inefficient coding for an allegedly two week sting operation. The next two steps are also redundant because cornhusker records this DNS request along with the “session id” and the IP it came from, in a “clients” table. Flash just sends the same information again. Anyway, the clients table would answer the question about the long delay, but they destroyed it because it probably proves malfeasance.
- At most, 36 and 60 seconds later cornhusker.py provides gallery.php an IP address to communicate with and it sends a request to that IP for permission to communicate. (Cornhusker has 3 seconds to respond or flash terminates).
- For the first session id, flash communicates 39 seconds later and for the second id it communicates 63 seconds later. However, every expert knows that the second DNS query taking longer than the first is HUGE red flag – indicating the whole sting was based on fabricated parallel construction.