1. A method of detecting malwares, the method comprising: converting, by a malware detection system, a target binary file into a corresponding assembly code, wherein the target binary file corresponds to an application to be deployed in a target device; generating, by the malware detection system, an abstract code corresponding to the assembly code by replacing registers in the assembly code with predefined representative variable names; assigning, by the malware detection system, a similarity score for the target binary file by comparing the abstract code with one or more reference abstract codes corresponding to one or more historical malwares identified by the malware detection system; and classifying, by the malware detection system, the target binary file as a malware when the similarity score for the target binary file is greater than a first threshold score.

2. The method as claimed in claim 1, wherein the similarity score for the target binary file is assigned based on one or more scoring parameters including at least one of number of matching code snippets in the abstract code, instruction length of the matching code snippets, and weight of the matching code snippets.

3. The method as claimed in claim 1, wherein classifying the target binary file comprises: classifying the target binary file as a non-malware when the similarity score for the target binary file is less than a second threshold score; or classifying the target binary file as a probable malware when the similarity score for the target binary file is less than the first threshold score and greater than the second threshold score.

4. The method as claimed in claim 2 comprises: transmitting and deploying the target binary file on the target device when the target binary file is classified as the non-malware.

5. The method as claimed in claim 2 comprises: performing a deep-scan classification on the abstract code of the target binary file when the target binary file is classified as the probable malware.

6. The method as claimed in claim 5, wherein performing the deep-scan classification comprises: segregating the assembly code of the target binary file into one or more logical groups based on predefined separation policies, wherein each of the one or more logical groups include one or more related assembly instructions; comparing each of the one or more logical groups with one or more reference logical groups corresponding to the one or more historical malwares; and classifying the target binary file as the malware when the one or more logical groups match with the one or more reference logical groups.

7. The method as claimed in claim 6, wherein the predefined separation policies are generated based on one or more policy parameters of the target device.

8. The method as claimed in claim 7, wherein the one or more policy parameters comprise at least one of, Operating System (OS) information of the target device, assembly instruction set of the target device, processor architecture of the target device, system call semantics, interrupt handler information and register list of the target device.

9. The method as claimed in claim 6, wherein the deep-scan classification is performed using a pretrained artificial intelligent system, trained using assembly code of the one or more historical malwares detected by the malware detection system.

10. A malware detection system for detecting malwares, the malware detection system comprising: a processor; and a memory, communicatively coupled to the processor, wherein the memory stores processor-executable instructions, which on execution, cause the processor to: convert a target binary file into a corresponding assembly code, wherein the target binary file corresponds to an application to be deployed in a target device; generate an abstract code corresponding to the assembly code by replacing registers in the assembly code with predefined representative variable names; assign a similarity score for the target binary file by comparing the abstract code with one or more reference abstract codes corresponding to one or more historical malwares identified by the malware detection system; and classify the target binary file as a malware when the similarity score for the target binary file is greater than a first threshold score.

11. The malware detection system as claimed in claim 10, wherein the processor assigns the similarity score for the target binary file based on one or more scoring parameters including at least one of number of matching code snippets in the abstract code, instruction length of the matching code snippets, and weight of the matching code snippets.

12. The malware detection system as claimed in claim 10, wherein the processor classifies the target binary file by: classifying the target binary file as a non-malware when the similarity score for the target binary file is less than a second threshold score; or classifying the target binary file as a probable malware when the similarity score for the target binary file is less than the first threshold score and greater than the second threshold score.

13. The malware detection system as claimed in claim 11, wherein the processor is further configured to: transmit and deploy the target binary file on the target device when the target binary file is classified as the non-malware.

14. The malware detection system as claimed in claim 11, wherein the processor is further configured to: perform a deep-scan classification on the abstract code of the target binary file when the target binary file is classified as the probable malware.

15. The malware detection system as claimed in claim 14, wherein the processor performs the deep-scan classification by: segregating the assembly code of the target binary file into one or more logical groups based on predefined separation policies, wherein each of the one or more logical groups include one or more related assembly instructions; comparing each of the one or more logical groups with one or more reference logical groups corresponding to the one or more historical malwares; and classifying the target binary file as the malware when the one or more logical groups match with the one or more reference logical groups.

16. The malware detection system as claimed in claim 15, wherein the processor generates the predefined separation policies based on one or more policy parameters of the target device.

17. The malware detection system as claimed in claim 15, wherein the one or more policy parameters comprise at least one of, Operating System (OS) information of the target device, assembly instruction set of the target device, processor architecture of the target device, system call semantics, interrupt handler information and register list of the target device.

