EXHIBIT 2

Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 1 of 54
2nd MaverickEye Expert Report Kal Toth (with Annexes) 2017Dec24.docx

1

Second Expert Report of Kal Toth Concerning the Maverickeye Case

December 24, 2017

Prepared by Dr. Kal Toth, P.Eng, Portland, OR 97205

For Mr. J. Curtis Edmondson, Law Offices of J. Curtis Edmondson, Hillsboro, OR 97124

The purpose of this document is to report on the adequacy of IPP International’s IPTRACKER system by 

examining IPTRACKER’s Functional Description and software. 

This report is driven by the Functional Description of IPTRACKER provided in the Declaration of Tobias 

Fieser (“Exhibit 1) located in Annex B, and the IPTRACKER software source code provided to me under 

Stipulated Protective Order per Case No. 3:15-cvv-00907-AC. 

As part of the effort to prepare this report, I conducted a preliminary inspection of the provided IPTRACKER 

software, tabulating my preliminary findings in a spreadsheet appearing in Annex D entitled MaverickEye 

Preliminary Source Code Inspection Report. Appendix E contains selected notices from IPTRACKER. 

Neither Annex D or Annex E reveal any of the source code.

Annex C contains a publication by Josh Brunty entitled “Validation of Forensics Tools and Software: A 

Quick Guide for the Digital Examiner which I briefly reference in Section 4 of this report.

Please know that given the Maverickeye IPTRACKER software has been placed under Stipulated 

Protective Order, I have taken steps to ensure that the alleged proprietary information embodied by this 

software has not been released by way of this report.

I have independently arrived at the opinions expressed in this report which depend on the accuracy of the 

information provided to me per Annex B, the provided IPTRACKER Source code. My opinions are shaped 

by my systems and software engineering qualifications, knowledge and experience detailed in Annex A and 

summarized in Section 1 of this report.

Table of Contents

1. My Qualifications ................................................................................................................................ 2

2. Synopsis of BitTorrent Technology .................................................................................................... 2

2.1 IPTRACKER is Considered Proprietary Software ............................................................................................... 3

2.2 Measures to Prevent Wrongful Accusation ......................................................................................................... 3

3. IPTRACKER Tracker Functional Description..................................................................................... 3

3.1 Observations: Unaddressed Problems ............................................................................................................... 4

3.2 Observations: Inadequate Functional Description............................................................................................... 4

4. Validation of Forensics Tools and Software ....................................................................................... 5

4.1 IPTRACKER: A Forensics Tool that Identifies Alleged Infringers........................................................................ 5

5. Preliminary Assessment of IPTRACKER Software Source Code...................................................... 5

5.1 Observations Regarding the Source Code.......................................................................................................... 6

5.2 Observations Regarding Notices Embedded in the Source Code....................................................................... 7

6. Summary of Findings.......................................................................................................................... 7

Annexes

Annex A: CV of Dr. Kal Toth, P.Eng.

Annex B: Exhibit 1, Declaration of Tobias Fieser (IPTRACKER)

Annex C: Validation of Forensics Tools and Software

Annex D: MaverickEye Software Inspection Report

Annex E: MaverickEye Embedded Declarations

Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 2 of 54
2nd MaverickEye Expert Report Kal Toth (with Annexes) 2017Dec24.docx

2

1. My Qualifications

My name is Kal Toth with a Ph.D. in computer engineering. I am a professional engineer (P.Eng.) with a 

Software Engineering designation registered in British Columbia, Canada. I have led teams of software 

engineers, developers and quality assurance engineers in industry for over 25 years specifying, 

architecting, and assuring software, systems, security, and Internet-based solutions for Intellitech, CGI 

Group, Datalink Systems Corp. and Hughes Aircraft. At CGI and Hughes Aircraft I was also the software 

and systems engineering practice leader. I have taught numerous software engineering and information 

technology-related courses to working professionals at the Technical University of British Columbia, 

Oregon State University and Portland State University. My resume includes lists of technical publications, 

reports, seminars and courses.

As Vice President of Systems Engineering for the CGI Group, I led a 3rd Party Validation and Verification 

team hired by the Canadian Federal Government to oversee their prime contractor’s $50M development of 

a security-critical global messaging system for Canada’s embassies abroad. The primary purpose of this 

project was to ensure that the prime contractor’s development teams developed adequate plans, 

requirements specifications, designs and test procedures, and executed their plans, reviews and 

procedures according to their obligations and standards called up under their contract with the Canadian 

government.

As Director of Quality at Hughes Aircraft of Canada, Systems Division, my team conducted the quality 

assurance and RMAS (reliability, maintainability, availability and safety) engineering tasks supporting the 

development of five large software-intensive Air Traffic Control (ATC) systems, in particular, Canada’s new 

ATC system, a $500M project. My responsibilities included facilitating the division’s software requirements, 

architecture, development and testing groups by specifying and promulgating the division’s transition from 

a traditional plan-based software process to a more flexible iterative software development process. 

As Vice President of Engineering for Datalink Systems Corp I managed an agile team of ten software 

engineers, programmers and testers developing and maintaining a real-time alert system for stock 

quotations sent to the mobile devices of customers who managed their portfolios via their browsers. The 

system ran on a server farm of a dozen physical servers, supported by an SQL database and was partially 

redundant. My team established an agile software development process, developed functional and design 

specifications for system enhancements, peer-reviewed specifications, and conducted independent module 

testing and system integration testing.

See Exhibit 6 for additional details.

2. Synopsis of BitTorrent Technology

BitTorrent is a peer-to-peer (P2P) file sharing protocol that enables large scale distribution of files among 

the devices of users across the Internet. This protocol is widely used across the web to support the 

distribution of large volumes of data, software packages, software updates, video, audio and various multimedia files efficiently and effectively. While infringement and piracy are serious concerns, BitTorrent 

technology is nevertheless an essential element of e-business, e-education, e-government, e-health, 

entertainment, and many other sectors of the global economy.

So-called BitTorrent clients (software modules) installed on end-user devices and the servers of web-based 

providers implement the BitTorrent protocols for peer-to-peer content sharing. A number of open source 

BitTorrent clients are available to users. Shared files are broken into many small pieces which are typically 

transferred among a large number of widely dispersed peers. Each peer can be simultaneously sending 

and receiving pieces from a significant number of files. Hashing techniques are used to ensure the integrity 

of transfers and the correct assembly of pieces which can arrive in arbitrary order at any given end point. 

Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 3 of 54
2nd MaverickEye Expert Report Kal Toth (with Annexes) 2017Dec24.docx

3

IPTRACKER’s core functionality is to detect BitTorrent users who have downloaded copyrighted material 

without permission (e.g. infringers who have not paid for the content). To accomplish this, IPTRACKER 

mimics the role of a BitTorrent peer, scanning/searching and collecting pieces of files from peer users 

across the web. However, IPTRACKER does not transfer (i.e. “seed”) any pieces of files to peer users. 

IPTRACKER is therefore a rather complex concurrent processing system that scans and tracks an 

exceeding large number of P2P clients across the web, implements BitTorrent’s non-trivial sharing 

protocols; captures Internet protocol information (e.g. IP addresses) of peer users; decodes, verifies, and 

assembles content; records protocol streams; assembles content into a large-scale database management 

system; and supports of number of operational, administrative, security, and backup/recovery tasks.

2.1 IPTRACKER is Considered Proprietary Software

I understand that the IPTRACKER software is considered to be proprietary. 

2.2 Measures to Prevent Wrongful Accusation

Previously I have described the following problems that could lead to IPTRACKER to wrongfully accuse

innocent parties of copyright infringement:

a) Implying Infringement when Files Partially Downloaded: Ideally, IPTRACKER can detect when 

a user decides to abandon an attempted download due to an inadvertent or accidental launch (i.e. 

user is not infringing). This could be accomplished if the system is required to download all pieces 

of a file – timing out after a pre-determined interval. However, I understand that IPTRACKER 

reports users to be infringers after having acquired only a small number of fragments (pieces) from 

the user’s IP address, perhaps only a single piece. IPTRACKER should download all pieces of a 

file before reporting possible infringement.

b) Attributing Infringement to Subscribers who Share Routers: WiFi routers are often shared 

among multiple parties, neighbors and lurkers. To eliminate wrongful infringement accusations, 

IPTRACKER should implement a reliable scheme for distinguishing the infringing party from the 

Internet subscriber who owns the service and the shared router.

c) Attributing Infringement to Current Subscriber Allocated an IP Address: Many routers are 

routinely reset: because routers can “freeze”; because of power failures; and because routers are 

sometimes intentionally powered down. Also, Internet providers may choose to remotely reset the 

IP address of a router for operational reasons. Such resets can allocate the IP address of an 

infringer to an innocent party. IPTRACKER should implement a reliable scheme to detect and 

compensate for such router resets.

3. IPTRACKER Tracker Functional Description

Tobias Fieser’s declaration (“Exhibit 1” in Annex B to this report) includes what is represented as a 

“Functional Description” of IPP’s IPTRACKER v1.2.1. Pages 3 and 4 identity some of the functions and 

features of IPTRACKER, but does not describe how these functions and features are related to each other, 

or, for that matter, to BitTorrent networks and protocols. Given the product is intended to detect copyright 

infringement accomplished by way of BitTorrent technology, I was surprised to not find a single reference to 

BitTorrent in these introductory pages. 

The figure on page 5 is a hardware block diagram void of any references to software. I fully expected the 

preponderance of custom functionality for ITTRACKER to be implemented by way of software, and that the 

core software modules comprising the system, including interfaces with BitTorrent components and 

protocols, would have been depicted in this figure. Although this figure depicts and labels several 

information flows, the purpose, content, ordering, and input/outputs attributed to these flows is not 

explained even in a cursory manner. 

Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 4 of 54
2nd MaverickEye Expert Report Kal Toth (with Annexes) 2017Dec24.docx

4

Although section 2.3 on page 6 is entitled “Description of the most important programs functions”, only a 

few components are identified, and their functionalities are not meaningfully explained. Similarly, page 7 

identifies database, privacy and date security features, but is devoid of any explanation of how these 

features are related to identified functions and devices on pages 3, 4, 5 and 6. Furthermore, I did not find a 

single reference to BitTorrent technology on pages 2 to 7. 

The first reference to BitTorrent appears in the last paragraph on page 8 of Section 4 Addendum. This 

page ostensibly provides basic knowledge about peer-to-peer file sharing which is rather poorly explained.

Pages 9 and 10 briefly describes Gnutella, Gnutella 2 and eDonkey networks with which IPTRACKER 

apparently integrates. The two accompanying sketches are devoid of useful information.

Page 11 provides a brief description of BitTorrent accompanied by a sketch, also devoid of useful 

information. Interestingly, this page is also devoid of any mention that IPTRACKER integrates with 

BitTorrent. I found this to be particularly surprising given that this seems not to be the case.

Page 12 briefly describes what a Globally Unique Identifier (UID) is, how it relates to peer-to-peer file 

sharing, and how hashing is used to support the reliable transfer of pieces and the assembly of files in P2P 

networks. However, nowhere in the document are these elements related or depicted.

3.1 Observations: Unaddressed Problems

The IPTRACKER functional description does not indicate how the problems in Section 2.2 are overcome:

a) The wrongful accusation of innocent parties because files are only partially downloaded;

b) The wrongful attribution of infringement to subscribers who share routers with other parties;

c) The wrongful attribution of infringement to subscribers because of IP address resets.

Therefore, it can be reasonably assumed that IPTRACKER does not cope with the problems of wrongful 

accusation described in Section 2.2 above. IPP International should be asked whether the software 

handles these problems, and if so, document the specifics of how this is accomplished as well as which 

software components have been programmed to cope with each problem.

