WO2009083734A1 - Déploiement d'application typée - Google Patents

Déploiement d'application typée Download PDF

Info

Publication number
WO2009083734A1
WO2009083734A1 PCT/GB2008/004309 GB2008004309W WO2009083734A1 WO 2009083734 A1 WO2009083734 A1 WO 2009083734A1 GB 2008004309 W GB2008004309 W GB 2008004309W WO 2009083734 A1 WO2009083734 A1 WO 2009083734A1
Authority
WO
WIPO (PCT)
Prior art keywords
executable file
typed
executable
computing device
file
Prior art date
Application number
PCT/GB2008/004309
Other languages
English (en)
Inventor
James Steele
Original Assignee
Symbian Software Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Symbian Software Limited filed Critical Symbian Software Limited
Publication of WO2009083734A1 publication Critical patent/WO2009083734A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44589—Program code verification, e.g. Java bytecode verification, proof-carrying code
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/51—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability

Definitions

  • This invention relates to the deployment of computer readable code and, in particular, to the deployment of computer readable code in the form of typed applications.
  • Multitasking operating systems run two or more processes by allocating alternating processing cycles to the processes at a speed unobservable to the user so that the processes appear to be running simultaneously.
  • a process may comprise one or more series of instructions (or 'code'), a series of instructions being termed a 'thread'.
  • 'context switching' the procedure of switching execution from one thread to another (termed 'context switching') can cause problems and is time consuming, particularly where the processes share memory resources or access memory resources used by the kernel.
  • process isolation is used to describe the extent to which processes of a particular system may avoid sharing memory resources and the extent to which the effects of the behaviour of one process may be isolated from other processes.
  • MMU Memory Manager Unit
  • Process isolation is desirable in that it reduces these overheads. Furthermore, process isolation protects integrity and prevents security breaches, for example through buffer overflows.
  • processes have been isolated by only allowing processes to access certain pages of physical memory and by preventing untrusted code from accessing system resources such as the MMU or interrupt controllers. This approach suffers from the disadvantages however that exception handling is slower under these constraints, as are translation lookaside buffer lookups and reloads. For larger applications it has been found that the performance costs are too great to strictly enforce process isolation using this traditional approach.
  • the MMU defines a number of memory domains where access is controlled according to the addresses defining these domains. These domains prevent processes from accessing memory belonging to other processes.
  • a second approach to isolating processes is a software-based approach which relies on verifying the safe behaviour of executable code and whether the corresponding process is capable of being isolated (i.e. whether the process is "safe" or not). Verification will determine whether the process is capable of being isolated and will not access memory belonging to another process or to the kernel. The difficulty when using this approach lies in being able to verify any particular application.
  • programming languages are used which provide a method of verifying the safety of a program.
  • Languages such as Java and C#, for example, provide the safety verification needed at both compile-time and run-time.
  • Typed Assembly Language provides an assembly language with a method of denoting, in the executable file, the data type of each value that is manipulated by any application specified in that language. By including the data type with the application, the safety of the application may be verified without the need for additional run-time verification.
  • PCC Proof Carrying Code
  • typed languages for process isolation suffers from two disadvantages. Firstly, the inclusion of the type increases the size of the resulting executable file and secondly, the time taken to verify a typed executable file is non-negligible.
  • typed files advantageously provide improved security as the typing information may be used to detect unauthorised alterations to the executable file or detect malicious executable files such as viruses.
  • the invention provides a method of developing a typed executable file which includes the steps of: (a) producing a typed executable file; (b) determining a stability point when the typed executable file may be considered immutable; and
  • the invention provides a method which allows a reduction in the number of times a typed executable file needs to be verified.
  • the typed executable file is produced according to this aspect of the invention, it is not necessary to repeat the verification process once the stability point has been reached.
  • This aspect of the invention has a number of advantages. Firstly, it is generally more efficient if the verification of an executable file need only be performed once. Secondly, where a single verification is required, the information used in the verification may be moved after the verification has been performed (e.g., by being deleted).
  • the stability point may be a point in the life cycle of the executable file.
  • the stability point may be taken as constant for all executable files to be installed on that device.
  • the stability point may be set for each executable file individually or the same stability point may be applied to a group of executable files.
  • the step of determining the stability point may include the step of determining when said executable file may be considered trustworthy.
  • the step of determining a stability point may include the step of determining when the typed executable file is ready for transport to a computing device upon which said executable file is to be installed.
  • the step of determining a stability point may include the step of determining when the typed executable file is ready for inclusion in a ROM image for a computing device.
  • ROM images are used in both "closed” and “open” systems where an "open” system is one where additional executable files may be added by a user and a "closed” system is one where all of the executable files are determined at the time the system is compiled.
  • the stability point may be taken as the point at which the typed executable file is ready to be installed on a computing device.
  • the invention is applicable to open systems and, in particular, to the executable files later added by users of the system.
  • the step of verifying said executable files is carried out by an installation program.
  • the step of verifying said executable file may include the step of determining whether a process corresponding to the typed executable file is capable of being isolated.
  • step of verifying said typed executable file is carried out once and only once for each executable file on a computing device.
  • the typed executable file includes typing information and, once the executable file has been verified, the typing information may be discarded or deleted as this information is no longer required, in view of the fact that it has been determined that the executable file is now considered immutable.
  • the step of verifying said typed executable file may be carried out as part of a security enforcement process.
  • the typing information is advantageously used to determine the trustworthiness of the executable file and is additional used to verify the executable file.
  • the method may include the additional step of storing a result of said verification process.
  • the result of said verification process is an indication of whether the executable file is safe or not.
  • the invention provides for a typed executable file comprising typing information wherein said typing information is encoded as part of an executable file representation of the typed executable file.
  • the typing information is stored in compressed form.
  • the typing information may be encoded in an executable file image header.
  • the typing information may be accessed through a Uniform Resource Identifier (URI).
  • URI Uniform Resource Identifier
  • the invention relates to a method of maintaining a computing system, the computing system comprising both typed and untyped executable files, wherein the method includes the steps of:
  • the system is able to determine, by reference to the list, whether a particular executable file is a typed or an untyped executable file and manage the memory allocation accordingly.
  • a list may be used in applying executable files according to the aforementioned aspect of the invention to existing mobile computing devices to ensure that both typed and untyped executable files run on the same computing device.
  • a system according to a preferred embodiment of the invention is able to execute a mixture of typed and untyped applications.
  • the invention provides a file comprising a set of computer readable instructions and typing information relating to said instructions, said typing information being located remote from said instructions.
  • a file comprising a set of computer readable instructions and typing information relating to said instructions, said typing information being located remote from said instructions.
  • the typing information may be accessed through a Uniform Resource Identifier (URI).
  • URI Uniform Resource Identifier
  • the file may further comprise data.
  • the invention provides for a verification system for an executable file, the executable file having a data portion and a typing portion, wherein said typing portion may be used to verify said data portion, and wherein said typing portion is maintained at a location remote from said data portion, the verification system being adapted to access said typing information and, on the basis of said typing information, to verify said executable file.
  • the invention provides for an operating system arranged to cause a computing device to operate according to the method herein described.
  • the invention provides for a computer readable medium comprising instructions for directing a computer to perform the method herein described.
  • the invention provides for a computer program or a suite of computer programs suitable for causing a computing device to operate in accordance with the method herein described.
  • Figure 1 is a schematic diagram of a mobile computing device
  • Figure 2 is a schematic diagram of the mobile computing device of Figure 1 connected to a further computing device
  • Figure 3 is a schematic drawing of components of the mobile computing device of Figure 1 ;
  • Figure 4 is a schematic diagram of application development and deployment;
  • Figure 5 is a flow diagram of a preferred embodiment of the invention;
  • Figure 6a is a schematic illustration of a typed executable file according to an embodiment of the invention;
  • Figure 6b is a schematic illustration of the typed executable file of Figure 5a after modification
  • Figure 7 is a schematic illustration of a verification system according to a preferred embodiment of the invention.
  • Figure 1 illustrates a mobile computing device 10 having a casing 12.
  • the casing 12 encapsulates a keypad 14, a screen 16, a speaker 18 and a microphone 20.
  • the device 10 further includes an antenna 22.
  • the mobile computing device operates as a telephone and as a computer in a manner known in the art and is capable of running computer programs.
  • a computer program will be referred to as an "application”. It is to be realised however that the term "application” is intended to refer to any code capable of affecting the operation of a computing device.
  • the associated file type will be referred to herein as an executable file although a single computer program may comprise one or more executable files.
  • Executable files to be run on the mobile computing device 10 are generally produced on another computing device and then transported to the computing device 10.
  • Figure 2 illustrates one example where executable files are produced on a further computing device, computer 20, and transported to mobile computing device 10.
  • the executable files may be transported to mobile device 10 by means of a wired connection 26 or a wireless connection 24.
  • FIG. 3 is a schematic illustration of certain components of the mobile computing device 10.
  • Device 10 includes a kernel 70 which represents the operating system of the device 10.
  • the operating system is the Symbian operating system produced by Symbian Software Ltd., U.K.
  • the kernel 70 is connected to a volatile system memory 72 which is controlled by means of a memory management unit 74, which is a part of the kernel 70.
  • Device drivers 76, 78 and 80 are connected to kernel 70 and control the behaviour of, and communication with, respective devices: keyboard 82, network card 84 and monitor 86. It is to be realised that the mobile computing device 10 includes many more devices and components than those illustrated here.
  • the network card 84 facilitates communication with other computing devices such as computer 20 by means of wired connection 26 and is one of the ways in which the mobile computing device 10 receives data from external sources.
  • the device 10 includes typed applications 88 which communicate with the kernel 70 and untyped applications 90 which also communicate with the kernel 70.
  • the typed applications are specified using a typed language. In the embodiment shown, the Typed Application Language (TAL) has been used, although other typed languages such as Proof Carrying Code (PCC) may be used instead.
  • TAL Typed Application Language
  • PCC Proof Carrying Code
  • the device 10 further includes a verification application 89 which acts to verify typed executable files in the manner described below.
  • the kernel 70 controls the system memory 72 and the devices 82, 84 and 86 (by means of device drivers 76, 78 and 80) in a known manner.
  • the kernel 70 accesses a typing list 92 which lists the typed and the untyped applications of the device 10 together with an indication of whether the application is typed or untyped.
  • a stability point is identified in the development and deployment of a typed application 88 ( Figure 3) at which time the application may be considered immutable.
  • changes to an application are always possible in that the application may be erased and replaced by another version, or may be updated, such changes take place within the trusted deployment environment in a controlled manner. Therefore, identifying the stability point involves identifying that point in the life cycle of an application when the development has ceased and the application may be considered ready for deployment as the application is now relatively immutable. In other words, this involves determining a point during the life cycle of the application when the application may be trusted.
  • Figure 4 is a general illustration of the portions of the life cycle of the typed 88 and untyped 90 applications of Figure 3 including development and subsequent deployment of the applications.
  • development phase 30 which occurs on computing device 20 of
  • the application is specified using a computer language which is then compiled to produce the typed or untyped executable file.
  • an application may comprise a number of executable files and data files, all of which are packaged together.
  • deployment stage 32 involves the transport of the executable file to the mobile computing device 10 and the installation on the device in such a manner that the mobile computing device 10 is able to run the corresponding application. This last step is referred to as the installation of the application.
  • Both the development and the deployment stages will vary significantly depending on a range of factors such as: the computer language used to develop the application, the complexity and functionality of the application, the data files needed for the application to operate, the manner in which the executable file of the application is transported to the mobile computing device 10, the manner in which the application is installed on the mobile computing device.
  • the development stage 30 is distinguished from the deployment stage 32 in this embodiment of the current invention in that an application is only considered as trusted once it enters the deployment stage 32 (as illustrated in Figure 3).
  • trusted refers to the fact that the environment in which the application is developed is less trustworthy than the environment in which the application is deployed.
  • the stability point is considered as the line 31 between development and deployment.
  • the line 31 represents the point in the life cycle of this application where the contents of the executable file can be considered trustworthy.
  • the point at which the content of the executable file is to be considered trustworthy may correspond to the point when the executable file is created.
  • the stability point may correspond to the time in the life cycle of the application when the application is ready to be installed (therefore excluding any transport of the executable file).
  • the same policy for determining the stability point is used for all applications running on a given device.
  • the stability point is set according to an application classification. In this embodiment, applications are classified as either trustworthy (in which case the stability point is set at the time when the executable file is created), or as untrustworthy (in which case the stability point is set at the point the corresponding executable file is installed on the device).
  • FIG. 5 is a flow diagram illustrating a method of a preferred embodiment of the invention. This represents the process whereby any of the typed applications 88 are installed onto device 10 of Figure 3, for example.
  • Step 40 represents the development of the application, as well as any transport of the corresponding executable file, up to the point where the executable file of the application may be considered as trusted.
  • a stability point is determined as described above with reference to Figure 4. As previously stated, the stability point will depend on the particular development process involved and will depend on a number of factors such as the trustworthiness of the development process. The stability point is set at a time in the development and deployment process at which it is considered that the risks of the application changing are considered acceptable. In the current embodiment, the stability point is set at that time in the development process when it is determined that it is unlikely that the executable file will undergo any changes, i.e. when the executable file is in a form in which it is ready to be installed.
  • the executable file or files of this application are verified to determine whether the application is safe, i.e. whether the processes of the application, when run, are capable of being isolated. With reference to Figure 4, this represents the end of the development process 30 occurring on computing device 20.
  • the resulting executable file is then transported to mobile computing device 10 by means of the wired connection 26 which connects to the network card 84 ( Figure 3).
  • the executable file is received by means of the network card 84.
  • the verification step 44 is carried out by the verification application 89.
  • the verification application 89 updates the typing list 92 with an entry containing an identifier for the application as well as an indication that the executable file for this application is a typed executable file.
  • the verification application 89 further includes an indication of whether the process of the application, when run, will be safe with the entry in the list 92 for this application.
  • step 46 the executable file is modified by deleting the typing information.
  • step 46 is an optional step which will depend on the scarcity of storage space in the device concerned. It is possible to delete the typing information due to the previous determination of the stability point rendering future validation of the executable file unnecessary and retention of the typing information optional.
  • the executable file is modified by first copying the typing information to a remote location, such as computing device 20 ( Figure 2), and then deleting this typing information from the executable file.
  • the executable file is installed in the mobile computing device 10.
  • This installation process may also occur in a number of different ways.
  • the executable file may be installed by copying it onto a ROM image which is then installed in the device 10.
  • the executable file is installed by means of an installation application. It is to be realised that where an installation application is used, the installation application will incorporate the verification application 89 and, in this instance, the verification application will not be provided integrated with device 10.
  • the typing list 92 maintains a list of each of the applications 88 and 90 installed on the device 10. Therefore, when an application is installed on the device 10, a corresponding entry will be made in the typing list 92. Similarly, when an application is deleted from the device 10, the corresponding entry in the typing list 92 will be removed.
  • the typed 88 and the untyped 90 applications will be installed in the device 10 during a manufacture process. The manufacturer will therefore know which applications are typed and which are untyped and appropriate entries will be made in the typing list 92 when the ROM image for the device 10 is compiled. Other of the typed 88 and the untyped 90 applications will be installed during use of the device 10 (i.e. after manufacture). When an application is installed, the installation program will verify the application as described above and update the list 92 with an identifier for that application together with an indication of whether that application is typed or not. The information regarding whether the application is safe or not is also included in the list 92.
  • the MMU When the application is run by the device 10, the MMU will access the list 92 and organise the memory in the manner described. Due to the fact that the MMU is now aware of how certain of the processes will behave when executed, the MMU is able to reduce the number of instances in which the cache need be cleared and the MMU mappings and need be invalidated, therefore improving the speed with which the processor of the device is able to switch between execution of threads belonging to different processes.
  • the memory management unit 74 is able to arrange and organise the memory by partitioning the memory appropriately when processes corresponding to both typed and untyped executable files are running.
  • the MMU will partition the memory into at least two domains and the first of these domains will be used to run applications corresponding to typed executable files. The second of these domains will be used to run applications corresponding to untyped executable files. Therefore, any switching between threads belonging to typed executable files will occur quickly and the device 10 will operate more quickly than a corresponding device running only applications corresponding to untyped executable files.
  • Figure 6a illustrates a typed executable file 50 according to an embodiment of the invention.
  • the typed executable file 50 includes a header portion 52 and a data portion 54.
  • the header portion 52 includes the typing information pertaining to the data portion 54.
  • the header information which includes the typing information, is compressed.
  • the header information has been compressed by use of the LZW algorithm, but in further embodiments any suitable compression algorithm may be used.
  • Figure 6b illustrates the executable file 50 after undergoing the modification step 46 when the process of Figure 4 is applied to the typed executable file 50 of Figure 5a.
  • the modification which the executable file has undergone comprises the separation of the header portion 52 from the data portion 54.
  • the data may be installed on the computing device 10 and the application of the data will operate in a normal manner.
  • the separation of the header portion from the data portion 54 may occur at any point, and need not occur after validation.
  • FIG. 7 illustrates a verification system comprising a verification application 64 in communication with a data portion 60 of an executable file and in communication with a header portion 62 of the same executable file.
  • the data portion 60 is stored remotely from the header portion 62, on a separate device.
  • the verification application 64 operates on an independent computing device. Therefore, the communication between the verification application 64 and both the data 60 and the header 62 occurs by means of TCP/IP communications (although it is to be realised that other forms of communication may alternatively be used).
  • URI Uniform Resource Identifiers
  • the verification application 64 verifies the data portion 60 of the executable by accessing the header portion 62 in a known manner.
  • URI Uniform Resource Identifiers
  • the data portion 60 may be stored on mobile computing device 10 and the header portion 62 on the computer 20 (both on appropriate storage devices associated with the respective computing devices).
  • the verification application may reside on either the mobile computing device 10 or on the computer 20. Alternatively, the verification application resides on a further computing device connected to the mobile computing device 10 where the data portion is stored and to the computer 20 where the header portion is stored. In this embodiment, the verification application will communicate with the header portion 62 and the data portion 60 by means of a computer network.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Stored Programmes (AREA)

