KR20200082422A - Lightweight crash report based debugging method considering security - Google Patents

Abstract

The present invention has a debugging method based on a lightweight crash report in consideration of security. The debugging method comprises: an execution step of executing a program in an electronic device; a generation step of automatically generating a crash report while collecting information on a crash and essential information required for error tracking if the crash occurs while the program is executed; an analysis step of receiving the generated crash report and analyzing information contained in the crash report to extract error information; and a tracing step of specifying a location of an error by tracking the extracted error information.

Description

Lightweight crash report based debugging method considering security}

The present invention relates to a lightweight crash report-based debugging method in consideration of security, and more specifically, due to a high-quality crash report that includes only essential information required for error tracking, it is possible to improve the report size, readability, and security. It is related to a lightweight crash report-based debugging method considering security that can trace errors down to the line unit of the source code using the generated crash report.

In recent years, the functions of software provided to users have become increasingly complex. Accordingly, in the past decades, the size of software and development costs have increased. In this situation, debugging is the most costly part of the software life cycle, accounting for about 50% of the total development cost.

In addition, since the cost of debugging increases proportionally as the life cycle of the software progresses, the most costly part is debugging performed after the software is distributed, that is, in the maintenance and maintenance phase.

The conventional debugging process is as follows.

First, the software distributed in the execution environment is executed, and a crash report is generated when an error occurs. Then, the crash report delivered to the development team is analyzed, and the location of the error is tracked to correct the error. Subsequently, the software is redistributed when all the tests have passed.

That is, in the conventional debugging process, many studies are being conducted in each stage, and there are the following limitations in the three stages of conventional crash report generation and analysis and error tracking.

First, in the conventional crash report generation step, when an error occurs, a dump file including contents such as system information, memory dump, and crash dump is generated from the operating system. The dump file generated without processing is attached to the crash report, which has the advantage that the developer can check various information about the user's execution environment, but the raw information contains meaningless data in the error tracking step. do.

In addition, there is a possibility that the information and personal information of other modules used by the user among the attached data may be included, and thus there is a vulnerability in terms of security.

Second, in the conventional crash report analysis step, the data attached to the crash report delivered to the developer is processed to make it easier for the developer to understand the contents of the dump file or to facilitate error tracking. However, as described above, it takes a lot of time to process information due to dump data collected along with data unnecessary for error tracking.

In addition, the amount of processed error information (or crash information) needs to be analyzed, which requires a lot of time and effort from the developer.

Third, in the conventional error tracking step, existing technologies use the analyzed error information and source code to track errors in a file or function unit. However, due to the large tracking unit, it takes additional developer time and effort to find the exact location of the error. In the case of WinDbg, an error tracking tool, line-level error tracking is performed by using dump files, source code, and program database information used in debugging mode in an integrated development environment.

This can greatly reduce the developer's effort, but causes problems due to unnecessary information analysis and processing by using the entire dump file as input, and traces line-level errors when the location of the program database file cannot be specified. This is impossible, and there is a limitation that requires additional developer time and effort.

In the present invention, due to a high-quality crash report containing only essential information required for error tracking, the size of the report can be reduced in weight, readability and security, and the generated crash report can be used to track errors down to the line unit of the source code. We would like to propose a lightweight crash report-based debugging method considering security.

The present invention is an execution step of executing a program in an electronic device, and when a crash occurs while the program is running, a generation step of automatically generating a crash report while collecting information on the crash and essential information required for error tracking is generated. A lightweight crash report-based debugging method considering security, including an analysis step of receiving a crash report and analyzing the information contained in the crash report to extract error information, and a tracking step of tracking the extracted error information to specify the location of the error To be equipped.

The present invention can improve the size, readability, and security of a report due to a high-quality crash report containing only essential information required for error tracking.

In addition, since the present invention can track errors down to the line unit of the source code using the generated lightweight crash report, errors can be corrected quickly and accurately.