3.2 Observations: Inadequate Functional Description

This document fails to describe the following functional aspects of the IPTRACKER system: 

a) Fails to identity the essential purpose of IPTRACKER to detect possible copyright infringers;

b) Fails to show where and how IPTracker integrates with the BitTorrent network and protocols;

c) Fails to identify significant software components or subsystems of IPTRACKER implementing

functionality and protocols for integrating with the BitTorrent;

d) Fails to describe how IPTRACKER software components integrate with each other and with 

IPTRACKER’s database management system (MySQL);

e) Fails to identity which, if any, software components of IPTRACKER were acquired from the open 

source software community and used “as is” or adapted; which software components were custom 

developed by IPP employees or contractors; and which software components were otherwise 

acquired (e.g. by way of development system software libraries).

In other words, this document provides virtually no useful information for assessing the adequacy of the 

IPTRACKER software and system for a forensics purpose such as detecting possible copyright infringers 

using the BitTorrent network. 

At a minimum, a detailed functional specification accompanied by an architectural design document is 

needed to assess the reliability and trustworthiness of a complex system such as IPTRACKER. Without 

Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 5 of 54
2nd MaverickEye Expert Report Kal Toth (with Annexes) 2017Dec24.docx

5

such documents in place, it is not possible to objectively assess the consistency, completeness or 

correctness of either the individual software components, or the integrated operational system by way of 

code inspections, design reviews, and testing. 

Nevertheless, I have conducted a preliminary assessment of the IPTRACKER software (see Section 5).

4. Validation of Forensics Tools and Software

In Annex C, I have provided the observations and insights of Josh Bunty (Marshall University Forensic 

Science Center) in his paper entitled “Validation of Forensics Tools and Software: A Quick Guide for the 

Forensics Examiner”. Informed by the work of the National Institute of Standards and Technology (NIST), 

Bunty asserts that software-based tools used for forensics purposes should be validated quarterly to 

ensure repeatable and reproducible results. Referencing the Daubert Standard which requires an 

independent judicial assessment of the reliability of a scientific test or method, he argues that this is a good 

starting point for drafting validation reports for forensics tools that will hold up in a court of law. He goes on 

to describe four basic steps for planning and testing forensics tools.

4.1 IPTRACKER: A Forensics Tool that Identifies Alleged Infringers

IPTRACKER is used to detect possible copyright infringement by BitTorrent users for the purpose of 

obtaining court subpoenas to seize and inspect their personal computers to determine if infringement 

actually took place. Given such an action can inflict significant emotional, social, and financial harm on an 

innocent party, an elevated level of assurance is warranted to ensure that the forensics tool used to identity 

a suspected infringer executes consistently and correctly, namely, that it is free of software defects that 

could silently implicate innocent parties. 

As demonstrated above, the functional description for IPTRACKER provides virtually no visibility into the 

intended functioning of the operational system. Furthermore, an architectural design specification showing 

how the software is integrated to implement the required functionality has not been provided. In the 

absence of both of these documents it is not possible to construct a validation plan and testing process that 

satisfies the guidance described by Bunty and advocated by NIST for forensics tools and software.

Following the process recommended by Bunty, I suggest that these clarifying questions be asked:

a) Since IPTRACKER digitally detects copyright infringement, is it considered to be a forensics tool?

b) Has the company established a forensics tool validation process for IPTRACKER?

c) How often is the IPTRACKER software validated? What techniques are used?

d) Does the company have a documented plan describing test steps, tools, and scenarios?

e) Does this validation process include setting up a test suite and controlled data set?

f) Does the validation process examine and compare test results against expected results? 

5. Preliminary Assessment of IPTRACKER Software Source Code

I conducted a preliminary inspection of the IPTRACKER software source code, tabulated my findings in a 

spreadsheet appearing in Annex D which is entitled “MaverickEye Preliminary Source Code Inspection 

Report”. My process involved reviewing and assessing the general scope and magnitude of the 

IPTRACKER software to discriminate open source and custom software components. This was partly 

accomplished by inspecting notices and comments embedded in the code documenting licenses, authors,

and copyright holders. I also searched the web to assess whether any of the IPTRACKER components 

were open source. When conducting my inspection, I annotated each IPTRACKER folder and file. To 

manage my search, I marked empty folders, empty files, non-text files (e.g. .rar, .dll, .exe), and “junk” (files 

Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 6 of 54
Second Expert Report Kal Toth Re Maverickeye 2017Dec23.docx

5

such documents in place, it is not possible to objectively assess the consistency, completeness or 

correctness of either the individual software components, or the integrated operational system by way of 

code inspections, design reviews, and testing. 

Nevertheless, I have conducted a preliminary assessment of the IPTRACKER software (see Section 5).

4. Validation of Forensics Tools and Software

In Annex C, I have provided the observations and insights of Josh Bunty (Marshall University Forensic 

Science Center) in his paper entitled “Validation of Forensics Tools and Software: A Quick Guide for the 

Forensics Examiner”. Informed by the work of the National Institute of Standards and Technology (NIST), 

Bunty asserts that software-based tools used for forensics purposes should be validated quarterly to 

ensure repeatable and reproducible results. Referencing the Daubert Standard which requires an 

independent judicial assessment of the reliability of a scientific test or method, he argues that this is a good 

starting point for drafting validation reports for forensics tools that will hold up in a court of law. He goes on 

to describe four basic steps for planning and testing forensics tools.

4.1 IPTRACKER: A Forensics Tool that Identifies Alleged Infringers

IPTRACKER is used to detect possible copyright infringement by BitTorrent users for the purpose of 

obtaining court subpoenas to seize and inspect their personal computers to determine if infringement 

actually took place. Given such an action can inflict significant emotional, social, and financial harm on an 

innocent party, an elevated level of assurance is warranted to ensure that the forensics tool used to identity 

a suspected infringer executes consistently and correctly, namely, that it is free of software defects that 

could silently implicate innocent parties. 

As demonstrated above, the functional description for IPTRACKER provides virtually no visibility into the 

intended functioning of the operational system. Furthermore, an architectural design specification showing 

how the software is integrated to implement the required functionality has not been provided. In the 

absence of both of these documents it is not possible to construct a validation plan and testing process that 

satisfies the guidance described by Bunty and advocated by NIST for forensics tools and software.

Following the process recommended by Bunty, I suggest that these clarifying questions be asked:

a) Since IPTRACKER digitally detects copyright infringement, is it considered to be a forensics tool?

b) Has the company established a forensics tool validation process for IPTRACKER?

c) How often is the IPTRACKER software validated? What techniques are used?

d) Does the company have a documented plan describing test steps, tools, and scenarios?

e) Does this validation process include setting up a test suite and controlled data set?

f) Does the validation process examine and compare test results against expected results? 

5. Preliminary Assessment of IPTRACKER Software Source Code

I conducted a preliminary inspection of the IPTRACKER software source code, tabulated my findings in a 

spreadsheet appearing in Annex D which is entitled “MaverickEye Preliminary Source Code Inspection 

Report”. My process involved reviewing and assessing the general scope and magnitude of the 

IPTRACKER software to discriminate open source and custom software components. This was partly 

accomplished by inspecting notices and comments embedded in the code documenting licenses, authors,

and copyright holders. I also searched the web to assess whether any of the IPTRACKER components 

were open source. When conducting my inspection, I annotated each IPTRACKER folder and file. To 

manage my search, I marked empty folders, empty files, non-text files (e.g. .rar, .dll, .exe), and “junk” (files 

Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 7 of 54
Second Expert Report Kal Toth Re Maverickeye 2017Dec23.docx

6

containing random text) as they were encountered. When encountering useful information, I annotated the 

file with the licensing, authorship, and copyright information, otherwise marking it “unremarkable”. I also 

recorded the size, in bytes, of each major subsystem, and assessed the approximate number of files 

composing each of these subsystems.

5.1 Observations Regarding the Source Code

The Table 1 below summarizes my overall assessment of the scope, size, categorization, and 

authorship/copyrights of IPTRACKER’s major subsystems. The software subsystems representing, 

perhaps, the most complex subsystems comprising IPTRACKER are SharpPcap and MonoTorrent. 

Without the aid of functional and architectural documentation, I surmise that MonoTorrent is the core 

software implementing the BitTorrent protocols, and SharpPcap is used to capture the protocol information 

when content is downloaded to IPTRACKER. 

A search of the web confirms that Alan McGovern and Gregor Burger were among the original developers 

of the MonoTorrent code. Similarly, Chris Morgan, Tamir Gal, Phillip Lemon developed the original 

SharpPcap code. Inspections of the source code confirm that Alan McGovern was also heavily involved in 

the development of MonoTorrent.Tests and MonoTorrent.Dht. Alan McGovern also played a role in the 

development of the GeoIP_Project which apparently determines the rough geographic location of an 

Internet IP address. Meanwhile, the README.txt (see Annex E) suggests that TrackerApp is closely 

coupled with the MonoTorrent subsystem.

Meanwhile, when inspecting the IPTRACKER code, I was not able to locate any objective evident that 

SharpPcap and MonoTracker were modified, enhanced and integrated by IPP International personnel.

Of course there is the possibility that one or more of the developers identified in Table 1 were hired by IPP 

International to create IPTRACKER. If claimed to be true, IPP International and the plaintiff should be 

asked to provide such evidence.

Table 1: IPTRACKER

IPTRACKER Bytes #Files1 Category Authors/Copyrights

.. TrackerApp/

.. SharpPcap/

.. Samples/

..SampleClient/

.. MonoTorrent.Tests/

.. MonoTorrent.Dht/

.. MonoTorrent/ 

.. GeoIP_Project/

.. AddFeatures/

274,000

2,590,000

6,900

493,000

328,000

373,000

3,710,000

4,070,000

152,000

22

107

3

37

62

62

216

65

16

Open Source

Open Source

-

-

Open Source

Open Source

Open Source

Open Source

-

Gregor Burger

Chris Morgan, Tamir Gal, Phillip Lemon

-

-

Alan McGovern

Alan McGovern, Jeremie Laval, Gregor Buguer

Numerous open source authors (see Annex D)

Alan McGovern, Miguel de Icaza

-

 

1 Approximately

Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 8 of 54
Second Expert Report Kal Toth Re Maverickeye 2017Dec23.docx

7

5.2 Observations Regarding Notices Embedded in the Source Code

I also examined three (3) notices embedded near the root of the IPTRACKER software, namely, 

LICENSE.txt, TODO.txt and README.txt. Table 2 records my observations and comments as they relate 

to three notices which appear in Annex E.

Table 2: IPTRACKER NOTICES

Observations Comments

Logging Client / src / LICENSE.txt

This license notice designates Alan McGovern and Oliver 

Dufour as copyright owners of MonoTorrent, a crossplatform library of C# code implementing the BitTorrent 

protocol. Permission is granted, free of charge without 

limitation or warrantee. The license requires this notice to 

be included in all copies or substantial portions of the 

software.

Given this notice is located at the root node of the entire 

IPTRACKER source code, the license appears to apply to 

all branches of the IPTRACKER source code tree (all 

subfolders and files).

Copyright: Gregor Burger, Alan McGovern

This seems to imply that all of the IPTRACKER software 

is open source which is not the position IPP International

has taken.

Logging Client / src / TODO.txt

“There is still loads of work to be done to make this a fully 

fledged BitTorrent Client”. 

This notice identifies 4 features to be improved, 3 features 

to be added, and the need to improve documentation

“If anyone finds bugs or anything in the code (which I'm 

sure there are many) [:p)] feel free to drop me an email.” 

This notice explicitly declares that the MonoTorrent 

software contains many bugs and is incomplete.

Objective evidence should be provided that the software 

bugs were fixed and which, if any, of the recommended 