Abstract

Un procédé de développement d'un fichier exécutable typé comprend l'étape consistant à déterminer un point dans le cycle de vie du fichier exécutable typé auquel le fichier peut être considéré comme inaltérable, et à vérifier qu'un processus correspondant à ce fichier exécutable peut être exécuté sans interférer avec d'autres processus, le processus de vérification ayant de préférence lieu une seule fois pendant le cycle de vie de l'application. Un autre aspect concerne la maintenance d'une liste de fichiers exécutables typés et non typés pour un dispositif de calcul qui peut être utilisé pour organiser l'accès à la mémoire pour les applications de ces fichiers exécutables. Un autre aspect concerne un fichier exécutable comportant des instructions d'ordinateur et des informations de vérification, les informations de vérification étant mémorisées à un emplacement à distance des instructions.
PCT/GB2008/004309 2007-12-31 2008-12-31 Déploiement d'application typée WO2009083734A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB0725382A GB2456134A (en) 2007-12-31 2007-12-31 Typed application development
GB0725382.6 2007-12-31

Publications (1)

Publication Number Publication Date
WO2009083734A1 true WO2009083734A1 (fr) 2009-07-09

Family

ID=39092513

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB2008/004309 WO2009083734A1 (fr) 2007-12-31 2008-12-31 Déploiement d'application typée

