RU2385485C1 - System and method of control over programs execution with help of binary applications tracing - Google Patents

Abstract

FIELD: information technologies.

SUBSTANCE: according to the present invention, on developer side in compiled software module they replace text lines of tracing by according identifiers. Software module is sent to user side. After tracing file has been formed on user side, this file is sent to developer side, where text lines are restored by identifiers contained in this file. As a result, a text file is produced, which may be easily analysed by developer.

EFFECT: simplified work with tracing file, makes possible to hide information that discloses logics behind software module operation.

10 cl, 6 dwg

Description

Technical field

The invention relates to methods and devices for generating and transmitting trace files.

State of the art

Currently, computers that are used in various areas of life are actively developed and used. However, various computer malfunctions can occur during computer operation. Therefore, there is a need to determine the causes of the failure.

Currently, there are many ways to determine the cause of a failure. One such way is to generate trace files.

Tracing - logging the work of the program in order to analyze its activity in case of any problems during the work of the program. As a rule, the trace file is made in text form. The text of the program indicates a call to a function that saves the lines of text specified by it. When the program compiles, these lines get to the program module file. Then these lines and the program module get to the client. In case of any problems, the client turns on the trace mode (tracing is carried out at the request of the client). The program creates a trace file and writes lines there as actions are performed. Strings can contain various parameters, for example, the names of files that open, error codes that occurred when opening.

The client then passes the resulting trace file to the developer. The developer analyzes the received file and determines the cause of the error or failure.

However, in this case, a problem arises - the client can see lines that tell about what happens while the program is running. This leads to the fact that know-how and other information that is not desirable for general disclosure may be disclosed.

The following methods are available to resolve this issue. The first way is to minimize tracing. The second method is camouflage, i.e. instead of an explicit description of the action, a specific word or abbreviation is written. But in this case a problem arises - subsequently it becomes difficult to decipher the written text.

Figure 1 shows a block diagram of the formation and transmission of the trace file. This drawing shows two sides — the developer side (101) and the user side of the application (103). The developer, on his side, develops the product (105) and as a result collects the executable module (107), which contains the data (109) necessary to trace the operation of this module. Then, the developer releases the product or transfers its modules (111) to the user in another way. On the user side, trace data is readable (113). At runtime (115), the module creates a trace of its work (117). The user sends the trace to the developer (119), where the received data (121) is analyzed (123).

Such a method of generating and transmitting a trace file is described in US Pat. No. 6,988,263, published Jan. 17, 2006, and US Pat. No. 6754890, published on June 22, 2004.

However, this method also has disadvantages. On the user side, the data for tracing inside the module (113) is visible in a readable form, which already represents the attack vector in relation to the developer - the user can assume the internal logic of the module based on this data. Trace data (117) contain not only information about the actions performed during the module's operation, but also about the sequence of their execution, and about the objects that were performed during the operation. Analysis of this file gives a second attack vector and provides the user with maximum information about the internal logic of the module.

Thus, there is a need to create a method and apparatus for generating and transmitting a trace file that can be easily restored and in which certain data could not be read by the client or any other third party.

SUMMARY OF THE INVENTION

The present invention is intended to generate and transmit a trace file.

A method for generating and transmitting a trace file contains the steps in which: on the developer's side, a program is compiled with the formation of an executable program module that contains the data necessary to trace the operation of this module; in the generated program module, replace the existing text trace lines with the corresponding identifiers; the user is referred to the compiled program with the generated software module, in which the trace lines are replaced with the corresponding identifiers; during program execution, information is stored on the module’s progress, thereby forming a trace file; transmit the trace file to the developer side, where they replace the identifiers of the lines in the said trace file with the corresponding text lines that were previously replaced on the developer's side after compiling the program, and then analyze the received replaced text lines and the information stored in the mentioned trace file on user side.

In a private embodiment, text strings and their corresponding identifiers are stored in a database.

In another particular embodiment, at the stage of replacing trace text strings with corresponding identifiers, formatting data is additionally replaced with a string of parameter types.

In another particular embodiment, when replacing the line identifiers in the said final trace file with the corresponding text lines, they additionally format their trace data.