18. The malware detection system as claimed in claim 16, wherein the processor performs the deep-scan classification using a pretrained artificial intelligent system, trained using assembly code of the one or more historical malwares detected by the malware detection system. Dated this 21st day of July, 2020 R. Ramya Rao IN/PA-1607 Of K & S Partners Agent for the Applicant   , Description:TECHNICAL FIELD The present subject matter is, in general, related to Internet of Things (IoT) and more particularly, but not exclusively, to a method and system for detecting malwares in an IoT environment. BACKGROUND Generally, an IoT environment includes edge devices and cloud servers or data centers that are connected by network gateways. The edge devices are installed with software applications that perform predefined functions. The software applications installed on the edge devices are updated using Over the Air (OTA) updates. In other words, the software applications running on these edge devices are updated remotely. In the existing systems, the updates for the software applications are scanned for presence of malware or virus at a base server before transmitting the updates to the edge devices as an OTA update. However, presently there is no malware detection mechanism employed at the edge devices. So, the edge devices may fail to detect if an incoming binary for update of the software application is a malware. Also, malwares take an advantage of the fact that they can change their signatures to deceive a signature-based malware detection mechanism which may be employed in the edge devices. Further, in the case of anomaly-based malware detection mechanism, unlike domains like network intrusion detection, there is no well-defined mechanism for distinguishing anomalies and normal binaries. Hence, it would be desirable to have an appropriate encoding scheme to detect and represent the anomalous applications. The information disclosed in this background of the disclosure section is only for enhancement of understanding of the general background of the invention and should not be taken as an acknowledgement or any form of suggestion that this information forms the prior art already known to a person skilled in the art. SUMMARY One or more shortcomings of the prior art may be overcome, and additional advantages may be provided through the present disclosure. Additional features and advantages may be realized through the techniques of the present disclosure. Other embodiments and aspects of the disclosure are described in detail herein and are considered a part of the claimed disclosure. Disclosed herein is a method for detecting malwares. The method comprises converting a target binary file into a corresponding assembly code. The target binary file corresponds to an application to be deployed in a target device. Further, the method comprises generating an abstract code corresponding to the assembly code by replacing registers in the assembly code with predefined representative variable names. Upon generating the abstract code, the method comprises assigning a similarity score for the target binary file by comparing the abstract code with one or more reference abstract codes corresponding to one or more historical malwares identified by the malware detection system. Finally, the method comprises classifying the target binary file as a malware when the similarity score for the target binary file is greater than a first threshold score. Further, the present disclosure relates to a malware detection system for detecting malwares. The malware detection system comprises a processor and a memory. The memory is communicatively coupled to the processor and stores processor-executable instructions, which on execution, cause the processor to convert a target binary file into a corresponding assembly code, wherein the target binary file corresponds to an application to be deployed in a target device. Further, the instructions cause the processor to generate an abstract code corresponding to the assembly code by replacing registers in the assembly code with predefined representative variable names. Upon generating the abstract code, the instructions cause the processor to assign a similarity score for the target binary file by comparing the abstract code with one or more reference abstract codes corresponding to one or more historical malwares identified by the malware detection system. Finally, the instructions cause the processor to classify the target binary file as a malware when the similarity score for the target binary file is greater than a first threshold score. The foregoing summary is illustrative only and is not intended to be in any way limiting. In addition to the illustrative aspects, embodiments, and features described above, further aspects, embodiments, and features will become apparent by reference to the drawings and the following detailed description. BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate exemplary embodiments and, together with the description, explain the disclosed principles. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the figures to reference like features and components. Some embodiments of system and/or methods in accordance with embodiments of the present subject matter are now described, by way of example only, and regarding the accompanying figures, in which: FIG. 1A and 1B illustrate an exemplary IoT environment and detection of malware in accordance with some embodiments of the present disclosure. FIG. 2 shows a detailed block diagram illustrating a malware detection system in accordance with some embodiments of the present disclosure. FIG. 3A – 3D illustrate abstraction of assembly code into corresponding abstract code in accordance with some embodiments of the present disclosure. FIG. 4A summarizes the method of malware detection using a substitution filter and a deep scan model in accordance with some embodiments of the present disclosure. FIG. 4B provides a detailed illustration of a method of detecting malware using the substitution filter in accordance with some embodiments of the present disclosure. FIG. 4C provides a detailed illustration of a method of detecting malware using the deep scan model in accordance with some embodiments of the present disclosure. FIG. 5A - 5C illustrate a method of logically separating the assembly code in accordance with some embodiments of the present disclosure. FIG. 6 illustrates a method of detecting malware in accordance with some embodiments of the present disclosure. FIG. 7 illustrates a block diagram of an exemplary computer system for implementing embodiments consistent with the present disclosure. It should be appreciated by those skilled in the art that any block diagrams herein represent conceptual views of illustrative systems embodying the principles of the present subject matter. Similarly, it will be appreciated that any flow charts, flow diagrams, state transition diagrams, pseudo code, and the like represent various processes which may be substantially represented in computer readable medium and executed by a computer or processor, whether such computer or processor is explicitly shown. DETAILED DESCRIPTION In the present disclosure, the word "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any embodiment or implementation of the present subject matter described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments. While the disclosure is susceptible to various modifications and alternative forms, specific embodiment thereof has been shown by way of example in the drawings and will be described in detail below. It should be understood, however that it is not intended to limit the disclosure to the specific forms disclosed, but on the contrary, the disclosure is to cover all modifications, equivalents, and alternative falling within the scope of the disclosure. The terms “comprises”, “comprising”, “includes”, or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a setup, device, or method that comprises a list of components or steps does not include only those components or steps but may include other components or steps not expressly listed or inherent to such setup or device or method. In other words, one or more elements in a system or apparatus proceeded by “comprises… a” does not, without more constraints, preclude the existence of other elements or additional elements in the system or method. The present disclosure relates to a method and a malware detection system for detecting malwares. In an embodiment, the method discloses converting a target binary file into a corresponding assembly code. The target binary file corresponds to an application to be deployed in a target device. Further, the method comprises generating an abstract code corresponding to the assembly code by replacing registers in the assembly code with predefined representative variable names. Upon generating the abstract code, the method comprises assigning a similarity score for the target binary file by comparing the abstract code with one or more reference abstract codes corresponding to one or more historical malwares identified by the malware detection system. Finally, the method comprises classifying the target binary file as a malware when the similarity score for the target binary file is greater than a first threshold score. One of the differences between the existing techniques and the method of present disclosure is that the existing techniques operate with an assumption that metamorphic engine is in the open and not morphed, such that an instruction substitution table used by a morphing engine may be available to view the substitutions. However, in real practice, the morphing engine, along with malware payload, are obfuscated. As a result, it will not be possible to retrieve the substitution table of the suspicious software. Ideally, a normalizer consists of four components, namely Dead Code Removal (DC), Program Reordering (PR), Register Renaming (RR) and Instruction Substitution (IS). However, the existing techniques assume that the normalizer will have the substitution tables in the database and therefore, IS unit is not required in the Normalizer. Other existing techniques involve encoding raw assembly instruction of a target binary. However, the encoding of the raw assembly instructions may not be accurate, because the encoding of each instruction observes its logical neighbours to come up with a representation of itself with respect to logical neighbours. Hence, in the raw assembly code, the control order might not be the logical order of the instructions due to the optimizations done by the compilers. Such logical neighbours may be extracted for each instruction by merely looking at the processor architecture on which the binary is intended to be executed. On the other hand, the proposed method of malware detection takes into consideration the substitution table of the known malwares captured earlier by the system. These substitution tables are abstracted. During the abstraction, representative variables are assigned to the registers used in the assembly code of the substitution tables. Subsequently, the assembly code of a new software is also abstracted by replacing the specific registers with representative variable names. Then, the abstracted code of the new software is compared with the abstracted substitution tables and a score is generated. Based on the score, the new software is classified as either a malware or not. Additionally, if there is a grey zone in the classification, such that the score is not confident enough to decide whether it is a malware or not, then a deep scan is done. Thus, the proposed method of malware detection helps in accurate and faster malware detection. In the following detailed description of the embodiments of the disclosure, reference is made to the accompanying drawings that form a part hereof, and in which are shown by way of illustration specific embodiments in which the disclosure may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the disclosure, and it is to be understood that other embodiments may be utilized and that changes may be made without departing from the scope of the present disclosure. The following description is, therefore, not to be taken in a limiting sense. FIG. 1A illustrates an exemplary IoT environment in accordance with some embodiments of the present disclosure. As shown in environment 100A, an IoT platform may include one or more IoT devices 101, an IoT gateway 103 and data centers 105. The IoT devices 101 may include, without limiting to, end-user computing devices like smartphones, network gadgets and sensory units. The IoT gateway 103 may be a communication bridge between the IoT devices 101 and the data centers 105. In an embodiment, the data centers 105 may include, without limiting to, servers and warehouses running on a cloud computing platform. In an embodiment, the data centers 105 may provide one or more instructions and updates to the IoT devices 101 through the IoT gateways 103. The IoT devices 101 may perform one or more predefined functions based on the data centers 105 and return resultant information to the data centers 105 through the IoT gateway 103. In an embodiment, introducing a new application and/or updating an already installed application on the IoT device may be performed by sending Over the Air (OTA) updates to the IoT devices 101. Generally, the OTA updates may be scanned for possible security breaches and malware attacks either at the data centers 105 or at the transmission side. In other words, there may not be any security checking means deployed on the IoT device side. This allows an attacker to introduce malicious data on to the IoT network causing malfunctions at the IoT devices 101. For instance, the attacker may introduce malicious packets on the IoT gateways 103 causing a surface attack 107 at the IoT gateway 103. The surface attacks 107 may tag along the OTA updates and propagate on either side of the network as indicated by arrows 107’. As a result, the IoT devices 101 may find it difficult to differentiate the malwares and the regular OTA updates. Thus, there may be chances that the malwares get introduced in the IoT network, interrupting the functionalities of the IoT devices 101. In an embodiment, as illustrated in FIG. 1B, the malware detection system 109 proposed in the present disclosure may be used for detecting possible malware attacks on the IoT environment by associating the malware detection system 109 to the IoT environment. In an implementation, the malware detection system 109 may be deployed on the IoT devices 101 for actively detecting and differentiating the malwares from the regular applications and updates. In an alternative implementation, the malware detection system 109 may be implemented on the IoT gateway 103 for monitoring and detecting possible malware attacks on the IoT network on the end-user side. In an embodiment, whenever an OTA update is transmitted to the IoT devices 101, the malware detection system 109 may retrieve a target binary file 111 corresponding to an application or update to be deployed in the target device from the network. Subsequently, the malware detection system 109 convert the target binary file 111 into a corresponding assembly code. As an example, the target binary code may be an executable data file (i.e., ‘.exe’ file). The assembly code may be a low-level machine-readable file corresponding to the target binary code. In an embodiment, once the assembly code has been obtained, the malware detection system 109 may generate an abstract code corresponding to the assembly code. In an implementation, the abstract code may be generated by replacing the ‘register’ variables in the assembly code with predefined representative variable names. Upon obtaining the abstract code, the malware detection system 109 may compute and assign a similarity score for the target binary file 111 by comparing the abstract code with one or more reference abstract codes stored in the malware detection system 109. The one or more reference abstract codes may be the abstract codes corresponding to the one or more historical malwares identified by the malware detection system 109. The historical malwares may be the malwares that are previously encountered by the IoT devices 101. In an embodiment, upon assigning the similarity score for the target binary file 111, the malware detection system 109 may classify the target binary file 111 as at least one of a malware or non-malware based on the similarity score. In an embodiment, the target binary file 111 may be classified as the malware when the similarity score assigned for the target binary file 111 is greater than a first threshold score. Similarly, the target binary file 111 may be classified as the non-malware when the similarity score assigned for the target binary file 111 is less than the first threshold score. In an embodiment, value of the first threshold score may be varied according to sensitivity of the application and level of security check to be implemented on the IoT devices 101. FIG. 2 shows a detailed block diagram illustrating a malware detection system 109 in accordance with some embodiments of the present disclosure. In an implementation, the malware detection system 109 may include an I/O interface 201, a processor 203 and a memory 205. The I/O interface 201 may be configured to retrieve a target binary file 111 being transmitted to a target device. Additionally, the I/O interface 201 may be used for retrieving information related to one or more historical malwares from an external storage associated with the malware detection system 109. In an embodiment, the processor 203 may be configured to perform one or more functions of the malware detection system 109 in detecting malwares or a malware attack. The memory 205 may be communicatively coupled to the processor 203 and may store data 207. In an embodiment, the data 207 may include, without limiting to, the target binary file 111, an assembly code 211, an abstract code 213, a similarity score 215 and other data 217. In some embodiments, the data 207 may be stored within the memory 205 in the form of various data structures. Additionally, the data 207 may be organized using data models, such as relational or hierarchical data models. The other data 217 may include data such as the instruction substitution tables of the historical malwares, predefined separation policies and one or more policy parameters, and other temporary data and files generated while performing various functions of the malware detection system 109. In an embodiment, the target binary file 111 may be an executable and/or installation file corresponding to an application or an update that needs to be deployed on a target device. In an embodiment, the assembly code 211 may be the low-level program code corresponding to the target binary file 111. In an embodiment, the abstract code 213 may be obtained by replacing each register variable in the assembly code 211 with a generic representative variable such as ‘reg’. In an embodiment, the similarly score may be computed by comparing the abstract code 213 of the target binary file 111 with one or more representative abstract codes 213 corresponding to the one or more historical malwares. That is, the similarity score 215 of the target binary file 111 may indicate the similarity between the application corresponding to the target binary file 111 and a malware that is already encountered by the IoT devices 101. Thus, the similarity score 215 helps in deciding whether the application corresponding to the target binary file 111 is a malware. In an embodiment, each of the data 207 stored in the memory 205 may be processed by one or more modules 209 configured in the malware detection system 109. In one implementation, the one or more modules 209 may be configured as a part of the processor 203. In another implementation, the one or more modules 209 may be configured external to the processor 203 and may be communicatively coupled to the processor 203. In an embodiment, the one or more modules 209 may include, without limiting to, a conversion module 221, an abstraction module 223, an assigning module 225, a deep scan model 227 and other modules 229. As used herein, the term module may refer to an Application Specific Integrated Circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group) or a memory that execute one or more software or firmware programs, a combinational logic circuit, a hardware component and/or other suitable components that provide the described functionality. In an embodiment, the other modules 229 may be used to perform various miscellaneous functionalities of the malware detection system 109. It will be appreciated that the one or more modules 209 may be represented as a single module or a combination of different modules. In an embodiment, the conversion module 221 may be configured for converting the target binary file 111 into the corresponding assembly code 211. In other words, the conversion module 221 may be a disassembler unit that disassembles the high-level target binary file 111 into the corresponding low-level assembly code 211. In an embodiment, the abstraction module 223 may be configured for generating the abstract code 213 corresponding to the assembly code 211 of the target binary file 111. The abstract code 213 may be generated by replacing each register variable in the assembly code 211 with more generic, predefined representative variable names. The process of generating the abstract code 213 corresponding to the assembly code 211 is illustrated with the representation of FIGS. 3A-3D. FIG. 3A shows an exemplary representation of the instruction substitution table of one or more metamorphic and/or historical malwares m_1, m_2, … m _n. These instruction substitution tables may be retried from a knowledge database or a storage unit associated with the malware detection system 109. Further, each row in the instruction substitution table may include an assembly instruction and its variations. As an example, the first row of the instruction substitution table of malware m_1 shown in FIG. 3A may represent the following assembly instruction: mov eax, #8 …. (1) In the above instruction, there is only one register variable ‘eax’. In order to create an abstract code 213 corresponding to this instruction, the register variable ‘eax’ may be assigned with a generic representative variable ‘reg’. Further, a constraint for summing the immediate values may be assigned, such that the sum of the immediate values may add up to the left-hand side of the instruction. That is, following variables may be updated in the abstraction module 223: No. of registers used = 1 Replacement variable = eax  reg Replacement constraint = When the above abstraction logic is applied to the assembly code 211 of equation (1), the following abstract code 213 may be obtained: mov reg, #V0 …. (2) Similarly, consider an instruction having two register variables: mov eax, ebx  push ebx pop eax In order to create an abstract code 213 for the above assembly instruction, the registers ‘eax’ and ‘ebx’ may be assigned with generic representative variables ‘reg1’ and ‘reg2’. In an embodiment, no constraint may be applied for the instructions of the type: mov . Accordingly, the abstraction module 223 may be updated with the following: No. of registers used = 1 Replacement variables = eax  reg1 & ebx  reg2 Thus, the resultant abstract code 213 may be as shown below: mov reg1, reg2  push reg2 pop reg1 Similarly, each assembly instruction in the instruction substitution table may be obtained by replacing the register variables with generic variables and values V0, V1, … Vn. FIG. 3B shows the abstract code 213 generated for each assembly code 211 in each row of the instruction substitution table of FIG. 3A. In an embodiment, abstraction of the instructions in the assembly code 211 may be performed in a sequential order, that is, one instructions at a time. Further, at the end of abstraction of each assembly instruction, the abstraction module 223 may refer to a matching instruction sequence from the abstract code 213. As shown in FIGS. 3C and 3D, the abstract code 213 corresponding to the assembly instruction may be generated only when there is a matching register variable in the instruction substitution table. That is, abstraction process may disregard the specific register and consider any generic register, before matching with the existing substitution tables, as shown in FIGS. 3C and 3D. In an embodiment, the instruction substitution may be implemented as a finite state machine, in which partial match of a substituted instruction may be maintained as state transitions. In an embodiment, the assigning module 225 may be configured for assigning a similarity score 215 for the target binary file 111 by comparing the abstract code 213 with the one or more reference abstract codes 213 corresponding to the one or more historical malwares identified by the malware detection system 109. In an embodiment, the factors and/or parameters that contribute to the scoring may include, without limiting to, the number of matching code snippets, the instruction length of the matching snippet and the weight of the matching snippet. In other words, the similarity score 215 may be computing using the function indicated in equation (3) below: Similarity score=∑_i^n▒〖Wi*LSi … (3)〗 Where: ‘n’ = Number of matching snippers ‘Wi’ = Weight of each matching snippet ‘LSi’ = Instruction length of each matching snippet In an embodiment, if the similarity score 215 of the target binary file 111 is less than a predefined lower threshold, then the application corresponding to the target binary file 111 may be classified as a non-malware. On the contrary, if the score of the new software is more than a predefined higher threshold, then the application corresponding to the target binary file 111 may be classified as the malware. However, if the score lies between the predefined lower threshold and the predefined higher threshold, then the application corresponding to the target binary file 111 may be passed to the deep scan model 227 for further analysis. In an embodiment, the assigning module 225 may be configured in a substation filter (to be explained with FIG. 4) in the malware detection system 109, as a fast and first-level malware detection functionality. In an embodiment, the deep scan model 227 may be configured for classifying the target binary file 111 as a malware or a non-malware based on the similarity score 215 for the target binary file 111, especially when the similarity score 215 for the target binary file 111 lies between the lower threshold value and the upper threshold value. In other words, the deep scan model 227 may be provoked when the fast substitution filter cannot decide whether the application corresponding to the target binary file 111 is a malware or a non-malware based on the similarity score 215. Thus, the deep scan model 227 may be considered as the second-level analysis, which is activated when the substitution filter cannot solely classify the application. A detailed overview of the deep scan model 227 is provided along with the description of FIG. 4C. FIG. 4A provides an overview and/or summarizes the method of malware detection using the substitution filter 401 and the deep scan model 227 in accordance with some embodiments of the present disclosure. In an embodiment, the substation filter may compare the abstract code 213 corresponding to the target binary file 111 with one or more representative abstract codes 213 of the historical malwares to compute a similarity score 215 for the target binary file 111. When the similarity score 215 is higher than the predefined higher threshold score, that is, when the similarity score 215 if very high, the application corresponding to the target binary file 111 is classified as a malware, as shown in block 403. Similarly, when the similarity score 215 is lower than the predefined lower threshold score, that is, when the similarity score 215 if low, the application corresponding to the target binary file 111 may be classified as a non-malware, as shown in block 405. However, when the similarity score 215 lies between the higher threshold and the lower threshold (i.e., partial decision), the substitution filter 401 may pass the similarity score 215 and the target binary file 111 to the deep scan model 227. Thereafter, the deep scan model 227 may analyze the target binary file 111 using a pre-trained artificial intelligent system configured in the malware detection system 109. Based on outcome of the pre-trained artificial intelligent system, the deep scan model 227 may decide the application as a malware or a non-malware, as indicated in blocks 403 and 405 respectively. The working of the substitution filter 401 and the deep scan model 227 and further explained in FIG. 4B and 4C in the subsequent sections of the description. FIG. 4B provides a detailed illustration of a method of detecting malware using the substitution filter 401 in accordance with some embodiments of the present disclosure. In an embodiment, the substitution filter 401 may include a disassembler 407, a normalizer 409, an abstraction unit 411, a storage unit 413 and a scoring unit 415. The disassembler 407 may be used for converting the target binary file 111 into corresponding assembly code 211. The normalizer 409 may be used for normalizing the assembly code 211 before using it for the abstraction. In an embodiment, the normalizer 409 may perform functions including, without limiting to, Dead Code Removal (DC), Program Reordering (PR), Register Renaming (RR) and Instruction Substitution (IS). Among the above functionalities, the Instruction Substitution is a unique functionality of the normalizer 409. In an embodiment, the abstraction unit 411 is used for generating an abstract code 213 for the assembly code 211 generated by the disassembler 407. Further, the abstraction unit 411 may be used for generating representative abstract codes 213 of historical malwares based on information available in the historical substitution tables stored on the storage unit 413. Further, the scoring unit 415 may be used for computing and assigning a similarity score 215 for the target binary file 111 based on the similarity between the abstract code 213 corresponding to the target binary file 111 and the historical malwares. Based on whether the similarity score 215 is higher or lower than the predefined higher and lower threshold scores, the substitution layer classifies the target binary file 111 as one of a malware or non-malware, as shown in block 403 and 405 respectively. FIG. 4C provides a detailed illustration of a method of detecting malware using the deep scan model 227 in accordance with some embodiments of the present disclosure. The deep scan model 227 may include a logical separation unit 421, multi-level separation blocks 423A-423D, and a training model 425. The logical separation unit 421 may be used for logically separating the assembly code 211 corresponding to the target binary file 111 based on predefined separation policies and the one or more policy parameters. Subsequently, the logically separated assembly code 211 may be passed on to the multi-level separation blocks including a sub-block level separation, block level separation, function level separation and program level separation. Separating the assembly codes 211 along these four layers of separation enhances accuracy of the logical separation of the assembly code 211 and thereby enhances accuracy of the classification. In an embodiment, the training model 425 may be a pretrained artificial intelligent system, which is trained with assembly codes 211, representative abstract codes 213 and logically separated blocks of the historical malwares. In other words, the pretrained artificial intelligent system takes as input the logically separated blocks of the assembly code 211 of the target binary file 111 and decides whether the target binary file 111 is similar to the historical malwares. In an embodiment, the storage unit 413 may store all the information related to the historical malwares. The logical separation unit 421 provide the logically separated blocks of assembly code 211 to the pretrained artificial intelligent system for further analysis. The transforming and training unit 429 may fetch the output of the pretrained artificial intelligent module and map it with each level of logical separation indicated in blocks 423A-423D. Finally, based on a correlation between the multi-level separation blocks and the artificial intelligent system, the deep scan model 227 may provide a classification output 431. Here, the classification output 431 may indicate whether the application corresponding to the target binary file 111 is a malware or non-malware. FIG. 5A - 5C illustrate logical separation of the assembly code 211 in accordance with some embodiments of the present disclosure. In an embodiment, the logical separation unit 421 of the deep scan model 227 may comprises a separation engine 501, a policy generation unit 505 and a knowledge base. In an embodiment, the disassembler 407 converts the target binary file 111 into corresponding assembly code 211 and provides it to the logical separation unit 421. At this point, the separation engine 501 in the logical separation unit 421 retrieves an appropriate separation policy 507 from the policy generation unit 505 for logically separating the assembly code 211. In an embodiment, the separation policy 507 used for the separation may be selected based on parameters including, but not limiting to, architecture of a Central Processing Unit (CPU) of the target device 503, hardware and Operating System (OS) information extracted from the target device 503, assembly instruction set, system call semantics, interrupt handler information, register list and the like. In an embodiment, the above information collected from the target device 503 may be referred and matched with corresponding historical information stored in the knowledge database 509 for choosing a correct separation policy 507 for separation of any piece of the assembly code 211. In an embodiment, upon successful completion of the logical separation of the assembly code 211, the separation engine 501 may return the logically separated blocks of the assembly code 211 to the multi-layer and/or multi-level separation functions 423A-423D illustrated in FIG. 4C. Thereafter, the multi-level separation functions 423A-423D run through the logically separated blocks of the assembly code 211 for classifying the target binary file 111 and deciding whether corresponding application is a malware or non-malware. In an embodiment, the classification decision, along with the separation policies and the hardware information of the target device 503, may be stored on the knowledge base as a reference for analyzing new target binary files 111 in the future instances. FIG. 5B provides an exemplary illustration of the logical separation process. In an embodiment, the assembly code 211 received from the disassembler 407 may be a combined set of all the instructions in the target binary file 111. The assembly code 211 may not reveal and/or distinguish different logical flows embedded in the target binary file 111. Logical separation of the assembly code 211 helps in identifying and distinguishing multiple logical flows and/or logical contexts in the assembly code 211. As an example, the assembly code 211 may be analyzed using appropriate separation policies and policy parameters 507 selected based on the hardware information of the target device 503 and segregated into multiple blocks of instructions as shown in 513A. Here, the instructions within each block of the stack 513A may be linked by a common logical context and hence may be grouped into distinct blocks. Further, each block in the stack 513A may be re-arranged into the logically separated blocks as represented by the stack 513B. As an example, all the instructions that involve operation on the registers ‘eax’, ‘ebx’ and ‘ecx’ may be segregated into a single logical flow, since these operations are performed in a sequential order. Similarly, the operations involving the registers ‘eax’ and ‘edx’ may be treated as having a separate context of operation and may be grouped in a separate logical block (highlighted in green). Thus, the assembly code 211 may be logically separated and grouped into two logical blocks indicated by stack 513B of FIG. 5B. In an embodiment, the logical separation of the assembly code 211 may be performed according to the following rules: Start new logical context at the base of an assemble basic block based on semantics of the assembly cod Track each general-purpose register as a new thread branch 515 Start a new thread branch 515 if a register is used and stop of defined The above separation rules may be applied to each instruction in the assembly code 211 to obtain a thread branch 515corresponding to each register in the assembly code 211. An exemplary thread branch 515 corresponding to the assembly code 211 is depicted in FIG. 5C. Here, the assembly code 211 may be logically separated into two blocks based on the hint that applying the separation policy 507 on each instruction in the assembly code 211 results in two disconnected logical thread branches. As an example, a predefined separation policy 507 that defines an action corresponding to various types of instructions in the assembly code 211 may be as listed in the following table – Table A. Instruction type Action mov immediate Stop register thread mov r1, r2 Continue register thread with r2 airth./logic operands: r1, r2 Fork two register threads r1 and r2 pop r Suspend reg thread with r push r Resume reg thread with r load r mem Stop reg thread, start mem thread store mem r Stop mem thread if active and start reg thread sys inst. (like software interrupt) Start reg threads on regs given by separation policy Table A: Snapshot of separation engine actions on instruction types Additionally, the separation policy 507 of the proposed disclosure is designed in accordance with the fact that the neighboring instructions in the raw assembly code 211 are not the actual or original logical neighbors of the target instruction. For instance, if the same code compiles with a different compiler or with a different compiler optimization setting, then these neighbors may not be consistent. Also, in the existing techniques, this fine grain noise of the raw assembly code 211 is passed as an input to the first level transformation layer, which is block level embedding, the most basic encoding itself may be erroneous and the error may even propagate to the higher transformation layers. This, in turn, may corrupt the higher transformation layers as well as the output encoding of the entire assembly code 211. The proposed separation policy 507 handles this erroneous possibility, by extracting the logical neighbors. If the logical neighbors are extracted, then any compiler or compiler optimization setting may not change the actual logical flow neighbors and hence the logical neighbors remain consistent. Thus, the encoding on the first transformer layer itself may be very concrete and accurate and the same may propagate to the higher, more abstract layers of transformation, increasing the encoding accuracy. In an embodiment, the accurate segregation of the assembly code 211 into respective logical blocks helps in assigning a most accurate similarity score 215 for the target binary file 111, which in turn, helps in accurate detection of the malwares. FIG. 6 shows a flowchart illustrating a method of detecting malwares in accordance with some embodiments of the present disclosure. As illustrated in FIG. 6, the method 600 includes one or more blocks illustrating method for detecting malwares using a malware detection system 109 shown in FIG. 1B. The method 600 may be described in the general context of computer executable instructions. Generally, the computer executable instructions may include routines, programs, objects, components, data structures, procedures, modules, and functions, which perform specific functions or implement specific abstract data types. The order in which the method 600 is described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any order to implement the method. Additionally, individual blocks may be deleted from the method without departing from the scope of the subject matter described herein. Furthermore, these methods may be implemented in any suitable hardware, software, firmware, or combination thereof. At block 601, the method 600 includes converting, by the malware detection system 109, a target binary file 111 into a corresponding assembly code 211. The target binary file 111 may correspond to an application to be deployed in a target device 503. At block 603, the method 600 includes generating, by the malware detection system 109, an abstract code 213 corresponding to the assembly code 211. In an embodiment, the abstract code 213 may be generated by replacing registers in the assembly code 211 with predefined representative variable names. At block 605, the method 600 includes assigning, by the malware detection system 109, a similarity score 215 for the target binary file 111 by comparing the abstract code 213 with one or more reference abstract codes 213 corresponding to one or more historical malwares identified by the malware detection system 109. In an embodiment, the similarity score 215 for the target binary file 111 may be assigned based on one or more scoring parameters including at least one of number of matching code snippets in the abstract code 213, instruction length of the matching code snippets, and weight of the matching code snippets. At block 607, the method 600 includes classifying, by the malware detection system 109, the target binary file 111 as a malware when the similarity score 215 for the target binary file 111 is greater than a first threshold score. In an embodiment, classifying the target binary file 111 may include classifying the target binary file 111 as a non-malware when the similarity score 215 for the target binary file 111 is less than a second threshold score. Alternatively, the target binary file 111 may be classifies as a probable malware when the similarity score 215 for the target binary file 111 is less than the first threshold score and greater than the second threshold score. In an embodiment, the target binary file 111 may be transmitted to and deployed on the target device 503 when the target binary file 111 is classified as the non-malware. On the other hand, a deep-scan classification may be performed on the abstract code 213 of the target binary file 111 when the target binary file 111 is classified as the probable malware. In an embodiment, the deep-scan classification may be performed by segregating the assembly code 211 of the target binary file 111 into one or more logical groups based on predefined separation policies. Each of the one or more logical groups may include one or more related assembly instructions. Once the assembly code 211 is segregated, each of the one or more logical groups may be compared with one or more reference logical groups corresponding to the one or more historical malwares. Subsequently, the target binary file 111 may be classified as the malware when the one or more logical groups match with the one or more reference logical groups. In an embodiment, the deep-scan classification may be performed using a pretrained artificial intelligent system, trained using assembly code 211 of the one or more historical malwares detected by the malware detection system 109. In an embodiment, the predefined separation policies may be generated based on one or more policy parameters of the target device 503. As an example, the one or more policy parameters may include, without limiting to, at least one of Operating System (OS) information of the target device 503, assembly instruction set of the target device 503, processor architecture of the target device 503, system call semantics, interrupt handler information and register list of the target device 503. Computer System FIG. 7 illustrates a block diagram of an exemplary computer system 700 for implementing embodiments consistent with the present disclosure. In an embodiment, the computer system 700 may be a malware detection system 109 shown in FIG. 1B, which may be used for malware or malware attack in an IoT environment. The computer system 700 may include a central processing unit (“CPU” or “processor”) 702. The processor 702 may comprise at least one data processor for executing program components for executing user- or system-generated business processes. A user may include a network operator, a user/owner of the IoT devices 101, a service provider and the like. The processor 702 may include specialized processing units such as integrated system (bus) controllers, memory management control units, floating point units, graphics processing units, digital signal processing units, etc. The processor 702 may be disposed in communication with one or more input/output (I/O) devices (711 and 712) via I/O interface 701. The I/O interface 701 may employ communication protocols/methods such as, without limitation, audio, analog, digital, stereo, IEEE-1394, serial bus, Universal Serial Bus (USB), infrared, PS/2, BNC, coaxial, component, composite, Digital Visual Interface (DVI), high-definition multimedia interface (HDMI), Radio Frequency (RF) antennas, S-Video, Video Graphics Array (VGA), IEEE 802.n /b/g/n/x, Bluetooth, cellular (e.g., Code-Division Multiple Access (CDMA), High-Speed Packet Access (HSPA+), Global System For Mobile Communications (GSM), Long-Term Evolution (LTE) or the like), etc. Using the I/O interface 701, the computer system 700 may communicate with one or more I/O devices 711 and 712. In some embodiments, the processor 702 may be disposed in communication with a communication network 709 via a network interface 703. The network interface 703 may communicate with the communication network 709. The network interface 703 may employ connection protocols including, without limitation, direct connect, Ethernet (e.g., twisted pair 10/100/1000 Base T), Transmission Control Protocol/Internet Protocol (TCP/IP), token ring, IEEE 802.11a/b/g/n/x, etc. Using the network interface 703 and the communication network 709, the computer system 700 may be communicatively associated with an external network for receiving a target binary file 111 which needs to be installed on one of the target IoT edge devices 503. Further, the computer system may use the communication network 709 to connect to the target device 503 on which a software update in the form of the target binary file 111 needs to be configured. In an implementation, the communication network 709 may be implemented as one of the several types of networks, such as intranet or Local Area Network (LAN) and such within the organization. The communication network 709 may either be a dedicated network or a shared network, which represents an association of several types of networks that use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP), Transmission Control Protocol/Internet Protocol (TCP/IP), Wireless Application Protocol (WAP), etc., to communicate with each other. Further, the communication network 709 may include a variety of network devices, including routers, bridges, servers, computing devices, storage devices, etc. In some embodiments, the processor 702 may be disposed in communication with a memory 705 (e.g., RAM 713, ROM 714, etc. as shown in FIG. 7) via a storage interface 704. The storage interface 704 may connect to memory 705 including, without limitation, memory drives, removable disc drives, etc., employing connection protocols such as Serial Advanced Technology Attachment (SATA), Integrated Drive Electronics (IDE), IEEE-1394, Universal Serial Bus (USB), fiber channel, Small Computer Systems Interface (SCSI), etc. The memory drives may further include a drum, magnetic disc drive, magneto-optical drive, optical drive, Redundant Array of Independent Discs (RAID), solid-state memory devices, solid-state drives, etc. The memory 705 may store a collection of program or database components, including, without limitation, user/application interface 706, an operating system 707, a web browser 708, and the like. In some embodiments, computer system 700 may store user/application data 706, such as the data, variables, records, etc. as described in this disclosure. Such databases may be implemented as fault-tolerant, relational, scalable, secure databases such as Oracle® or Sybase®. The operating system 707 may facilitate resource management and operation of the computer system 700. Examples of operating systems include, without limitation, APPLE® MACINTOSH® OS X®, UNIX®, UNIX-like system distributions (E.G., BERKELEY SOFTWARE DISTRIBUTION® (BSD), FREEBSD®, NETBSD®, OPENBSD, etc.), LINUX® DISTRIBUTIONS (E.G., RED HAT®, UBUNTU®, KUBUNTU®, etc.), IBM® OS/2®, MICROSOFT® WINDOWS® (XP®, VISTA®/7/8, 10 etc.), APPLE® IOS®, GOOGLETM ANDROIDTM, BLACKBERRY® OS , or the like. The user interface 706 may facilitate display, execution, interaction, manipulation, or operation of program components through textual or graphical facilities. For example, the user interface 706 may provide computer interaction interface elements on a display system operatively connected to the computer system 700, such as cursors, icons, check boxes, menus, scrollers, windows, widgets, and the like. Further, Graphical User Interfaces (GUIs) may be employed, including, without limitation, APPLE® MACINTOSH® operating systems’ Aqua®, IBM® OS/2®, MICROSOFT® WINDOWS® (e.g., Aero, Metro, etc.), web interface libraries (e.g., ActiveX®, JAVA®, JAVASCRIPT®, AJAX, HTML, ADOBE® FLASH®, etc.), or the like. The web browser 708 may be a hypertext viewing application. Secure web browsing may be provided using Secure Hypertext Transport Protocol (HTTPS), Secure Sockets Layer (SSL), Transport Layer Security (TLS), and the like. The web browsers 708 may utilize facilities such as AJAX, DHTML, ADOBE® FLASH®, JAVASCRIPT®, JAVA®, Application Programming Interfaces (APIs), and the like. Further, the computer system 700 may implement a mail server stored program component. The mail server may utilize facilities such as ASP, ACTIVEX®, ANSI® C++/C#, MICROSOFT®, .NET, CGI SCRIPTS, JAVA®, JAVASCRIPT®, PERL®, PHP, PYTHON®, WEBOBJECTS®, etc. The mail server may utilize communication protocols such as Internet Message Access Protocol (IMAP), Messaging Application Programming Interface (MAPI), MICROSOFT® exchange, Post Office Protocol (POP), Simple Mail Transfer Protocol (SMTP), or the like. In some embodiments, the computer system 700 may implement a mail client stored program component. The mail client may be a mail viewing application, such as APPLE® MAIL, MICROSOFT® ENTOURAGE®, MICROSOFT® OUTLOOK®, MOZILLA® THUNDERBIRD®, and the like. Furthermore, one or more computer-readable storage media may be utilized in implementing embodiments consistent with the present disclosure. A computer-readable storage medium refers to any type of physical memory on which information or data readable by a processor may be stored. Thus, a computer-readable storage medium may store instructions for execution by one or more processors, including instructions for causing the processor(s) to perform steps or stages consistent with the embodiments described herein. The term “computer-readable medium” should be understood to include tangible items and exclude carrier waves and transient signals, that is, non-transitory. Examples include Random Access Memory (RAM), Read-Only Memory (ROM), volatile memory, nonvolatile memory, hard drives, Compact Disc (CD) ROMs, Digital Video Disc (DVDs), flash drives, disks, and any other known physical storage media. Advantages of the embodiment of the present disclosure are illustrated herein. In an embodiment, the present disclosure discloses a method for detecting a probable malware attack in an IoT environment. In an embodiment, the method of present disclosure helps in enhancing security of the IoT platform and edge devices deployed in the IoT platform by accurately detecting and preventing malware attack on the edge devices. In an embodiment, the method of present disclosure performs precise encoding of the assembly instructions using hardware information for the logical separation, thereby achieving higher accuracy in malware detection. In an embodiment, the malware detection mechanism of the present disclosure may also be realized in any computing device, other than the IoT edge devices or IoT gateways, before uploading and deploying the malware detection mechanism into the target IoT edge device. The terms "an embodiment", "embodiment", "embodiments", "the embodiment", "the embodiments", "one or more embodiments", "some embodiments", and "one embodiment" mean "one or more (but not all) embodiments of the invention(s)" unless expressly specified otherwise. The terms "including", "comprising", “having” and variations thereof mean "including but not limited to", unless expressly specified otherwise. The enumerated listing of items does not imply that any or all the items are mutually exclusive, unless expressly specified otherwise. The terms "a", "an" and "the" mean "one or more", unless expressly specified otherwise. A description of an embodiment with several components in communication with each other does not imply that all such components are required. On the contrary, a variety of optional components are described to illustrate the wide variety of possible embodiments of the invention. When a single device or article is described herein, it will be clear that more than one device/article (whether they cooperate) may be used in place of a single device/article. Similarly, where more than one device or article is described herein (whether they cooperate), it will be clear that a single device/article may be used in place of the more than one device or article or a different number of devices/articles may be used instead of the shown number of devices or programs. The functionality and/or the features of a device may be alternatively embodied by one or more other devices which are not explicitly described as having such functionality/features. Thus, other embodiments of the invention need not include the device itself. Finally, the language used in the specification has been principally selected for readability and instructional purposes, and it may not have been selected to delineate or circumscribe the inventive subject matter. It is therefore intended that the scope of the invention be limited not by this detailed description, but rather by any claims that issue on an application based here on. Accordingly, the embodiments of the present invention are intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims. While various aspects and embodiments have been disclosed herein, other aspects and embodiments will be apparent to those skilled in the art. The various aspects and embodiments disclosed herein are for purposes of illustration and are not intended to be limiting, with the true scope and spirit being indicated by the following claims. Referral Numerals: Reference Number Description 100A, 100B IoT environment 101 IoT devices 103 IoT Gateways 105 Data centers 107 Surface attack 107’ Attack propagation 109 Malware detection system 111 Target binary file 113 Malware classification 201 I/O interface 203 Processor 205 Memory 207 Data 209 Modules 211 Assembly code 213 Abstract code 215 Similarity score 217 Other data 221 Conversion module 223 Abstraction module 225 Assigning module 227 Deep scan model 229 Other modules 305 Matching sequence 401 Substitution filter 407 Disassembler 409 Normalizer 411 Abstraction unit 413 Storage unit 415 Scoring unit 421 Logical separation unit 423A-423D Multi-level transformation 425 Training model 429 Transforming and Training unit 431 Classification output 501 Separation engine 503 Target device 505 Policy generation unit 507 Separation policy 509 Knowledge database 515 Thread branch 700 Exemplary computer system 701 I/O Interface of the exemplary computer system 702 Processor of the exemplary computer system 703 Network interface 704 Storage interface 705 Memory of the exemplary computer system 706 User/Application 707 Operating system 708 Web browser 709 Communication network 711 Input devices 712 Output devices 713 RAM 714 ROM

