JP5550578B2 - Entry rewriting device and entry rewriting program - Google Patents

Description

  The present invention relates to an entry rewriting device and an entry rewriting program for rewriting a shared library API entry and a kernel jump system call entry.

  In information system verification / testing, the program group that configures the information system actually operates as designed for various operations including errors of "various library groups, OS, and hardware". Therefore, it is necessary to verify by acquiring various kinds of trace information and confirming whether the processing is correctly performed. However, in order to perform verification, it is generally difficult to simulate an error of “various library groups, OS, hardware” or acquire trace information. Conventionally, as shown in Patent Document 1 and Patent Document 2, in order to simulate an OS or hardware error, a specific driver interface or OS system call is hooked to obtain OS or hardware error information. There is a method of simulating by injecting (trace information can also be acquired by the same method).

  However, this method cannot be used to simulate errors in various library groups or to acquire trace information. In the prior art, this was possible because hooking was performed after entering the kernel (system call, driver interface), but since various libraries are not in the kernel but in user space, the same is possible without modification of the user program. This is because the method cannot be used.

  In addition, as shown in Patent Document 3, there is a method of injecting and simulating error information using a library wrapper function in order to simulate errors of various library interface groups (the same method is used for acquiring trace information). Possible). However, in order to use the wrapper function, it is necessary to create a link of the wrapper function to the target program, that is, it is necessary to modify the target program, and it is necessary to modify all the programs in the information system. In this regard, such modifications cannot be applied to programs provided by third parties.

Japanese Unexamined Patent Publication No. 2009-104490, FIG. 2, etc. Japanese Patent Laid-Open No. 2000-259446, FIG. 2, etc. Japanese Patent Application Laid-Open No. 2007-133590, FIG.

Conventional methods for hooking system calls to simulate OS and hardware errors, and methods for preparing library wrapper functions to simulate various library group errors have the following problems.
(1) In order to simulate errors in various library API (Application Programming Interface) groups, it is necessary to modify the target program, which is difficult to use in combination tests and system tests, and cannot be modified. Not applicable to the program.
(2) In the method of hooking a system call, the logical space for executing arbitrary code such as error injection is limited to the kernel space 30, while the logical space in which various library groups operate is a process space (user space). . Therefore, the method of hooking various library APIs similarly cannot be used. When trying to hook, it is necessary to embed a code for executing arbitrary code in the target program in advance, and this requires modification of the target program as in the case of using a wrapper function. Alternatively, when executing in the kernel space 30, in order to jump into the kernel space 30, it is necessary to prepare a pseudo system call corresponding to each shared library API to be hooked in the OS kernel. Need to be modified.

  The present invention hooks various library APIs so that arbitrary code can be executed in the kernel space, thereby making it possible to simulate errors without modifying the OS kernel and program group in the target information system. The purpose is to enable acquisition of trace information.

The entry rewriting device of the present invention comprises:
A shared library indicating a shared library to which a specified shared library API (Application Programming Interface) belongs is mapped to a process space of a memory, and the mapped shared library is stored with a start address of the mapped shared library. A library that records a jump destination address of a jump instruction corresponding to the shared library API according to the designation belonging to the specification and rewrites the jump instruction having the recorded jump destination address into an interrupt instruction that jumps to a kernel jump system call An API entry rewriting unit;
The jump destination address of the jump instruction of the kernel jump system call entry corresponding to the interrupt instruction rewritten by the library API entry rewriting unit is recorded, and the jump destination address of the library API entry rewriting unit corresponds to the rewritten interrupt instruction. System call entry rewriting for rewriting the jump instruction set in the entry of the system call for kernel jump into the predetermined jump instruction to an arbitrary code execution unit that executes predetermined processing by being called by a predetermined jump instruction And a section.

  According to the present invention, error simulation and acquisition of trace information can be performed without modifying the OS kernel and the program group in the target information system.