In another particular embodiment, said database contains a database of program modules and a database of strings, while the database of program modules contains at least the identifier of the program module and associated ones — the name of the module file, the compilation date of the module, the number of trace lines, the name and version of the product, which included the module and the version of the module, and the database of strings contains the identifier of the program module, in which there was a string, a string identifier unique to the module, and the text of the string.

A system for generating and transmitting a trace file containing means installed on the developer's side for compiling a program and generating an executable program module that contains data necessary for tracing the operation of this module; a database for storing trace text strings and their corresponding identifiers; means for replacing the existing text trace lines in the generated software module with the corresponding identifiers stored in said database; means for transmitting to the user the aforementioned compiled program with the generated program module, in which the trace lines are replaced with the corresponding identifiers; means for generating a trace file, which is designed to save information about the progress of the program in a trace file during program execution; means for transmitting the generated trace file to the developer side; means for replacing line identifiers in said trace file with corresponding text lines stored in the database and which were previously replaced on the developer's side after compiling the program; means for outputting to the developer the received replaced text lines and said information stored in said trace file on the user side, for the developer to analyze these text lines and said information.

In a particular embodiment, said replacement means are made in the form of a single means.

In another particular embodiment, said means of replacing existing trace text strings with corresponding identifiers additionally replaces formatting data with a string of parameter types.

In another particular embodiment, said means for replacing identifiers with corresponding text strings further format the trace data.

In another particular embodiment, the said database contains a database of program modules and a database of strings, while the database of program modules contains at least the identifier of the program module and associated ones — the name of the program module file, the compilation date of the program module, the number of trace lines, name and version the product, which included the software module, and the version of the software module, and the database of strings contains a software module in which there was a string, a string identifier unique to the module, and the text of the string.

Brief Description of the Drawings

Additional objectives, features and advantages of the present invention will be apparent from reading the following description of an embodiment of the invention with reference to the accompanying drawings, in which:

figure 1 shows a block diagram of an algorithm for generating, transmitting and analyzing a trace file known in the art;

figure 2 shows a block diagram of an algorithm for generating, transmitting and analyzing a trace file in accordance with the present invention;

figure 3 shows a block diagram of the conversion of the software module for binary tracing;

figure 4 shows a block diagram of an algorithm for restoring trace data in a readable form;

5 shows a database structure;

6 shows a structural block diagram of a system for generating and transmitting a trace module in accordance with the present invention.

Detailed disclosure of preferred embodiments

The objects and features of the present invention and methods for achieving these objects and features will become apparent by reference to exemplary embodiments. However, the present invention is not limited to the exemplary embodiments disclosed below, it can be embodied in various forms. The essence defined in the description is nothing more than the specific details provided to assist the specialist in the field of technology in a comprehensive understanding of the invention, and the present invention is defined only in the scope of the attached claims.

For clarity of the invention, the following should be noted. There are two sides. The first side is the developer, and the second side is the user.

Well-known computers are used on both sides. In general, these computers comprise a processor (CPU) and memory connected via a bus, as well as a display for displaying various information. The memory may be different, such as ROM, RAM, EPROM, EEPROM, etc. Computers also contain a mouse and keyboard for entering and managing information. These computers may contain other known devices, such as a modem, joystick, etc.

Computers use various operating systems, for example, the WINDOWS operating system, which has various versions, such as WINDOWS 98, WINDOWS 2000, WINDOWS XP, etc .; Linux operating system, DOS, Novell, Unix, MacOS, IBM OS / 390 operating systems, etc.

Computers on the user side and computers on the developer side can connect to each other through well-known networks such as local area networks (LANs), regional networks, WLANs, the Internet, etc. Information transfer, including a compiled program and a trace file module generated on the developer's side, can be carried out on various networks using modems. In a similar way, information is transmitted, including the final trace file module generated on the user side, can also be transmitted over the network using modems and local area networks (LANs).

However, it should be noted here that the trace file module generated on the developer's side and the compiled program can be transferred to the user in another way. For example, by selling on other storage media: CD, DVD, etc.

Figure 2 shows a block diagram of the formation and transmission of a trace file module in accordance with the present invention. There are two sides - the developer side (201) and the application user side (203). The developer, on his side, develops the software product (205) and as a result collects the executable software module (207), which contains the data (209) needed to trace the operation of this software module.