Claims:WE CLAIM:

1. A method of detecting malwares, the method comprising:
converting, by a malware detection system, a target binary file into a corresponding assembly code, wherein the target binary file corresponds to an application to be deployed in a target device;
generating, by the malware detection system, an abstract code corresponding to the assembly code by replacing registers in the assembly code with predefined representative variable names;
assigning, by the malware detection system, a similarity score for the target binary file by comparing the abstract code with one or more reference abstract codes corresponding to one or more historical malwares identified by the malware detection system; and
classifying, by the malware detection system, the target binary file as a malware when the similarity score for the target binary file is greater than a first threshold score.

2. The method as claimed in claim 1, wherein the similarity score for the target binary file is assigned based on one or more scoring parameters including at least one of number of matching code snippets in the abstract code, instruction length of the matching code snippets, and weight of the matching code snippets.

3. The method as claimed in claim 1, wherein classifying the target binary file comprises:
classifying the target binary file as a non-malware when the similarity score for the target binary file is less than a second threshold score; or
classifying the target binary file as a probable malware when the similarity score for the target binary file is less than the first threshold score and greater than the second threshold score.

4. The method as claimed in claim 2 comprises:
transmitting and deploying the target binary file on the target device when the target binary file is classified as the non-malware.

5. The method as claimed in claim 2 comprises:
performing a deep-scan classification on the abstract code of the target binary file when the target binary file is classified as the probable malware.