FIG. 2 is a block diagram of the target computer 101 according to the first embodiment. The operation | movement flow of the prior preparation stage of the object computer 101 of Embodiment 1. FIG. FIG. 3 is a diagram showing access destinations of each element of the target computer 101 according to the first embodiment. FIG. 6 is a diagram showing a shared library symbol table 32-4 according to the first embodiment. FIG. 4 is a diagram illustrating an execution condition table 32-3 according to the first embodiment. The figure which shows the shared library API entry of Embodiment 1, and a reboot system call entry. FIG. 3 shows an entry storage table according to the first embodiment. 9 is a flowchart showing the operation of the arbitrary code execution unit 32-1 according to the first embodiment. FIG. 3 is a diagram showing access destinations of each element of the target computer 101 according to the first embodiment. FIG. 3 illustrates a CPU register of Embodiment 1; FIG. 3 is a diagram showing a breakdown of a process space according to the first embodiment. FIG. 4 is a block diagram of a target computer 102 according to the second embodiment. The figure which shows the operation | movement concept of the backtrace execution part 32-5 of Embodiment 2. FIG. The conceptual diagram which shows the path | route called the shared library of Embodiment 2. FIG. The conceptual diagram which shows the path | route called the shared library of Embodiment 2. FIG. The operation | movement flow of the backtrace execution part 32-5 of Embodiment 2. FIG. FIG. 10 shows an individual process symbol table 32-6 according to the second embodiment. FIG. 6 shows an execution condition table according to the second embodiment. The figure which shows an example of the external appearance of the object computer of Embodiment 3. FIG. The figure which shows an example of the hardware constitutions of the object computer of Embodiment 3. FIG.

Embodiment 1 FIG.
FIG. 1 is a configuration diagram showing the operation principle of the target computer 101 (entry rewriting device, arbitrary code execution method). In FIG. 1, a target computer 101 is a computer on which a program group constituting an information system to be tested / verified operates.
(1) The condition setting command unit 10 provides man-machine interface means for using the target computer 101.
(2) The system call entry rewriting unit 11 rewrites the jump instruction to the kernel jump system call entity 31-2 in the kernel jump system call entry 31-1 into a jump instruction to the arbitrary code execution unit 32-1.
(3) The library API entry rewriting unit 12 sends a jump instruction to the shared library API entity 22-2 in any shared library API entry 22-1 for executing arbitrary code such as error injection or trace information acquisition to the kernel. It is rewritten as an interrupt instruction for jumping to the jump-in system call entry 31-1.
(4) The condition setting unit 13 sets a condition for executing an arbitrary code in the execution condition table 32-3, for example, executing only when the calling process is a designated program.
(5) The symbol table generation unit 14 generates a shared library symbol table 32-4 of the shared library to which the shared library API to be hooked belongs, and stores it in the shared library symbol table 32-4.
(6) The arbitrary code execution unit 32-1 executes an arbitrary code when the conditions in the execution condition table 32-3 are met.

(Description of operation)
Next, the operation will be described.
In the first embodiment, a case where a code that simulates an error is executed as an arbitrary code will be described as an example. However, the same applies to a case where trace information is acquired or another arbitrary code is executed.

FIG. 2 is an operation flow in a preliminary preparation stage among the basic operations of the target computer 101.
FIG. 3 is a diagram showing where each component is accessing.

(Symbol table generation unit 14)
First, the symbol table generation unit 14 registers information related to the shared library API designated by the operator (user) in the shared library symbol table 32-4 as shown in FIG. Is not performed (S11). In FIG. 4, a shared library name, an API symbol name, and an API entry address are registered.

(Condition setting unit 13)
Next, the condition setting unit 13 adds a target shared library API symbol name, a return value setting condition, a calling program name, etc. in accordance with the designation by the operator (user) in the execution condition table 32-3 as shown in FIG. Is registered as an execution condition (S12). As an execution condition, the operator can specify a process ID, a function name in the caller program, and the like.

(Library API entry rewriting unit 12)
Next, the library API entry rewriting unit 12 maps the shared library to which the shared library API designated by the operator belongs to the App process space 20 in which the condition setting command unit 10 is operating, and holds the mapped start address. (S13). This head address is assumed to be “0xVWXY”. This head address is used in the processing of S28 in FIG.
Next, the library API entry rewriting unit 12 corresponds to the target shared library API among the shared library API entries 22-1 which are part of the mapped shared library as shown in FIG. The jump instruction (for example, BL0x2A00 in FIG. 6A) is read. Then, the library API entry rewriting unit 12 stores the read address (BL0x2A00) that is the original jump destination to the shared library API entity as shown in FIG. 7 (API entry part of FIG. 7). -2 (fwrite BL0x2A00) is recorded (S14), and the jump instruction (BL0x2A00) in the target library API entry in FIG. 6A is jumped to the reboot system call used for the kernel jump system call. It is rewritten to an interrupt instruction (INT 0x ~) (S15).
In this example, the case where the reboot system call is used as the kernel jumping system call has been described as an example, and the reboot system call is not necessarily used. Any system call that can easily determine whether the system call was actually called or jumped from the rewritten entry can be used, and the reboot system call is used as an example of a system call that meets this condition. Explained when to do.