Next, the module is processed in a special way (211) when trace lines from the module are placed in the database (219). Strings are replaced by string identifiers, and formatting data is replaced by a string of parameter types (213). This replacement process will be described in detail below with reference to FIG.

Then, the developer releases the product or transfers its modules to the user in another way (215). As noted above, such a transfer can be carried out, for example, by selling to the user this module or by transmitting this module over the network.

On the user side, trace data is not readable (217). At runtime (221), the software module creates a trace of its work (227). The user sends the trace to the developer (225), where the received data (223) is decoded (229). At this stage, using the line identifiers from the database (219), the original lines are obtained, their trace data (223) are formatted and displayed in a readable form (231). This replacement process will be described in detail below with reference to FIG.

The readable data obtained is analyzed (233) by the developer.

As you can see, in this scheme on the user side there are no readable ones in the software module (217). The data obtained during trace (227) does not contain a description of actions, only the objects on which actions were performed. It is also worth noting that in the data (227) the numbers are stored in binary form. Thus, the only data that remains readable is string parameters, such as file names, which usually make up a small part of the trace. Based on this data, the user cannot assume the internal logic of the module.

It should also be noted that this method of generating a trace file allows the developer to decide whether he needs to convert the software module, and thus hide the trace data, or not convert the software module and have the trace file readable. The latter can be used for internal product testing.

Next, with reference to FIG. 3, the replacement of the text lines of the program module with the corresponding identifiers for binary tracing will be described.

After the processing of the program module (301) has begun, the module file (303) opens, in which all trace lines (305) are located. The module file is registered (307) in the database (309) and receives the module identifier (311). Next, for each row, a set of operations (313) is performed. The row is placed (315) in the database (317) and receives the row identifier (319). A pair of module identifiers and a string allow you to uniquely identify a string. The parameter formatting is highlighted in the line and a line of parameter types is formed (321). Next, a binary sequence (323) is formed, which replaces (325) the original string in the module. This procedure is repeated for each row (327). After replacing all the lines, the file is closed (329) and at the output (331) a software module with binary tracing is obtained.

Now with reference to figure 4 will be described in detail the process of restoring trace data in a readable form.

The binary trace data received from the user is opened for reading (403) and the output for text data is prepared (405). Next begins the cycle (407). A data block (409) is read from the trace file and divided into module identifier, line identifier, and parameters (411). The identifiers determine (413) from the database of strings (415) the original string (417) is taken out, for which formatting is performed using parameters (419) and the resulting text string (421) is output. Loop (423) is repeated until all binary trace data has been processed. At the end of the input, the files are closed (425).

Figure 5 presents the structure of the database. As you can see from this drawing, the database consists of two databases - the database of software modules (TraceFiles) and the database of strings (TraceStrings).

The base of program modules contains the identifier of the module and associated with it - the name of the module file, the compilation date of the module, the number of trace lines, the name and version of the product that included the file, and the version of the module.

The string database contains the identifier of the module in which the string was, a string identifier unique to the module, and a string test.

We also note that the base of software modules is used abstractly and is practically not involved in the process of restoring binary tracing. Implementation is possible when the base of software modules is not maintained. In this case, the row identifier uniquely identifies the row between all rows for all modules.

The method for generating and transmitting a trace file described above is implemented using a system for generating and transmitting a trace file.

This system, as can be seen from the drawing (Fig.6), contains interconnected means (610) for compiling a program and forming an executable program module; a database (620) for storing trace text strings and their corresponding identifiers; means (630) for replacing existing trace text strings in the compiled program module with corresponding identifiers stored in said database; transmission means (640) to the user of said compiled program with a software module in which trace lines are replaced with corresponding identifiers; means (650) for generating a trace file, which is designed to save information about the program progress to a trace file during program execution; means (660) for transmitting the generated trace file to the developer side; means (670) for replacing line identifiers in said trace file with corresponding text lines stored in the database and which were previously replaced on the developer's side during program compilation; means (680) for outputting to the developer the received replaced text strings and said information stored in said final module on the user side, for the developer to analyze these text strings and said information.

It should be noted here that the means 610, 620, 630, 640, 670, 680 are installed on the side of the developer. All other means are installed on the user side.