6. The method as claimed in claim 5, wherein performing the deep-scan classification comprises:
segregating the assembly code of the target binary file into one or more logical groups based on predefined separation policies, wherein each of the one or more logical groups include one or more related assembly instructions;
comparing each of the one or more logical groups with one or more reference logical groups corresponding to the one or more historical malwares; and
classifying the target binary file as the malware when the one or more logical groups match with the one or more reference logical groups.

7. The method as claimed in claim 6, wherein the predefined separation policies are generated based on one or more policy parameters of the target device.

8. The method as claimed in claim 7, wherein the one or more policy parameters comprise at least one of, Operating System (OS) information of the target device, assembly instruction set of the target device, processor architecture of the target device, system call semantics, interrupt handler information and register list of the target device.

9. The method as claimed in claim 6, wherein the deep-scan classification is performed using a pretrained artificial intelligent system, trained using assembly code of the one or more historical malwares detected by the malware detection system.

10. A malware detection system for detecting malwares, the malware detection system comprising:
a processor; and
a memory, communicatively coupled to the processor, wherein the memory stores processor-executable instructions, which on execution, cause the processor to:
convert a target binary file into a corresponding assembly code, wherein the target binary file corresponds to an application to be deployed in a target device;
generate an abstract code corresponding to the assembly code by replacing registers in the assembly code with predefined representative variable names;
assign a similarity score for the target binary file by comparing the abstract code with one or more reference abstract codes corresponding to one or more historical malwares identified by the malware detection system; and
classify the target binary file as a malware when the similarity score for the target binary file is greater than a first threshold score.