(System call entry rewriting unit 11)
Next, the system call entry rewriting unit 11 jumps the jump instruction of the jump instruction to the kernel jump system call entity 31-2 in the entry of the reboot system call set in the kernel jump system call (FIG. 6B). The address (“0xABCD” in FIG. 6B) is recorded in the entry storage table 32-2 (reboot range shown in the upper side of FIG. 7) (S16), and the jump instruction in the entry of the system call for kernel jumping (BL 0xABCD in FIG. 6B) is rewritten as a jump instruction to the arbitrary code execution unit 32-1. The above is the operation flow in the preliminary preparation stage.

FIG. 8 is an operation flow when a target information system is actually operated and verified / tested out of the basic operations of the target computer 101.
FIG. 9 is a schematic diagram of the execution flow of the target program.

(Load module shared library API call 21)
First, when a shared library API (for example, “fwrite”) is called in the load module 21, a jump is made from the load module shared library API call 21 to the shared library API entry 22-1 of FIG. 6A (S21). Then, it jumps into the OS kernel 31 by the interrupt instruction (INT 0x˜: interrupt instruction jumping to the kernel jumping system call) rewritten in advance (S22). The jump to the arbitrary code execution unit 32-1 in the driver 32 is jumped by the jump instruction of the reboot system call entry (rewritten to the jump instruction to the arbitrary code execution unit 32-1) rewritten in advance (S23).

(Arbitrary code execution unit 32-1)
Next, the arbitrary code execution unit 32-1 first reads the interrupt history register of the CPU as shown in FIG. 10, and confirms which shared library API entry 22-1 has jumped by interrupting. Then, the shared library API entry address is acquired (S24).

  Next, the arbitrary code execution unit 32-1 confirms whether the first and second arguments of the call are magic codes of the reboot system call, or whether the third argument is a command code of the correct reboot system call (S25). ). If it is a correct argument, the arbitrary code execution unit 32-1 jumps to the actual address of the reboot system call recorded in the entry storage table 32-2, and performs the system call processing (S26).

  If it is not a correct argument (possibly a process to be verified), the following processing is performed. As shown in FIG. 11, the address of the shared library API entry differs in the mapped address of the shared library for each process. Therefore, the arbitrary code execution unit 32-1 refers to the memory map table in its own process and confirms to which shared library the shared library API entry address acquired in S24 belongs (S27). Note that at this stage, even the symbol name cannot be specified. Since only the address is known, the arbitrary code execution unit 32-1 can determine which shared library is the mapped address area from the mapped address of the shared library. The shared library to which the shared library belongs (the shared library identified in S27) from the head of the identified shared library and the shared library API entry address (obtained in S24) from the top of the shared library related to the interrupt The address difference up to the entry address is calculated (denoted as Δ address) (S28).

  Then, the arbitrary code execution unit 32-1 searches the shared library symbol table 33-4 and checks whether it is the target shared library API. At this time, the arbitrary code execution unit 32-1 adds the “Δ address” calculated in S28 to the head address (“0xVWXY”) held in S13 in the preparatory stage to obtain an added address value. Then, the arbitrary code execution unit 32-1 finds an address corresponding to the addition address value from the shared library symbol table 32-4, and checks whether or not the shared library name associated with the interrupt exists in the line. If it is not the target shared library API, it is determined that the call is a properly called reboot system call, and the process jumps to the entity of the reboot system call in the entry storage table 32-2 (S29). The case of NO in S29 is a case where the symbol name of the line specified by the check is not an API symbol name registered in the execution condition table 32-3 of FIG. The fact that there is no symbol in the execution condition table 32-3 even though it branches here (NO in S25) without corresponding to the magic code of the reboot system call means that the arbitrary code execution unit 32-1 It is determined that the API call 21 is calling the reboot system call with an incorrect argument.

In the case of the target shared library API, the execution condition table 32-3 is referred to and it is determined whether the calling source program, the return value condition, and the like are met (S30). If not, the arbitrary code execution unit 32-1 jumps to the regular jump destination address of the shared library API in the entry storage table 32-2 (S33).
If the condition is met, the arbitrary code execution unit 32-1 sets a return value (S31), and calls the load module shared library API in the App process space 20 indicated by the RP (return pointer) stored in the kernel stack. A jump is made immediately after the shared library API call in 21 (S32).

  As a result, by hooking various library APIs so that arbitrary code can be executed in the kernel space 30, error simulation can be performed without modifying the OS kernel 31 and the program group in the target information system. And trace information can be acquired.