Country Status (2)

Country Link
GB (1) GB2456134A (fr)
WO (1) WO2009083734A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106055971A (zh) * 2016-05-26 2016-10-26 广东欧珀移动通信有限公司 一种防沉迷的方法、装置和移动终端
CN106055972A (zh) * 2016-05-26 2016-10-26 广东欧珀移动通信有限公司 一种智能终端的控制方法、装置及智能终端

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6128774A (en) * 1997-10-28 2000-10-03 Necula; George C. Safe to execute verification of software
US20030097581A1 (en) * 2001-09-28 2003-05-22 Zimmer Vincent J. Technique to support co-location and certification of executable content from a pre-boot space into an operating system runtime environment
EP1526429A2 (fr) * 2003-10-24 2005-04-27 Microsoft Corporation Protection des resources du système d'exploitation
WO2005106654A1 (fr) * 2004-04-29 2005-11-10 Symbian Software Limited Installation de logiciel sur un support amovible
WO2006069335A2 (fr) * 2004-12-21 2006-06-29 Ntt Docomo, Inc. Execution de flux d'informations pour code assembleur style risc
GB2429081A (en) * 2005-08-10 2007-02-14 Symbian Software Ltd Protected software identifiers for improving the security of a computing device
US20070240194A1 (en) * 2006-03-28 2007-10-11 Hargrave Bentley J Scoped permissions for software application deployment

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6128774A (en) * 1997-10-28 2000-10-03 Necula; George C. Safe to execute verification of software
US20030097581A1 (en) * 2001-09-28 2003-05-22 Zimmer Vincent J. Technique to support co-location and certification of executable content from a pre-boot space into an operating system runtime environment
EP1526429A2 (fr) * 2003-10-24 2005-04-27 Microsoft Corporation Protection des resources du système d'exploitation
WO2005106654A1 (fr) * 2004-04-29 2005-11-10 Symbian Software Limited Installation de logiciel sur un support amovible
WO2006069335A2 (fr) * 2004-12-21 2006-06-29 Ntt Docomo, Inc. Execution de flux d'informations pour code assembleur style risc
GB2429081A (en) * 2005-08-10 2007-02-14 Symbian Software Ltd Protected software identifiers for improving the security of a computing device
US20070240194A1 (en) * 2006-03-28 2007-10-11 Hargrave Bentley J Scoped permissions for software application deployment

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
BINGYANG ZHOU ED - ANONYMOUS: "Risk Analysis and Protection for WBIS", NEXT GENERATION WEB SERVICES PRACTICES, 2006. NWESP 2006. INTERNATIONA L CONFERENCE ON, IEEE, PI, 25 September 2006 (2006-09-25), pages 94 - 100, XP031331768, ISBN: 978-0-7695-2664-5 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106055971A (zh) * 2016-05-26 2016-10-26 广东欧珀移动通信有限公司 一种防沉迷的方法、装置和移动终端
CN106055972A (zh) * 2016-05-26 2016-10-26 广东欧珀移动通信有限公司 一种智能终端的控制方法、装置及智能终端
CN106055972B (zh) * 2016-05-26 2019-06-28 Oppo广东移动通信有限公司 一种智能终端的控制方法、装置及智能终端