In addition, the present invention can reduce debugging costs by generating a lightweight crash report capable of personal information security and automating the analysis and error tracking steps.

1 is for explaining a lightweight crash report-based debugging system considering security according to an embodiment of the present invention.
2 is for explaining a lightweight crash report based debugging method considering security according to an embodiment of the present invention.
3 is a detailed description of a lightweight crash report based debugging method considering security according to an embodiment of the present invention.
4 is for explaining a crash point according to a relative virtual address for each environment according to an embodiment of the present invention.
5 is for describing relative virtual address and source code line mapping information according to an embodiment of the present invention.
6 is a comparison of error tracking analysis time and collected data items using a lightweight crash report-based debugging method considering security according to an embodiment of the present invention.

The technique described below may be applied to various changes and may have various embodiments, and specific embodiments will be illustrated in the drawings and described in detail. However, this is not intended to limit the technology described below to specific embodiments, and should be understood to include all modifications, equivalents, and substitutes included in the spirit and scope of the technology described below.

Terms such as first, second, A, B, etc. can be used to describe various components, but the components are not limited by the above terms, and only for distinguishing one component from other components Used only. For example, the first component may be referred to as a second component, and similarly, the second component may be referred to as a first component without departing from the scope of the technology described below. The term and/or includes a combination of a plurality of related described items or any one of a plurality of related described items.

In the terminology used herein, a singular expression should be understood to include a plural expression unless it is clearly interpreted differently in context, and "includes." Terms such as the meaning, number, steps, operations, components, parts, or combinations thereof are meant to exist, and one or more other features or numbers, steps, operation components, parts, or combinations thereof It should be understood that it does not exclude the possibility of the presence or addition of.

Prior to the detailed description of the drawings, it is intended to clarify that the division of components in this specification is only divided by the main functions of each component. That is, two or more components to be described below may be combined into one component or one component may be divided into two or more for each subdivided function. In addition, each of the constituent parts to be described below may additionally perform some or all of the functions of other constituent parts in addition to the main functions of the constituent parts, and some of the main functions of the constituent parts are different. Needless to say, it may also be carried out in a dedicated manner.

In addition, in performing the method or the method of operation, each process constituting the method may occur differently from the specified order unless a specific order is explicitly stated in the context. That is, each process may occur in the same order as specified, may be performed substantially simultaneously, or may be performed in the reverse order.

1 is for explaining a lightweight crash report-based debugging system considering security according to an embodiment of the present invention.

Referring to FIG. 1, a lightweight crash report-based debugging system 1000 considering security according to an embodiment of the present invention may include an electronic device 100 and a security server 300.

The electronic device 100 may be a device capable of executing a plurality of programs or a plurality of software. For example, the electronic device 100 may include a portable terminal, a smart phone, a tablet PC, a computer, a laptop computer, and the like. The present invention is not limited thereto, and may include all devices capable of executing a plurality of programs or a plurality of software.

The electronic device 100 may include a control unit 110 and a communication unit 130.

When a crash occurs while executing a program or software, the controller 110 may automatically generate a crash report while collecting information about the crash and essential information required for error tracking. Crash can be defined as an error, such as a forced termination caused by a defect in the code while using the software. Such a crash can cause a big problem in terms of usability. Crashes can be caused mainly by errors such as Unhandled Exceptions. The controller 110 may be referred to as a main board or a central processing unit (CPU). Errors can be called bugs or errors.

The essential information may be process, exception, and memory information useful for error tracking without invading personal information in the execution environment of the electronic device 100. The crash report may be a report that increases security by collecting and processing processes, exceptions, and memory information useful for error tracking without invading personal information in the execution environment of the electronic device 100. That is, the crash report may be a high-quality, lightweight crash report with improved security using essential information.

The communication unit 130 may be electrically connected to the control unit 110 to receive a crash report generated automatically from the control unit 110 and transmit it to the security server 300.