additions, improvements, and documentation were 

implemented.

Logging Client / src / README.txt

This notice provides guidance to developers using and 

modifying MonoTorrent to suit a given purpose. This 

notice also provides guidance for using MonoTorrent 

Client, MonoTorrent.Tracker, MonoTorrent.TrackerApp 

and other code fragments identified.

This notice provides objective evidence that the software 

license identified above applies to MonoTorrent Client, 

MonoTorrent.Tracker, and MonoTorrent.TrackerApp. 

6. Summary of Findings

The Functional Description provided in the declaration of Tobias Fieser provides virtually no useful 

information for assessing the adequacy of the IPTRACKER software and system for a forensics purpose 

such as detecting possible copyright infringers using the BitTorrent network. At a minimum, a detailed 

functional specification accompanied by an architectural design document is needed to assess the 

reliability and trustworthiness of a complex system such as IPTRACKER.

IPP International has apparently taken the position that IPTRACKER is a forensics tool given copyright 

infringement by BitTorrent users is allegedly detected. The company should be required to demonstrate 

that a sound forensics tool validation process be applied to the IPTRACKER system quarterly.

My inspection of the IPTRACKER software suggests that most of the software is open source. I did not 

find any objective evidence that any of the software source code was created, modified, or enhanced by 

IPP International personnel.

Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 9 of 54
Second Expert Report Kal Toth Re Maverickeye 2017Dec23.docx

8

Of course there is the possibility that one or more of the developers identified in Table 1 were hired by IPP 

International to create the IPTRACKER software. If so claimed, IPP International and the plaintiff should be 

asked to provide corroborating objective evidence.

The MonoTorrent license notice that the software is free is located at the root node of the IPTRACKER 

source code. This seems to imply that virtually all of the IPTRACKER software is open source. Apparently, 

IPP International takes the position that IPTRACKER is proprietary.

The TODO notice embedded in the software declares that the MonoTorrent software contains many bugs

and is incomplete. Objective evidence should be provided that the software bugs were fixed and which, if 

any, of the recommended additions, improvements, and documentation were implemented.

My rate is $350.00 per hour. It took me __ hours to draft, edit, and complete this report including Annexes.

Signed under the Penalty of Perjury, 

Kal Toth (Kalman C. Toth)

Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 10 of 54
Annex to Second Expert Report Kal Toth Re Maverickeye.docx

Annex A: CV of Dr. Kal Toth, P.Eng.

Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 11 of 54
Kalman C. Toth Ph.D., P. Eng. 

304-1132 SW 19th Ave Portland OR 97205

kalmanctoth@gmail.com 503.984.3531

Systems and Software Engineering and Security Technology Professional

Background / Experience:

 Executive leadership for systems, software, quality and IT organizations, projects and teams.

 Technology startups, IT consulting, mission-critical projects.

 Software and systems engineering manager, innovator, and change agent

 Cyber security, identity management, e-commerce, mobile computing, distributed systems, 

networking, communications, and databases. 

 Developed technology solutions, and provided consulting and educational services for 

government, the financial/banking/brokerage sector, and universities. 

 Selected Projects: Air traffic control systems; real-time stock quotation system for mobile devices; 

security devices and gateways; global secure messaging; on-line learning management systems; 

search and rescue system. 

 Delivered numerous technical and management courses to working professionals.

Competencies: 

Systems, software and quality engineering, Strategic and business planning, Project management, 

Identity assurance and security engineering and technology, e-learning / distance education.

Citizenship and Residency: U.S. and Canadian Citizen (dual); U.S. Resident

Languages: English (mother tongue), Hungarian (father tongue), and French fluency

World: Early IT career with World Health Organization, Geneva; well-travelled in Europe

Education:

B. Eng. Electrical Engineering

M. Eng. Systems Engineering and Computer Science

Ph.D. Computer Systems Engineering 

Professional Engineer (P. Eng.): BC Association of Professional Engineers and Geoscientists

Training/Education Courses: E-commerce, software engineering, project management ...

Pacific Northwest Software Quality Conference: Board member and 2013 Conference Chair

Portland State University: Faculty Senate Budget Committee; Intellectual Property/DE Taskforce

Goose Hollow: Vice President of the neighbourhood association’s board of directors, 2016

Patent Pending: “Electronic Identity and Credentialing System”, filed USPTO, Oct 1st, 2014

Publications and Courses: Over 100 technical papers, articles, industry reports and courses.

See also http://www.linkedin.com/pub/kal-toth/2/60b/b19

Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 12 of 54
Kalman C. Toth, Ph.D. P.Eng. 

2

Key Positions

NexGenID (2013 - 2014)

- Founded company and created innovative identity and credentialing technology: “Electronic 

identity and credentialing technology” per above-referenced patent-pending

- Developed detailed functional specification and supported marketing and funding efforts 

aTrust Inc. (2012 - 2013), Chief Technology Officer (CTO)

- Evolved this startup’s vision, technology roadmap, and product-line development strategy

- Built and maintained partner/vendor relationships in technology and banking sectors

- Managed and evaluated the distributed development team’s progress and performance

Portland State University (2003-12), Executive Director and Associate Professor

- Directed, enhanced and evolved the Oregon Master of Software Engineering (OMSE) into a 

fully online learning program for working software professionals in Oregon’s hi-tech sector

- Delivered software engineering, project management, quality engineering, distributed team, 

estimating, and architectural design courses and seminars – both face-to-face and online

- Investigated identity management technologies targeted at the healthcare and banking sectors 

creating the “Persona Concept”, a framework for managing electronic credentials and private 

data of users across PCs, smart cards, smart phones, and other personal devices

Oregon State University (2001-2003), Associate Professor Computer Science

Technical University of British Columbia (1999-2001), Assoc. Prof., Information Technology

Datalink Systems Corp. (1997-99), Vice President Engineering

- Managed Datalink’s technical operations and information technology infrastructure

- Led the development of a web-based service and payment processor for delivering real-time 

stock quotes, news, sports, and other services to wireless devices - pagers and cell phones

- Worked with marketing/support to develop requirements and rapid response to user problems

- Removed security weaknesses of the previously deployed service center

- Developed replacement architecture with scalability, backup and recovery features

Hughes Aircraft Systems Division (1992-95), Director of Quality

- Led quality, reliability, maintainability, availability and system safety teams for five (5) large air 

traffic control projects (Canada, Canadian military, Switzerland, Indonesia and China)

- Leading member of the core team that created the division’s innovative iterative software 

process that was adopted to develop the $400M Canadian air traffic control system (CAATS)

- Created a new process infrastructure for the division’s policies, practices and procedures

CGI Group Inc. (1988-1992), Vice President Systems Engineering & VP Total Quality

- Practice leader across CGI’s 10 regional offices for project management, software 

engineering, quality engineering, configuration management, and software estimating

- Led process improvement initiatives across CGI’s US and Canadian offices

- Developed and initiated a strategic plan to implement a company-wide total quality process

- Conducted independent verification and validation of a $50M project to develop a globally 

secure network across Canada’s embassies abroad for External Affairs Canada

- Developed an innovative information security analysis model for Defence Canada

Intellitech Canada Ltd. (1983-88), Founder & President

- Founded Intellitech, growing it into a 25-person systems engineering and consulting firm

- Conducted numerous design and development projects for distributed information systems, 

networks and security gateways for military, government and industry clients

- Led the development of Intellitech’s secure packet-network product and the delivery of 

prototypes to Communications Canada – funded by the Canadian National Research Council 

and the Bank of Montreal, and sponsored by the Communications Security Establishment

Carleton University (1980-83), Assistant Prof., Systems Engineering and Computer Science

Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 13 of 54
Kal Toth

 3

Conferences and Journal Publications

 Kalman C Toth, Brewing Next Generation Identity, Pacific Northwest Software Quality Conference, October 

2015

 Kalman C Toth, Herman Migliore, Critical Factors Characterizing Projects and Lifecycle Models, PNSQC, 

October 2013

 Kalman Toth, Learning Software Engineering – Online, Pacific Northwest Software Quality Conference, 

October 2011

 Kal Toth, An Organizational Approach for Sustaining E-Learning in a Large Urban University, Future of Ed’n, 

June 2011

 Kal Toth, Software Engineering Online and Hybrid Learning Models at PSU, CATA, March, 2011

 Kal Toth, Raleigh Ledet, Lessons Learned about Distributed Software Team Collaboration, PNSQC, October, 

2010

 Kal Toth, Software Estimating: Navigating to the Landing Zone, Computers & their Applications, Honolulu, HI, 

Mar 2010

 Kal Toth et. al., Distributed Software Engineering Team Collaboration, poster session, PNSQC, October 2009

 Kal Toth, Software Estimating, Flexibility and Principled Negotiation, Computers and their Applications in 

Industry and Engineering (CAINE), San Francisco, November, 2009 

 Kal Toth, Selecting Software Estimating Techniques that Fit the Software Process, Pacific Northwest 

Software Quality Conference (PNSQC), Portland, Oregon, October, 2008

 Dan Brook, Kal Toth, Levels of Process Ceremony for Software Configuration Management, Pacific 

Northwest Software Quality Conference (PNSQC), Portland, Oregon, October, 2007

 Kalman C. Toth, A Practical Identity Management Reference Implementation, International Conference on 

Computers and Their Application (CATA), Honolulu, Hawaii, March 28-30, 2007

 Kal Toth, Experiences with Open Source Software Engineering Tools, IEEE Software, November/December

2006

 Kalman Toth, Persona Concept for Web-Based Identity Management, 2006 International Conference on 

Privacy, Security and Trust, UOIT, Newmarket, Ontario, Oct 30-November 1 2006

 L. Grove, R. Hickman, W. Matthews, K. Toth, Open Source Software Engineering Tools, Pacific Northwest 

Software Quality Conference (PNSQC), Portland, Oregon, October 12-13, 2004

 K.C. Toth, M.Subramanium, Requirements for the Persona Concept, Requirements for High Assurance 

Systems (RHAS’03) workshop, Monterey, CA, September 9, 2003

 K.C. Toth, M. Subramanium, The Persona Concept: A Consumer-Centered Identity Model, MobEA 

(Emerging Applications for Wireless and Mobile Access), Budapest, Hungary, May 2003

 K.C. Toth, M. Subramanium, Persona Concept for Privacy and Authentication, International Business & 

Economics Research Journal, June 2003

 K.C. Toth, M. Subramanium, I. Chen, Persona Concept for Privacy and Authentication, International Applied 

Business Research Conference, Acapulco, Mexico, March 2003; recipient of best paper award

 K.C. Toth and S. Nagboth, A Constraint-Based Personalization Model for E-Business Applications, 

International Applied Business Research Conference, Acapulco, Mexico, March 2003

 K.C. Toth, S. Nagboth, Intelligent Agents for Business Applications Using Constraint-Based Personalization, 

International Business & Economics Research (IBER) Journal, May 2002

 K.C. Toth, Software Product Evolution in the Classroom, American Society for Engineering Education / PSW, 

Fresno, California, April 8, 2002

 K.C. Toth, Simulating (Software) Product Evolution in the Classroom, The Western Canadian Conference on 

Computing Education (WCCCE), Nelson, British Columbia, May 3, 2001

 K.C. Toth and H. Todino, Instant Internet Intelligence for Wireless Business Applications, International 

Applied Business Research Conference, Cancun, Mexico, March 2001

 D Cyr, H Trevor-Smith, T Schiphorst & K.C Toth, A Web-Enabled Case Study in Project Management, 

International Business Education and Technology Conference, Cancun Mexico, March 2001

 K.C. Toth, M.Donat and J. Joyce, Generating Test Cases from Formal Specifications, 1996 International 

