WO2003021433A1

WO2003021433A1 - Method and system for compiling and verifying computer code

Info

Publication number: WO2003021433A1
Application number: PCT/AU2002/001206
Authority: WO
Inventors: Martin Sigmund
Original assignee: Mobilesoft (Aust) Pty Ltd.
Priority date: 2001-09-03
Filing date: 2002-09-03
Publication date: 2003-03-13
Also published as: AUPR745301A0

Abstract

A method of compiling source code into object code uses a compiler which inserts time and/or date data into the object code. The method includes the steps of compiling the source code, and setting or forcing clock data used by the compiler to a predetermined value or range of values during the compiling of source code. Verification of the object code is preferably thereafter done through the additional preferred step of comparing the object code with object code created in a previous compiling operation, to determine whether they are identical.

Description

Method and System for Compiling and Verifying Computer Code

Field of the Invention

The present invention relates to the compilation and verification of computer code. It relates particularly to the compilation of code in a manner that facilitates verification of that code, and to methods for verifying code utilising such compilation methods.

Background to the Invention A computer program is generally written as a series of statements and instructions in a high-level language, such as C++ and the like.

This form of a program is known as source code, and may comprise a plurality of separately developed modules of one or more routines for carrying out various different functions of the program. In order for such a program to be run on a computer, the source code must be translated into machine code, i.e. code that a computer can understand and follow directly.

The conversion of source code into object code is carried out by a compiler. A compiler analyses the source code modules, and converts them into modules of object code - the machine code equivalent of the source code.

A link editor, which is generally included in the compiler, then combines the object code modules (as well as object code for library routines and other required system code) into executable code, i.e. an addressable machine code file that is ready to run on a computing device. The addressable machine code file is the file that is supplied to a user of the program, and, generally, the company or individual authoring the program will retain the source code.

In many cases, it may be necessary to verify that the executable code run by a user is a true copy of the original executable code. Verification may be desirable for a number of reasons. For example, verification may ensure that the code stored on the user's machine has not been corrupted (e.g. through a storage media failure). It may also ensure that a correct version of the program is running on a machine. In a particularly important application, the verification may be an authentication process by which a regulatory body is able to determine that program code and/or other stored data are authentic copies of approved software components. For example, in the gaming industry, game code components which run on gaming devices, such as electronic gaming machines (EGMs), must be approved by a gaming authority in order to ensure that the code will operate the gaming devices in accordance with appropriate gaming regulations. Once code is approved, the regulatory authority may need to verify periodically that the code running on a machine is indeed an approved version, and that it has not been modified e.g. to allow for a fraudulent win to be paid out.

Verification may allow a byte-by-byte check of the code, and various methods are available which act on each byte of a code to provide a resulting check number. If two code files produce the same check number, then the files can be considered to be identical to a high degree of certainty (dependent on the exact check method used).

The inventors of the present invention have identified a number of problems that can arise in the verification of code, and an aim of the present invention is to provide a method and system of compiling code so as to facilitate the verification process.

Summary of the Invention

Viewed from one aspect, the present invention provides a method of compiling source code into object code using a compiler which inserts time and/or date data into the object code, the method including the steps of:

(a) compiling the source code; and

(b) setting or forcing clock data used by the compiler to a predetermined value or range of values during the compiling of source code.

The present invention helps to ensure that consistent machine code is produced from the same source code. To understand this, it should be realised that a compiler will often insert time and date data into the object code that it creates as well as into the final linked code.

This can cause problems in code verification, as the resulting executable code may include a number of date/time stamps within its body, and so, on a byte-by-byte comparison, executable code compiled from the same source code will vary depending on the time that the executable code was compiled.

Thus, without the present invention, executable code produced by for example a regulator from the source code provided by an authoring company will not byte-for-byte match the executable code produced by the authoring company from the same source code, as the executable code of the regulator will have been compiled at a different time to that at which the executable code of the authoring company was compiled.

In view of this, authentic code provided by an authoring company to for example a gaming establishment may not by verifiable by the regulator using e.g. a byte-for-byte verification test.

The present invention however allows the authoring company and regulator to use the same known constant clock data and so produce identical executable code. The authoring company thus passes both the source code to be approved and the forced constant clock data used during the compilation process to the regulator. Once the regulator has approved the source code, the regulator can compile the code using the provided clock data (and the present inventive compiling method) to produce executable code that is the same as that produced by the authoring company. The regulator can therefore obtain e.g. a check number by acting on the code it holds, and can verify that a third party is using the same code by running the same check on their code and comparing the results.