The security server 300 analyzes the electronic device 100 and the secure communication unit 330 capable of transmitting or receiving data, and a crash report to extract error information or error codes, and treat the extracted errors to upgrade the program or It may include a security control unit 310 that can be controlled to patch. That is, the security server 300 may execute or perform a debugging task that tracks and corrects a crash.

The secure communication unit 330 may receive a crash report from the electronic device 100 or transmit an upgraded or patched program to the electronic device 100.

The security control unit 310 may receive a crash report and analyze the information contained in the crash report to extract error information. Error information may be referred to as an error code or error data.

The security control unit 310 may track the extracted error information to specify the location of the error. The security control unit 310 can detect or check the error more accurately because the crash report received in the execution environment can be connected to the source code to accurately track the error.

When the location of the error is specified or fixed, the security control unit 310 may treat or remove information or data on the location of the specified error.

The security control unit 310 may generate or repair the error by removing or treating the error at the specified error location. Information can be referred to as code or data.

The security control unit 310 may treat an error-generated code and regenerate a program based on the error-removed code. The security control unit 310 may transmit the regenerated program to the electronic device. That is, the security control unit 310 may redistribute the regenerated program.

The electronic device 100 may receive the regenerated program from the security control unit 310 and upgrade or patch an existing program.

2 is for explaining a lightweight crash report based debugging method considering security according to an embodiment of the present invention.

Referring to FIG. 2, a lightweight crash report-based debugging method considering security according to an embodiment of the present invention may include an execution step, a generation step, an analysis step, and a tracking step. The execution phase and the generation phase may be executed in the execution environment of the electronic device, and the analysis phase and the tracking phase may be executed in the development environment of the security server.

The electronic device may display an executable program or predetermined software (S10).

The electronic device may execute a predetermined program or predetermined software selected under the control of the controller (S20). For example, a predetermined program or predetermined software may include an application program, application software, an application, an application, an app, and the like.

The electronic device may check or detect a crash in real time while the program or software is running under the control of the controller (S30).

If a crash occurs or is detected while the program or software is running under the control of the control unit, the electronic device may automatically generate a crash report while collecting information about the crash and essential information required for error tracking (S40). For example, the essential information may be process, exception, and memory information useful for error tracking without invading personal information in the execution environment of the electronic device. The crash report can be made lighter by collecting and processing process, exception, and memory information useful for error tracking in the execution environment of the electronic device. In addition, the crash report can improve security by excluding personal information from the execution environment of the electronic device.

The electronic device may provide a crash report generated under the control of the control unit to the communication unit. The communication unit may transmit the generated crash report to the security server (S50).

When the crash report is transmitted from the electronic device, the security server may analyze information contained in the crash report. The security server may receive the crash report through the secure communication unit and analyze the crash report under the control of the security control unit (S60).

The security server may extract error information of the program or software based on the information contained in the crash report analyzed under the control of the control unit (S70).

The security server can track the error information extracted under the control of the security control unit to specify the location of the error. The security server can more accurately specify the location of the error by linking the crash report with the source code under the control of the security control unit to track the error information in a precise unit.

If the location of the error is specified under the control of the security control unit, the security server may fix the location of the error (S80).

The security control unit can accurately recognize which part of the program or where the error has occurred by tracking the location of the error-generated code or the error-generated information and fixing it. Thereafter, the security server may treat information or data on the location of the fixed error under the control of the security control unit.

The security control unit may generate information on which the error has been corrected by removing or treating the error at the location of the fixed error. Information can be referred to as code or data.

The security control unit can repair the error-generated code and regenerate the program based on the error-removed code. The security control unit may test the regenerated program (S90).

If the error continues to occur after testing the regenerated program, the security control unit may move to a step of extracting error information of the program or software based on the information contained in the analyzed crash report (S70).

The security control unit extracts the error information of the program or software based on the information contained in the crash report analyzed until the error is cleared, tracks the error information, locates the error, and then fixes the specified error location You can cure the error or eliminate it.