Embodiment 2. FIG.
Next, the target computer 102 according to the second embodiment will be described with reference to FIGS. The target computer 102 is configured to further include a backtrace execution unit 32-5 and an individual process symbol table 32-6 (FIG. 17) in addition to the target computer 101 of the first embodiment.

FIG. 12 is a block diagram of the target computer 102.
FIG. 13 shows an operation concept of the backtrace execution unit 32-5.
FIG. 14 is a conceptual diagram showing a path through which a shared library is called.
FIG. 15 is a conceptual diagram showing a path in which a shared library is called.
FIG. 16 is an operation flow of the backtrace execution unit 32-5.
FIG. 17 is a diagram showing the individual process symbol table 32-6.
FIG. 18 shows an execution condition table in the second embodiment.

  In addition to the contents described in the first embodiment, the target computer 102 according to the second embodiment makes it possible to specify conditions for the call source path of the shared library API. In FIG. 12, in addition to the configuration in the first embodiment (FIG. 1), the target computer 102 includes a backtrace execution unit 32-5 and an individual process symbol table 32-6 (in FIG. 12, expressed as an individual Proc symbol table). Have).

(Description of operation)
Next, the operation will be described.
FIG. 13 shows an operation concept of the backtrace execution unit 32-5. The backtrace execution unit 32-5 is called when determining whether the return value setting condition in FIG. 8 is met (S30 in FIG. 8). The backtrace execution unit 32-5 performs backtrace to determine whether or not the specified path, for example, in FIG. 14, the shared library APIslib_2 matches when called via sub_02 and sub_13.

  FIG. 16 shows an operation flow. First, as shown in the execution condition table of FIG. 18, when a caller condition is set as a return value setting condition for the called API (slib_2), the condition is confirmed in the flow of FIG. . In the flow of FIG. 16, first, from the register save area ((1) of FIG. 13) that is performed when the shared library API slib_2 is called, that is, when an interrupt occurs because it is rewritten to a system call, The value of the program counter (PC) and the value of the stack pointer (SP) at the time of occurrence of the interrupt are acquired (S41).

  Next, it is confirmed to which symbol on the individual process symbol table (FIG. 17) the address indicated by the program counter value corresponds, and the symbol name is held (S44). For example, if the PC points to 0x00400550, it corresponds to the address area of the symbol name sub_12.

  Next, it is confirmed whether or not the retained symbol name is “main” (S45), and if “Yes”, the flow is terminated because the backtrace is completed to the end and the condition is not met (S46). If No, it is confirmed whether the held symbol name meets the conditions (S47). If Yes, it is further confirmed whether all the conditions are satisfied (S48). If Yes, the flow is terminated because the condition is met (S49). If No, the return pointer (RP) value and the next stack pointer (SP) value are acquired from the address pointed to by the stack pointer (pointing to the top of the stack area) (S50).

  Next, it is confirmed to which symbol on the individual process symbol table (FIG. 17) the address indicated by the return pointer value corresponds, and the symbol name is held (S51).

  Thereafter, (S45) to (S51) are repeated according to the flow until the end condition is satisfied. As a means for generating the individual process symbol table (FIG. 17) in S42 of FIG. 16, an address (shared library) obtained by calculating the address of the symbol table of the load module and the symbol table of the shared library mapped to the process. This is done by sorting the addresses mapped in the symbol table by the addresses recorded in the symbol table. As a result, for example, when an error is injected by hooking a shared library API that can be called from a plurality of functions as shown in FIG. This has the effect of enabling comprehensive testing.