The clock data may be set in any suitable manner so as to give a consistent output during the compile. It may for example be possible to intercept compiler calls to a clock of the system on which the compiler runs, and direct such calls so that they return data from a different address to that in which the clock data is normally kept. This different address may then store the desired clock data. Alternatively, the clock of the system may itself be set to a desired value. In a preferred embodiment of the present invention, the clock data on the machine that is running a compiler program is set to a desired value during a compile process. Thus, when the compiler reads the machine's clock it will always return the same value, and so will always insert the same value into the object code modules. In one embodiment, updating of the clock by the machine may possibly be disabled, so as to prevent the set clock data from changing. Preferably, however, the clock data is continually reset to the set value.

Setting and/or resetting may be carried out in any suitable manner, e.g. by running a setting/resetting program which may be in the form of for example a batch file, an independent executable program, scripting or the like.

Resetting should occur with sufficient frequency that the compiler will always see the same clock data. Various factors may affect this. For example, the resolution of the clock data and/or the resolution to which the compiler reads the clock data may affect the frequency of reset: If the clock only provides time to the nearest second or the compiler only reads/records the time to the nearest second, ignoring any tenths of seconds data, then resetting need only occur to prevent the update of the seconds data. The reset frequency may also be affected by the frequency with which the compiler updates or calls the clock data.

The time between clock data resets should also be long enough that it does not overly affect compile time by taking up processor time.

Where the clock/compiler resolution is about 1 second, then two resets per second may be adequate. Three resets per second are however preferable. It has been found that a reset period of between about 10 ms and about

550 ms provides adequate results, and that a reset every 330ms works well with for example Borland C++ 4.5, IBM Visual Age C++ for Windows 3.5, and Microsoft Visual C++ 6.0 running under Windows NT/2000.

The machine clock, which may be changed to the desired clock data values, may be a CMOS clock, a Bios clock and/or a system clock of an operating system, as appropriate. This may vary depending on where the compiler obtains its clock data from and how the machine running the compiler organises its clock data, e.g. a change of the CMOS clock may automatically change the system clock which is then read by the compiler. In one embodiment, the clock data may be forced to a meaningless set number or the like. In a preferred embodiment, however, the clock data provides identification data. Thus, the clock data could be changed so as to provide a version number for the resulting object and/or executable code corresponding to the version number of the source code. This might also include the date on which the executable code was produced. The forced data will preferably take on a date/time format.

As said, when supplying source code to a regulator or the like, the authoring company will also supply the clock data that was used whilst compiling its own copy of the executable code. When the clock data is the version number of the code, this may already be provided in the text of the source code itself, so that the authoring company may not need to specifically provide separate clock data. The regulator may enter the clock data into its own compiling system manually, e.g. at a prompt from the clock reset program, or the clock reset program could obtain the version number from the source code itself, e.g. by parsing a header of the code.

The source code and clock data may be supplied to the regulator in any suitable manner, e.g. by a download, such as over the Internet, or by providing a hard copy, such as on a CD-ROM or the like. In one preferred form, the source code is developed on source code management software, e.g. Microsoft's Visual Source Safe, and the code is exported e.g. onto a disc that is sent with the clock data to a regulator running the same or similar management software.

Various verification methods may be used to determine that executable codes compiled in the above manners are consistent with one another. Example verification procedures may for example use CRC, SHA-1 , and digital signatures in general. Verification may take place periodically or may be event- driven, e.g. when a jackpot of an electronic gaming machine is won.

The code to be verified may be inspected on-site, or through remote access. For example, a regulator may issue a request for a digital signature from a set software component on a remote system, which may then determine the verification data and transmit it to the regulator for comparison to the regulator's data.

The regulator may include a variable step in the verification process, e.g. by starting the verification procedure at a variable offset to the start of the code under investigation. This can then prevent the monitored party from determining the correct answer to a test, and of then merely storing that value for later replies to the regulator. The invention may be used in any suitable verification situation. As well as in the above-mentioned regulatory system, the invention may be used in for example determining that software on e.g. a remote computer, laptop, PDA

(personal digital assistant), mobile phone or any other programmed device, is approved and/or unaltered/uncorrupted.