As noted above with reference to figure 2-4, the developer using the means 610 compiles the program and program module containing text strings. After which the tool 630 replaces the text strings with the corresponding identifiers. For this, the tool 630 accesses the database 620, from which the tool obtains the corresponding identifiers of the replaced lines of the trace file module. This process has been described in detail above with reference to FIG. 3.

After the means 630 has replaced the text strings with the corresponding identifiers, it transmits the generated program module to the transmission means 640. This tool transfers the module to the user side.

On the user side, the trace file generation tool 650 stores information on the progress of the program into a trace file during program execution. After the trace file has been generated, the transmission means 660 transfers the generated trace file to the developer.

The resulting file is supplied to the means 670 replacing the line identifiers in said trace file with the corresponding text lines. To do this, this tool accesses the database 620, from which it receives text strings stored in the database and which correspond to those identifiers contained in the trace file. Thus, identifiers are replaced with strings that were previously replaced on the developer's side during program compilation. This process has been described in detail above with reference to FIG. 4.

After that, the received text information is transmitted from the means 670 to the means 680 output. This tool outputs the received text information (i.e., received replaced text strings and said information stored in said trace file on the user side) to a screen, a file, or to paper. Then the developer can analyze these text strings and the information mentioned.

It should also be noted that the replacement means 630 and 670 can be made in the form of a single tool.

In conclusion, it should be noted that the information provided in the description are only examples that do not limit the scope of the present invention defined by the claims. One skilled in the art will recognize that there may be other embodiments of the present invention consistent with the spirit and scope of the present invention.

Claims (10)

1. A method for generating and transmitting a trace file, comprising the steps of:
on the developer's side, the program is compiled with the formation of an executable program module that contains the data necessary to trace the operation of this module;
in the generated program module, the existing text trace lines are replaced with the corresponding identifiers, the user is given the mentioned compiled program with the program module in which the trace lines are replaced with the corresponding identifiers,
during program execution, said program module saves information about the module’s progress, thereby forming a trace file,
transmit the trace file to the developer side, where they replace the identifiers of the lines in the said trace file with the corresponding text lines that were previously replaced on the developer's side after compiling the program, and then analyze the received replaced text lines and the information stored in the mentioned trace file on user side. 2. The method according to claim 1, in which text strings and their corresponding identifiers are stored in a database. 3. The method according to claim 2, in which at the stage of replacing the trace text strings with the corresponding identifiers, the formatting data is additionally replaced with a string of parameter types. 4. The method according to claim 3, in which when replacing the line identifiers in the said trace file with the corresponding text lines, formatting data of their trace is additionally carried out. 5. The method according to claim 4, in which said database contains a database of program modules and a database of strings, while the database of program modules contains at least a module identifier and associated module file name, module compilation date, number of trace lines, name and the version of the product, which included the module, and the version of the module, and the database of strings contains the identifier of the program module, in which there was a string, a string identifier unique to the module, and the text of the string. 6. A system for generating and transmitting a trace file containing a tool installed on the developer's side for compiling a program and generating an executable program module that contains data necessary for tracing the operation of this module;
a database for storing trace text strings and their corresponding identifiers;
means for replacing the existing text trace lines in the compiled program module with the corresponding identifiers stored in said database;
means for transmitting to the user the aforementioned compiled program with a software module in which the trace lines are replaced with the corresponding identifiers; means for generating a trace file which is intended to store information about the progress of the program module into the trace file during program execution;
means for transmitting the generated trace file to the developer side,
means for replacing line identifiers in said trace file with corresponding text lines stored in the database and which were previously replaced on the developer's side after compiling the program,
means for outputting to the developer the received replaced text strings and said information stored in said trace file on the user side, for the developer to analyze these text strings and said information. 7. The system according to claim 6, in which the said means of replacement are made in the form of a single tool. 8. The system according to claim 7, in which said means of replacing existing text trace lines with corresponding identifiers additionally replaces the formatting data with a string of parameter types. 9. The system of claim 8, in which the said means of replacing identifiers with the corresponding text strings further formats the data of their trace. 10. The system of claim 8, in which said database contains a database of program modules and a database of strings, while the database of program modules contains at least an identifier of a program module and associated module file name, module compilation date, number of trace lines, name and the version of the product, which included the module, and the version of the module, and the database of strings contains the identifier of the program module in which there was a string, a string identifier unique to the module, and the text of the string.

Images