11. The malware detection system as claimed in claim 10, wherein the processor assigns the similarity score for the target binary file based on one or more scoring parameters including at least one of number of matching code snippets in the abstract code, instruction length of the matching code snippets, and weight of the matching code snippets.

12. The malware detection system as claimed in claim 10, wherein the processor classifies the target binary file by:
classifying the target binary file as a non-malware when the similarity score for the target binary file is less than a second threshold score; or
classifying the target binary file as a probable malware when the similarity score for the target binary file is less than the first threshold score and greater than the second threshold score.

13. The malware detection system as claimed in claim 11, wherein the processor is further configured to:
transmit and deploy the target binary file on the target device when the target binary file is classified as the non-malware.

14. The malware detection system as claimed in claim 11, wherein the processor is further configured to:
perform a deep-scan classification on the abstract code of the target binary file when the target binary file is classified as the probable malware.
15. The malware detection system as claimed in claim 14, wherein the processor performs the deep-scan classification by:
segregating the assembly code of the target binary file into one or more logical groups based on predefined separation policies, wherein each of the one or more logical groups include one or more related assembly instructions;
comparing each of the one or more logical groups with one or more reference logical groups corresponding to the one or more historical malwares; and
classifying the target binary file as the malware when the one or more logical groups match with the one or more reference logical groups.

16. The malware detection system as claimed in claim 15, wherein the processor generates the predefined separation policies based on one or more policy parameters of the target device.

17. The malware detection system as claimed in claim 15, wherein the one or more policy parameters comprise at least one of, Operating System (OS) information of the target device, assembly instruction set of the target device, processor architecture of the target device, system call semantics, interrupt handler information and register list of the target device.

18. The malware detection system as claimed in claim 16, wherein the processor performs the deep-scan classification using a pretrained artificial intelligent system, trained using assembly code of the one or more historical malwares detected by the malware detection system.

Dated this 21st day of July, 2020
R. Ramya Rao
IN/PA-1607
Of K & S Partners
Agent for the Applicant
 
, Description:TECHNICAL FIELD
The present subject matter is, in general, related to Internet of Things (IoT) and more particularly, but not exclusively, to a method and system for detecting malwares in an IoT environment.

BACKGROUND
Generally, an IoT environment includes edge devices and cloud servers or data centers that are connected by network gateways. The edge devices are installed with software applications that perform predefined functions. The software applications installed on the edge devices are updated using Over the Air (OTA) updates. In other words, the software applications running on these edge devices are updated remotely.

In the existing systems, the updates for the software applications are scanned for presence of malware or virus at a base server before transmitting the updates to the edge devices as an OTA update. However, presently there is no malware detection mechanism employed at the edge devices. So, the edge devices may fail to detect if an incoming binary for update of the software application is a malware. Also, malwares take an advantage of the fact that they can change their signatures to deceive a signature-based malware detection mechanism which may be employed in the edge devices.

Further, in the case of anomaly-based malware detection mechanism, unlike domains like network intrusion detection, there is no well-defined mechanism for distinguishing anomalies and normal binaries. Hence, it would be desirable to have an appropriate encoding scheme to detect and represent the anomalous applications.

The information disclosed in this background of the disclosure section is only for enhancement of understanding of the general background of the invention and should not be taken as an acknowledgement or any form of suggestion that this information forms the prior art already known to a person skilled in the art.

SUMMARY
One or more shortcomings of the prior art may be overcome, and additional advantages may be provided through the present disclosure. Additional features and advantages may be realized through the techniques of the present disclosure. Other embodiments and aspects of the disclosure are described in detail herein and are considered a part of the claimed disclosure.

Disclosed herein is a method for detecting malwares. The method comprises converting a target binary file into a corresponding assembly code. The target binary file corresponds to an application to be deployed in a target device. Further, the method comprises generating an abstract code corresponding to the assembly code by replacing registers in the assembly code with predefined representative variable names. Upon generating the abstract code, the method comprises assigning a similarity score for the target binary file by comparing the abstract code with one or more reference abstract codes corresponding to one or more historical malwares identified by the malware detection system. Finally, the method comprises classifying the target binary file as a malware when the similarity score for the target binary file is greater than a first threshold score.

Further, the present disclosure relates to a malware detection system for detecting malwares. The malware detection system comprises a processor and a memory. The memory is communicatively coupled to the processor and stores processor-executable instructions, which on execution, cause the processor to convert a target binary file into a corresponding assembly code, wherein the target binary file corresponds to an application to be deployed in a target device. Further, the instructions cause the processor to generate an abstract code corresponding to the assembly code by replacing registers in the assembly code with predefined representative variable names. Upon generating the abstract code, the instructions cause the processor to assign a similarity score for the target binary file by comparing the abstract code with one or more reference abstract codes corresponding to one or more historical malwares identified by the malware detection system. Finally, the instructions cause the processor to classify the target binary file as a malware when the similarity score for the target binary file is greater than a first threshold score.

The foregoing summary is illustrative only and is not intended to be in any way limiting. In addition to the illustrative aspects, embodiments, and features described above, further aspects, embodiments, and features will become apparent by reference to the drawings and the following detailed description.

BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS
The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate exemplary embodiments and, together with the description, explain the disclosed principles. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the figures to reference like features and components. Some embodiments of system and/or methods in accordance with embodiments of the present subject matter are now described, by way of example only, and regarding the accompanying figures, in which:

FIG. 1A and 1B illustrate an exemplary IoT environment and detection of malware in accordance with some embodiments of the present disclosure.

FIG. 2 shows a detailed block diagram illustrating a malware detection system in accordance with some embodiments of the present disclosure.

FIG. 3A – 3D illustrate abstraction of assembly code into corresponding abstract code in accordance with some embodiments of the present disclosure.

FIG. 4A summarizes the method of malware detection using a substitution filter and a deep scan model in accordance with some embodiments of the present disclosure.

FIG. 4B provides a detailed illustration of a method of detecting malware using the substitution filter in accordance with some embodiments of the present disclosure.

FIG. 4C provides a detailed illustration of a method of detecting malware using the deep scan model in accordance with some embodiments of the present disclosure.

FIG. 5A - 5C illustrate a method of logically separating the assembly code in accordance with some embodiments of the present disclosure.

FIG. 6 illustrates a method of detecting malware in accordance with some embodiments of the present disclosure.

FIG. 7 illustrates a block diagram of an exemplary computer system for implementing embodiments consistent with the present disclosure.

It should be appreciated by those skilled in the art that any block diagrams herein represent conceptual views of illustrative systems embodying the principles of the present subject matter. Similarly, it will be appreciated that any flow charts, flow diagrams, state transition diagrams, pseudo code, and the like represent various processes which may be substantially represented in computer readable medium and executed by a computer or processor, whether such computer or processor is explicitly shown.

DETAILED DESCRIPTION
In the present disclosure, the word "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any embodiment or implementation of the present subject matter described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments.
While the disclosure is susceptible to various modifications and alternative forms, specific embodiment thereof has been shown by way of example in the drawings and will be described in detail below. It should be understood, however that it is not intended to limit the disclosure to the specific forms disclosed, but on the contrary, the disclosure is to cover all modifications, equivalents, and alternative falling within the scope of the disclosure.
The terms “comprises”, “comprising”, “includes”, or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a setup, device, or method that comprises a list of components or steps does not include only those components or steps but may include other components or steps not expressly listed or inherent to such setup or device or method. In other words, one or more elements in a system or apparatus proceeded by “comprises… a” does not, without more constraints, preclude the existence of other elements or additional elements in the system or method.
The present disclosure relates to a method and a malware detection system for detecting malwares. In an embodiment, the method discloses converting a target binary file into a corresponding assembly code. The target binary file corresponds to an application to be deployed in a target device. Further, the method comprises generating an abstract code corresponding to the assembly code by replacing registers in the assembly code with predefined representative variable names. Upon generating the abstract code, the method comprises assigning a similarity score for the target binary file by comparing the abstract code with one or more reference abstract codes corresponding to one or more historical malwares identified by the malware detection system. Finally, the method comprises classifying the target binary file as a malware when the similarity score for the target binary file is greater than a first threshold score.
One of the differences between the existing techniques and the method of present disclosure is that the existing techniques operate with an assumption that metamorphic engine is in the open and not morphed, such that an instruction substitution table used by a morphing engine may be available to view the substitutions. However, in real practice, the morphing engine, along with malware payload, are obfuscated. As a result, it will not be possible to retrieve the substitution table of the suspicious software. Ideally, a normalizer consists of four components, namely Dead Code Removal (DC), Program Reordering (PR), Register Renaming (RR) and Instruction Substitution (IS). However, the existing techniques assume that the normalizer will have the substitution tables in the database and therefore, IS unit is not required in the Normalizer.
Other existing techniques involve encoding raw assembly instruction of a target binary. However, the encoding of the raw assembly instructions may not be accurate, because the encoding of each instruction observes its logical neighbours to come up with a representation of itself with respect to logical neighbours. Hence, in the raw assembly code, the control order might not be the logical order of the instructions due to the optimizations done by the compilers. Such logical neighbours may be extracted for each instruction by merely looking at the processor architecture on which the binary is intended to be executed.
On the other hand, the proposed method of malware detection takes into consideration the substitution table of the known malwares captured earlier by the system. These substitution tables are abstracted. During the abstraction, representative variables are assigned to the registers used in the assembly code of the substitution tables. Subsequently, the assembly code of a new software is also abstracted by replacing the specific registers with representative variable names. Then, the abstracted code of the new software is compared with the abstracted substitution tables and a score is generated. Based on the score, the new software is classified as either a malware or not. Additionally, if there is a grey zone in the classification, such that the score is not confident enough to decide whether it is a malware or not, then a deep scan is done. Thus, the proposed method of malware detection helps in accurate and faster malware detection.
In the following detailed description of the embodiments of the disclosure, reference is made to the accompanying drawings that form a part hereof, and in which are shown by way of illustration specific embodiments in which the disclosure may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the disclosure, and it is to be understood that other embodiments may be utilized and that changes may be made without departing from the scope of the present disclosure. The following description is, therefore, not to be taken in a limiting sense.