It may also be used in escrow. Thus, an authoring company may lodge the source code to a program with an independent third party so that customers buying the program will have the reassurance of access to the source code should the authoring company go out of business or the like. The present invention can be used to allow the trusted third party to ensure that the source code they are given by the authoring company is the correct code for the executable program held by the customers.

The present invention may be used in any situation where code is translated, and the translated code needs to be verified. For example, it may be useful in the "compiling" of bytecode from for example Java, and the term "executable code" should be taken to cover "bytecode" and the like.

As well as setting the clock data to a set value, the present method of compiling may also include further steps to ensure that the executable code created by two parties from the same source code is consistent. Thus, it has been found preferable to perform a "clean" of a project prior to the build for each module (that is, force a compiler project clean environment). This should include for example the removal of housekeeping, optimisation and the like files, such as .obj, .pch, .exe, .res files, etc., as well as any template created files. Such files are preferably removed from the compiler environment because if a module is shared across a number of different projects, i.e. is used in executables working in different areas of a system, the build process may change, as a different compiler option and/or define may be used. Cleaning the compiler of such files helps to prevent such inconsistencies in the build. As a further step, when initiating the compile, the e.g. regulator should use the same directory/folder names as e.g. the authoring company, including ensuring case sensitivity. This is because it has been found that some compilers may include fully qualified paths relating to the source code into the object code for reference purposes. If these path names are different on the different compiling systems of e.g. an authoring company and a regulator, then inconsistent code may occur.

It is also preferable that the builds are performed on machines with identical configurations, such as CPU configurations (type, speed and quantity), memory capacity and I/O configurations. This is because a change in the hardware may affect for example the order in which the object code modules are arranged with respect to one another.

Identical configurations may be achieved by providing machines with the same physical hardware and the like, and/or possibly through the setting of the machine configurations of the systems to the same performance parameters. The former of these methods is preferred.

The constant clock data supplied is preferably selected so that it indicates a later time than the date/time stamp of the last modified source file. This ensures that all the builds will be created, and that the compiler will not use a previous build version because it seemingly has a later date/time stamp than the current setting (often if a compiler has a stored compiled module of a later date/time than that of an input version of the module, it will use the stored module and will not recompile the input module).

The above teachings provide methods for building consistent executable code from the same source code which can use existing compilers by providing e.g. an executable program which runs during the compile and resets the machine clock used by the compiler to a set value.

Viewed from a further aspect, the present invention provides a system of compiling code including: (a) compiling means for compiling source code into object code, the compiling means inserting time and/or date data into the object code; and (b) means for setting or forcing clock data used by the compiling means to a predetermined value or range of values during the compiling of source code. The present invention further provides computer software including: (a) a compiler component which compiles code with clock data embedded into the executable code, and

(b) a clock reset component which sets the clock data used by the compiler component to a predetermined value or range of values during a compile action. The present invention also extends to executable code compiled in accordance with the above compilation methods.

The present invention further extends to a method of verifying executable code including the step of comparing files of executable code from the same source code with one another, wherein the files of executable code are produced from the source code using the above compilation methods. The invention also provides a system for providing such a verification method.

Viewed from a further aspect, the present invention provides a method for verifying executable code, including the step of comparing files of executable code from the same source code with one another, wherein the executable files are produced from the source code using a compilation method which does not include different clock data in the executable files.

Viewed from a still further aspect, the present invention provides a method of building multiple copies of executable code from a single version of source code, including the steps of compiling the code at different times, wherein, during the compiling processes, identification data is included in the object code and executable code, the identification data being clock data which is identical for each compile process.

The present invention may alternatively provide consistent executable code from the same source code by providing a compiler that strips the clock data from the code before or after linking the object code modules together. Thus, the compiler may record the position of clock data in the object code modules and/or in the executable code, and may then remove them at an appropriate time in the compile process. In a further aspect, a compiler may be provided which inserts identification data into the object/executable code that is not time/clock data dependent, e.g. module/program version numbers.

In a still further aspect, the present invention includes a compiler which may compile code to include clock data, but which includes an option not to include clock data, e.g. to include nothing or desired data such as version data, during a final compile after the software is fully developed.

The invention further extends to verification systems and methods using any of the above mentioned features in any appropriate combination, and may provide an executable code verification method, wherein the executable code is compiled in accordance with any of the above methods.

