Method for automated fuzzing for IoT device based on automated reset and apparatus using the same
11175992 ยท 2021-11-16
Assignee
Inventors
Cpc classification
International classification
G06F11/14
PHYSICS
Abstract
Disclosed herein are a method for automated fuzzing for an IoT device based on automated reset and an apparatus using the same. The method includes loading, by the apparatus, a fuzzing agent into an IoT device based on firmware; monitoring, by the apparatus, the status of processing of fuzzing input by the IoT device based on the fuzzing agent; collecting, by the apparatus, fuzzing data corresponding to occurrence of a crash based on hooking using the fuzzing agent when the crash occurs in the IoT device; and resetting, by the apparatus, the IoT device based on the fuzzing agent.
Claims
1. A method for automated fuzzing for an IoT device, comprising: loading, by an apparatus for automated fuzzing for the IoT device, a fuzzing agent into the IoT device based on firmware; monitoring, by the apparatus for automated fuzzing for the IoT device, a status of processing of fuzzing input by the IoT device based on the fuzzing agent; collecting, by the apparatus for automated fuzzing for the IoT device, fuzzing data corresponding to occurrence of a crash based on hooking using the fuzzing agent when the crash occurs in the IoT device; and resetting, by the apparatus for automated fuzzing for the IoT device, the IoT device based on the fuzzing agent.
2. The method of claim 1, wherein collecting the fuzzing data comprises: is detecting, in advance, a location of an exception handler of the IoT device in firmware memory based on firmware information of the IoT device; and hooking exception handling executed in response to the crash in the IoT device based on the location of the exception handler.
3. The method of claim 2, wherein hooking the exception handling is configured to hook an interrupt corresponding to the crash, among multiple interrupts defined in an exception table.
4. The method of claim 2, wherein the fuzzing data includes at least one of crash occurrence information and a value of a register of CPU architecture that is used in the IoT device during execution of the exception handling.
5. The method of claim 2, wherein the fuzzing agent is loaded into an available space that is not used in the firmware memory.
6. The method of claim 1, wherein the fuzzing agent is in a form of a binary file compiled appropriately for CPU architecture on which the firmware of the IoT device is run.
7. The method of claim 2, wherein the fuzzing agent is loaded based on at least one of an interface accessible to the firmware memory and a debug port of the IoT device.
8. The method of claim 2, wherein the firmware information is collected based on at least one of information published by a manufacturer of the IoT device and debugging data of the IoT device.
9. The method of claim 1, wherein the crash corresponds to a situation in which the firmware of the IoT device is not capable of running normally.
10. An apparatus for automated fuzzing for an IoT device, comprising: a processor for loading a fuzzing agent into the IoT device based on firmware, monitoring a status of processing of fuzzing input by the IoT device based on the fuzzing agent, collecting fuzzing data corresponding to occurrence of a crash based on hooking using the fuzzing agent when the crash occurs in the IoT device, and resetting the IoT device based on the fuzzing agent; and memory for storing the fuzzing data.
11. The apparatus of claim 10, wherein the processor detects, in advance, a location of an exception handler of the IoT device in firmware memory based on firmware information of the IoT device and hooks exception handling executed in response to the crash in the IoT device based on the location of the exception handler.
12. The apparatus of claim 11, wherein the processor hooks an interrupt corresponding to the crash, among multiple interrupts defined in an exception table.
13. The apparatus of claim 11, wherein the fuzzing data includes at least one of crash occurrence information and a value of a register of CPU architecture that is used in the IoT device during execution of the exception handling.
14. The apparatus of claim 11, wherein the fuzzing agent is loaded into an available space that is not used in the firmware memory.
15. The apparatus of claim 10, wherein the fuzzing agent is in a form of a binary file compiled appropriately for CPU architecture on which the firmware of the IoT device is run.
16. The apparatus of claim 11, wherein the fuzzing agent is loaded based on at least one of an interface accessible to the firmware memory and a debug port of the IoT device.
17. The apparatus of claim 11, wherein the firmware information is collected based on at least one of information published by a manufacturer of the IoT device and debugging data of the IoT device.
18. The method of claim 10, wherein the crash corresponds to a situation in which the firmware of the IoT device is not capable of running normally.
Description
BRIEF DESCRIPTION OF THE DRAWINGS
(1) The above and other objects, features and advantages of the present invention will be more clearly understood from the following detailed description, taken in conjunction with the accompanying drawings, in which:
(2)
(3)
(4)
(5)
(6)
(7)
(8)
(9)
(10)
(11)
DESCRIPTION OF THE PREFERRED EMBODIMENTS
(12) The present invention will be described in detail below with reference to the accompanying drawings. Repeated descriptions and descriptions of known functions and configurations that have been deemed to unnecessarily obscure the gist of the present invention will be omitted below. The embodiments of the present invention are intended to fully describe the present invention to a person having ordinary knowledge in the art to which the present invention pertains. Accordingly, the shapes, sizes, etc. of components in the drawings may be exaggerated in order to make the description clearer.
(13) Hereinafter, a preferred embodiment of the present invention will be described in detail with reference to the accompanying drawings.
(14) Generally, performing fuzzing for software requires a function of generating the input to be provided to the fuzzing target software, a function of delivering the input to the fuzzing target software, a function of monitoring the status of processing of the input by the fuzzing target software or a result incurred due to the input in the fuzzing target software, and a function of constructing an environment for repeatedly performing a fuzzing process.
(15) Here, when the input to be provided for fuzzing does not comply with the processable format of the fuzzing target software, the case where the corresponding software excludes the input, rather than processing the same, frequently occurs. In this case, fuzzing is not performed, which causes a problem of low effectiveness. In order to prevent this problem, the input to be provided to the fuzzing target software is generated so as to comply with the processable format of the corresponding software.
(16) Also, the result of processing the fuzzing input by the software is monitored, whereby the input causing an error in the corresponding software may be identified and the presence of a vulnerability therein may be recognized.
(17) Here, the error may include all forms of errors, including termination (a crash) of software, which adversely affect the software such that the software, for which fuzzing is performed, is not operated normally.
(18) The present invention intends to propose technology through which automated fuzzing for an Internet-of-Things (IoT) device or Industrial Control System (ICS), which operates based on firmware, can be performed using the above-mentioned functions.
(19) Hereinafter, a description will be made with a focus on IoT devices for convenience of description, but the described technology or configuration may also be applied to and used in ICS-related devices.
(20)
(21) Referring to
(22) Here, the fuzzing agent may be a tool developed in order to perform automated fuzzing for an IoT device according to an embodiment of the present invention.
(23) For example, the fuzzing agent may be developed in order to perform a function of monitoring firmware and an initialization (reset) function based on information about the firmware of the IoT device, which is the fuzzing target.
(24) Here, the information about the firmware of the IoT device may be collected based on at least one of information published by the manufacturer of the IoT device and debugging data of the IoT device.
(25) For example, when the manufacturer of the IoT device, which is the fuzzing target, publishes firmware information, the published information may be acquired and used.
(26) When it is difficult to freely acquire information about the firmware of the IoT device, firmware information may be collected using debugging data of the IoT device, which is acquired using an interface accessible to firmware memory of the IoT device, such as a Universal Asynchronous Receiver/Transmitter (UART) or Joint Test Action Group (JTAG) interface.
(27) Generally, in order to use debugging data, information about a chip or memory used in the IoT device is required. Therefore, an interface accessible to the firmware memory of the IoT device, such as a UART or JTAG interface, is provided, and information about the chip or memory used in the IoT device may be acquired using the interface.
(28) Here, the debug ports 210 and 220 illustrated in
(29) Here, the fuzzing agent may be loaded using at least one of an interface accessible to the firmware memory of the IoT device and the debug port of the IoT device.
(30) For example, referring to
(31) In another example, referring to
(32) Here, the fuzzing agent may be in the form of a binary file compiled appropriately for the CPU architecture on which the firmware of the IoT device is run.
(33) For example, the fuzzing agent may be compiled appropriately for CPU architecture, such as Intel X86, ARM, PowerPC or the like, thereby being generated in the form of binary code.
(34) Here, the fuzzing agent may be configured or generated so as to enable hooking of exception handling in a fuzzing process for the IoT device.
(35) Here, the fuzzing agent may be loaded into available space that is not used in the firmware memory of the IoT device.
(36) For example, after access to the firmware memory through UART or JTAG, the space that is not being used is reserved, and code of the fuzzing agent received from the apparatus for automated fuzzing for an IoT device may be loaded into the reserved space.
(37) For example, the fuzzing agent code according to an embodiment of the present invention may be loaded into the firmware memory of the IoT device as illustrated in
(38) Here, a library included in the firmware of the IoT device is checked, and available functions may be secured.
(39) Also, in order to hook exception handling later, the locations of an exception handler and an exception table may be checked, along with information related thereto.
(40) Here, the fuzzing agent in the form of binary code is loaded, as shown in the example illustrated in
(41) Also, in the method for automated fuzzing for an IoT device based on automated reset according to an embodiment of the present invention, the apparatus for automated fuzzing for an IoT device monitors the status of processing of the fuzzing input by the IoT device based on the fuzzing agent at step S120.
(42) Here, the fuzzing agent according to an embodiment of the present invention determines whether a crash occurs in the IoT device by performing monitoring at step S125.
(43) When it is determined at step S125 that a crash occurs in the IoT device, the apparatus for automated fuzzing for an IoT device collects fuzzing data corresponding to the occurrence of the crash based on hooking using the fuzzing agent at step S130.
(44) Here, the crash may be the situation in which the firmware of the IoT device is not capable of running normally.
(45) For example, when the firmware of the IoT device is terminated due to the fuzzing input or when the firmware of the IoT device is no longer run due to an error arising from the fuzzing input, it may be determined that a crash occurs.
(46) Here, the location of the exception handler of the IoT device in the firmware memory may be detected in advance based on the information about the firmware of the IoT device.
(47) For example, reverse engineering analysis is performed on the information about the firmware of the IoT device, whereby the location of the exception handler in the firmware memory of the IoT device may be identified.
(48) Based on the identified location of the exception handler, exception handling executed in response to the crash in the IoT device may be hooked.
(49) Generally, firmware of an IoT device may be designed to, when a crash occurs due to a problem or error in the IoT device, recognize the crash and perform its own exception handling. In the present invention, exception handling internally performed in the IoT device is intercepted, whereby a fuzzing process may be performed.
(50) Particularly, an IoT device or an ICS device is designed such that, when a crash occurs, the device recovers the functions thereof by being initialized as soon as possible in order to sustain the operation for achieving the first intended purpose, and information for processing the same is defined in an exception table.
(51) For example, in preparation for various interrupts capable of occurring in an IoT device, the operation to be performed in response to the occurrence of an interrupt may be previously defined in the exception table.
(52) Accordingly, the present invention may hook an interrupt corresponding to a crash, among the multiple interrupts defined in the exception table.
(53) That is, general exception handling may be designed to actually perform initialization for system function recovery when it is determined that a crash occurs in a system, and in this process, the present invention hooks an interrupt, whereby fuzzing data may be collected before the system is reset.
(54) Here, the fuzzing agent may deliver the collected fuzzing data to the apparatus for automated fuzzing for an IoT device.
(55) Here, the fuzzing data may include at least one of crash occurrence information and the value of a register of CPU architecture that is used in the IoT device during execution of the exception handling.
(56) For example, referring to
(57) Particularly in the corresponding memory, functions of each register may be checked using information provided by VxWorks OS.
(58) For example, a program counter contains information about the location in a program currently being executed, and using the same, the location at which a crash occurs in the program may be identified.
(59) Here, when it is determined at step S125 that no crash occurs in the IoT device, the processing status of the IoT device may be continuously monitored until automated fuzzing for the IoT device is terminated.
(60) Also, in the method for automated fuzzing for an IoT device based on automated reset according to an embodiment of the present invention, the apparatus for automated fuzzing for an IoT device resets the IoT device based on the fuzzing agent at step S140.
(61) Here, fuzzing for the IoT device may be repeatedly performed in an automated manner by resetting the IoT device.
(62) For example, when the reset of the IoT device is completed, the apparatus for automated fuzzing for an IoT device inputs new fuzzing input, which is different from the previous fuzzing input, into the IoT device based on the fuzzing agent and repeatedly performs steps S110 to S140, thereby continually performing automated fuzzing for the IoT device.
(63) Hereinafter, the process of performing fuzzing for an IoT device using a fuzzing agent according to an embodiment of the present invention will be described in detail with reference to
(64) First, referring to
(65) The fuzzing agent 720, which is uploaded into the IoT device, monitors the status of processing of fuzzing input by the IoT device at step S810, thereby determining whether a crash occurs at step S815.
(66) When it is determined at step S815 that no crash occurs, monitoring may be repeatedly performed until fuzzing for the IoT device is completed.
(67) Also, when it is determined at step S815 that a crash occurs, the value of a register of CPU architecture that is used during execution of exception handling for responding to the occurrence of the crash in the IoT device may be collected at step S820 based on the register value read function of the fuzzing agent, illustrated in
(68) Here, the fuzzing agent reads from a register for an instruction pointer (IP) that points to the current instruction being executed in the IoT device, thereby detecting the location at which the crash occurs.
(69) Then, the fuzzing agent may deliver fuzzing data to the apparatus 710 for automated fuzzing for an IoT device at step S830 based on the register value transmission function illustrated in
(70) Here, the fuzzing data may be delivered over a network, and may include the value of the register, crash occurrence information, the location at which the crash occurs, and the like.
(71) Then, the fuzzing agent may reset the IoT device at step S840 based on the reset function illustrated in
(72) Through the above-described method for automated fuzzing for an IoT device, automated fuzzing technology for an IoT device operating based on firmware may be provided.
(73) Also, there may be provided technology for automatically performing a fuzzing function capable of detecting the occurrence of a crash by monitoring an IoT device, collecting and delivering information related to the occurrence of the crash, and initializing (resetting) the IoT device.
(74) Also, a vulnerability in an IoT device may be detected early based on automated fuzzing such that it is possible to respond thereto, whereby an environment in which the IoT device can be used more securely may be constructed.
(75)
(76)
(77) Hereinafter, a method for automated fuzzing for an IoT device according to an embodiment of the present invention will be described in detail with reference to
(78) First, the apparatus 910 for automated fuzzing for an IoT device illustrated in
(79) For example, the fuzzing agent may be uploaded into the firmware memory of the IoT device 920 through the connection between the USB port of the apparatus 910 for automated fuzzing for an IoT device and the debug port (UART or JTAG) of the IoT device 920 or through the connection between the network ports, as shown in
(80) Then, the apparatus 910 for automated fuzzing for an IoT device may generate fuzzing input using a processor and deliver the same to the IoT device 920 through the network port at step S1030.
(81) Then, the apparatus 910 for automated fuzzing for an IoT device monitors a process in which the IoT device 920 processes the fuzzing input based on the fuzzing agent loaded into the IoT device 920, thereby determining whether a crash occurs at step S1035.
(82) When it is determined at step S1035 that a crash occurs, the apparatus 910 for automated fuzzing for an IoT device hooks exception handling executed by the IoT device 920 through the fuzzing agent, thereby collecting and recording fuzzing data at step S1040.
(83) Here, the fuzzing agent may deliver the fuzzing data, including the value of a register related to the operation of the IoT device in the event of a crash, crash occurrence information, the location at which the crash occurs, and the like, to the apparatus 910 for automated fuzzing for an IoT device based on the network port of the IoT device 920.
(84) Then, the apparatus 910 for automated fuzzing for an IoT device may reset the IoT device 920 through the fuzzing agent at step S1050, and may determine whether fuzzing for the IoT device 920 is completed at step S1055.
(85) Also, when it is determined at step S1035 that no crash occurs, whether fuzzing for the IoT device 920 is completed may be determined at step S1055.
(86) When it is determined at step S1055 that fuzzing for the IoT device 920 is not completed, the apparatus 910 for automated fuzzing for an IoT device may repeatedly perform the fuzzing process from steps S1030 to S1055 based on the fuzzing agent.
(87) Also, when it is determined at step S1055 that fuzzing for the IoT device 920 is completed, the apparatus 910 for automated fuzzing for an IoT device may record a history of fuzzing for the IoT device 920 in internal memory and terminate fuzzing at step S1060.
(88) Here,
(89)
(90) Referring to
(91) The communication unit 1110 may serve to transmit and receive information required for automated fuzzing for an IoT device through a communication network. Here, the network provides a path through which data is delivered between devices, and may be conceptually understood as including networks that are currently being used and networks that have yet to be developed.
(92) For example, the network may be an IP network, which provides service for transmission and reception of a large amount of data and uninterrupted data service through an Internet Protocol (IP), an all-IP network, which is an IP network structure that integrates different networks based on IP, or the like, and may be configured with a combination of one or more of a wired network, a Wireless Broadband (WiBro) network, a 3G mobile communication network including WCDMA, a High-Speed Downlink Packet Access (HSDPA) network, a 3.5G mobile communication network including an LTE network, a 4G mobile communication network including LTE advanced, a satellite communication network, and a Wi-Fi network.
(93) Also, the network may be any one of a wired/wireless local area network for providing communication between various kinds of data devices in a limited area, a mobile communication network for providing communication between mobile devices or between a mobile device and the outside thereof, a satellite communication network for providing communication between earth stations using a satellite, and a wired/wireless communication network, or may be a combination of two or more selected therefrom. Meanwhile, the transmission protocol standard for the network is not limited to existing transmission protocol standards, but may include all transmission protocol standards to be developed in the future.
(94) The processor 1120 loads a fuzzing agent into an IoT device based on firmware.
(95) Here, the fuzzing agent may be a tool developed in order to perform automated fuzzing for an IoT device according to an embodiment of the present invention.
(96) For example, the fuzzing agent may be developed in order to perform a function of monitoring firmware and an initialization (reset) function based on information about the firmware of the IoT device, which is the fuzzing target.
(97) Here, the information about the firmware of the IoT device may be collected based on at least one of information published by the manufacturer of the IoT device and debugging data of the IoT device.
(98) For example, when the manufacturer of the IoT device, which is the fuzzing target, publishes firmware information, the published information may be acquired and used.
(99) When it is difficult to freely acquire information about the firmware of the IoT device, firmware information may be collected using debugging data of the IoT device, which is acquired using an interface accessible to firmware memory of the IoT device, such as a Universal Asynchronous Receiver/Transmitter (UART) or Joint Test Action Group (JTAG) interface.
(100) Generally, in order to use debugging data, information about a chip or memory used in the IoT device is required. Therefore, an interface accessible to the firmware memory of the IoT device, such as a UART or JTAG interface, is provided, and information about the chip or memory used in the IoT device may be acquired using the interface.
(101) Here, the debug ports 210 and 220 illustrated in
(102) Here, the fuzzing agent may be loaded using at least one of an interface accessible to the firmware memory of the IoT device and the debug port of the IoT device.
(103) For example, referring to
(104) In another example, referring to
(105) Here, the fuzzing agent may be in the form of a binary file compiled appropriately for the CPU architecture on which the firmware of the IoT device is run.
(106) For example, the fuzzing agent may be compiled appropriately for CPU architecture, such as Intel X86, ARM, PowerPC or the like, thereby being generated in the form of binary code.
(107) Here, the fuzzing agent may be configured or generated so as to enable hooking of exception handling in a fuzzing process for the IoT device.
(108) Here, the fuzzing agent may be loaded into available space that is not used in the firmware memory of the IoT device.
(109) For example, after access to the firmware memory through UART or JTAG, the space that is not being used is reserved, and code of the fuzzing agent received from the apparatus for automated fuzzing for an IoT device may be loaded into the reserved space.
(110) For example, the fuzzing agent code according to an embodiment of the present invention may be loaded into the firmware memory of the IoT device, as illustrated in
(111) Here, a library included in the firmware of the IoT device is checked, and available functions may be secured.
(112) Also, in order to hook exception handling later, the locations of an exception handler and an exception table may be checked, along with information related thereto.
(113) Here, the fuzzing agent in the form of binary code is loaded, as shown in the example illustrated in
(114) Also, the processor 1120 monitors the status of processing of the fuzzing input by the IoT device based on the fuzzing agent.
(115) Also, the processor 1120 determines whether a crash occurs in the IoT device by performing monitoring through the fuzzing agent, and collects fuzzing data corresponding to the occurrence of a crash based on hooking using the fuzzing agent when the crash occurs in the IoT device.
(116) Here, the crash may be the situation in which the firmware of the IoT device is not capable of running normally.
(117) For example, when the firmware of the IoT device is terminated due to the fuzzing input or when the firmware of the IoT device is no longer run due to an error arising from the fuzzing input, it may be determined that a crash occurs.
(118) Here, the location of the exception handler of the IoT device in the firmware memory may be detected in advance based on the information about the firmware of the IoT device.
(119) For example, reverse engineering analysis is performed on the information about the firmware of the IoT device, whereby the location of the exception handler in the firmware memory of the IoT device may be identified.
(120) Based on the identified location of the exception handler, exception handling executed in response to a crash in the IoT device may be hooked.
(121) Generally, firmware of an IoT device may be designed to, when a crash occurs due to a problem or error in the IoT device, recognize the crash and perform its own exception handling. In the present invention, exception handling internally performed in the IoT device is intercepted, whereby a fuzzing process may be performed.
(122) Particularly, an IoT device or an ICS device is designed such that, when a crash occurs, the device recovers the functions thereof by being initialized as soon as possible in order to sustain the operation for achieving the first intended purpose, and information for processing the same is defined in an exception table.
(123) For example, in preparation for various interrupts capable of occurring in an IoT device, the operation to be performed in response to the occurrence of an interrupt may be previously defined in the exception table.
(124) Accordingly, the present invention may hook an interrupt corresponding to a crash, among the multiple interrupts defined in the exception table.
(125) That is, general exception handling may be designed to actually perform initialization for system function recovery when it is determined that a crash occurs in a system, and in this process, the present invention hooks an interrupt, whereby fuzzing data may be collected before the system is reset.
(126) Here, the fuzzing agent may deliver the collected fuzzing data to the apparatus for automated fuzzing for an IoT device.
(127) Here, the fuzzing data may include at least one of crash occurrence information and the value of a register of CPU architecture used in the IoT device during execution of exception handling.
(128) For example, referring to
(129) Particularly in the corresponding memory, functions of each register may be checked using information provided by VxWorks OS.
(130) For example, a program counter contains information about the location in a program currently being executed, and using the same, the location at which a crash occurs in the program may be identified.
(131) Also, when no crash occurs in the IoT device, the processor 1120 may continuously monitor the processing status of the IoT device until automated fuzzing for the IoT device is terminated.
(132) Also, the processor 1120 resets the IoT device based on the fuzzing agent.
(133) Here, fuzzing for the IoT device may be repeatedly performed in an automated manner by resetting the IoT device.
(134) For example, when the reset of the IoT device is completed, the apparatus for automated fuzzing for an IoT device inputs new fuzzing input, which is different from the previous fuzzing input, into the IoT device based on the fuzzing agent and repeats the above-described fuzzing process, thereby continually performing automated fuzzing for the IoT device.
(135) Hereinafter, the process of performing fuzzing for an IoT device using a fuzzing agent according to an embodiment of the present invention will be described in detail with reference to
(136) First, referring to
(137) The fuzzing agent 720, which is uploaded into the IoT device, monitors the status of processing of fuzzing input by the IoT device at step S810, thereby determining whether a crash occurs at step S815.
(138) When it is determined at step S815 that no crash occurs, monitoring may be repeatedly performed until fuzzing for the IoT device is completed.
(139) Also, when it is determined at step S815 that a crash occurs, the value of a register of CPU architecture that is used during execution of exception handling for responding to the occurrence of the crash in the IoT device may be collected at step S820 based on the register value read function of the fuzzing agent, illustrated in
(140) Here, the fuzzing agent reads from a register for an instruction pointer (IP) that points to the current instruction being executed in the IoT device, thereby detecting the location at which the crash occurs.
(141) Then, the fuzzing agent may deliver fuzzing data to the apparatus 710 for automated fuzzing for an IoT device at step S830 based on the register value transmission function illustrated in
(142) Here, the fuzzing data may be delivered over a network, and may include the value of the register, crash occurrence information, the location at which the crash occurs, and the like.
(143) Then, the fuzzing agent may reset the IoT device at step S840 based on the reset function illustrated in
(144) The memory 1130 stores fuzzing data.
(145) Also, the memory 1130 may store various kinds of information generated during the above-described process for automated fuzzing for an IoT device.
(146) According to an embodiment, the memory 1030 may be separate from the apparatus for automated fuzzing for an IoT device, and may support the function of automated fuzzing for an IoT device. Here, the memory 1030 may operate as separate mass storage, and may include a control function for performing operations.
(147) Using the above-described apparatus for automated fuzzing for an IoT device, automated fuzzing technology for an IoT device operating based on firmware may be provided.
(148) Also, there may be provided technology for automatically performing a fuzzing function capable of detecting the occurrence of a crash by monitoring an IoT device, collecting and delivering information related to the occurrence of the crash, and initializing (resetting) the IoT device.
(149) Also, a vulnerability in an IoT device may be detected early based on automated fuzzing such that it is possible to respond thereto, whereby an environment in which the IoT device can be used more securely may be constructed.
(150) According to the present invention, automated fuzzing technology for an IoT device that operates based on firmware may be provided.
(151) Also, the present invention may provide technology for automatically performing a fuzzing function capable of detecting the occurrence of a crash by monitoring an IoT device, collecting and delivering information related to the occurrence of the crash, and initializing (resetting) the IoT device.
(152) Also, the present invention enables response to a vulnerability in an IoT device by detecting the same early based on automated fuzzing, thereby constructing an environment in which the IoT device can be used more securely.
(153) As described above, the method for automated fuzzing for an IoT device based on automated reset and the apparatus using the same according to the present invention are not limitedly applied to the configurations and operations of the above-described embodiments, but all or some of the embodiments may be selectively combined and configured, so the embodiments may be modified in various ways.