SYSTEM FOR PREVENTING ILLEGAL CHANGE OF PROGRAM WITH OPERATION SYSTEM AND COMPILER COOPERATED, AND METHOD THEREOF
TECHNICAL FIELD The present invention relates to a system of preventing an illegal change of a program, and a method thereof, and particularly to a system of preventing an illegal change of a program with an operating system and compiler cooperated, and a method thereof.
BACKGROUND ART In general, the method of allotting product numbers used for confirming whether a program is true or forged one is very weak in preventing illegal copies of a product. It is because, only with a product number, illegal copies of an original product can be set up using a CD recorder or hard disk. To make up for such a weakness, a method for preventing illegal setting up fundamentally by inputting a code for preventing illegal copies into a specific track of a CD and changing the concerned code when copies are conducted, a method for preventing illegal copies by locking a software and allowing copies only to those who have the corresponding locks, a method for preventing illegal copies by allowing copies only to those who received a product number after having been confirmed by a selling agent of the software, and the likes, are employed. However, all of these methods are easy to survey that with what routine an illegal copies are determined, by analyzing a programming code using analyzing tool such as reverse assembly, and normal executions are openly conducted by skipping over the concerned routine, that is, by not making execution of determining illegal copies. Such an illegal change of a program is used not only in the true product of a software, but in a program having an effective date such as a program of an estimated edition, and a continual use can be obtained even after the effective date is over by making the date check of the program of the estimated edition impossible.
Among the methods of prior arts, there is one that prevents normal execution by changing the password when an illegal change of a program is conducted, but this is only an expedient to make the finding of the encoded routine difficult but not a fundamental
solution for preventing the illegal change. Also for a program developer, this is a problem that makes the developer under the double duty of developing a program and developing a new encoded routine.
DISCLOSURE OF INVENTION
The present invention has been made to solve the problems above mentioned, and an object of the present invention is to provide a system for preventing an illegal changes of a program with an operating system and compiler cooperated, and a method thereof, that is capable of deciding whether an illegal change of the program exists by surveying the program on the operating system with a corresponding encoding module, when executing the program after having sold the program, the program with an operating system produced by a compiler which is a developing tool, having the same encoding module as that of the compiler, and encoded using encoding module provided in the compiler, when the developer compiles the program. Another object of the present invention is to provide a system and a method, capable of preventing an ill-intentioned program by making an operating system's permission necessary when the program is compiled.
A feature of the present invention for attaining the objects above mentioned is that a system for preventing an illegal change of a program is comprised of: a compiler, wherein an operating system's permission is necessary when the code made by a program developer is compiled, and an information on the compiled file is encoded so that a confirming code of illegal change is formed and stored in the compiled file; an operating system, wherein the operating system is an executing base, and confirms whether an illegal change is conducted and an operating system's permission is made, by the confirming code of an illegal change and the permission code of the operating system, before the program is executed.
A feature of the present invention for attaining the objects above mentioned is that a method for preventing an illegal change of a program is comprised of: a first stage, wherein after a program developer completed the framing of a program code through a compiler program, an encoded information is inserted to the program with the standardized
encoding module between the operating system and the compiler when the program is compiled; a second stage, wherein after the program framed at the first stage is set up on a computer, and when the program is executed, the operating system determine, if the program is illegally changed using the encoded information; and a third stage, wherein as a result of the determination, if the program is changed, the execution is stopped, and if the program is not changed, the execution is made normally.
BRIEF DESCRIPTION OF DRAWINGS Fig. 1 is a diagram showing a system for realizing the present invention. Fig. 2 is a flow chart showing an encoding step of a program on a compiler according to the present invention.
Fig. 3 is a flow chart showing a confirming step of an illegal change of a program according to the present invention.
Fig. 4 is a flow chart showing a diagnosing step of allowing permission and an ill- intentioned program according to the present invention.
BEST MODE FOR CARRYING OUT THE INVENTION The present invention will be described in more detail with reference to the preferred embodiment shown in the attached drawings. Fig. 1 is a diagram showing a system for realizing the present invention.
To realize the present invention, first, use of a standardized encoding module must be arranged between the operating system developer 100 and the compiler developer 120. If the operating system developer 100 provides the compiler developer 120 with a number of standardized encoding modules to be included in the operating system, the compiler developer 120 includes the encoding modules in the compiler and sells the encoding modules to a program developer 140, and the program developer 140 completes the framing of a program code, encodes the program code with a encoding module selected from a number of the encoding modules when compiles the program, and includes the encoded code in the program. The operating system means UNIX, OS/2, and the likes, and the compiler means visual
basic, C++, and the likes.
The compiler developed by the compiler developer 120 includes a code-creating unit
155 for encoding a file compiled with the standardized encoding module, an operating system's permitting unit 145 for obtaining the operating system's permission, and a local code-creating unit 150 for omitting an unnecessary permitting step in the development stage.
The operating system developer 100 includes a code module 105 for being permitted by the operating system to prevent the production of an ill-intentioned program, a database 115 for storing the information on the developer, and a database 110 for storing the lists of ill-intentioned programs. Also, the operating system that the operating system developer sells to a user is comprised of a code creating unit 155 having a number of modules that encode a loaded program to confirm whether the program has changed, an operating system's permission code creating unit 105 for drawing out the permission code to confirm ■ whether an operating system's permission is granted, a local code-creating unit 150 for confirming whether the program is the one drawn out from the developer computer, an ill- intentioned program list 110 for confirming whether the program is the one registered in the ill-intentioned program list, and a control unit 165 for controlling each of the code- creating units and confirming whether the created code is identical with the code stored in the loaded file and whether the created code is the registered one in the ill-intentioned program list.
The program developer 140 obtains the operating system's permission from the operating system developer through an internet network, when compiles the program, after completed the development of the program, and the user 160 receives the ill-intentioned program list 110 from the operating system developer. Next, each step will be explained in more detail.
Fig. 2 is a flow chart showing an encoding step of a program on a compiler according to the present invention.
As shown in Fig.2, after the completion of framing a program code, an execution file or DLL (Dynamic Link Library) file is compiled (S202), to create the execution file or DLL file (S203). At this time, a selection between a compilation for localizing and a
compilation for distributing is made (S200). The reason for this is that since a program development is not completed at a stroke, but should be accompanied with many tests and steps of modifying bugs, if the permitting step for an operating system (to be described below) is needed every time a program is compiled, a program developer cannot avoid a complication.
When the selection of the type of the compilation is completed (S200), a selection of an encoding module for encoding the program (S201) is made. This step is unnecessary when a single encoding module is used between the operating system and the compiler, but to prevent an illegal change of a program more intensively, it is preferable to use a number of modules.
If the compilation for localizing is selected at the above step (S200), a setup code (i.e. the sole code to distinguish the system) is drawn out using the hardware information of the program developer, and the permitting information of the operating system is initialized (S210). Next, an encoding module code is drawn out with the program information (e.g. the name of the program developer, the name the program, etc.) and the selected encoding module information (S211). This is the step unnecessary, as mentioned above, when a single encoding module is used. The reason why the encoding module code is so drawn out is that when a program is set up on the operating system, if there is no information on the encoding module used, tests must be conducted with all the modules the operating system has, thus lowering the operating performance. Also, if the information on the used encoding module is recorded in a file as it is, a problem may occur that illegal changes become easy. Accordingly, the information on the encoding module is also encoded as a kind of security measures.
The local code, the operating system's permission code, and the program information thus framed are stored in a compiled file (S212). Next, the size and the data of the compiled file are encoded with the selected encoding module. Subsequently, a file size code and a checksum code are drawn out (S213), and stored in the compiled file (S214). The file size code is to determine whether the size of the file is changed, and the checksum code is to prevent changes of data without accompanying changes of the file sizes. The encoding may have various forms, but this is not the pursuing subject of the present
invention, rather to be left in charge of an operating developer and a compiler developer to decide.
Next, the compiling step of a distributing program, i.e. not the developing stage, will be described. When a program is compiled after completed developing, a compilation for distributing is selected (S200), and also an encoding module to be used is selected (S201). After the compilation of the program code (S202, S203) is made, an operating system's permission is requested through an internet network. With above request, a compiled execution file or DLL file and the program information (e.g. the name of the developer, the name of the program, etc.) are provided to the operating system (S205). Accordingly, the operating system developer encodes the compiled execution file or DLL file with an exclusive encoding module of the operating system, draws out a permission code (S206), and provides the program developer with the permission code (S207). Also, the operating developer stores the received information and the permitted date in the database and manages thereof (S208). The reason for this is that since an ill-intentioned person will not try to obtain the operating system's permission in spite of exposing his identification, a framing of such a program can intercepted beforehand, and a list for cutting off execution of an ill-intentioned program expecting in the future can be prepared. The ill-intentioned program means the one that brings about undesirable results to a user such as a virus program. On receiving the operating system's permission code from the operating system developer, the compiler initializes the local code (S209), and frames an encoded program via the steps S211— S214.
Fig. 3 is a flow chart showing a confirming step of an illegal change of a program according to the present invention, and Fig. 4 is a flow chart showing a diagnosing step of allowing permission and an ill-intentioned program according to the present invention.
A user may set up the program developed through the steps of Fig. 2 in his own computer. When an executing command of the concerned program is issued (S300), the program loader of the operating system calls out the execution file or the DLL file (301), and draws out the loaded file size and the checksum (S302). Also, the program loader of the operating system reads out the program information in the file and the encoding
module (S303). Then, an encoding module code is drawn out with the read-out program and the encoding module information (S304). Next, a determination is made whether the drawn-out encoding module code and the read-out encoding module code are identical (S305). If the result shows as not identical, confirmation is made whether tests of all the encoding modules on the operating system have been performed (S306). If affirmative, the execution is stopped, whereas if negative, the steps S304-— -S305 are repeated with other encoding modules. If the result in the step 305 shows as identical, the concerned module is selected (S307) as the encoding was made with that module. With this module, the drawn- out file size information and the checksum information are encoded, and drawn out as a file size code and a checksum code (S308). When the drawn-out is completed, the file size code and the checksum code stored in the concerned file are read out (S309). Then, a determination is made whether the drawn-out file size code and the read-out file size code are identical (S310). If the result shows as not identical, the execution is stopped, whereas if identical, a determination is made again whether the drawn-out checksum and the read- out checksum are identical (S311). If the result shows as not identical, the execution is stopped, whereas if identical, the execution proceeds to the next step (A). Through these steps, a determination can be made whether a change of the file was conducted.
When having passed the above steps, the execution proceeds to the steps for determining whether the program is permitted by the operating system and is listed in the ill-intentioned program list.
Next, the local code is read out from the loaded file (S400). A determination is made whether the read-out local code is vacant, and if vacant, as it means the program has been permitted by the operating system, the information on the loaded file is encoded with the permitted encoding module of operating system (the same one used for drawing out permitted code in the steps of Fig. 2) included in the operating system, and the permitted code stored in the loaded file is read out (S402). Then, the drawn-out permission code and the read-out code of the operating system are compared (S403), and if not identical, the execution is stopped, whereas if identical, the execution proceeds to the next steps.
If the read-out local code is not vacant in the step S401, as it means the program is still being developed, a determination is made whether the program has been set up in the
developer's computer, and is being intended distributing without the operating system's permission. First, the setup code of the set computer is drawn out, and then the local code is drawn out from the drawn-out setup code (S404). A determination is made whether the drawn-out local code and the read-out local code are identical (S405), and if not identical, as it means the program is the one flown out of the developer's program, the program is stopped. If the result in the step S405 shows as identical, as it means the program is still being developed, the execution proceeds to the next steps.
From now on, the steps are for the purpose of diagnosing the ill-intentioned programs that have passed all the steps above mentioned without a hitch, and preventing the execution thereof.
A determination is made whether the program information that was read out from the loaded file exists in ill-intentioned program list that was downloaded from the operating system developer (S406). This ill-intentioned program list is provided to the user of the operating system, whenever the operating system developer newly updates the program information on an ill-intentioned program that acquired. The result in the step S406 shows as not exists, the normal execution is made (S407), whereas if exists, the execution is stopped to prevent the execution of the ill-intentioned program.
However, here is a problem that if the controlling module of the operating system that tests and controls all the steps becomes an object of illegal changes, the steps above mentioned may become meaningless. Accordingly, to prevent such a risk, a double security measure, that makes other modules on the operating system determine whether the controlling module is changed in like manner as the steps of Fig. 3, must be considered. As a more secure measure, a method of testing whether the controlling module is changed at the initial stage of booting of ROM BIOS can be used. Preferably, to the ROM BIOS, a routine that tests the controlling module of the operating system is inserted so as not to limited to an only operating system.
Also, in a method for preventing an illegal change of a program according to the present invention, as described above, an agreement must be arrived at to use the standardized and same code and routine between the operating system developer and the compiler developer, and the former programs must be passed through changing procedures
so as to be executed in the new operating system. To realize the present invention, a series of transient stages must be accompanied, i.e. the former program and the new program created with an encoding module are executed simultaneously. However, as an insertion of an additional change preventing code or true or forged product confirming code is an optional matter of the program developer, the description thereof will be omitted here.
INDUSTRIAL APPLICABILITY As described above, according to the present invention, a software developer needs not to concentrate on trying to add an encoding code for preventing illegal changes, because an operating system prevents the illegal changes fundamentally, as the operating system determines whether an illegal change conducted. Also, the spread of a virus program can be prevented, as the program infected with a virus program cannot be executed. In addition, since only the program that obtained permission after passing through the prior registering steps for an operating system can be executed, there is an advantage of preventing development t of a virus program. Also, there is an advantage of preventing the spread of a virus program, since, even for the virus programs created evading the security measures, a list of illegal programs is drawn up and distributed by the operating system.
While the preferred embodiments of the present invention have been described herein referring to the drawings, it should be understood that other modifications, substitutions and alternatives are apparent to one of ordinary skill in the art. Such modifications, substitutions and alternatives can be made without departing from the spirit and scope of the present invention. Accordingly, the above described does not limit the scope of the present invention, which should be determined from the appended claims.