The invention further extends to a verification system including a pair of compiling systems for receiving the same source code and producing executable code, and means for comparing executable code from the two compiling systems, wherein the compiling systems compile the source code in accordance with any of the above compiling methods.

The invention also extends to a method of verifying code, the method including the steps of building executable code from source code at a first site (for supply to a user of the code), supplying the source code to a second site (e.g. a regulator), building executable code from the source code at the second site, and comparing the executable code built at the two sites, wherein the first site forces or sets to a predetermined value or range of values the date and/or time data used during the building of the executable code at the first site, and provides the predetermined value or range of values to the second site, and wherein the second site forces or sets to the predetermined value or range of values the date and/or time data used during the building of the executable code at the second site.

Brief Description of the Drawings

An embodiment of the present invention will now be described, by way of example only, with reference to the accompanying drawings. It is to be understood that the particularity of the drawings does not supersede the generality of the preceding description of the invention. In the drawings:

Figure 1 is a schematic diagram of a verification system using a compiling method in accordance with an embodiment of the present invention; and

Figure 2 is a flow diagram of a clock reset program run in parallel with a compiler to provide a compiling method in accordance with an embodiment of the present invention. Detailed Description

Referring to Figure 1 , a software end user 1 may be for example a gaming establishment running a number of electronic gaming machines. The software it uses may run individual gaming machines, e.g. so that they play poker, blackjack, Keno and the like, and will provide appropriate wins and the like. The software may also run networked machines to provide e.g. jackpot games that run over a number of machines in a casino and/or over a number of machines in a state, etc. The software may also provide various management and monitoring functions. In order to ensure the proper running of gaming facilities, a regulator is often appointed e.g. by a state authority. The regulator needs to approve software that is to be run on the electronic gaming machines, and also needs to monitor the software actually installed at gaming establishments to ensure that the establishments are running approved software and that that software has not been illegally modified, e.g. to provide an illegal jackpot. Monitoring may take place periodically and/or may be triggered by a specific event, e.g. a jackpot win.

The present invention enables a regulator to monitor software run by an end user 1 to ensure that the software is identical to that approved by the regulator.

A software authoring company 2 will write software for use by an end user 1 in a high-level language, such as C++ and the like, which will generate source code 3. To generate an executable program 4, the source code 3 is compiled by a compiler program 5 run on a computer 6. Generally, the source code 3 will comprise a number of separately developed modules 7 that are linked together. Each module 7 may carry out one or more specific functions and may comprise one or more routines.

The compiler 5 translates the source code modules 7 into object code files 8, i.e. into machine language understandable by a computer. The compiler 5 then links the object code files 8 together into the single executable file 4. When doing this, the compiler 5 will also link in various library files 9, system files and the like, as necessary. The resulting executable code 4 is then provided to the end user 1 in any suitable manner, e.g. by being downloaded from the Internet or installed from disc or CD-ROM.

In order to have the software approved, the authoring company 2 will supply the source code 3 to a regulatory body 10 which can then inspect the code 3 to ensure that it complies with all necessary requirements

The regulator 10 will compile the source code 3 using a compiler 5' on their own computer system 6' to produce their own executable code 4'. The regulator 10 can then run a check program which operates on the executable code 4', e.g. in a byte-by-byte manner, to produce a check number 11.

The check program may take any suitable form, and may include a SHA- 1 check, a CRC check or some other check that produces an appropriate digital signature or other unique identifier.

Identical code will produce the same check number, and so the regulatory body 10 can check that the end user 1 has been provided with and is running uncorrupted and approved code by having the end user 1 perform the same check function and provide the body 10 with the resulting check number.

If the end user is using the correct software, then the check number that they produce will correspond to the check number 11 produced by the regulatory body 10 from its own version of the executable code 4'.

In order to ensure that the end user does not merely store the correct check number 11 to return this value at a later test time, each test can include a variable element that changes the check number 11 each time. For example, the check may be made to start a set number of bytes into the code rather than at the start of the code.

The monitoring may take place by having the regulator attend the establishment of the end user 1 , but is preferably carried out remotely with the regulator interrogating the end user's system for the check information, e.g. over the Internet or some other connection. A problem in implementing such a checking system is that using standard compiling techniques, the executable code 4' generated by the regulator 10 is not guaranteed to be identical byte-for-byte to the code 4 generated by the authoring company 2. Therefore, even if the end user 1 is using approved software, the check number that it provides may not tally with that generated using the regulator's executable code 4'.