Also Published As

Publication number Publication date
GB0725382D0 (en) 2008-02-06
GB2456134A (en) 2009-07-08

Similar Documents

Publication Publication Date Title
US9229881B2 (en) Security in virtualized computer programs
US10228929B2 (en) Method and apparatus for modifying a computer program in a trusted manner
KR102206115B1 (ko) 인터프리터 가상 머신을 이용한 행동 멀웨어 탐지
KR102649092B1 (ko) 바운디드 포인터의 사용을 제어하기 위한 장치 및 방법
KR101806090B1 (ko) 멀웨어 검출을 위한 애플리케이션들의 제네릭 언패킹
EP3076292B1 (fr) Système et procédé de contrôle d'accès d'une image native d'un code machine à des ressources de système d'exploitation
US10402378B2 (en) Method and system for executing an executable file
US8316120B2 (en) Applicability detection using third party target state
US9906537B2 (en) System, method, and computer program product for conditionally performing an action based on an attribute
JP2019159830A (ja) 情報処理装置、情報処理方法およびプログラム
EP3121750B1 (fr) Système et procédé de vérification d'antivirus d'images natives d'ensembles de logiciels
US20190102279A1 (en) Generating an instrumented software package and executing an instance thereof
US6993761B1 (en) Method and apparatus to verify type safety of an application snapshot
WO2009083734A1 (fr) Déploiement d'application typée
CN111222122A (zh) 应用权限管理方法、装置及嵌入式设备
US8006281B2 (en) Network accessible trusted code
RU2628920C2 (ru) Способ обнаружения вредоносных сборок
WO2020012474A1 (fr) Système et procédé de protection contre les attaques par programmation orientée retour
RU2625052C1 (ru) Способ ограничения доступа образа машинного кода к ресурсам операционной системы
Zhao et al. Speculation-Free Function Table Construction in LLVM IR for Fine-Grained Control Flow Integrity
CN117688551A (zh) 启动路径白名单更新方法、装置、电子设备及存储介质
JP2008521111A5 (fr)

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08866812

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08866812

Country of ref document: EP

Kind code of ref document: A1