FIG. 1A illustrates an exemplary IoT environment in accordance with some embodiments of the present disclosure.

As shown in environment 100A, an IoT platform may include one or more IoT devices 101, an IoT gateway 103 and data centers 105. The IoT devices 101 may include, without limiting to, end-user computing devices like smartphones, network gadgets and sensory units. The IoT gateway 103 may be a communication bridge between the IoT devices 101 and the data centers 105. In an embodiment, the data centers 105 may include, without limiting to, servers and warehouses running on a cloud computing platform. In an embodiment, the data centers 105 may provide one or more instructions and updates to the IoT devices 101 through the IoT gateways 103. The IoT devices 101 may perform one or more predefined functions based on the data centers 105 and return resultant information to the data centers 105 through the IoT gateway 103.

In an embodiment, introducing a new application and/or updating an already installed application on the IoT device may be performed by sending Over the Air (OTA) updates to the IoT devices 101. Generally, the OTA updates may be scanned for possible security breaches and malware attacks either at the data centers 105 or at the transmission side. In other words, there may not be any security checking means deployed on the IoT device side. This allows an attacker to introduce malicious data on to the IoT network causing malfunctions at the IoT devices 101. For instance, the attacker may introduce malicious packets on the IoT gateways 103 causing a surface attack 107 at the IoT gateway 103. The surface attacks 107 may tag along the OTA updates and propagate on either side of the network as indicated by arrows 107’. As a result, the IoT devices 101 may find it difficult to differentiate the malwares and the regular OTA updates. Thus, there may be chances that the malwares get introduced in the IoT network, interrupting the functionalities of the IoT devices 101.

In an embodiment, as illustrated in FIG. 1B, the malware detection system 109 proposed in the present disclosure may be used for detecting possible malware attacks on the IoT environment by associating the malware detection system 109 to the IoT environment. In an implementation, the malware detection system 109 may be deployed on the IoT devices 101 for actively detecting and differentiating the malwares from the regular applications and updates. In an alternative implementation, the malware detection system 109 may be implemented on the IoT gateway 103 for monitoring and detecting possible malware attacks on the IoT network on the end-user side.

In an embodiment, whenever an OTA update is transmitted to the IoT devices 101, the malware detection system 109 may retrieve a target binary file 111 corresponding to an application or update to be deployed in the target device from the network. Subsequently, the malware detection system 109 convert the target binary file 111 into a corresponding assembly code. As an example, the target binary code may be an executable data file (i.e., ‘.exe’ file). The assembly code may be a low-level machine-readable file corresponding to the target binary code.

In an embodiment, once the assembly code has been obtained, the malware detection system 109 may generate an abstract code corresponding to the assembly code. In an implementation, the abstract code may be generated by replacing the ‘register’ variables in the assembly code with predefined representative variable names. Upon obtaining the abstract code, the malware detection system 109 may compute and assign a similarity score for the target binary file 111 by comparing the abstract code with one or more reference abstract codes stored in the malware detection system 109. The one or more reference abstract codes may be the abstract codes corresponding to the one or more historical malwares identified by the malware detection system 109. The historical malwares may be the malwares that are previously encountered by the IoT devices 101.

In an embodiment, upon assigning the similarity score for the target binary file 111, the malware detection system 109 may classify the target binary file 111 as at least one of a malware or non-malware based on the similarity score. In an embodiment, the target binary file 111 may be classified as the malware when the similarity score assigned for the target binary file 111 is greater than a first threshold score. Similarly, the target binary file 111 may be classified as the non-malware when the similarity score assigned for the target binary file 111 is less than the first threshold score. In an embodiment, value of the first threshold score may be varied according to sensitivity of the application and level of security check to be implemented on the IoT devices 101.

FIG. 2 shows a detailed block diagram illustrating a malware detection system 109 in accordance with some embodiments of the present disclosure.

In an implementation, the malware detection system 109 may include an I/O interface 201, a processor 203 and a memory 205. The I/O interface 201 may be configured to retrieve a target binary file 111 being transmitted to a target device. Additionally, the I/O interface 201 may be used for retrieving information related to one or more historical malwares from an external storage associated with the malware detection system 109. In an embodiment, the processor 203 may be configured to perform one or more functions of the malware detection system 109 in detecting malwares or a malware attack. The memory 205 may be communicatively coupled to the processor 203 and may store data 207.

In an embodiment, the data 207 may include, without limiting to, the target binary file 111, an assembly code 211, an abstract code 213, a similarity score 215 and other data 217. In some embodiments, the data 207 may be stored within the memory 205 in the form of various data structures. Additionally, the data 207 may be organized using data models, such as relational or hierarchical data models. The other data 217 may include data such as the instruction substitution tables of the historical malwares, predefined separation policies and one or more policy parameters, and other temporary data and files generated while performing various functions of the malware detection system 109.

In an embodiment, the target binary file 111 may be an executable and/or installation file corresponding to an application or an update that needs to be deployed on a target device.

In an embodiment, the assembly code 211 may be the low-level program code corresponding to the target binary file 111. In an embodiment, the abstract code 213 may be obtained by replacing each register variable in the assembly code 211 with a generic representative variable such as ‘reg’.

In an embodiment, the similarly score may be computed by comparing the abstract code 213 of the target binary file 111 with one or more representative abstract codes 213 corresponding to the one or more historical malwares. That is, the similarity score 215 of the target binary file 111 may indicate the similarity between the application corresponding to the target binary file 111 and a malware that is already encountered by the IoT devices 101. Thus, the similarity score 215 helps in deciding whether the application corresponding to the target binary file 111 is a malware.

In an embodiment, each of the data 207 stored in the memory 205 may be processed by one or more modules 209 configured in the malware detection system 109. In one implementation, the one or more modules 209 may be configured as a part of the processor 203. In another implementation, the one or more modules 209 may be configured external to the processor 203 and may be communicatively coupled to the processor 203. In an embodiment, the one or more modules 209 may include, without limiting to, a conversion module 221, an abstraction module 223, an assigning module 225, a deep scan model 227 and other modules 229.

As used herein, the term module may refer to an Application Specific Integrated Circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group) or a memory that execute one or more software or firmware programs, a combinational logic circuit, a hardware component and/or other suitable components that provide the described functionality. In an embodiment, the other modules 229 may be used to perform various miscellaneous functionalities of the malware detection system 109. It will be appreciated that the one or more modules 209 may be represented as a single module or a combination of different modules.

In an embodiment, the conversion module 221 may be configured for converting the target binary file 111 into the corresponding assembly code 211. In other words, the conversion module 221 may be a disassembler unit that disassembles the high-level target binary file 111 into the corresponding low-level assembly code 211.

In an embodiment, the abstraction module 223 may be configured for generating the abstract code 213 corresponding to the assembly code 211 of the target binary file 111. The abstract code 213 may be generated by replacing each register variable in the assembly code 211 with more generic, predefined representative variable names. The process of generating the abstract code 213 corresponding to the assembly code 211 is illustrated with the representation of FIGS. 3A-3D.

FIG. 3A shows an exemplary representation of the instruction substitution table of one or more metamorphic and/or historical malwares m_1, m_2, … m _n. These instruction substitution tables may be retried from a knowledge database or a storage unit associated with the malware detection system 109. Further, each row in the instruction substitution table may include an assembly instruction and its variations. As an example, the first row of the instruction substitution table of malware m_1 shown in FIG. 3A may represent the following assembly instruction:
mov eax, #8 …. (1)

In the above instruction, there is only one register variable ‘eax’. In order to create an abstract code 213 corresponding to this instruction, the register variable ‘eax’ may be assigned with a generic representative variable ‘reg’. Further, a constraint for summing the immediate values may be assigned, such that the sum of the immediate values may add up to the left-hand side of the instruction. That is, following variables may be updated in the abstraction module 223:

No. of registers used = 1
Replacement variable = eax  reg
Replacement constraint =

When the above abstraction logic is applied to the assembly code 211 of equation (1), the following abstract code 213 may be obtained:
mov reg, #V0 …. (2)

Similarly, consider an instruction having two register variables:
mov eax, ebx  push ebx
pop eax

In order to create an abstract code 213 for the above assembly instruction, the registers ‘eax’ and ‘ebx’ may be assigned with generic representative variables ‘reg1’ and ‘reg2’. In an embodiment, no constraint may be applied for the instructions of the type: mov . Accordingly, the abstraction module 223 may be updated with the following:
No. of registers used = 1
Replacement variables = eax  reg1 & ebx  reg2
Thus, the resultant abstract code 213 may be as shown below:
mov reg1, reg2  push reg2
pop reg1

Similarly, each assembly instruction in the instruction substitution table may be obtained by replacing the register variables with generic variables and values V0, V1, … Vn. FIG. 3B shows the abstract code 213 generated for each assembly code 211 in each row of the instruction substitution table of FIG. 3A.

In an embodiment, abstraction of the instructions in the assembly code 211 may be performed in a sequential order, that is, one instructions at a time. Further, at the end of abstraction of each assembly instruction, the abstraction module 223 may refer to a matching instruction sequence from the abstract code 213. As shown in FIGS. 3C and 3D, the abstract code 213 corresponding to the assembly instruction may be generated only when there is a matching register variable in the instruction substitution table. That is, abstraction process may disregard the specific register and consider any generic register, before matching with the existing substitution tables, as shown in FIGS. 3C and 3D. In an embodiment, the instruction substitution may be implemented as a finite state machine, in which partial match of a substituted instruction may be maintained as state transitions.

In an embodiment, the assigning module 225 may be configured for assigning a similarity score 215 for the target binary file 111 by comparing the abstract code 213 with the one or more reference abstract codes 213 corresponding to the one or more historical malwares identified by the malware detection system 109. In an embodiment, the factors and/or parameters that contribute to the scoring may include, without limiting to, the number of matching code snippets, the instruction length of the matching snippet and the weight of the matching snippet. In other words, the similarity score 215 may be computing using the function indicated in equation (3) below:

Similarity score=∑_i^n▒〖Wi*LSi … (3)〗

Where:
‘n’ = Number of matching snippers
‘Wi’ = Weight of each matching snippet
‘LSi’ = Instruction length of each matching snippet

In an embodiment, if the similarity score 215 of the target binary file 111 is less than a predefined lower threshold, then the application corresponding to the target binary file 111 may be classified as a non-malware. On the contrary, if the score of the new software is more than a predefined higher threshold, then the application corresponding to the target binary file 111 may be classified as the malware. However, if the score lies between the predefined lower threshold and the predefined higher threshold, then the application corresponding to the target binary file 111 may be passed to the deep scan model 227 for further analysis. In an embodiment, the assigning module 225 may be configured in a substation filter (to be explained with FIG. 4) in the malware detection system 109, as a fast and first-level malware detection functionality.