A main cause of the differences in code 4, 4' is that the compiler 5 will generally date and time stamp the object code modules 8 and the executable code 4 for housekeeping and optimising functions using data from a clock 12 of the computer 6. For example, during a recompile of the source code 3 during the development process, only one of the modules 7 may have been modified since the previous compile. The compiler 5 determines this by comparing the date stamp of the modules 7 with those of the associated object code modules 8, and so can use the previously compiled object code modules 8 of the unchanged source code modules 7 rather than having to recompile all of the modules 7. This saves time during the compiling process, but also means that the object code 8 produced by the compiler 5 will differ from the object code 8' produced by the compiler 5' of the regulatory body. This is because the authoring company 2 and regulator 10 will compile the source code at different times, and so the date/time stamps inserted into the object code modules 8, 8' will be different. Accordingly a byte-by-byte comparison of the two executable codes 4, 4' will not produce the same result. Similarly, date/time data may be added at linkage to the executable code 4 itself by the compiler 5. The present invention overcomes this problem by forcing the clock 12 of the authoring company's computer system 6 that is used by the compiler 5 to a set value during the compile process. Thus, whenever the compile program 5 calls the clock data for stamping into the object code 8 and/or executable code 4, that data will take a consistent value. The clock data that is changed may be CMOS, BIOS and/or System clock data, as appropriate.

The clock 12 is set by a program 13 that is run simultaneously with the compiler 5. The program flowchart is shown in Fig. 2. At step S1 , the clock reset program prompts the user for the data that should replace the time and date data currently in the clock. This data 14 may take any suitable form, and may be the current date and the version of the code in a time format. Thus, for version 1.4.5 of the software compiled on 1 August 2001 , the clock data may be entered as 01 :08:2001/1 :4:05 am. In this case, only the version information (i.e. 1 :4:05) may need to be entered, as the date may be set automatically. At step S2 the user data is obtained and suitably checked for validity at step S3 (e.g. to ensure that the correct format has been used). The program 13 then sets the clock to the inputted value at step S4, waits for e.g. 330 ms at step

S5, and then continually resets the clock to the input value by cycling through steps S4 and S5 until the program 13 is terminated.

The wait time, e.g. 330 ms, may depend upon various parameters such as how often the compiler looks to the clock and upon other system features, and may vary from compiler to compiler and machine to machine. Too many resets could slow the compiling process by using valuable processor time, whilst too few could result in the clock ticking over and providing the compiler with a value different from that set by the user. The wait time may also depend on the resolution of the clock and/or of the compiler. If the clock resolution is only to one second, i.e. no counting of tenths of seconds and lower, or if the compiler only reads or records the clock data to a resolution of one second, i.e. ignores any clock data relating to tenths of seconds and lower, then the wait time can be set so that the clock is updated at least once during each second. Thus, an update of e.g. twice per second may be acceptable.

A value of about 330 ms has been found to give good results for a number of different compilers, in that consistently identical executable code is produced with little effect on compile time.

In order for the regulator 10 to compile executable code 4' identical to the code 4 of the authoring company 2, the authoring body must supply both the source code 3 and the data 14 which was used to replace the clock data (e.g. the version data including the date of the compile). The regulatory body 10 can then compile their own executable code from the source code 3 whilst running their own copy of the clock reset program 13' to set the clock 12' on their system 6' to the data value 14 provided by the authoring company 2.

Once compiled, the regulator 10 can determine a check number 11 from the code 4', and can have confidence that any check number from the end-user 1 should be the same if the end user 1 is running approved code.

Thus, the invention enables a regulator or the like to produce their own object/executable code from approved source code, and to verify that code compiled by another from the same source code is indeed from that source code and has not be tampered with or corrupted. As well as resetting the clock data, various other steps may be taken to ensure that the executable code 4, 4' produced by the authoring company 2 and the regulator 10 are the same.

The computer systems 6, 6' of the two bodies should preferably be set- up in an identical fashion, i.e. have the same processor configurations, RAM and the like. This helps to ensure for example that the various object code files are linked together in the same order by the compiler.