Council of Systems Engineering (INCOSE) Symposium, July 1996

 R. John, J. Madhur, R. Stewart, K. Toth, Software Quality Metrics Process For Large Scale Systems 

Development, 1996 INCOSE Symposium, July 1996

 K.C. Toth, J.J. Joyce, J. Masters, G. Pelletier, Precise, Unambiguous, Machine-Readable ATC Standards: 

Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 14 of 54
Kal Toth

 4

Use of "Formal Methods" in the ATC Industry, ATCA Conference Proceedings, September 1995

 K Toth & J. Joyce, Industrialization of Formal Methods Through Process Definition, feature paper at the 1995 

National Council on Systems Engineering Symposium, July 1995

 T. Paine, P. Kruchten & K. Toth, Modernizing ATC Through Modern Software Methods, Proceedings of the 

38th Annual Air Traffic Control Association, Nashville, Tennessee, October 1993

 M.W.L. Dennison, K.C. Toth & J.F. Clayton, Using a Practical Approach to Threat/Risk Analysis, Third Annual 

Canadian Computer Security Conference, Ottawa, May 14-16, 1991

 K. Toth, Information Security Architectures, AFCEA '90 (Armed Forces Communications & Electronics 

Association Technical Conference), Hawaii, November, 1990

 K.C. Toth, Security Architectures for Information Networks, AFCEA Canada '90, April 1990

 H. Adra, J. Allen, K. Toth, Trusted Integrated Project Support Environments, Second Annual Canadian 

Computer Security Conference, Ottawa, March 1990

 K. Toth, Towards an Improved Information Security Model, 1st Canadian Comp. Security Conf, January 1989

 K. Toth, Security Management in Data Networks, 1st Annual Canadian Computer Security Conf, January

1989

 AC Capel, C Laferriere & K.C Toth, Protecting the Security of X.25 Comm’s, Data Com Mag, November 1988

 K.C. Toth, S.A. Mahmoud, J.S. Riordon, Query Processing Strategies in a Distributed Database Architecture, 

Distributed Data Systems, North-Holland Publishing Co., 1982

 K.C. Toth, S.A. Mahmoud & J.S. Riordon, An Approach to Query Processing in Distributed Databases, 

Proceedings of the Sixth International Conference on Very Large Data Bases, Montreal, 1980

 Kalman C. Toth, Distributed Database Architecture & Query Processing Strategies, Ph.D. Carleton U 1980

 S.A. Mahmoud, J.S. Riordon & K.C. Toth, Distributed Database Partitioning & Query Processing, G. Bracchi 

and G.M. Nijessen (ed), Data Base Architecture, IFIP, North Holland, 1979

 S.A. Mahmoud, J.S. Riordon and K.C. Toth, Distributed Database Partitioning and Query Processing 

Strategies, IFIP Conference on Database Architecture, Venice, June, 1979

 J.S. Riordon, S.A. Mahmoud, K.C. Toth & O. Sherif, Distributed Database Architecture and Query 

Processing, CIPS/DPMA, Quebec City, June 1979

 K.C. Toth, S.A. Mahmoud, J.S. Riordon, O. Sherif, The ADD System - An Architecture for Distributed 

Databases, Proc. of the 4th International Conference of Very Large Data Bases, Berlin, September1978

 S.A. Mahmoud & K.C. Toth, Design Considerations for a Mini-Computer Database, MIMI International 

Conference, Zurich, June 7-9, 1977

 S.A. Mahmoud, J.S. Riordon & K.C. Toth, Design of a Distributed Database File Manager for a 

Mini-Computer Network, COMPSAC77, Chicago, November 8-11, 1977

 Kalman C. Toth, Contributions to the Synthesis of Computer-Communication Networks, M.Eng. Thesis, 

Carleton University, Ottawa, April 1972

Trade Articles

 “What’s the hard part of software development anyway?”, Software Assoc. of Oregon, Nov. 2007

 “Better Mileage with Hybrid Learning”, with Kathy Milhauser, Software Assoc. of Oregon, June 2007

 “Can Software Engineers Develop Communications Skills Online?”, Software Assoc. of Oregon, March 2007

 “Is Online Software Engineering Education for You?”, Software Association of Oregon (SAO), February

2007

 “OMSE Exchange: A Software Engineering Clearing House”, Software Assoc. of Oregon (SAO), November

2006

 “So Many Engineering Practices: Which to Follow?” (Part III), Software Assoc. of Oregon (SAO), July 2005

 “So Many Engineering Practices: Which to Follow?” (Part II),, Software Assoc. of Oregon (SAO), June 2005

 “So Many Engineering Practices: Which to Follow?” (Part I),, Software Assoc. of Oregon (SAO), May 2005

 “Which is the Right Software Process for your Problem?”, Software Assoc. of Oregon (SAO), April 2005

 “Outsourcing Software Development: A Case for Effective Scope Management”, SAO, March 2005

 “Why Invest in Software Engineering Education?”, SAO, February 2005

Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 15 of 54
Kal Toth

 5

Industry Reports 

 "Requirements for SimbaERP", report to Simba Technologies on the Requirements for a proposed 

ERP/Data Warehousing product, January, 1999

 System Security and Recovery Procedures, Datalink Systems Corp, January 1999

 "Technology Skills Gap Analysis: B.C. Software Industry”, under contract to the Software Development 

Centre (B.C.) for B.C. Ministry of Education, Skills and Training and the National Research Council, March 

1997

 "Process Product Standard", internal Hughes System Division Report, June 1994

 "In-Process Review (IPR) Process", internal Hughes System Division Report, December 1993

 "Change in Development Methodology", internal Hughes Systems Division Report, June 1, 1993

 "Total Quality Implementation Program", internal CGI report to the Management Committee, 1991

 "Total Quality Process: Directions & Priorities", internal CGI report to the Management Committee, 1991

 "TQP: Client Satisfaction Assessment Process", internal CGI guide, 1991

 "Software Quality Assurance Program", internal CGI practice guide, 1990

 "Configuration Management Framework", internal CGI practice guide, 1990

 "EDI and Security", CGI Group report, Dec. 1990

 "COSICS Security Verification Plan", Intellitech report to External Affairs, December, 1988

 "Information Security Model", report to National Defence, November 15, 1988

 "Network Processing Strategy Study", a series of reports to Transport Canada, 1988

 "Data Encryption Equipment Specification", Internal report specifying the components of CryptoNet, 

Intellitech's X.25/DES product, 1986

 "A Survey of Integrated Project Support Environments", Report to the Department of National Defence, 1986

 "A New Implementation Strategy for Secure Operating Systems", Intellitech Report, March 1986

 "Computer System Study" (Computer Integrated Manufacturing and Manufacturing Requirements Planning), 

Reports to General Metals Co, El Naser Glass Co. and Delta Steel Mills, 1985/86

 "Search and Rescue Satellite (SARSAT) Aided Tracking System, Ground System Study", five reports 

regarding Mission Control Centre design to National Defence, 1983 and 1984

 "Design Specification for the NCCS Communications Management System", Atmospheric Env. Serv, January

1984

 "Design & Analysis of Alternatives for the Integrated Data Network", Report to the Department of National 

Defence, 1982

 "Recovery Mechanisms for the ADD Distributed Database System", Intellitech Report, July 1982 (also 

presented at a NATO workshop in 1982)

 "Implementation Alternatives and Gateway Considerations for a Data Network to Serve the Defence 

Research Establishments", Report to the Department of National Defence, 1981

 "Design and Security Considerations for a Gateway to Interconnect SAMSON and DATAPAC", Report to the 

Department of National Defence, 1980

 "Open System Interconnection: Application Issues Associated with the ISO and CCITT Layered Models", 

report to the Department of Communications, 1980

 “On Query Decomposition & Processing in Distributed DBs”, INRIA Research Report, N. Spyratos & K.C. 

Toth, 1980

 "Query Processing Strategy Formulation in ADD", Carleton University report, 1979

 "A Modeling Approach to Systems Analysis of Processing Networks", one of five reports to the Department of 

Communications, Spectrum Management Systems

 "Design Issues in Distributed Databases", Carleton University report

 "Design & Configuration Analysis of an Aeronautical Satellite Comm. Centre (ASCC)", report to Transport 

Canada

Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 16 of 54
Kal Toth

 6

University Undergraduate and Graduate Courses

For Portland State University:

 Principles of Software 

Engineering

 Software Project Management

 Software Quality Engineering

 Software Design Techniques

 Software Estimating

 Distributed Software Engineering Team Collaboration

 Software Engineering Practicum

 Computing Fundamentals II (Visual Basic)

 Senior Capstone projects

 Directed studies on information security and software 

engineering

For Oregon State University:

 E-Commerce Systems

 Software Engineering I: principles, processes, requirements, OO design, architecture, SPM

 Software Engineering II: implementation, SCM, test techniques, reviews and inspections, SQA

For the Technical University of British Columbia and the University of Alberta:

 Software Engineering Best Practices

 E-Commerce Systems

For the University of British Columbia and Simon Fraser University:

 Software Engineering Best 

Practices

 Software Project Management

 Professional Issues in Software Engineering

 Software Engineering Team Project

For Carleton University:

 Undergrad course on data structures, databases, programming, and computer architecture

Workshops, Seminars, Tutorials, Professional Training Courses

 Professional Development Course in Software Engineering for Regence Group, Portland, Or, June 2007

 “Identity Management Systems”, tutorial for IEEE International Computer Software and Applications 

Conference (COMPSAC), Chicago, September 2006

 Information security seminars for the Assoc. of Prof. Engineers and Geoscientists of British Columbia, 2002 

and 2006

 Extending the Reach of Mobile E-Commerce, Software Productivity Centre, June 2000

 Wireless Handheld Technologies and Telelearning, Telelearning Conference, Toronto, November 2000 

 E-Commerce Lifecycle, Transactions and Security, MacDonald Dettwiler & Assoc., November 1999

 Personal Software Process (PSP): Software Productivity Centre / MacDonald Dettwiler & Associates, 1997

 WestMOST Software Engineering Telelearning Workshop, Saskatoon, 1998

 Software Project Management (including software process and metrics) at Carleton University, December 

1994

 Software Development Methods and Process: Iterative Software Development, for the Canadian Automated 

Air Traffic System (CAATS) at Hughes Aircraft, Systems Division and Transport Canada, March 1993

 Canadian Automated Air Traffic System, seminars presented at UBC (Computer Science), SFU (Applied 

Sciences), and Hughes (for staff and graduate students from UVIC, BCIT, SFU and UBC), 1993 and 1994

 Total Quality Management, a series of seminars presented to CGI Group technical staff across Canada,1991 

and 1992

 Total Quality Management, lecture to 4th year computer systems engineers at Carleton University, 1991

 Information Security Technology Overview for AFCEA INFOSEC Course, Canadian Forces Base (CFB)

Kingston, October 1991

Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 17 of 54
Annex to Second Expert Report Kal Toth Re Maverickeye.docx

Annex B: Exhibit 1, Declaration of Tobias Fieser (IPTRACKER)

Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 18 of 54
Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 19 of 54
Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 20 of 54
Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 21 of 54
Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 22 of 54
Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 23 of 54
Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 24 of 54
Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 25 of 54
Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 26 of 54
Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 27 of 54
Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 28 of 54
Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 29 of 54
Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 30 of 54
Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 31 of 54
Annex to Second Expert Report Kal Toth Re Maverickeye.docx

Annex C: Validation of Forensics Tools and Software

Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 32 of 54
Validation of Forensics Tools and Software: A Quick Guide for the Digital Forensic Examiner

https://www.forensicmag.com/article/2011/03/validation-forensic-tools-and-software-quick-guide-digital-forensic-examiner

Wed, 03/02/2011 - 7:45am by Josh Brunty