Embodiment 3 FIG.
The third embodiment will be described with reference to FIGS. The third embodiment describes the hardware configuration of the target computers 101 and 102 that are computers.
FIG. 19 is a diagram illustrating an example of an appearance of the target computer 101 or the target computer 102 that is a computer.
FIG. 20 is a diagram illustrating an example of hardware resources of the target computer 101 or the target computer 102. In the following description, the target computer 101 is assumed. The description of the target computer 101 also applies to the target computer 102 as it is.

  19, the target computer 101 includes a system unit 830, a display device 813 having a CRT (Cathode / Ray / Tube) or LCD (liquid crystal) display screen, a keyboard 814 (Key / Board: K / B), Hardware resources such as a mouse 815 and a compact disk device 818 (CDD: Compact Disk Drive) are provided, and these are connected by cables and signal lines. The system unit 830 is connected to the network.

  In FIG. 20 showing hardware resources, the target computer 101 includes a CPU 810 (Central Processing Unit) that executes a program. The CPU 810 is connected to a ROM (Read Only Memory) 811, a RAM (Random Access Memory) 812, a display device 813, a keyboard 814, a mouse 815, a communication board 816, a CDD 818, and a magnetic disk device 820 via a bus 825. Control hardware devices. Instead of the magnetic disk device 820, a storage device such as an optical disk device or a flash memory may be used.

  The RAM 812 is an example of a volatile memory. Storage media such as the ROM 811, the CDD 818, and the magnetic disk device 820 are examples of nonvolatile memories. These are examples of a “storage device” or a storage unit, a storage unit, and a buffer. The communication board 816, the keyboard 814, and the like are examples of an input unit and an input device. The communication board 816, the display device 813, and the like are examples of an output unit and an output device. The communication board 816 is connected to the network.

  The magnetic disk device 820 stores an operating system 821 (OS), a window system 822, a program group 823, and a file group 824. The programs in the program group 823 are executed by the CPU 810, the operating system 821, and the window system 822.

  The program group 823 stores programs that execute the functions described as “˜units” in the description of the above embodiments. The program is read and executed by the CPU 810.

  In the description of the above embodiment, the file group 824 includes “to determination result”, “to calculation result”, “to extraction result”, “to generation result”, and “to processing result”. The described information, data, signal values, variable values, parameters, and the like are stored as items of “˜file” and “˜database”. The “˜file” and “˜database” are stored in a recording medium such as a disk or a memory. Information, data, signal values, variable values, and parameters stored in a storage medium such as a disk or memory are read out to the main memory or cache memory by the CPU 810 via a read / write circuit, and extracted, searched, referenced, compared, and calculated. Used for CPU operations such as calculation, processing, output, printing, and display. Information, data, signal values, variable values, and parameters are temporarily stored in the main memory, cache memory, and buffer memory during the CPU operations of extraction, search, reference, comparison, operation, calculation, processing, output, printing, and display. Is remembered.

  In the description of the embodiment described above, the data and signal values are the memory of the RAM 812, the compact disk of the CDD 818, the magnetic disk of the magnetic disk device 820, other optical disks, mini disks, and DVDs (Digital Versatile Disk). Or the like. Data and signals are transmitted on-line via the bus 825, signal lines, cables, and other transmission media.

  In the above description of the embodiment, what has been described as “to part” may be “to means”, and “to step”, “to procedure”, and “to processing”. May be. That is, what has been described as “˜unit” may be implemented by software alone, a combination of software and hardware, or a combination of firmware. Firmware and software are stored as programs in a recording medium such as a magnetic disk, a flexible disk, an optical disk, a compact disk, a mini disk, and a DVD. The program is read by the CPU 810 and executed by the CPU 810. That is, the program causes the computer to function as the “˜unit” described above. Alternatively, the computer executes the procedure and method of “to part” described above.

  In the above embodiment, the target computer 101 (entry rewriting device) as an apparatus has been described. However, it is apparent from the above description that the operation of the target computer 101 can also be grasped as an entry rewriting program.

In the above embodiment, the arbitrary code execution method that includes the following means and elements and enables arbitrary code to be executed in the kernel space without modifying the application program has been described.
(A) Accepting an arbitrary code execution condition interactively with the tester, instructing the condition setting unit to write to the execution condition table, and triggering arbitrary code execution to the library API entry rewriting unit Instructs the system call entry rewriting unit to rewrite the system call entry designated as the system call for kernel jumping, and instructs the symbol table generation unit to share the target Means for instructing generation of library symbol table (condition setting command);
(B) Means for rewriting the jump destination of the target shared library API entry in the shared library to which the target program is dynamically linked to the address of the system jump entry for kernel jumping and holding the original address in the entry storage table (library API entry rewriting part);
(C) means for rewriting the jump destination of the system call entry in the kernel to an arbitrary code execution unit (system call entry rewriting unit);
(D) Means (condition setting unit) for writing a combined condition such as a target shared library API, a designated program, and a process ID in an execution condition table as a condition for executing an arbitrary code;
(E) means for searching for a shared library to which the target shared library API belongs, and storing the symbol table of the shared library in the shared library symbol table in a state sorted by relative address values (symbol table generating unit)
(F) When called, the execution condition table is checked after determining which shared library API is called, and if the condition is met, means for executing the specified code (arbitrary code execution unit);