When the error is treated after testing the regenerated program (S100), the security control unit may determine that it is a program or software that can be executed and transmit it to the electronic device (S110). For example, the security control unit may transmit a higher version of the program to the electronic device than the existing program. Accordingly, the electronic device may receive the regenerated program from the security control unit, and upgrade or patch an existing program to execute a high version program in which errors are removed.

3 is a detailed description of a lightweight crash report based debugging method considering security according to an embodiment of the present invention.

Referring to FIG. 3, the electronic device may execute software (Executable file) distributed in an execution environment (S110). The software executed in the execution environment may include business logic (131) and error tracking library (132). The business logic 131 may be referred to as implemented source code.

If a crash occurs while executing the software distributed in the execution environment, a step of automatically generating a crash report may be performed (S130). In the step of generating the crash report automatically (S130), a dump file is generated (133) in the software to be executed, essential information for error tracking is collected (134), and a crash report is created (135).

The crash report processes the distributed information, the minimum information required for line-level error tracking, the executable unique number, the relative error address information, and the stack information into the dump file or dump data, so that the personal information is not included. The size can be significantly reduced. Accordingly, the electronic device may generate a lightweight crash report and transmit or transmit the generated lightweight crash report to the security server.

Table 1 compares the collected information of the existing crash report with the proposed crash report.

[Table 1]

As described in Table 1, the crash report proposed in the present invention can collect four types of information from a dump file. For example, it may be system information, module information, thread information, and exception information, respectively.

In the system information, it is possible to collect 1) the operating system type, 2) the version of the operating system, 3) the level of the processor, and 4) the architecture information of the processor so that the developer can understand the environment information of the basic execution environment in order to reproduce the error.

In module information, a crash, that is, information on a module in which an exception has occurred can be collected. For example, module information can mean 1) the name of the module, such as an executable or dynamic library, 2) the physical address and size information of the module loaded into physical memory, and a unique number of the module. It can be a 3) timestamp used to find a matching module. The time stamp can be referred to as the version of the program.

In the thread information, it is possible to collect information that helps to reproduce the error, including the execution history up to the point where the exception occurred. For example, the thread information may be 1) a thread ID in which an exception occurs, and 2) call trace information of a backtrace method.

Exception information may collect information that can specifically tell what kind of exception occurred in development. For example, the exception information may collect 1) the thread ID of the error, 2) the physical memory address where the error occurred, and 3) Null pointer dereference, Divide by zero.

Also, essential information required for error tracking may be a relative virtual address and a time stamp. Relative virtual addresses and time stamps can be used to track line-by-line errors. Detailed description thereof will be described later.

The security server may perform a step of analyzing a crash report performed in the development environment (S150).

The steps to analyze the crash report analyze the contents of the crash report delivered or transmitted, specify the path of the project that matches the distributed software based on the analysis results, and specify and analyze the program generated when compiling the project as a database file You can do That is, in the step of analyzing the crash report, error information may be extracted by analyzing the information contained in the crash report received from the development environment and the executable file or dynamic library file located in the project path of the distributed software.

The step of analyzing the crash report (S150) may be divided into a first analysis step and a second analysis step. The first analysis step may be a step of searching and analyzing the same module based on the time stamp (331,332,334). The second analysis step may be a step of analyzing information by mapping a RVA (Relative Virtual Address)-line based on the database of the program (331,333,335). RVA (Relative Virtual Address) may be an address of a memory item in an image file of a program. The RVA of an item can be mostly different from the location in the file (file pointer) on disk.

The first analysis step may use the time stamp to search for the same module to use the address difference information obtained from the crash report (331,332,334).

In the first analysis step, the module name and time stamp included in the crash report can be extracted. The first analysis step may analyze headers of files having the same extension as the error module while exploring or searching project paths of previously distributed software using information of the module name and time stamp. In the first analysis step, a path of an executable file or a dynamic library file having the same time stamp may be obtained through headers of files having the same extension as the analyzed error module (331,332,334).