Tools and software for digital forensic analysis should be validated quarterly.With the field of digital forensics growing at 

an almost warp-like speed, there are many issues out there that can disrupt and discredit even the most experienced 

forensic examiner. One of the issues that continues to be of utmost importance is the validation of the technology and 

software associated with performing a digital forensic examination. The science of digital forensics is founded on the 

principles of repeatable processes and quality evidence. Knowing how to design and properly maintain a good validation 

process is a key requirement for any digital forensic examiner. This article will attempt to outline the issues faced when 

drafting tool and software validations, the legal standards that should be followed when drafting validations, and a quick 

overview of what should be included in every validation.

Setting the Standard: Standards and Legal Baselines for Software/Tool Validation

According to the National Institute of Standards and Technology (NIST), test results must 

be repeatable and reproducible to be considered admissible as electronic evidence. Digital forensics test results are 

repeatable when the same results are obtained using the same methods in the same testing environment. Digital 

forensics test results are reproducible when the same test results are obtained using the same method in a different 

testing environment (different mobile phone, hard drive, and so on). NIST specifically defines these terms as follows:

Repeatability refers to obtaining the same results when using the same method on identical test items in the same 

laboratory by the same operator using the same equipment within short intervals of time.

Reproducibility refers to obtaining the same results being obtained when using the same method on identical test items 

in different laboratories with different operators utilizing different equipment.

In the legal community, the Daubert Standard can be used for guidance when drafting software/tool validations. The 

Daubert Standard allows novel tests to be admitted in court, as long as certain criteria are met. According to the ruling 

in Daubert v. Merrell Dow Pharmaceuticals Inc. the following criteria were identified to determine the reliability of a 

particular scientific technique:

1. Has the method in question undergone empirical testing?

2. Has the method been subjected to peer review?

3. Does the method have any known or potential error rate?

4. Do standards exist for the control of the technique's operation?

5. Has the method received general acceptance in the relevant scientific community?

The Daubert Standard requires an independent judicial assessment of the reliability of the scientific test or method. This 

reliability assessment, however, does not require, nor does it permit, explicit identification of a relevant scientific 

community and an express determination of a particular degree of acceptance within that community. Additionally, the 

Daubert Standard was quick to point out that the fact that a theory or technique has not been subjected to peer review or 

has not been published does not automatically render the tool/software inadmissible. The ruling recognizes that scientific 

principles must be flexible and must be the product of reliable principles and methods. Although the Daubert Standard 

was in no way directed toward digital forensics validations, the scientific baselines and methods it suggests are a good 

starting point for drafting validation reports that will hold up in a court of law and the digital forensics community.

The Scientific Method and Software/Tool Validations: A Perfect Fit

In the Daubert ruling, The Court defined scientific methodology as “the process of formulating hypotheses and then 

conducting experiments to prove or falsify the hypothesis.” The Scientific Method refers to a body of techniques for 

investigating phenomena, acquiring new knowledge, or correcting and integrating previous knowledge. To be termed 

scientific, the method must be based on gathering, observing, or investigating, and showing measurable and repeatable 

results. Most of the time, the scientific process starts with a simple question that leads to a hypothesis, which then leads 

to experimentation, and an ultimate conclusion. To exemplify, if you are validating a particular hardware write blocking 

device you may want to start with the simple question “Does this tool successfully allow normal write-block operation to 

occur to source media?” Since it is assumed that the write-blocking device supports various types of media (SATA, IDE, 

and so on) you may be required to list the various requirements of the tool. Because if this, it is good practice for an 

examiner to use the scientific method as a baseline for formulating digital forensic validations. It is recommended that 

forensic examiners follow these four basic steps as a starting point for an internal validation program:

1) Develop the Plan

Developing the scope of the plan may involve background and defining what the software or tool should do in a detailed 

fashion. Developing the scope of the plan also involves creating a protocol for testing by outlining the steps, tools, and 

requirements of such tools to be used during the test. This may include evaluation of multiple test scenarios for the same 

software or tool. To illustrate, if validating a particular forensic software imaging tool, that tool could be tested to determine 

whether or not it successfully creates, hashes, and verifies a particular baseline image that has been previously setup. 

There are several publically available resources and guides that can be useful in establishing what a tool should do such 

as those available from NIST’s Computer Forensic Tool Testing Project (CFTT) available from http://www.cftt.nist.gov. 

The CFTT also publishes detailed validation reports on various types of forensic hardware and software ranging from 

mobile phones to disk imaging tools. In addition to CFTT, Marshall University has published various software and tool 

validation reports that are publically available for download from http://forensics.marshall.edu/Digital/DigitalPublications.html. These detailed reports can be used to get a feel for how your own internal protocol should be drafted. 

Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 33 of 54
The scope of the plan may also include items such as: tool version, testing manufacturer, and how often the tests will be 

done. These factors should be established based on your organization standards. Typically, technology within a lab 

setting is re-validated quarterly or biannually at the very least.

2) Develop a Controlled Data Set

This area may be the longest and most difficult part of the validation process as it is the most involved. This is because it

involves setting-up specific devices and baseline images and then adding data to the specific areas of the media or 

device. Acquisitions would then need to be performed and documented after each addition to validate the primary 

baseline. This baseline may include a dummy mobile phone, USB thumb drive, or hard drive depending on the software or 

hardware tool you are testing. In addition to building your own baseline images, Brian Carrier has posted several 

publically available disk images designed to test specific tool capabilities, such as the ability to recover deleted files, find 

keywords, and process images. These data sets are documented and are available at http://dftt.sourceforge.net. Once 

baseline images are created, tested, and validated it is a good idea to document what is contained within these images. 

This will not only assist in future validations, but may also be handy for internal competency and proficiency examinations 

for digital examiners.

3) Conduct the Tests in a Controlled Environment

Outside all the recommendations and standards set forth by NIST and the legal community, it only makes sense that a 

digital forensics examiner would perform an internal validation of the software and tools being used in the laboratory. In 

some cases these validations are arbitrary and can occur either in a controlled or uncontrolled environment. Since 

examiners are continuously bearing enormous caseloads and work responsibilities, consistent and proper validations 

sometimes fall through the cracks and are validated in a somewhat uncontrolled “on-the-fly” manner. It’s also a common 

practice in digital forensics for examiners to “borrow” validations from other laboratories and fail to validate their own 

software and tools. Be very careful with letting this happen. Keep in mind that in order for digital forensics to be practici ng 

true scientific principles, the processes used must be proven to be repeatable and reproducible. In order for thi s to occur, 

the validation should occur within a controlled environment within your laboratory with the tools that you will be using. If 

the examiner uses a process, software, or even a tool that is haphazard or too varied from one examination to the next,

the science then becomes more of an arbitrary art. Simply put, validations not only protect the integrity of the evidence, 

they may also protect your credibility. As stated previously, using a repeatable, consistent, scientific method in drafting 

these validations is always recommended.

4) Validate the Test Results against Known and Expected Results

At this point, testing is conducted against the requirements set forth for the software or tool in the previous steps. Keep in 

mind that results generated through the experimentation and validation stage must be repeatable. Validation should go 

beyond a simple surface scan when it comes to the use of those technologies in a scientific process. With that said, it is 

recommended that each requirement be tested at least three times. If there are any variables that may affect the outcome 

of the validation (e.g. failure to write-block, software bugs) they should be determined after three test runs. There may be 

cases, however, where more or fewer test runs may be required to generate valid results.

It’s also important to realize that you are probably not the first to use and validate a particular software or tool, so chances 

are that if you are experiencing inconsistent results, the community may be experiencing the same results as well. 

Utilizing peer review may be a valuable asset when performing these validations. Organizations such as the High 

Technology Crime Investigation Association (HTCIA) and the International Association of Computer Investigative 

Specialists (IACIS) maintain active member e-mail lists for members that can be leveraged for peer review. There are also 

various lists and message boards pertaining to mobile phone forensics that can be quite helpful when validating a new 

mobile technology. In addition, most forensic software vendors maintain message boards for software, which can be used 

to research bugs or inconsistencies arising during validation testing.

Conclusion

Real world laboratory use, controlled internal tests utilizing scientific principles, and peer review should all be leveraged in 

a validation test plan. Sharing unique results with the digital forensics community at-large helps investigators, examiners, 

and even software and tool vendors ensure that current best practices are followed. As the field of digital forensics 

continues to grow and evolve as a science the importance of proper scientific validation will be more important than ever.

References

1. Brown, C. "Computer Evidence: Collection & Preservation." Hingham: Thomson/Delmar. 2006.

2. Carrier, B. “Digital Forensics Tool Testing Images.” Accessed 06 Feb 2011. http://dftt.sourceforge.net/.

3. Daubert v. Merrell Dow Pharmaceuticals, 509 U.S. 579 (1993).

4. High Technology Crime Investigation Association, Accessed 06 Feb 2011. www.htcia.org.

5. International Association of Computer Investigative Specialists, Accessed 06 Feb 2011. www.iacis.org.

6. Maras, MH. Computer Forensics: Cybercriminals, Laws, and Evidence. Sudbury: Jones & Bartlett. 2011.

7. 7. Marshall University Forensic Science Center-Digital Publications, Accessed 06 Feb 2011. http://forensics.marshall.edu/Digital/Digital-Publications.html.

8. NIST Computer Forensic Tool Testing Project. Accessed 06 Feb 2011. www.cftt.nist.gov.

9. Shroader, A. "How to Validate Your Forensic Tools." Orem: Paraben Corp. 2010.

Josh Brunty currently manages the digital forensics graduate program and the digital forensics research and casework laboratories at the Marshall 

University Forensic Science Center in Huntington, WV. Josh holds numerous certifications within the digital forensics discipl ine including: AccessData 

Certified Examiner (ACE), Computer Hacking Forensic Examiner (CHFI), Seized Computer Evidence Recovery Specialist (SCERS), and is certified in 

Information Assessment Methodology (NSA-IAM). He has developed a variety of digital forensics training curriculum; including past recertificat ion 

scenarios/exams for the International Association of Computer Investigative Specialists (IACIS). Josh is an active member of the Mid-Atlantic 

Association of the High Technology Crime Investigation Association (HTCIA) and the Digital-Multimedia Sciences section of the American Academy of 

Forensic Sciences (AAFS). He can be reached at josh.brunty@marshall.edu.

Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 34 of 54
Annex Header Pages.docx

Annex D: MaverickEye Preliminary Software Inspection Report

Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 35 of 54
MaverickEye Preliminary Source Code Inspection Report 12/14/2017

Size Note Observations

MaverickEye/

Logging Client.rar 5.06MB Unremarkable (an archive)

Logging Client/ 17.1MB Why is this name used? Was all the cource code provided?

Makefile 1.7KB Unremarkableconfigure 1.24KB Unremarkablesrc/ 17.1MB

TODO Annex E Completeness: “There's still loads of work to be done to make 

this a fully fledged Bittorrent Client” indicating 4 features to be 

improved, 3 features to be added, and the need to improve documentation; Code Quality: “If anyone finds bugs or anything in 