In the above embodiment, the arbitrary code execution method that further includes the following means and elements and enables the condition specification of the route in which the caller function is called has been described.
(A) Means for searching through which function in the load module the shared library API is called (backtrace execution unit);
(B) An element (individual process symbol table) holding an individual symbol table of each application process necessary for executing the backtrace;

  101, 102 Target computer, 10 Condition setting command part, 11 System call entry rewriting part, 12 Library API entry rewriting part, 13 Condition setting part, 14 Symbol table generating part, 20 App process space, 21 Load module shared library API call, 22 Shared library group, 22-1 Shared library API entry, 22-2 Shared library API entity, 30 kernel space, 31 OS kernel, 31-1 Kernel jump system call entry, 31-2 Kernel jump system call entity, 32 Driver, 32-1 Arbitrary code execution unit, 32-2 Entry storage table, 32-3 Execution condition table, 32-4 Shared library symbol table, 32-5 Backtrace execution unit, 32-6 Process symbol table.

Claims (6)

A shared library indicating a shared library to which a specified shared library API (Application Programming Interface) belongs is mapped to a process space of a memory, and the mapped shared library is stored with a start address of the mapped shared library. A library that records a jump destination address of a jump instruction corresponding to the shared library API according to the designation belonging to the specification and rewrites the jump instruction having the recorded jump destination address into an interrupt instruction that jumps to a kernel jump system call An API entry rewriting unit;
The jump destination address of the jump instruction of the kernel jump system call entry corresponding to the interrupt instruction rewritten by the library API entry rewriting unit is recorded, and the jump destination address of the library API entry rewriting unit corresponds to the rewritten interrupt instruction. System call entry rewriting for rewriting the jump instruction set in the entry of the system call for kernel jump into the predetermined jump instruction to an arbitrary code execution unit that executes predetermined processing by being called by a predetermined jump instruction And an entry rewriting device. The entry rewriting device further includes:
An execution condition storage unit that stores predetermined execution conditions for the shared library API;
The arbitrary code execution unit, comprising: an arbitrary code execution unit that executes the predetermined process based on the execution condition stored in the execution condition storage unit when called by the predetermined jump instruction The entry rewriting device according to claim 1. The entry rewriting device further includes:
A symbol table storage unit for storing information on a predetermined shared library API;
The arbitrary code execution unit
When called by the predetermined jump instruction, it is determined which shared library API is called by referring to information stored in the symbol table storage unit, and corresponds to the determined shared library API. 3. The entry rewriting device according to claim 2, wherein an execution condition is extracted from the execution condition storage unit, and the predetermined process is executed based on the execution condition corresponding to the extracted shared library API. The arbitrary code execution unit
Whether or not the execution condition corresponding to the extracted shared library API matches the state of the called shared library API when the execution condition corresponding to the determined shared library API is extracted from the execution condition storage unit 4. The entry rewriting device according to claim 3, wherein when the two are determined to match, the predetermined processing is executed based on the execution condition corresponding to the extracted shared library API. The entry rewriting device further includes:
An individual symbol table storage unit that stores a symbol name and a start address of the symbol for each application process, and stores an individual symbol table used for backtrace execution
A backtrace execution unit that executes a backtrace indicating processing for specifying which function the shared library API is called by using the individual symbol table stored in the individual symbol table storage unit. The entry rewriting device according to claim 4, wherein: Computer
A shared library indicating a shared library to which a specified shared library API (Application Programming Interface) belongs is mapped to a process space of a memory, and the mapped shared library is stored with a start address of the mapped shared library. A library that records a jump destination address of a jump instruction corresponding to the shared library API according to the designation belonging to the specification and rewrites the jump instruction having the recorded jump destination address into an interrupt instruction that jumps to a kernel jump system call API entry rewriting part,
The jump destination address of the jump instruction of the kernel jump system call entry corresponding to the interrupt instruction rewritten by the library API entry rewriting unit is recorded, and the jump destination address of the library API entry rewriting unit corresponds to the rewritten interrupt instruction. System call entry rewriting for rewriting the jump instruction set in the entry of the system call for kernel jump into the predetermined jump instruction to an arbitrary code execution unit that executes predetermined processing by being called by a predetermined jump instruction Part,
Entry rewriting program to function as

Images