The second analysis step may analyze the database of the program in order to utilize the address difference information (331,333,335). When compiling the module to be distributed, the database file of the program can be created in the same path as the module to be distributed through setting options in debugging mode (331,333,335). For example, the database file of the program may be a PDB file, a class, method, and source code represented by RVA (Relative Virtual Address).

The PDB file may be generated to support debugging during development, and may include information such as path information of resources necessary to operate the corresponding module, RVA mapping information for each line of source code, and symbol table.

The second analysis step may be obtained by analyzing RVA mapping information for each line of the corresponding file (331,333,335).

The step of analyzing the crash report delivers the address difference information (331,332,334) extracted from the crash report obtained through the first analysis step and the RVA mapping information (331,333,335) of each source code line obtained through the second analysis step to the error tracking step. Or you can transmit.

Finally, an error tracking step may be performed (S170).

In the step of tracking the error (S170), a crash occurrence point can be derived based on the address difference information extracted from the crash report transmitted in the analysis step and RVA mapping information for each source code line (336,337,338,339). In the step of tracking errors per line (S170), the error location of each line can be specified through RVA mapping information per source code line and address difference information in the error module, which are two pieces of information received in the step of analyzing the crash report. Yes (336,337,338,339). Detailed description thereof will be described later.

As described above, the tracking step (S170) uses two input values, the crash address included in the crash report, and the source code-RVA mapping information extracted in the LINES section of the program data file. Can be derived (336,337,338,339).

4 is for explaining a crash point according to a relative virtual address for each environment according to an embodiment of the present invention.

Referring to FIG. 4, although the exe file is substantially the same, the address value of the development environment and the address value of the execution environment may be different. For example, the starting value of the address of the development environment may be 0x21963126, and the starting value of the address of the execution environment may be 0x00000000. Here, numbers starting with 0x~~~ may be relative virtual address (RVA) values.

The exe file of the development environment and the exe file of the execution environment may include a header file. For example, the header file of the exe file of the development environment may have an address value of 0x21963126 to 0x22363126. And the header file of the exe file of the execution environment may have an address value of 0x00000000 to 0x40000000.

The header file contents can be divided into a file header, an optional header, and a section header. At least one of a file header, an optional header, and a section header may include time stamp information.

The time stamp can be defined at the time of the software build. The time stamp can be called a version.

The control unit of the electronic device may extract timestamp information of an execution environment in which an error has occurred and output it to the crash report. The security control unit may check the time stamp of the crash report transmitted through the electronic device.

The security control unit may store or have at least one time stamp for a program or software executed in an execution environment. For example, the security control unit may store or have various versions of programs or software executed in an execution environment.

The security control unit may search the time stamp (0x5bbac917) of the same software as the time stamp (0x5bbac917) of the software in which the error occurred by matching the time stamp (0x5bbac917) of the software in error with at least one of the stored time stamps.

For example, assuming that the version of the software with the error is V2.3, the security control unit matches the version V2.0 of the software to the version V2.9 of the software, which is the same as the version V2.3 of the software with the error. You can search for version V2.3 of the software.

The exe file of the development environment and the exe file of the execution environment may include a relative virtual address.

The relative virtual address of the exe file of the development environment may have an address value of 0x22363126 to 0xFFFFFFFF. In addition, the relative virtual address of the exe file of the execution environment may have an address value of 0x40000000 to 0xFFFFFFFF. The relative virtual address may be relative virtual address information for the source code.

The address value of 0x22363126 in the exe file of the development environment and 0x40000000 in the exe file of the execution environment may be the starting address value of the source code virtual address. Also, the address value of 0x7FFFFFFF in the exe file of the development environment and 0x7FFFFFFF in the exe file of the execution environment may be the end address value of the virtual address of the source code.

The address value of the development environment and the address value of the execution environment may be different, but the interval address value, which is the value minus the error address and the start address, may not change. Using this, the security control unit can find even the line unit of the source code where the error occurred.