the code (which I'm sure there are many) feel free to drop me 

an email” indicates MonoTorrent is open source SW. script Unremarkable

README Annex E Instructions to developers for building and using the MonoTorrent 

code. The code is in MonoTorrent.Tracker (see ...MonoTorrent/). MonoTorrent.TrackerApp contains sample tracker implementation.

MonoTorrent.sln A visual studio development session.LICENSE Annex E Authors: Alan McGovern and Olivier Dufour; Copyright 2006 

Alan McGovern unlimited permissions, no warranty.

build.xml Unremarkable

TrackerApp/ 274KB

trackerapp.in UnremarkableTrackerApp.csproj UnremarkableStressTest.cs UnremarkableMain.cs Author and 2006 copyright Gregor Burger, burger.gregor@gmail.comChangeLog Several changes logged by Alan McGovern 2007 to 2009AssemblyInfo.cs Author and 2006 copyright Gregor Burger, burger.gregor@gmail.comapp.config Unremarkableobj/

Debug/ Unremarkable: Folder contains one empty sub-folder, 1 file containing 

log records,and 7 files that cannot be opened, are empty or contain junk

Page 1 Dr. Kal Toth, P.Eng.

Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 36 of 54
MaverickEye Preliminary Source Code Inspection Report 12/14/2017

Release/ Unremarkable: Folder contains one empty sub-folder, 1 file containing 

log records,and 7 files that cannot be opened, are empty or contain junk

SharpPcap/ 2.59MB Open Source SW under GNU LGPL for protocol capture; most of the 

code is fairly well-documented

***********.cs (22 files + 1 image) Most files are copyright Chris Morgan, Tamir Gal Phillip Lemon (2005 

to 2011

WinPcap/ (13 files) Most files are copyright Chris Morgan, Tamir Gal Phillip Lemon (2005 

to 2011

PacketDotNet/ 1 unremarkable XML file plus dll (non-text file)obj/debug/ 1 empty folder + 8 unremarkable files: 2 are non-text and 3 are emptyLibPcap/ Ditto ...code is well commenteddocs/Api/SharpPcap.xml Unremarkablebin/Debug/ (5 files) Unremarkable: 2 XML + derived ddll (non-text) + file containing junkAirPcap/ (23 files) Most files are copyright of Chris Morgan

Samples/ 6.9KB

ClientSample.cs Unremarkable

Program.cs Unremarkable

Samples.csproj Unremarkable

SampleClient/ 493KB

***********.cs (3 files) Unremarkable – 3 file(s) minimally commented

TestClient.suo Non-text file

***********.cs (6 files) Unremarkable – 6 file(s) minimally commentedProperties/ (3files) Unremarkable

obj/

Debug/ 1 empty folder + 13 unremarkable files: 2 are non-text and 3 are 

empty

Release/ 1 empty folder + 8 unremarkable files: 2 are non-text and 3 are empty

MonoTorrent.Tests/ 328KB

MonoTorrent.Tests.csproj Unremarkable – file void of meaningful commentsTracker/ (3 files) Unremarkable – contains 3 file(s) with minimal commentsDht/

AssemblyInfo.cs 1 file copyright Alan McGovern 2008,alan.mcgovern@gmail.com***********.cs (8 files) Unremarkable – 8 file(s) minimally commentedTokenTest.cs Copyright (C) 2008 Olivier Dufour olivier.duff@gmail.com

Page 2 Dr. Kal Toth, P.Eng.

Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 37 of 54
MaverickEye Preliminary Source Code Inspection Report 12/14/2017

Common/ Unremarkable – 8 file(s) minimally commented

BEncodingTest.cs Copyright (C) 2006 Alan McGovernBitFieldTest.cs Copyright (C) 2006 Alan McGovern***********.cs (8 files) Unremarkable – 8 file(s) minimally commentedTorrentTest.cs Copyright (C) 2006 Alan McGovernUriQueryBuilderTests.cs Copyright (C) 2009 Olivier Dufour and Alan McGovern

Client/

AllowedFastAlgorithmTest.cs Copyright (C) 2006 Alan McGovern***********.cs (2 files) Unremarkable – 2 file(s) minimally commentedDiskWriterTests.cs Copyright (C) 2009 Alan McGovernEndGamePickerTests.cs UnremarkableFileManager.cs DiskWriterTests.csHttpTrackerTests.cs UnremarkableInitialSeedingModeTest.cs UnremarkableInitialSeedUnchokerTests.cs Copyright (C) 2009 Alan McGovern***********.cs (5 files) Unremarkable – 5 file(s) minimally commentedNetworkIOTests.cs Copyright (C) 2010 Alan McGovernNullWriter.cs Copyright (C) 2009 Alan McGovernPeerMessagesTest.cs Copyright (C) 2006 Alan McGovernPeerTest.cs Copyright (C) 2008 Alan McGovern***********.cs (5 files) Unremarkable – 3 file(s) minimally commentedPriorityPickerTests.cs Copyright (C) 2008 Alan McGovern***********.cs (5 files) Unremarkable – 5 file(s) minimally commentedTestPicker.cs Copyright (C) 2008 Alan McGovern***********.cs (4 files) Unremarkable – 4 file(s) minimally commentedTransferTest.cs Copyright (C) 2008 Alan McGovernUdpTrackerTests.cs Copyright (C) 2008 Alan McGovern

MonoTorrent.Dht/ 373KB Unremarkable

TransactionId.cs Unremarkablemonotorrent.dht.pc.in UnremarkableMonoTorrent.Dht.csproj UnremarkableMessageLoop.cs Copyright (C) 2008 Alan McGovernMessageFactory.cs Copyright (C) 2008 Alan McGovernMessageException.cs UnremarkableMessage.cs Copyright (C) 2008 Alan McGovernDhtEngine.cs Copyright (C) 2008 Alan McGovern

Page 3 Dr. Kal Toth, P.Eng.

Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 38 of 54
MaverickEye Preliminary Source Code Inspection Report 12/14/2017

BigInteger.cs Copyright (c) 2003 Ben Maurer, 2002 Chew Keong TAN, 2004, 2007 

Novell, Sebastien Pouliot <sebastien@ximian.com>

AssemblyInfo.cs UnremarkableTasks/

AnnounceTask.cs Unremarkable

GetPeersTask.cs UnremarkableInitialiseTask.cs UnremarkableITask.cs UnremarkableRefreshBucketTask.cs UnremarkableReplaceNodeTask.cs UnremarkableSendMessageTask.cs UnremarkableTask.cs Unremarkable

RoutingTable

Bucket.cs Copyright (C) 2008 Alan McGovern, Jérémie Laval 

<jeremie.laval@gmail.com>

RoutingTable.cs Copyright (C) 2008 Alan McGovern

obj/

Debug/ 1 empty folder + 10 unremarkable files: 2 are non-text and 3 are 

empty

Release/ 1 empty folder + 8 unremarkable files: 2 are non-text and 3 are empty

Nodes/

Node.cs Copyright (C) 2008 Alan McGovern, Jérémie LavalNodeId.cs Copyright (C) 2008 Alan McGovern, Jérémie LavalNodeState.cs Copyright (C) 2008 Alan McGovern, Jérémie LavalTokenManager.cs Copyright (C) 2008 Olivier Dufour <olivier.duff@gmail.com>

Messages/

Errors/

ErrorMessage.cs Copyright (C) 2008 Alan McGovern

Queries/

AnnouncePeer.cs Copyright (C) 2008 Alan McGovernFindNode.cs Copyright (C) 2008 Alan McGovernGetPeers.cs Copyright (C) 2008 Alan McGovernPing.cs Copyright (C) 2008 Alan McGovernQueryMessage.cs Copyright (C) 2008 Alan McGovern

Responses/

AnnouncePeerResponse.cs Copyright (C) 2008 Alan McGovern

Page 4 Dr. Kal Toth, P.Eng.

Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 39 of 54
MaverickEye Preliminary Source Code Inspection Report 12/14/2017

FindNodeResponse.cs Copyright (C) 2008 Alan McGovern

GetPeersResponse.cs Copyright (C) 2008 Alan McGovernPingResponse.cs Copyright (C) 2008 Alan McGovernResponseMessage.cs Copyright (C) 2008 Alan McGovern

Listeners/

DhtListener.cs Unremarkable

EventArgs/

NodeAddedEventArgs.cs UnremarkableNodeFoundEventArgs.cs Copyright (C) 2008 Olivier DufourSendMessageEventArgs.cs UnremarkableTaskCompleteEventArgs.cs Unremarkable

MonoTorrent/ 3.71MB

monotorrent.pc.in UnremarkableMonoTorrent.csproj Project file – otherwise unremarkableLogManager.cs Imported from SharpDc project, written by Vladislav Pozdnyakov 

(hackward@gmail.com) 2012-2013, licensed under the LGPL

DBConnect.cs Database integration component otherwise unremarkableChangeLog Several changes logged by Alan McGovern 2007 to 2009AssemblyInfo.cs.in Copyright Alan McGovern,Gregor Buguer, MIT X11 Licensed

AssemblyInfo.cs Copyright Alan McGovern,Gregor Buguer, MIT X11 Licensed

obj/

Debug/ Unremarkable: Folder contains one empty sub-folder, 1 file containing 

log records,and 5 files that cannot be opened, are empty or contain junk

Release/ Unremarkable: Folder contains one empty sub-folder, 1 file containing 

log records,and 5 files that cannot be opened, are empty or contain junk

MonoTorrent.Tracker/

Tracker.cs Author and Copyright 2006: Gregor Burger 

burger.gregor@gmail.com, open permissions, no warranty

SimpleTorrentManager.cs Author and Copyright 2006: Gregor Burger, open permissions, no 

warranty

RequestParameters.cs UnremarkableRequestMonitor.cs UnremarkablePeer.cs Author and 2006 Copyright: Gregor Burger, open permissions, no 

warranty

Itrackable.cs Unremarkable

Page 5 Dr. Kal Toth, P.Eng.

Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 40 of 54
MaverickEye Preliminary Source Code Inspection Report 12/14/2017

IPAddressComparer.cs UnremarkableInfoHashTrackable.cs UnremarkableChangeLog Multiple changes logged 2007-2009 by Alan McGovern 

alan.mcgovern@gmail.com

Listeners/

HttpListener.cs Copyright 2006: Gregor Burger, open permissions, no 

warranty

ListenerBase.cs UnremarkableManualListener.cs UnremarkableUdpListener.cs Copyright 2006: Olivier Dufour, olivier.duff@gmail.com, open, no 

warranty

Frontend/

AnnounceParameters.cs Author and Copyright 2006: Gregor Burger, open permissions, no 

warranty

ChangeLog Empty Empty Fileglobal.asax Unremarkableindex.aspx UnremarkableScrapeParameters.cs Author and Copyright 2006: Gregor Burger, open permissions, no 

warranty

web.config Unremarkable

Exceptions/

TrackerException.cs Unremarkable

EventArgs/ Unremarkable

AnnounceEventArgs.cs UnremarkablePeerEventArgs.cs UnremarkableScrapeEventArgs.cs UnremarkableTimedOutEventArgs.cs Unremarkable

MonoTorrent.TorrentWatchers

ITorrentWatcher.cs Copyright 2006 Stephane Zanoni <stephane@ethernal.net>TorrentFolderWatcher.cs Copyright 2006 Stephane Zanoni stephane@ethernal.netTorrentWatcherEventArgs.cs Copyright 2006 Stephane Zanoni stephane@ethernal.netTorrentWatchers.cs Copyright 2006 Stephane Zanoni stephane@ethernal.net

MonoTorrent.Common

AsyncResult.cs Author and 2008 copyright, Alan McGovern, unlimited permissions, no 

warranty

BitField.cs Author and 2006 copyright, Alan McGovern, unlimited permissions, no 

warranty

Page 6 Dr. Kal Toth, P.Eng.

Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 41 of 54
MaverickEye Preliminary Source Code Inspection Report 12/14/2017

Cache.cs Author and 2009 copyright, Alan McGovern, unlimited permissions, no 

warranty

ChangeLog Change records 2008-2009 by Alan McGovernCheck.cs UnremarkableEditableTorrent.cs UnremarkableEnums.cs Author and 2006 copyright, Alan McGovern, unlimited permissions, no 

warranty

FileMapping.cs Author and 2009 copyright, Alan McGovern, unlimited permissions, no 

warranty

HashAlgoFactory.cs Author and 2009 copyright, Alan McGovern, unlimited permissions, no 

warranty

Hashes.cs UnremarkableICacheable.cs Author and 2008 copyright, Alan McGovern, unlimited permissions, no 

warranty

IFileSource.cs UnremarkableInfoHash.cs UnremarkableMagnetLink.cs UnremarkableMonoTorrentCollectionBase.cs UnremarkablePeerID.cs Authors: Gregor Burger burger.gregor@gmail.com, Alan McGovern, 

alan.mcgovern@gmail.com, Copyright (C) 2006 Gregor Burger, unlimited permissions, no warranty

RawTrackerTier.cs UnremarkableRawTrackerTiers.cs UnremarkableSpeedMonitor.cs Author and 2010 copyright, Alan McGovern, unlimited permissions, no 

warranty

TimeoutDispatcher.cs Author: Aaron Bockover abockover@novell.com Copyright (C) 2008 

Novell, Inc., unlimited permissions, no warranty

ToolBox.cs Author and 2006 copyright, Alan McGovern, unlimited permissions, no 

warranty

Torrent.cs Author and 2006 copyright, Alan McGovern, unlimited permissions, no 

warranty

TorrentCreator.cs Authors: Gregor Burger burger.gregor@gmail.com, Alan McGovern 

alan.mcgovern@gmail.com, Copyright 2006-2007 Gregor Burger & Alan McGovern, unlimited permissions, no warranty

TorrentCreatorAsyncResult.cs UnremarkableTorrentEditor.cs Author and 2010 copyright, Alan McGovern, unlimited permissions, no 

warranty

Page 7 Dr. Kal Toth, P.Eng.

Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 42 of 54
MaverickEye Preliminary Source Code Inspection Report 12/14/2017

TorrentException.cs Author and 2006 copyright, Alan McGovern, unlimited permissions, no 

warranty

TorrentFile.cs Author and 2006 copyright, Alan McGovern, unlimited permissions, no 

warranty

TorrentFileSource.cs UnremarkableUriHelper.cs Patrik Torstensson Patrik.Torstensson@labs2.com, Wictor WilÃ©n 

(decode/encode functions) wictor@ibizkit.se, Tim Coleman tim@timcoleman.com), Gonzalo Paniagua Javier gonzalo@ximian.com, Marek Habersack mhabersack@novell.com, Copyright 2005-2010 Novell, Inc http://www.novell.com

UriQueryBuilder.cs Authors: Olivier Dufour olivier.duff@gmail.com, Alan McGovern 

alan.mcgovern@gmail.com, Copyright (C) 2009 Olivier Dufour, Alan McGovern, unlimited permissions, no warranty

VersionInfo.cs Author and 2006 copyright, Alan McGovern, unlimited permissions, no 

warranty

MonoTorrent.Client

WaitHandleGroup.cs UnremarkableTransferType.cs UnremarkableTorrentFileStream.cs UnremarkablePiece.cs Copyright (C) 2006 Alan McGovernPeerIO.cs Copyright (C) 2010 Alan McGovernNullDhtEngine.cs Copyright (C) 2009 Alan McGovernNetworkIO.cs Copyright (C) 2008 Alan McGovernMono.Security.dll dll (non text)MainLoop.cs Copyright (C) 2008 Alan McGovernLogger.cs UnremarkableIDhtEngine.cs Copyright (C) 2009 Alan McGovernFileStreamBuffer.cs UnremarkableCodeRoadmap.txt Interesting (not code) Road map (plan for restructuring) the MonoTorrent.ClientClientEngine.cs Copyright (C) 2006 Alan McGovernCLASS DESCRIPTION Documents class in MonoTorrent (undated therefore relevancy 

uncertain)

ChangeLog Change records in 2008 by Alan McGovernBlock.cs Copyright (C) 2006 Alan McGovernAsyncIOState.cs Copyright (C) 2008 Alan McGovernAsyncConnectState.cs Copyright (C) 2010 Alan McGovernAllowedFastAlgorithm.cs Copyright (C) 2006 Alan McGovern

Page 8 Dr. Kal Toth, P.Eng.

Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 43 of 54
MaverickEye Preliminary Source Code Inspection Report 12/14/2017

AllowedFastAlgorithm.cs/

InitialSeedUnchoker.cs Copyright (C) 2009 Alan McGovernIUnchoker.cs Copyright (C) 2009 Alan McGovernUnchoker.cs Copyright (C) 2009 Alan McGovern

Tracker/

AnnounceParameters.cs UnremarkableHTTPTracker.cs Copyright (C) 2007 Eric Butler, eric@extremeboredom.netITracker.cs UnremarkableScrapeParameters.cs UnremarkableTracker.cs Copyright (C) 2006 Alan McGovernTrackerConnectionId.cs Copyright (C) 2006 Alan McGovernTrackerFactory.cs Copyright (C) 2007 Eric Butler (co-authored with Alan McGovernTrackerTier.cs UnremarkableUdpTracker.cs Unremarkable

Tasks/

DelegateTask.cs UnremarkableTask.cs Copyright (C) 2008 Alan McGovern

Settings/

ChangeLog One change record: 2008-06-05 Alan McGovernEngineSettings.cs Copyright (C) 2006 Alan McGovernTorrentSettings.cs Copyright (C) 2006 Alan McGovern

RateLimiters/

DiskWriterLimiter.cs Copyright (C) 2009 Alan McGovernIRateLimiter.cs Copyright (C) 2009 Alan McGovernPauseLimiter.cs Copyright (C) 2009 Alan McGovernRateLimiter.cs Copyright (C) 2006 Alan McGovernRateLimiterGroup.cs Copyright (C) 2009 Alan McGovern

PieceWriter/

DiskWriter.cs UnremarkableIPieceWriter.cs UnremarkableMemoryWriter.cs UnremarkableNtfsSparseFile.cs UnremarkablePieceData.cs UnremarkablePieceWriter.cs Unremarkable

PiecePicking/

ChangeLog Change records in 2008 and 2009 by Alan McGovern

Page 9 Dr. Kal Toth, P.Eng.

Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 44 of 54
MaverickEye Preliminary Source Code Inspection Report 12/14/2017

EndGamePicker.cs Copyright (C) 2008 Alan McGovernEndGameSwitcher.cs Copyright (C) 2009 Alan McGovernIgnoringPicker.cs Copyright (C) 2008 Alan McGovernLoggingPicker.cs Copyright (C) 2009 Alan McGovernNullPicker.cs Copyright (C) 2009 Alan McGovernPiecePicker.cs Copyright (C) 2008 Alan McGovernPriorityPicker.cs Copyright (C) 2008 Alan McGovernRandomisedPicker.cs Copyright (C) 2008 Alan McGovernRarestFirstPicker.cs Copyright (C) 2008 Alan McGovernSlidingWindowPicker.cs Copyright (C) 2006 Karthik Kailash karthik.l.kailash@gmail.com, 

David Sanghera dsanghera@gmail.com

SortedList.cs Copyright (C) 2008 Alan McGovernStandardPicker.cs Copyright (C) 2006 Alan McGovern

Peers/

ChangeLog 2008-01-12 Alan McGovern <alan.mcgovern@gmail.com>Peer.cs Copyright (C) 2006 Alan McGovernPeerList.cs Unremarkable

PeerConnections/

ChangeLog 2008 Change Records by Alan McGovernConnectionFactory.cs UnremarkableHTTPConnection.cs Copyright (C) 2006 Alan McGovernHttpRequestData.cs UnremarkableIConnection.cs UnremarkableIPV6Connection.cs UnremarkablePeerId.cs Copyright (C) 2006 Alan McGovernTCPConnection.cs Copyright (C) 2006 Alan McGovern

NetworkIO/

ReceiveMessageState.cs Copyright (C) 2010 Alan McGovernState.cs Copyright (C) 2010 Alan McGovern

Modes/

DownloadMode.cs UnremarkableErrorMode.cs UnremarkableHashingMode.cs UnremarkableInitialSeedingMode.cs Copyright (C) 2009 Alan McGovernMetadataMode.cs Copyright (C) 2009 Olivier Dufour, co-authored with Alan McGovern

Page 10 Dr. Kal Toth, P.Eng.

Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 45 of 54
MaverickEye Preliminary Source Code Inspection Report 12/14/2017

Mode.cs Copyright (C) 2009 Alan McGovernPausedMode.cs UnremarkableStoppedMode.cs UnremarkableStoppingMode.cs Unremarkable

Messages/

UnknownMessage.cs Empty FilePeerMessage.cs UnremarkableMessageBundle.cs UnremarkableMessage.cs Copyright (C) 2008 Alan McGovernIMessage.cs Unremarkable

uTorrent/

PeerExchangeMessage.cs Unremarkable

UdpTrackerMessages/

UdpTrackerMessage.cs Copyright (C) 2008 Alan McGovernScrapeResponseMessage.cs Copyright (C) 2008 Alan McGovernScrapeMessage.cs Copyright (C) 2008 Alan McGovernScrapeDetails.cs Copyright (C) 2008 Alan McGoverMessageType.cs Copyright (C) 2008 Alan McGoverErrorMessage.cs Copyright (C) 2008 Alan McGoverConnectResponseMessage.cs Copyright (C) 2008 Alan McGoverConnectMessage.cs Copyright (C) 2008 Alan McGoverAnnounceResponseMessage.cs Copyright (C) 2008 Alan McGoverAnnounceMessage.cs Unremarkable

Extensions/

AuthenticationMessage.cs Unremarkable

StandardMessages/

BitfieldMessage.cs Copyright (C) 2006 Alan McGovernCancelMessage.cs Copyright (C) 2006 Alan McGovernChangeLog 2008-02-02 Alan McGovernChokeMessage.cs Copyright (C) 2006 Alan McGovernHandshakeMessage.cs Copyright (C) 2006 Alan McGovernHaveMessage.cs Copyright (C) 2006 Alan McGovernInterestedMessage.cs Copyright (C) 2006 Alan McGovernKeepAliveMessage.cs Copyright (C) 2006 Alan McGovernNotInterestedMessage.cs Copyright (C) 2006 Alan McGovernPieceMessage.cs Copyright (C) 2006 Alan McGovern

Page 11 Dr. Kal Toth, P.Eng.

Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 46 of 54
MaverickEye Preliminary Source Code Inspection Report 12/14/2017

PortMessage.cs Copyright (C) 2006 Alan McGovernRequestMessage.cs Copyright (C) 2006 Alan McGovernUnchokeMessage.cs Copyright (C) 2006 Alan McGovern

LibtorrentMessages/

ChangeLog Empty FileExtendedHandshakeMessage.cs Copyright (C) 2006 Alan McGovernExtensionSupports.cs Copyright (C) 2009 Alan McGovernLibtorrentMessage.cs Copyright (C) 2006 Alan McGovernLTChat.cs UnremarkableLTMetadata.cs Copyright (C) 2006 Alan McGovernLTSupport.cs Unremarkable

FastPeerExtensions/

AllowedFastMessage.cs Copyright (C) 2006 Alan McGovernChangeLog Empty FileHaveAllMessage.cs Copyright (C) 2006 Alan McGovernHaveNoneMessage.cs Copyright (C) 2006 Alan McGovernIFastPeerMessage.cs UnremarkableRejectRequestMessage.cs Copyright (C) 2006 Alan McGovernSuggestPieceMessage.cs Copyright (C) 2006 Alan McGovern

MonoTorrent.BEncoding

BEncodedDictionary.cs Author and 2008 copyright, Alan McGovern, unlimited permissions, no 

warranty

BEncodedList.cs Author and 2008 copyright, Alan McGovern, unlimited permissions, no 

warranty

BEncodedNumber.cs Author and 2008 copyright, Alan McGovern, unlimited permissions, no 

warranty

BencodedString.cs Author and 2008 copyright, Alan McGovern, unlimited permissions, no 

warranty

BencodingException.cs Author and 2008 copyright, Alan McGovern, unlimited permissions, no 

warranty

ChangeLog Empty log fileIBEncodedValue.cs Author and 2008 copyright, Alan McGovern, unlimited permissions, no 

warranty

RawReader.cs

Author and 2008 copyright, Alan McGovern, unlimited permissions, no warranty

BanLists

Page 12 Dr. Kal Toth, P.Eng.

Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 47 of 54
MaverickEye Preliminary Source Code Inspection Report 12/14/2017

BanList.cs Author and 2008 copyright, Alan McGovern, unlimited permissions, no 

warranty

ListParser.cs Author and 2008 copyright, Alan McGovern, unlimited permissions, no 

warranty

RangeCollection.cs Author and 2008 copyright, Alan McGovern, unlimited permissions, no 

warranty

GeoIP_project/ 4.07MB

RestSharp.xml Unremarkable XMLRestSharp.dll dll derived from aboveProgram.cs UnremarkableNewtonsoft.Json.xml Unremarkable XMLNewtonsoft.Json.dll dll derived from aboveMaxMind.GeoIP2.XML Unremarkable XMLMaxMind.GeoIP2.dll dll derived from aboveMaxMind.Db.xml Unremarkable XMLMaxMind.Db.dll dll derived from aboveGeoIP_project.csproj Unremarkable project fileApp.config UnremarkableProperties/

AssemblyInfo.cs Unremarkable

obj/

Debug/ 1 empty folder, 3 unremarkable files, 1 dll, 2 unreadable fiiles (dlls), 1 

junk, 3 empty

Release/ 1 empty folder, 2 unremarkable files, 1 dll, 2 unreadable fiiles (dlls), 1 

junk, 3 empty

bin/

Debug/ 11 unremarkable filesRelease/ 11 unremarkable files

DhtSampleClient/ 4.20KB

AssemblyInfo.cs Copyright © Alan McGovern 2008Program.cs UnremarkableSampleClient.csproj Unremarkable

curses/ 21.5KB

MonoTorrent Author: Miguel de Icaza miguel.de.icaza@gmail.com Copyright 2007 

Novell

CreatingCaptureFile/ 4.00MB

PcapClass.cs Unremarkable

Page 13 Dr. Kal Toth, P.Eng.

Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 48 of 54
MaverickEye Preliminary Source Code Inspection Report 12/14/2017

CreatingCaptureFile.csproj Unremarkable

Service References/ Empty Folderobj/

Debug/ 1 empty folder, 3 unremarkable files, 1 dll, 2 unreadable fiiles (dlls), 1 

junk, 3 empty

Release/ 1 empty folder, 2 unremarkable files, 1 dll, 2 unreadable fiiles (dlls), 1 

junk, 3 empty

FakesAssemblies/

SharpPcap.Fakes.dll dll (non text)SharpPcap.Fakes.fakesconfig UnremarkableSharpPcap.Fakes.messages UnremarkableSharpPcap.Fakes.xml Unremarkable

Fakes/

SharpPcap.fakes Unremarkable

bin/

Debug/ 12 Unremarkable FilesRelease/ Empty Folder

AddFeatures/ 152KB

Program.cs Crypto Module – UnremarkableApp.Config UnremarkableAddFeatures.csproj Build Program – Unremarkable

Properties/

AssemblyInfo.cs Unremarkable -part of above build process

obj/

Debug/ Unremarkable: Folder contains one empty sub-folder, 1 file containing 

log records,and 5 files that cannot be opened, are empty or contain junk

Release/ Unremarkable: Folder contains one empty sub-folder, 1 file containing 

log records,and 5 files that cannot be opened, are empty or contain junk

bin/

Debug/ Unremarkable – 2 unreadable fiiles (dlls) and 1 config fileRelease/ Unremarkable – 2 unreadable fiiles (dlls) and 1 config file

.vs/ 609KB

MonoTorrent/V14/ Empty Folder

Page 14 Dr. Kal Toth, P.Eng.

Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 49 of 54
Annex E Maverickeye Notices.docx

Annex E: MaverickEye Notices

[1] Logging Client / LICENSE.txt

[2] Logging Client / DOTO.txt

[3] Logging Client / README.txt

Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 50 of 54
Annex E Maverickeye Notices.docx

[1] Logging Client / src / LICENSE.txt

// MonoTorrent

//

// Authors:

// Alan McGovern <alan.mcgovern@gmail.com>

// Olivier Dufour

//

// Copyright (C) 2006 Alan McGovern

//

// Permission is hereby granted, free of charge, to any person obtaining

// a copy of this software and associated documentation files (the

// "Software"), to deal in the Software without restriction, including

// without limitation the rights to use, copy, modify, merge, publish,

// distribute, sublicense, and/or sell copies of the Software, and to

// permit persons to whom the Software is furnished to do so, subject to

// the following conditions:

// 

// The above copyright notice and this permission notice shall be

// included in all copies or substantial portions of the Software.

// 

// THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,

// EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF

// MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND

// NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE

// LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION

// OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION

// WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 51 of 54
Annex E Maverickeye Notices.docx

[2] Logging Client / src / TODO.txt

[ Client DLL ]

There's still loads of work to be done to make this a fully fledged Bittorrent Client. I've divided the work into 

three sections (for the moment). Features to be added, features to be improved and sections of code that 

need rearchitecting. I've also put a difficulty estimation for anyone interested in picking an item and 

completing it.

-- FEATURES TO BE ADDED --

 01) HTTP Seeding - The ability to use a normal HTTP/FTP download as a "seed". [MEDIUM-HIGH]

 04) Implement DHT/Peer Exchange. [MEDIUM-LOW]

 14) Support SOCKS proxies

 29) Algorithm to allow for automatic scheduling of torrents based on rules is being implemented. Should 

