Use the assembled statement positioning program unusual

xiaoxiao2021-03-06  115

Use the assembled statement positioning program unusual

(Author: PROCEEDINGS OF Hu Song, 2000 at 17:14 on August 1)

SUMMARY This paper proposes a method of rapid positioning with assembly language leading to the process of exceptions to speed up an abnormal BUG. Foreword During the debugging process of the program, it often encounters the exception of the program. After the program runs some operations, the program is turned off after Windows popping up an exception. Figure 1-1 In this problem is the unfortunateness of each programmer, because this exception is the poor BUG reproducibility, the operation steps are unknown. No one can't tell what kind of operation, what kind of environment can reproduce this error. Programming commissioners have to run procedures again and again, hoping to find the steps that generate this error and code that happens the error. In addition, if only Release has happened, the Debug version does not happen, it will be more troublesome. Programmers can only join the log record in the program, I hope to find the wrong program code. If there is a way to know the location of the error code, that is, this problem solves half when the source code will cause the exception information box to pop up. So, according to this information box, how do I locate the location in the exe / dll file? I know how the position is to get the source code that generates the instruction? This article adds a method of rapid positioning with assembly language in this article. Principle one. The structure of the Windows file first understands the basic knowledge of the Windows file before understanding the method. For Windows 32-bit EXE and DLL (PE files), some information on the file is maintained in the header of the file (section section). For an executable code, the .Text section is not available. With QuickView, you can see that the Virtual Address in the Image Base and Section Table in Image Optional Header, Point To Raw Data. For EXE, it is generally image base = 0x00400000, Virtual Address = 0x00001000. For the DLL, image base = 0x10000000, Virtual Address = 0x00001000. The Point to Raw Data is different due to the DLL. The actual value can also be obtained by QuickView. The meaning of these parameters is: Image Base: The base runs at the baseline. EXE is typically 0x00400000, DLL is 0x10000000. This value is the priority address when the program is running. The EXE value is generally constant, and the DLL may be able to load the address and the base address inconsistent. This is because there are multiple DLLs, there can be only one DLL on 0x10000000, and other DLLs are loaded into other addresses. Virtual Address: The relative address of the .Text section when the program loads the memory. Point to Raw Data: Document. The address of the .Text section These three parameters are: Location in Memory - EXE / DLL Load Address - Virtual Address Point To Raw Data = The location in the exe / dll file .

The instructions at 0x00401010 in Figure 1-1 have an abnormality, the position in the file is: through the Proc List.exe tool, you can see that the EXE loads the memory to load the address = 0x00400000 can be seen by QuickView, The other parameters of the EXE are: Virtual Address = 0x00001000 Point To Raw Data = 0x00001000, the location of the code can be calculated in the file is: 0x00401010 - 0x00400000 - 0x00001000 0x00001000 = 0x00001010 For DLL, the processing method is basically the same. Note: The above calculation has been implemented in proclist.exe. When using it, just enter the address of the exception, you can draw the address in the file. two. The positioning scheme with assembly language is based on the analysis of the Windows file structure on the upper side. It can be known that the location of the instruction in the file is found in the location according to the error instruction, so that the corresponding assembly instruction is found. The rest of the job is to find the corresponding advanced language code based on the assembly instruction. However, it is impossible for the code generated by the compilation instruction to be directly investigated by the assembly instruction. In addition, when the program is a release version, it is impossible to find code through the VC because there is no DEBUG information. Solution: Add some special code in the program, compile the code, if the command is generated in the middle of these special code, almost the source code of the error code is also located in the middle of these special codes. Due to the special code as a mark, you need to use some code that does not appear as a special code. In this way, it will not be mistaken as a special code. Therefore, the 90 CC 90 CC 90 CC is selected here as a special code, and its corresponding assembly is NOP INT 3 // generates a DEBUG breakpoint, and the debugger is dedicated. NOP INT 3 NOP INT 3 These instructions are impossible in a normal program, so as special codes are feasible. The following will be described below: as the following program: void fun1 () {INT * a; a = null; / / makes an exception end * a = 3;} When the program is running, when calling FUN1 (), The program will produce an exception. First, the abnormal command is positioned. Before closing the program (pressing the [OK] button), it is seen by proclist.exe that the EXE's memory base address is: 0x00400000 via QuickView: Virtual Address = 0x00001000 Point To Raw Data = 0x000001000 Location instruction in the file Location: 0x00401010 - 0x00400000 - 0x00001000 0x00001000 = 0x00001010 Note: You can also directly calculate the command address of 0x00001010 via ProClist.exe. Steps: 1, start proclist.exe when the message box is displayed. 2. Find the program in ProClist.exe 3. Click this item with the right right click and pop up the menu. 4. Select the [BUG Address Calc] menu item and enter 0x401010 in the dialog. 5. Press the [OK] button to display the calculation results in MessageBox.

转载请注明原文地址:https://www.9cbs.com/read-125288.html

New Post(0)