For example, assuming that the address value of the error in the execution environment is 0x40080000, the security control unit intervals the value of the address in the execution environment minus the starting address value of the source code virtual address in the execution environment. Can be calculated.

That is, the security control unit may calculate 0x00080000 (interval address value) by subtracting 0x40000000 (start address value of the source code virtual address) from 0x40080000 (the address value where the error occurred).

Accordingly, the security control unit may calculate an address value in which an error occurs in the development environment by adding the interval address value to the start address value of the source code virtual address in the development environment.

That is, the security control unit may calculate 0x22443126 (the address value in which an error occurs) by adding 0x00080000 (interval address value) to 0x22363126 (start address value of the source code virtual address).

In other words. In each environment, the interval address value (0x00080000) can be obtained by obtaining the difference between the error address and the start address of the virtual address. Accordingly, in any environment, if the environment is moved from the starting address value by 0x00080000, the problematic source code address value can be calculated.

5 is for describing relative virtual address and source code line mapping information according to an embodiment of the present invention.

2 to 4, in the line-by-line error tracking step, it is possible to specify an error location in line units through RVA mapping information for each source code line received in the crash report analysis step and address difference information in the error module.

In the case of the same module (refer to FIG. 4), when the same address difference is used, since the error points are exactly matched, the error points can be specified regardless of the execution environment.

By using this principle, the security control unit can track errors with high accuracy with only the minimum data required. To achieve this, it is necessary to track the address difference or the point indicated by the value of the address difference.

The RVA mapping information for each line obtained through the above-described program database analysis in FIGS. 2 to 4 may be configured as a list of functions.

RVA-line mapping information in the form as shown in FIG. 5 may be recorded in the function list.

line 37 can indicate the line position of the source code where the error occurred. [00023230] [0001:0002230] may indicate a relative virtual address (RVA). And len = 0x3F may indicate the length of the RVA. [C:\..\main.cpp]: Can indicate the location of the file where the error occurred. (MD5: 7A..9F): A hash value can be represented.

In the case of a module other than the same module, the relative virtual address mapped to the error point may not match the relative virtual address. That is, in case of other modules, the value of the address difference may be different. Accordingly, the security control unit may track the location of the error by using the information of the relative virtual address mapped to the line and the length of the RVA described above.

Finally, if a line in the range containing the address difference value is found, error line information can be derived together with information included in the crash report.

6 is a comparison of error tracking analysis time and collected data items using a lightweight crash report-based debugging system considering security according to an embodiment of the present invention.

As shown in FIG. 6, (A) Error tracing time is WinDbg, which is a conventional error tracking tool, is 17.545(S), and the present invention is 3.821(S). (B) The collected # of dump data is 82 WinDbg, which is a conventional error tracking tool, and the present invention is 23.

The present invention has been experimented with Process hacker, a C++ open source project based on Native Win32 API. Experiment environment is Intel Core i5-7600, 8GB RAM, Windows 10 32/64bit, Windows Server 2003/2008 32/64bit, Microsoft Visual Studio 2017 (Windows 10 32/64bit), Microsoft Visual Studio 2010 (Windows Server 2003/2008 32 /64bit), Python 3.6.4.

The present invention injects a Divide by zero error as one of the frequently occurring errors in order to induce a crash in an open source that operates normally. For example, the Divide by zero error may be an error that occurs when dividing by 0. Divide by zero error is int b = 0; int a = 100 / b; It can be expressed as cout << a << endl;.

As shown in Table 1, WinDbg, a conventional error tracking tool, can receive and trace errors by analyzing about 82 memory dumps including system environment information of an execution environment. However, it is difficult for developers to see the results of analysis at a glance, and it is expensive to analyze errors.

On the other hand, the present invention can show the same error tracking accuracy as WinDbg, which is a conventional error tracking tool, by checking only 23 analysis results reduced by about 72%.