allow for people to select "seed for 30 mins after completion or a ratio of 1.4 us reached and total 

bandwidth is below 150kB/sec" etc.

-- FEATURES TO BE IMPROVED --

 01) Allow editing of .torrent information EXCEPT for the infohash section [MEDIUM]

 05) New super seeding algorithm. At the moment defaults to "seeding" which defaults to "downloading. 

[LOW]

 30) Put peers that i can connect to but drop the connection in a seperate "busy" list instead of dropping 

them completely.

 31) After receiving X number of pieces from a peer, reduce their FailedConnectionAttempts value as 

they are "good"

If anyone finds bugs or anything in the code (which i'm sure there are many :p) feel free to drop me an 

email. For the moment i don't want people commiting patches directly to SVN, i'd like to see them first. But 

if you want to fix a bug, please go right ahead and write the code. The only request i have is to do your best 

to match my coding style. There's nothing worse than having several different coding styles in the same 

class.

[ Tracker DLL ]

-- FEATURES TO BE ADDED --

 06) Integrate the Tracker into the GUI 

 08) Change the backend to use the event form 07

 09) Add in support for NAT-Checking (checking if peers are connectable). If they aren't, send em a 

warning message

-- FEATURES TO BE IMPROVED --

 03) Improve doc

Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 52 of 54
Annex E Maverickeye Notices.docx