Before the final compile of the code for sending to the regulator 10, the authoring company 2 should preferably do a "clean" of the compiler environment to remove temporary files and the like, e.g. ".obj", ".pch", ".exe", ".res" files and the like, as well as compiler generated source code/template created files. Such files can affect the way a build executes. The regulatory should also perform such a clean before compiling the code.

All directories/folders should preferably be named in the same manner on both the authoring company's system and the regulatory body's system, e.g. throughout their full path names and using consistent lower and/or uppercase letters. This is because the compiler program may insert references into the object code of the directory of the source code module or the like.

Also, the constant clock data should be selected so that it will seem to the compiler to be later than the date/time of the last modified source file. This is to prevent the compiler from using an old previously compiled file in the compile process rather than a currently input file because it thinks that the current file has an older date than the previously compiled file (and so does not need updating). It will be clear that the above validation processes are not only applicable to software for gaming establishments, but may be used in many other situations where a regulator or the like must monitor software. It would for example be applicable to the confirmation that software on any code-running device, e.g. a laptop, PDA, mobile phone, networked computer or the like, is approved software and/or is the correct version of the software and/or is untampered software and/or is uncorrupted software.

The present invention may be used in other situations also. For example, in escrow, an authoring company or individual may provide their source code to a trusted third party, such as a solicitor or the like, for security for their clients who may need to obtain the source code should for example the authoring company go out of business and be unable to provide support services.

In such situations, the third party may need to compile the source code and check it against the software installed at the various clients in order to ensure that the source code is indeed the correct code for the client-installed executables.

This is therefore a situation in which the check is made to ensure that the trusted party has been given the correct source code (by testing it against the executable code provided to the client), rather than to approve source code functionality and to check for corresponding executable code.

The present invention is also applicable to tests for verifying other translated code, e.g. bytecode used in Java or other interpreted languages. In this case, high-level code is turned into bytecode by a suitable translator such as javac (the Java "compiler"). The terms "compile" and "executable code" should thus be given a broad understanding, and should be taken to cover for example translations into bytecode and bytecode respectively.

The compiling process for producing consistent code may be used in any other appropriate situations.

It is to be understood that various alterations, additions and/or modifications may be made to the parts previously described without departing from the ambit of the present invention, and that, in the light of the teachings of the present invention, the invention may be implemented in software, firmware and/or hardware in a variety of manners as would be understood by the skilled addressee.

Claims

Claims:

1. A method of compiling source code into object code using a compiler which inserts time and/or date data into the object code, the method including the steps of:

(a) compiling the source code; and

2. A method of compiling source code according to claim 1 wherein the compiling operation is run on a machine and the clock data used by the compiler is set to the predetermined value or range of values by setting the machine's clock to the predetermined value or range of values.

3. A method of compiling source code according to claim 2 wherein the machine's clock is frequently reset throughout the compiling operation, on each occasion to a desired value.

4. A method of compiling source code according to claim 3 wherein the desired value in each case is the same, and provides identification data.

5. A method of compiling source code according to any one of claims 1 to 4 including the further step of:

(c) comparing the object code with object code created in a previous compiling operation, to determine whether they are identical.

6. A system of compiling code including:

(a) compiling means for compiling source code into object code, the compiling means inserting time and/or date data into the object code; and (b) means for setting or forcing clock data used by the compiling means to a predetermined value or range of values during the compiling of source code.

7. Computer software including: (a) a compiler component which compiles code with clock data embedded into the executable code, and

(b) a clock reset component which sets the clock data used by the compiler component to a predetermined value or range of values during a compile action.

8. Executable code compiled in accordance with the method of any one of claims 1 to 5.

9. A method of verifying executable code including the step of comparing files of executable code from the same source code with one another, wherein the files of executable code are produced from the source code using a method according to any one of claims 1 to 5.

10. A method of building multiple copies of executable code from a single version of source code, including the steps of compiling the code at different times, wherein, during the compiling processes, identification data is included in the object code and executable code, the identification data being clock data which is identical for each compile process.

11. A method of verifying code, the method including the steps of building executable code from source code at a first site, supplying the source code to a second site, building executable code from the source code at the second site, and comparing the executable code built at the two sites, wherein the first site forces or sets to a predetermined value or range of values the date and/or time data used during the building of the executable code at the first site, and provides the predetermined value or range of values to the second site, and wherein the second site forces or sets to the predetermined value or range of values the date and/or time data used during the building of the executable code at the second site.