In an embodiment, the deep scan model 227 may be configured for classifying the target binary file 111 as a malware or a non-malware based on the similarity score 215 for the target binary file 111, especially when the similarity score 215 for the target binary file 111 lies between the lower threshold value and the upper threshold value. In other words, the deep scan model 227 may be provoked when the fast substitution filter cannot decide whether the application corresponding to the target binary file 111 is a malware or a non-malware based on the similarity score 215. Thus, the deep scan model 227 may be considered as the second-level analysis, which is activated when the substitution filter cannot solely classify the application. A detailed overview of the deep scan model 227 is provided along with the description of FIG. 4C.

FIG. 4A provides an overview and/or summarizes the method of malware detection using the substitution filter 401 and the deep scan model 227 in accordance with some embodiments of the present disclosure.

In an embodiment, the substation filter may compare the abstract code 213 corresponding to the target binary file 111 with one or more representative abstract codes 213 of the historical malwares to compute a similarity score 215 for the target binary file 111. When the similarity score 215 is higher than the predefined higher threshold score, that is, when the similarity score 215 if very high, the application corresponding to the target binary file 111 is classified as a malware, as shown in block 403. Similarly, when the similarity score 215 is lower than the predefined lower threshold score, that is, when the similarity score 215 if low, the application corresponding to the target binary file 111 may be classified as a non-malware, as shown in block 405. However, when the similarity score 215 lies between the higher threshold and the lower threshold (i.e., partial decision), the substitution filter 401 may pass the similarity score 215 and the target binary file 111 to the deep scan model 227. Thereafter, the deep scan model 227 may analyze the target binary file 111 using a pre-trained artificial intelligent system configured in the malware detection system 109. Based on outcome of the pre-trained artificial intelligent system, the deep scan model 227 may decide the application as a malware or a non-malware, as indicated in blocks 403 and 405 respectively. The working of the substitution filter 401 and the deep scan model 227 and further explained in FIG. 4B and 4C in the subsequent sections of the description.

FIG. 4B provides a detailed illustration of a method of detecting malware using the substitution filter 401 in accordance with some embodiments of the present disclosure.

In an embodiment, the substitution filter 401 may include a disassembler 407, a normalizer 409, an abstraction unit 411, a storage unit 413 and a scoring unit 415. The disassembler 407 may be used for converting the target binary file 111 into corresponding assembly code 211. The normalizer 409 may be used for normalizing the assembly code 211 before using it for the abstraction. In an embodiment, the normalizer 409 may perform functions including, without limiting to, Dead Code Removal (DC), Program Reordering (PR), Register Renaming (RR) and Instruction Substitution (IS). Among the above functionalities, the Instruction Substitution is a unique functionality of the normalizer 409.

In an embodiment, the abstraction unit 411 is used for generating an abstract code 213 for the assembly code 211 generated by the disassembler 407. Further, the abstraction unit 411 may be used for generating representative abstract codes 213 of historical malwares based on information available in the historical substitution tables stored on the storage unit 413. Further, the scoring unit 415 may be used for computing and assigning a similarity score 215 for the target binary file 111 based on the similarity between the abstract code 213 corresponding to the target binary file 111 and the historical malwares. Based on whether the similarity score 215 is higher or lower than the predefined higher and lower threshold scores, the substitution layer classifies the target binary file 111 as one of a malware or non-malware, as shown in block 403 and 405 respectively.

FIG. 4C provides a detailed illustration of a method of detecting malware using the deep scan model 227 in accordance with some embodiments of the present disclosure.

The deep scan model 227 may include a logical separation unit 421, multi-level separation blocks 423A-423D, and a training model 425. The logical separation unit 421 may be used for logically separating the assembly code 211 corresponding to the target binary file 111 based on predefined separation policies and the one or more policy parameters. Subsequently, the logically separated assembly code 211 may be passed on to the multi-level separation blocks including a sub-block level separation, block level separation, function level separation and program level separation. Separating the assembly codes 211 along these four layers of separation enhances accuracy of the logical separation of the assembly code 211 and thereby enhances accuracy of the classification.

In an embodiment, the training model 425 may be a pretrained artificial intelligent system, which is trained with assembly codes 211, representative abstract codes 213 and logically separated blocks of the historical malwares. In other words, the pretrained artificial intelligent system takes as input the logically separated blocks of the assembly code 211 of the target binary file 111 and decides whether the target binary file 111 is similar to the historical malwares. In an embodiment, the storage unit 413 may store all the information related to the historical malwares. The logical separation unit 421 provide the logically separated blocks of assembly code 211 to the pretrained artificial intelligent system for further analysis. The transforming and training unit 429 may fetch the output of the pretrained artificial intelligent module and map it with each level of logical separation indicated in blocks 423A-423D. Finally, based on a correlation between the multi-level separation blocks and the artificial intelligent system, the deep scan model 227 may provide a classification output 431. Here, the classification output 431 may indicate whether the application corresponding to the target binary file 111 is a malware or non-malware.

FIG. 5A - 5C illustrate logical separation of the assembly code 211 in accordance with some embodiments of the present disclosure.

In an embodiment, the logical separation unit 421 of the deep scan model 227 may comprises a separation engine 501, a policy generation unit 505 and a knowledge base. In an embodiment, the disassembler 407 converts the target binary file 111 into corresponding assembly code 211 and provides it to the logical separation unit 421. At this point, the separation engine 501 in the logical separation unit 421 retrieves an appropriate separation policy 507 from the policy generation unit 505 for logically separating the assembly code 211. In an embodiment, the separation policy 507 used for the separation may be selected based on parameters including, but not limiting to, architecture of a Central Processing Unit (CPU) of the target device 503, hardware and Operating System (OS) information extracted from the target device 503, assembly instruction set, system call semantics, interrupt handler information, register list and the like. In an embodiment, the above information collected from the target device 503 may be referred and matched with corresponding historical information stored in the knowledge database 509 for choosing a correct separation policy 507 for separation of any piece of the assembly code 211.

In an embodiment, upon successful completion of the logical separation of the assembly code 211, the separation engine 501 may return the logically separated blocks of the assembly code 211 to the multi-layer and/or multi-level separation functions 423A-423D illustrated in FIG. 4C. Thereafter, the multi-level separation functions 423A-423D run through the logically separated blocks of the assembly code 211 for classifying the target binary file 111 and deciding whether corresponding application is a malware or non-malware. In an embodiment, the classification decision, along with the separation policies and the hardware information of the target device 503, may be stored on the knowledge base as a reference for analyzing new target binary files 111 in the future instances.

FIG. 5B provides an exemplary illustration of the logical separation process. In an embodiment, the assembly code 211 received from the disassembler 407 may be a combined set of all the instructions in the target binary file 111. The assembly code 211 may not reveal and/or distinguish different logical flows embedded in the target binary file 111. Logical separation of the assembly code 211 helps in identifying and distinguishing multiple logical flows and/or logical contexts in the assembly code 211. As an example, the assembly code 211 may be analyzed using appropriate separation policies and policy parameters 507 selected based on the hardware information of the target device 503 and segregated into multiple blocks of instructions as shown in 513A. Here, the instructions within each block of the stack 513A may be linked by a common logical context and hence may be grouped into distinct blocks. Further, each block in the stack 513A may be re-arranged into the logically separated blocks as represented by the stack 513B.

As an example, all the instructions that involve operation on the registers ‘eax’, ‘ebx’ and ‘ecx’ may be segregated into a single logical flow, since these operations are performed in a sequential order. Similarly, the operations involving the registers ‘eax’ and ‘edx’ may be treated as having a separate context of operation and may be grouped in a separate logical block (highlighted in green). Thus, the assembly code 211 may be logically separated and grouped into two logical blocks indicated by stack 513B of FIG. 5B.

In an embodiment, the logical separation of the assembly code 211 may be performed according to the following rules:
Start new logical context at the base of an assemble basic block based on semantics of the assembly cod
Track each general-purpose register as a new thread branch 515
Start a new thread branch 515 if a register is used and stop of defined

The above separation rules may be applied to each instruction in the assembly code 211 to obtain a thread branch 515corresponding to each register in the assembly code 211. An exemplary thread branch 515 corresponding to the assembly code 211 is depicted in FIG. 5C. Here, the assembly code 211 may be logically separated into two blocks based on the hint that applying the separation policy 507 on each instruction in the assembly code 211 results in two disconnected logical thread branches. As an example, a predefined separation policy 507 that defines an action corresponding to various types of instructions in the assembly code 211 may be as listed in the following table – Table A.

Instruction type Action
mov immediate Stop register thread
mov r1, r2 Continue register thread with r2
airth./logic operands: r1, r2 Fork two register threads r1 and r2
pop r Suspend reg thread with r
push r Resume reg thread with r
load r mem Stop reg thread, start mem thread
store mem r Stop mem thread if active and start reg thread
sys inst. (like software interrupt) Start reg threads on regs given by separation policy

Table A: Snapshot of separation engine actions on instruction types
Additionally, the separation policy 507 of the proposed disclosure is designed in accordance with the fact that the neighboring instructions in the raw assembly code 211 are not the actual or original logical neighbors of the target instruction. For instance, if the same code compiles with a different compiler or with a different compiler optimization setting, then these neighbors may not be consistent. Also, in the existing techniques, this fine grain noise of the raw assembly code 211 is passed as an input to the first level transformation layer, which is block level embedding, the most basic encoding itself may be erroneous and the error may even propagate to the higher transformation layers. This, in turn, may corrupt the higher transformation layers as well as the output encoding of the entire assembly code 211.

The proposed separation policy 507 handles this erroneous possibility, by extracting the logical neighbors. If the logical neighbors are extracted, then any compiler or compiler optimization setting may not change the actual logical flow neighbors and hence the logical neighbors remain consistent. Thus, the encoding on the first transformer layer itself may be very concrete and accurate and the same may propagate to the higher, more abstract layers of transformation, increasing the encoding accuracy. In an embodiment, the accurate segregation of the assembly code 211 into respective logical blocks helps in assigning a most accurate similarity score 215 for the target binary file 111, which in turn, helps in accurate detection of the malwares.

FIG. 6 shows a flowchart illustrating a method of detecting malwares in accordance with some embodiments of the present disclosure.

As illustrated in FIG. 6, the method 600 includes one or more blocks illustrating method for detecting malwares using a malware detection system 109 shown in FIG. 1B. The method 600 may be described in the general context of computer executable instructions. Generally, the computer executable instructions may include routines, programs, objects, components, data structures, procedures, modules, and functions, which perform specific functions or implement specific abstract data types.

The order in which the method 600 is described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any order to implement the method. Additionally, individual blocks may be deleted from the method without departing from the scope of the subject matter described herein. Furthermore, these methods may be implemented in any suitable hardware, software, firmware, or combination thereof.

At block 601, the method 600 includes converting, by the malware detection system 109, a target binary file 111 into a corresponding assembly code 211. The target binary file 111 may correspond to an application to be deployed in a target device 503.

At block 603, the method 600 includes generating, by the malware detection system 109, an abstract code 213 corresponding to the assembly code 211. In an embodiment, the abstract code 213 may be generated by replacing registers in the assembly code 211 with predefined representative variable names.

At block 605, the method 600 includes assigning, by the malware detection system 109, a similarity score 215 for the target binary file 111 by comparing the abstract code 213 with one or more reference abstract codes 213 corresponding to one or more historical malwares identified by the malware detection system 109. In an embodiment, the similarity score 215 for the target binary file 111 may be assigned based on one or more scoring parameters including at least one of number of matching code snippets in the abstract code 213, instruction length of the matching code snippets, and weight of the matching code snippets.

At block 607, the method 600 includes classifying, by the malware detection system 109, the target binary file 111 as a malware when the similarity score 215 for the target binary file 111 is greater than a first threshold score. In an embodiment, classifying the target binary file 111 may include classifying the target binary file 111 as a non-malware when the similarity score 215 for the target binary file 111 is less than a second threshold score. Alternatively, the target binary file 111 may be classifies as a probable malware when the similarity score 215 for the target binary file 111 is less than the first threshold score and greater than the second threshold score.