[3] Logging Client / src / README.txt

PRE-REQUISITES

------------------------------------------------------------------------------------------------------------

To run: MS.NET 2.0 or Mono 1.1.16.1+

To build: MonoDevelop, Visual Studio, SharpDevelop or the standard *nix toolchain

BUILDING MONOTORRENT:

------------------------------------------------------------------------------------------------------------

MakeFiles:

To build using the makefiles, execute the following commands:

$ ./autogen.sh

$ make

$ make install

This will only build MonoTorrent.dll. The other sub-projects are not built via this method.

Project Files:

You can open the MonoTorrent.sln file in MonoDevelop, SharpDevelop or Visual Studio. This is the 

preferred way to build MonoTorrent and all the sub-projects.

BRIEF INTRODUCTION INTO HOW THE CODE SHOULD BE USED

------------------------------------------------------------------------------------------------------------

[MonoTorrent Client]

To run the sample client you need to do the following:

1) Make sure that MonoTorrent.dll and SampleClient.exe are in the same folder

2) Create a folder in that directory called "Torrents".

3) Put any number of .torrent files into the Torrents directory. This files will all be loaded by the sample 

client.

5) Launch SampleClient.exe to begin downloading. All files will be downloaded to a directory called 

"Downloads".

Note: Only statistics will only be shown for the first .torrent loaded into the engine. So there is no real point

in loading more than one .torrent into the engine.

Developer Notes:

There are a few important things developers should note before creating a gui/service using the library. 

Firstly there is no guarantee what thread the events will be fired on, so if you're doing GUI updates, you will 

need to make sure that you perform your actual GUI update in a threadsafe manner.

[The Tracker]

============

The code of the Tracker is located in MonoTorrent.Tracker. There is one sample Tracker implementation

in MonoTorrent.TrackerApp. 

The Tracker is a piece of Software which listens for HttpRequests. Each Request can either be an 

Announce or Scrape request. Therefore the Tracker needs code which handles HttpRequests. The Tracker 

was programmed in such a way that it is independent of the http handling code. The http handling code is 

called Frontend.

Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 53 of 54
Annex E Maverickeye Notices.docx

There are currently two Frontends implemented. The first uses the class HttpListener. This implementation

got most attention. The second one uses the Asp.Net infrastructe and the HttpHandles classes. It therefore

could be used in xsp2, mod_mono or even in IIS. But the second implementation was just a proof of 

concept and is not tested but should be functional. There exists and Frontend directory which contains all 

the Frontend handling code.

There is also a Backend part of the Tracker. The backend is responsible for storing the Informations per

Torrent which should be Announced to the peers. There is currently one Backend implementation which 

uses the .Net internal Datastructes List<> and Dictionary<> called SimpleTorrentManager. A Backend 

needs to implement the ITorrentManager interface.

If you would like to start the Tracker the TrackerEngine is the class you would like to use. The sequence

below is enough to start the Tracker:

TrackerEngine engine = TrackerEngine.Instance

engine.Address = "127.0.0.1";

engine.Port = 10000;

engine.Frontend = TrackerFrontend.InternalHttp;

engine.Start();

Adding Torrents is easy too. Just get an Tracker instance and call AddTorrent:

Torrent t = new Torrent();

t.LoadTorrent(path);

TrackerEngine.Instance.Tracker.AddTorrent(t);

The two code snippets are enough to start a simple tracker. If you would like to tune the Tracker to use

less Bandwidth you can set various things in the Tracker instance. One such thing would be to use the 

compact response format:

Tracker.Instance.AllowNonCompact = true;

The other place where you can tune is to implement the IIntervalAlgorithm. An implementor can controll at 

which rate the peers should request an Announce or Scrape. Currently we have an static implementation 

which uses static defaults taken from the original BitTorrent implementation. It's even possible to higher

the intervals based on the number of peers using the Torrent. 

Tracker.cs is the code where everything is glued together. It is something like the heart of the Tracker

implementation.

How to Test:

If you want to test the Tracker just compile it with MonoDevelop. The Tracker searches (and creates if not

found) for a directory named ./torrents. In this Directory every Torrent is loaded on startup. To test 

the Torrent you need some torrents pointing at the Tracker. This can be done with the unit test. Just 

run gnunit2 and load the Common.dll in src/bin/Debug. Copy the single.torrent and torrentcreator.torrent 

into src/bin/Debug/torrents and start the Tracker in MonoDevelop. Then you can load the Torrents in 

Azureus or BitTorrent and check if the Tracker reacts on Announces and Scrapes. 

Case 3:15-cv-00907-AC Document 138-12 Filed 02/28/18 Page 54 of 54