Therefore, according to the present invention, the size of the crash report can be reduced, and readability can be improved because only the core content necessary for error tracking is read.

The present invention can reduce the total analysis time showing the error line position by about 78% compared to WinDbg, which is a conventional error tracking tool. As described above, the reason for the reduced time required is as follows.

First, in the conventional WinDbg, the dump file itself is an input value in the form of an input value, and data to be analyzed can be vast. However, since the lightweight crash report-based debugging method considering the security according to the present invention utilizes a lightweight crash report, the size of the data to be analyzed is small, so the analysis time can be reduced.

Second, if the process of specifying the program database file to track the line position in the conventional WinDbg is impossible or took a long time, the lightweight crash report-based debugging method considering the security according to the present invention sets the trace path in advance as an input value Therefore, the time for specifying the program database file can be relatively reduced.

Embodiments of the present invention and the accompanying drawings are only a part of the technical spirit included in the above-described technology clearly, those skilled in the art within the scope of the technical spirit included in the specification and drawings of the above-described technology It will be apparent that modifications and specific embodiments that can be easily inferred are all included in the scope of the above-described technology.

100: electronic device
110: communication unit
130: control unit
300: security server
310: secure communication unit
330: security control

Claims (13)

In the debugging method based on the lightweight crash report considering security,
An execution step of executing a program in the electronic device;
A generation step of automatically generating a crash report while collecting information on the crash and essential information required for error tracking when a crash occurs while the program is executing;
An analysis step of receiving the generated crash report and analyzing the information contained in the crash report to extract error information;
A tracking step of tracking the extracted error information and specifying the location of the error;
Lightweight crash report-based debugging method considering security including a. According to claim 1,
The generating step
A lightweight crash report-based debugging method considering security, characterized in that the program generates a dump file, collects the essential information to track errors, and automatically generates the crash report. According to claim 2,
The crash report above
A lightweight crash report-based debugging method considering security, characterized in that a unique number of an executable file capable of executing the program, relative error address information, and stack information are processed into the dump file. According to claim 2,
The crash report is a lightweight crash report-based debugging method considering security, characterized in that it collects system information, module information, thread information, and exception information from the dump file. According to claim 4,
The system information is
A lightweight crash report-based debugging method considering security, characterized by including the operating system type, operating system version, processor level, and processor architecture information. According to claim 4,
The module information
A lightweight crash report-based debugging method considering security, characterized in that it includes the name of the module, the physical address and size information loaded into the physical memory, and the unique number of the module. According to claim 4,
The thread information
A lightweight crash report-based debugging method considering security, characterized in that it includes the thread ID in which the exception occurred and the call stack information of the backtrace method. According to claim 4,
The exception information
A lightweight crash report-based debugging method considering security, characterized in that it contains an error-occurring thread ID, an error-occurring physical memory address, and error rectification information. According to claim 2,
The essential information is a lightweight crash report based debugging method considering security, characterized in that it has a relative virtual address and a time stamp. The method of claim 9,
The analysis step
Searching for and analyzing the same module based on the time stamp, and
A lightweight crash report based debugging method considering security, comprising mapping the relative virtual address lines based on a program database and analyzing the information. The method of claim 9,
The analysis step
The time stamp of the above program that caused the error in the execution environment and
A lightweight crash report-based debugging method considering security, characterized in that the time stamp in the execution environment is the same as the time stamp in the development environment by matching at least one time stamp stored in the development environment. The method of claim 11,
The execution environment or the executable file of the development environment includes a start address value of a virtual address of source code, an end address value of a virtual address of source code, and an address value issued by an error,
The analysis step
A lightweight crash report-based debugging method considering security, characterized in that an interval address value is calculated using a difference between the address value where the error occurred and the start address value of the virtual address. The method of claim 12,
The analysis step
A lightweight crash report-based debugging method considering security, characterized in that the error location is specified by using the calculated interval address value.

Images