In an embodiment, the target binary file 111 may be transmitted to and deployed on the target device 503 when the target binary file 111 is classified as the non-malware. On the other hand, a deep-scan classification may be performed on the abstract code 213 of the target binary file 111 when the target binary file 111 is classified as the probable malware. In an embodiment, the deep-scan classification may be performed by segregating the assembly code 211 of the target binary file 111 into one or more logical groups based on predefined separation policies. Each of the one or more logical groups may include one or more related assembly instructions. Once the assembly code 211 is segregated, each of the one or more logical groups may be compared with one or more reference logical groups corresponding to the one or more historical malwares. Subsequently, the target binary file 111 may be classified as the malware when the one or more logical groups match with the one or more reference logical groups. In an embodiment, the deep-scan classification may be performed using a pretrained artificial intelligent system, trained using assembly code 211 of the one or more historical malwares detected by the malware detection system 109.

In an embodiment, the predefined separation policies may be generated based on one or more policy parameters of the target device 503. As an example, the one or more policy parameters may include, without limiting to, at least one of Operating System (OS) information of the target device 503, assembly instruction set of the target device 503, processor architecture of the target device 503, system call semantics, interrupt handler information and register list of the target device 503.

Computer System
FIG. 7 illustrates a block diagram of an exemplary computer system 700 for implementing embodiments consistent with the present disclosure. In an embodiment, the computer system 700 may be a malware detection system 109 shown in FIG. 1B, which may be used for malware or malware attack in an IoT environment. The computer system 700 may include a central processing unit (“CPU” or “processor”) 702. The processor 702 may comprise at least one data processor for executing program components for executing user- or system-generated business processes. A user may include a network operator, a user/owner of the IoT devices 101, a service provider and the like. The processor 702 may include specialized processing units such as integrated system (bus) controllers, memory management control units, floating point units, graphics processing units, digital signal processing units, etc.
The processor 702 may be disposed in communication with one or more input/output (I/O) devices (711 and 712) via I/O interface 701. The I/O interface 701 may employ communication protocols/methods such as, without limitation, audio, analog, digital, stereo, IEEE-1394, serial bus, Universal Serial Bus (USB), infrared, PS/2, BNC, coaxial, component, composite, Digital Visual Interface (DVI), high-definition multimedia interface (HDMI), Radio Frequency (RF) antennas, S-Video, Video Graphics Array (VGA), IEEE 802.n /b/g/n/x, Bluetooth, cellular (e.g., Code-Division Multiple Access (CDMA), High-Speed Packet Access (HSPA+), Global System For Mobile Communications (GSM), Long-Term Evolution (LTE) or the like), etc. Using the I/O interface 701, the computer system 700 may communicate with one or more I/O devices 711 and 712.
In some embodiments, the processor 702 may be disposed in communication with a communication network 709 via a network interface 703. The network interface 703 may communicate with the communication network 709. The network interface 703 may employ connection protocols including, without limitation, direct connect, Ethernet (e.g., twisted pair 10/100/1000 Base T), Transmission Control Protocol/Internet Protocol (TCP/IP), token ring, IEEE 802.11a/b/g/n/x, etc. Using the network interface 703 and the communication network 709, the computer system 700 may be communicatively associated with an external network for receiving a target binary file 111 which needs to be installed on one of the target IoT edge devices 503. Further, the computer system may use the communication network 709 to connect to the target device 503 on which a software update in the form of the target binary file 111 needs to be configured.
In an implementation, the communication network 709 may be implemented as one of the several types of networks, such as intranet or Local Area Network (LAN) and such within the organization. The communication network 709 may either be a dedicated network or a shared network, which represents an association of several types of networks that use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP), Transmission Control Protocol/Internet Protocol (TCP/IP), Wireless Application Protocol (WAP), etc., to communicate with each other. Further, the communication network 709 may include a variety of network devices, including routers, bridges, servers, computing devices, storage devices, etc.
In some embodiments, the processor 702 may be disposed in communication with a memory 705 (e.g., RAM 713, ROM 714, etc. as shown in FIG. 7) via a storage interface 704. The storage interface 704 may connect to memory 705 including, without limitation, memory drives, removable disc drives, etc., employing connection protocols such as Serial Advanced Technology Attachment (SATA), Integrated Drive Electronics (IDE), IEEE-1394, Universal Serial Bus (USB), fiber channel, Small Computer Systems Interface (SCSI), etc. The memory drives may further include a drum, magnetic disc drive, magneto-optical drive, optical drive, Redundant Array of Independent Discs (RAID), solid-state memory devices, solid-state drives, etc.
The memory 705 may store a collection of program or database components, including, without limitation, user/application interface 706, an operating system 707, a web browser 708, and the like. In some embodiments, computer system 700 may store user/application data 706, such as the data, variables, records, etc. as described in this disclosure. Such databases may be implemented as fault-tolerant, relational, scalable, secure databases such as Oracle® or Sybase®.
The operating system 707 may facilitate resource management and operation of the computer system 700. Examples of operating systems include, without limitation, APPLE® MACINTOSH® OS X®, UNIX®, UNIX-like system distributions (E.G., BERKELEY SOFTWARE DISTRIBUTION® (BSD), FREEBSD®, NETBSD®, OPENBSD, etc.), LINUX® DISTRIBUTIONS (E.G., RED HAT®, UBUNTU®, KUBUNTU®, etc.), IBM® OS/2®, MICROSOFT® WINDOWS® (XP®, VISTA®/7/8, 10 etc.), APPLE® IOS®, GOOGLETM ANDROIDTM, BLACKBERRY® OS , or the like.
The user interface 706 may facilitate display, execution, interaction, manipulation, or operation of program components through textual or graphical facilities. For example, the user interface 706 may provide computer interaction interface elements on a display system operatively connected to the computer system 700, such as cursors, icons, check boxes, menus, scrollers, windows, widgets, and the like. Further, Graphical User Interfaces (GUIs) may be employed, including, without limitation, APPLE® MACINTOSH® operating systems’ Aqua®, IBM® OS/2®, MICROSOFT® WINDOWS® (e.g., Aero, Metro, etc.), web interface libraries (e.g., ActiveX®, JAVA®, JAVASCRIPT®, AJAX, HTML, ADOBE® FLASH®, etc.), or the like.

The web browser 708 may be a hypertext viewing application. Secure web browsing may be provided using Secure Hypertext Transport Protocol (HTTPS), Secure Sockets Layer (SSL), Transport Layer Security (TLS), and the like. The web browsers 708 may utilize facilities such as AJAX, DHTML, ADOBE® FLASH®, JAVASCRIPT®, JAVA®, Application Programming Interfaces (APIs), and the like. Further, the computer system 700 may implement a mail server stored program component. The mail server may utilize facilities such as ASP, ACTIVEX®, ANSI® C++/C#, MICROSOFT®, .NET, CGI SCRIPTS, JAVA®, JAVASCRIPT®, PERL®, PHP, PYTHON®, WEBOBJECTS®, etc. The mail server may utilize communication protocols such as Internet Message Access Protocol (IMAP), Messaging Application Programming Interface (MAPI), MICROSOFT® exchange, Post Office Protocol (POP), Simple Mail Transfer Protocol (SMTP), or the like. In some embodiments, the computer system 700 may implement a mail client stored program component. The mail client may be a mail viewing application, such as APPLE® MAIL, MICROSOFT® ENTOURAGE®, MICROSOFT® OUTLOOK®, MOZILLA® THUNDERBIRD®, and the like.

Furthermore, one or more computer-readable storage media may be utilized in implementing embodiments consistent with the present disclosure. A computer-readable storage medium refers to any type of physical memory on which information or data readable by a processor may be stored. Thus, a computer-readable storage medium may store instructions for execution by one or more processors, including instructions for causing the processor(s) to perform steps or stages consistent with the embodiments described herein. The term “computer-readable medium” should be understood to include tangible items and exclude carrier waves and transient signals, that is, non-transitory. Examples include Random Access Memory (RAM), Read-Only Memory (ROM), volatile memory, nonvolatile memory, hard drives, Compact Disc (CD) ROMs, Digital Video Disc (DVDs), flash drives, disks, and any other known physical storage media.

Advantages of the embodiment of the present disclosure are illustrated herein.
In an embodiment, the present disclosure discloses a method for detecting a probable malware attack in an IoT environment.

In an embodiment, the method of present disclosure helps in enhancing security of the IoT platform and edge devices deployed in the IoT platform by accurately detecting and preventing malware attack on the edge devices.

In an embodiment, the method of present disclosure performs precise encoding of the assembly instructions using hardware information for the logical separation, thereby achieving higher accuracy in malware detection.

In an embodiment, the malware detection mechanism of the present disclosure may also be realized in any computing device, other than the IoT edge devices or IoT gateways, before uploading and deploying the malware detection mechanism into the target IoT edge device.

The terms "an embodiment", "embodiment", "embodiments", "the embodiment", "the embodiments", "one or more embodiments", "some embodiments", and "one embodiment" mean "one or more (but not all) embodiments of the invention(s)" unless expressly specified otherwise.

The terms "including", "comprising", “having” and variations thereof mean "including but not limited to", unless expressly specified otherwise.

The enumerated listing of items does not imply that any or all the items are mutually exclusive, unless expressly specified otherwise. The terms "a", "an" and "the" mean "one or more", unless expressly specified otherwise.

A description of an embodiment with several components in communication with each other does not imply that all such components are required. On the contrary, a variety of optional components are described to illustrate the wide variety of possible embodiments of the invention.

When a single device or article is described herein, it will be clear that more than one device/article (whether they cooperate) may be used in place of a single device/article. Similarly, where more than one device or article is described herein (whether they cooperate), it will be clear that a single device/article may be used in place of the more than one device or article or a different number of devices/articles may be used instead of the shown number of devices or programs. The functionality and/or the features of a device may be alternatively embodied by one or more other devices which are not explicitly described as having such functionality/features. Thus, other embodiments of the invention need not include the device itself.

Finally, the language used in the specification has been principally selected for readability and instructional purposes, and it may not have been selected to delineate or circumscribe the inventive subject matter. It is therefore intended that the scope of the invention be limited not by this detailed description, but rather by any claims that issue on an application based here on. Accordingly, the embodiments of the present invention are intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims.

While various aspects and embodiments have been disclosed herein, other aspects and embodiments will be apparent to those skilled in the art. The various aspects and embodiments disclosed herein are for purposes of illustration and are not intended to be limiting, with the true scope and spirit being indicated by the following claims.
Referral Numerals:
Reference Number Description
100A, 100B IoT environment
101 IoT devices
103 IoT Gateways
105 Data centers
107 Surface attack
107’ Attack propagation
109 Malware detection system
111 Target binary file
113 Malware classification
201 I/O interface
203 Processor
205 Memory
207 Data
209 Modules
211 Assembly code
213 Abstract code
215 Similarity score
217 Other data
221 Conversion module
223 Abstraction module
225 Assigning module
227 Deep scan model
229 Other modules
305 Matching sequence
401 Substitution filter
407 Disassembler
409 Normalizer
411 Abstraction unit
413 Storage unit
415 Scoring unit
421 Logical separation unit
423A-423D Multi-level transformation
425 Training model
429 Transforming and Training unit
431 Classification output
501 Separation engine
503 Target device
505 Policy generation unit
507 Separation policy
509 Knowledge database
515 Thread branch
700 Exemplary computer system
701 I/O Interface of the exemplary computer system
702 Processor of the exemplary computer system
703 Network interface
704 Storage interface
705 Memory of the exemplary computer system
706 User/Application
707 Operating system
708 Web browser
709 Communication network
711 Input devices
712 Output devices
713 RAM
714 ROM