EP2018610A1 - Determination de nombres d'appels de methode critique dans une application en langage objet - Google Patents

Determination de nombres d'appels de methode critique dans une application en langage objet

Info

Publication number
EP2018610A1
EP2018610A1 EP07766022A EP07766022A EP2018610A1 EP 2018610 A1 EP2018610 A1 EP 2018610A1 EP 07766022 A EP07766022 A EP 07766022A EP 07766022 A EP07766022 A EP 07766022A EP 2018610 A1 EP2018610 A1 EP 2018610A1
Authority
EP
European Patent Office
Prior art keywords
application
call
critical
calling
graph
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
EP07766022A
Other languages
German (de)
English (en)
Inventor
Pierre Cregut
Cuihtlauac Alvarado
Thomas Jensen
Gerardo Schneider
David Pichardie
David Cachera
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
France Telecom SA
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 France Telecom SA filed Critical France Telecom SA
Publication of EP2018610A1 publication Critical patent/EP2018610A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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 OR CALCULATING; 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/55—Detecting local intrusion or implementing counter-measures
    • G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
    • G06F21/562—Static detection
    • G06F21/563—Static detection by source code analysis
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/20—Software design
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/43—Checking; Contextual analysis
    • G06F8/433—Dependency analysis; Data or control flow analysis

Definitions

  • the present invention relates to the automatic analysis of applications written in a pseudo-typed object oriented programming language. More particularly, it relates to a determination of call numbers of a critical method of an application to be installed in a mobile terminal between two interactions between a user of the mobile terminal and the application.
  • the standard security policy specifies that access to a critical functionality via a method, called the critical method of the application, must be explicitly authorized by the user; for example, a validation is requested as a question on the terminal screen.
  • the network operator or the manufacturer of the mobile terminal can affix a signature on applications, thus certifying the quality of the latter.
  • a signed application will eventually have access to more features of the mobile terminal and fewer validation messages will be presented to the user.
  • the applications are developed by a developer and the network operator must validate and sign these applications before making them available to the operator's client users.
  • a user may be confused by the number of validation messages or by the number of operations he has already initiated, and may unknowingly accept an action of the application using a critical functionality of the mobile terminal.
  • the user can also inadvertently remove a protection installed in the mobile terminal, allowing the execution in loop of a dangerous feature.
  • the prior validation and the application signature thus help to eliminate potentially dangerous applications because of these psychological aspects.
  • the operator therefore undertakes that the application does not do any action to which the user would not have consented if he had a validation message. Since the user only protects his interests, the operator can nevertheless refuse an application that damages his network, for example an application that triggers attempts to deny service.
  • tools for calculating the worst execution time WCET (initials of the words "Worst Case Execution Time"), such as the tools aiT of the company ABSINT, which are used to check properties in real time of embedded systems , can calculate the number of method calls for example by considering the execution time of other functions as null and arbitrarily giving a unit value for the call of one of the methods.
  • the number of method calls is calculated for the overall execution time of the pseudo-code of an application, but not for the execution time of the pseudo-code between two interactions between the application and the user. Therefore, although several short messages can be sent during the execution of the application, it is not considered dangerous since the sending of these short messages can be part of independent transactions, each of which could be authorized by the user.
  • the invention proposes a method for determining an upper bound of call numbers of a critical method of an application between two interactions between the application. and a user, the application being written in an object-oriented language executing in a runtime environment invoking callback methods of the application in response to either an internal event related to a method call d recording an action of the environment, or an external event, said method comprising a construction of a call graph whose each arc connects a calling method to a called method of the application.
  • the method is characterized in that it comprises the steps of: replacing in the call graph each arc having an action recording method as a method called by a set of arcs connecting the calling method of the arc to recall methods that may be triggered in response to the call of the action recording method, identifying callback methods in the call graph called in response to events external to the environment, estimating number of calls of the critical method identified in the call graph respectively for the identified callback methods, and determining the upper bound of the estimated call numbers of the critical method.
  • the invention advantageously takes into account all the callback methods that react indirectly to external events and are called by the execution environment.
  • An external event is for example an action of the user on the mobile terminal, such as a validation of an operation, or a reception of data by the mobile terminal.
  • a internal event is for example a delay (that is to say a delayed execution of a called method), or the launch of a "thread”.
  • callback methods can be triggered both in response to action registration method calls and in response to external events. Therefore, all calls for critical methods considered to be potentially dangerous are taken into account by the method according to the invention.
  • the invention it is determined, for an application to be installed in a user terminal, an upper bound of the numbers of critical method calls considered as potentially dangerous during an execution segment of the application where the user does not have control of the application.
  • said application written in an object-oriented language may advantageously have been compiled into a pseudolanguage (as explained below); it may be in particular an application compiled so as to be interpreted by a Java virtual machine (registered trademark).
  • the method according to the invention can be carried out during a validation phase of the application before downloading it by client users of the operator providing the application, the application being for example an application downloadable on a mobile terminal.
  • the operator - or the Company Services and Engineering Computer (SSII) responsible for testing the application - is prompted (e) to validate the application by digitally signing it when the upper bound is less than or equal to a predetermined threshold.
  • SSII Company Services and Engineering Computer
  • Validation or invalidation of the application therefore results from a test procedure implementing a method as briefly described above.
  • the invention is also aimed at a method of validation by a network operator or by an SSII of an application written in an object-oriented language.
  • This method is characterized in that it comprises the following steps: testing the application by means of a method according to the invention, and validating the application if the upper limit of the estimated call numbers of the critical method is lower or equal to a predetermined threshold, and invalidate it otherwise.
  • said application can be in any useful form, for example (as mentioned above) in the form of software that has been compiled into a pseudolanguage.
  • validation phase carried out according to the method according to the invention can be directly introduced into programming rules established by the operator and imposed on developers providing applications to the operator.
  • the invention also relates to a data processing device for determining an upper bound of call numbers of a critical method of an application between two interactions between the application and a user, the application being written in a object-oriented language executing in a runtime environment invoking callback methods of the application in response to either an event internal to the environment related to an environment action recording method call, or to an external event, said device comprising means for constructing a call graph whose each arc connects a calling method to a method called from the app.
  • the device is characterized in that it comprises: means for replacing in the call graph each arc having an action recording method as a method called by a set of arcs connecting the calling method of the arc to recall methods that may be triggered in response to the call of the action registration method, a means for identifying callback methods in the call graph called in response to events external to the environment means for estimating call numbers of the critical method identified in the call graph respectively for the identified callback methods, and means for determining the upper bound of the estimated call numbers of the critical method.
  • the invention relates to a computer program adapted to be implemented in a device for determining an upper bound of call numbers of a critical method of an application between two interactions between the application and a device. user, said program comprising instructions which, when the program is executed on said data processing device, perform the steps according to the method of the invention.
  • FIG. 1 is a schematic block diagram of a Java platform managing calls of a critical method of an application
  • FIG. 2 is a call graph connecting methods of an application
  • FIG. 3 is a schematic block diagram of a data processing device for determining an upper bound of call numbers of a critical method of an application according to the invention.
  • FIG. 4 is an algorithm of a method for determining an upper bound of call numbers of a critical method of an application according to the invention.
  • a programming language to an object-oriented language, such as the Java programming language, having a runtime and graphics environment, such as libraries for MIDP mobile terminal profile.
  • a runtime and graphics environment such as libraries for MIDP mobile terminal profile.
  • MIDP Mobile Information Device Profile
  • the invention is applicable to other languages such as the programming language ".net” (registered trademark) and other execution environments and graphics based on the description of the human-machine interface by objects graphics and event handlers, such as the Java AWT package (initials English words "Abstract Window Toolkit”).
  • the runtime and graphics environment may be for terminals other than mobile terminals, such as personal computers or point-of-sale terminals.
  • a Java platform can be installed in a microcontroller with a runtime environment that can host applications that have been developed in the Java programming language as the source language.
  • the microcontroller can be that of a mobile terminal for cellular radio network and the platform can be a platform J2ME (initials of the words "Java 2, Micro Edition").
  • the microcontroller may be that of a smart card, for example a SIM or USIM card.
  • a program written in Java is not compiled in native code, but in the form of an intermediate language independent of the platform, called pseudo-language.
  • the pseudo-language is composed of instructions coded on a byte called pseudocodes ("bytecodes" in English).
  • the runtime environment of a Java platform then comprises an interpreter constituted by a virtual machine and method libraries for these programs implemented in the memories of the microcontroller.
  • the virtual machine interprets Java executable programs that have been compiled into pseudolanguage so that a microcontroller processor executes in native code the compiled programs.
  • the pseudo-codes are statically typed, that is to say the virtual machine checks before the execution of the program if an execution of part of the program can become uncontrolled and if all the data manipulated respects certain rules of good training.
  • the data can not be used as application code.
  • a Java program includes a set of class definitions. Each class can be instantiated at runtime into objects that are dynamic structures containing object-specific local variables and class-specific methods.
  • classes use an inheritance mechanism, that is, descendant classes acquire the properties of ascending classes.
  • threads in English and hereinafter, composed of sequences of pseudo-code sequential instructions, are concurrently executable concurrently.
  • Each thread has a class containing a callback method that is called when the thread is created.
  • an object of that class is created and placed as an argument of a method that starts the execution of the thread.
  • the execution environment comprises for example the specialized MIDP library for the use of the J2ME platform on mobile terminals.
  • the MIDP library provides interfaces to the mobile terminal such as a cellular radio network connection manager, a human-machine interface and access permanent to a predetermined data memory space.
  • the runtime environment can be any other fixed runtime environment, so that a program does not use library extension capabilities available in the runtime environment, and results delivered by runtime techniques. static analysis is exhaustive, that is, all possible executions of the application have been analyzed. In particular, the runtime environment must refuse any dynamic loading of new libraries and any access to reflexivity mechanisms on the pseudo-code of the application to dynamically build method calls.
  • Running an application using the MIDP library is controlled by an event handler included in the Java platform.
  • the event handler manages an event queue that is external or internal to the application.
  • the event handler activates different parts of the application's pseudo-code according to the events that occur and respects priority rules between the events that occurred.
  • the execution manager commands the execution of the application to stop.
  • the application is encoded according to a predetermined event pattern in response to which code portions of the application are respectively executed.
  • Each display on the screen of the mobile terminal is recorded in the runtime environment a callback method managing events related to the display.
  • a new callback method is called and recorded, controlling a new display.
  • the application controls a display on the screen of the mobile terminal by means of a display object.
  • the content of the display can be associated with specialized objects by means of methods specific to the display object. Examples of specialized objects are commands that define software buttons displayed on the screen of the mobile terminal and which are selected by means of keys of the mobile terminal, thereby triggering an external event.
  • event listening objects each containing a callback method that is called at each external or internal event.
  • a callback method included in one of the event listening objects is called with the display object of the current display and the command representing the event generator button.
  • the callback method contains portions of codes to be executed, for example relating to calls from other methods, some of which may be critical, and a method call to execute the next display.
  • an interaction between the user and the application corresponds to an action of the user on the mobile terminal, triggering an external event
  • the time interval between two interactions corresponds to a segment of Execution of the application where the user does not have control of the application and during which a critical method can be executed several times.
  • calls of a critical method MC which commands a short message sending from a mobile terminal are started following various events occurring over the course of time represented by a vertical downward arrow.
  • the Java PFJ platform that can be executed by the microcontroller in the mobile terminal includes an EE runtime environment including MIDP libraries, a GE event handler, and various lightweight processes, such as a TA helper thread and a timed thread. TT.
  • an application is started by the user of the mobile terminal.
  • the EE execution environment calls, at a time t1, a callback method MR that calls the critical method MC to the handler.
  • instant tl '; the critical method MC is executed by the virtual machine of the PFJ platform under the control of the GE event handler.
  • the callback method then calls at a time t2 a MEA action registration method of the EE execution environment which is a timer of a thread which will therefore be executed, after a predetermined time, at a time t5.
  • the callback method MR furthermore calls at a time t3 a method for creating MCTA of an auxiliary thread TA which automatically executes the critical method MC.
  • the event handler GE stops the execution of the callback method MR to treat for example a new external event.
  • the execution environment calls, at a time t5, a timed thread TT which automatically executes the critical method MC.
  • FIG. 1 illustrates not only the call of the critical method MC at time t1 'to command the sending of a short message according to the execution of the pseudocode by the event manager, but also the sending of two messages short indirectly generated by the external event at times t3 and t5.
  • the sending of three short messages has been ordered.
  • the callback method MR called at time tl triggers two internal events related to the auxiliary thread and the timed thread to send two other short messages.
  • FIG. 2 represents a call graph of a code portion of an application such as that described previously with reference to FIG. 1.
  • the call graph includes nodes corresponding respectively to the different methods relating to the application and arcs each connecting a calling method to a called method.
  • Each arc can be annotated by the call statement in the code of the calling method used to call the called method.
  • the MR recall method is directly related to the critical method MC since it calls the latter.
  • the MR callback method is directly related to the MEA action registration method and the MCTA auxiliary thread creation method.
  • the MEA action registration method will subsequently trigger a call to a timed TT thread creation method indirectly through a mechanism internal to the runtime environment. Therefore, there is no link in the call graph between the MEA action registration method and the TT timed thread creation method.
  • the callback method MR can be connected to a first method called MAI which calls a second method MA2.
  • the second method called MA2 can call the callback method MR, thus creating a call loop in the call graph due to recursive calls of the callback method MR.
  • the DTD data processing device is a computer of the personal computer, or server, or terminal, or a combination of these.
  • the FC class files include information defining classes of the application to be tested and are made available to the CPU CPU and the MGA call graph construction module in the DTD device to perform static code analysis. of the application. Static analysis is a set of operations to obtain properties on possible executions of the code without performing any actual execution.
  • a static analysis can be a "devirtualization" which determines for each call of a method on an object the possible implementations of the method that could be used when calling the method.
  • devirtualization determines the classes that respond to a method call during execution, that is, classes that contain a method that can respond to the method call. When actually executing the code, only one of these classes will be activated in response to the method call.
  • the MGA call graph construction module constructs and stores a call graph GA relating to the application to be tested, parts of which may be similar to the simple graph shown by way of example in FIG.
  • the identification module MI identifies at least one critical method MC and callback methods MR of the application and the evaluation module ME determines a terminal on the number of calls of the critical method MC .
  • the method according to the invention for determining an upper bound of call numbers of a critical method of an application between two interactions between the application and a user comprises steps E1 to E7 executed under the control of the central unit UC in the DTD data processing device and implemented by instructions of a computer program recorded on a recording medium readable by the data processing device.
  • the application developed by a developer is transmitted to an IT service provider to test the application, in the form of FC class files that are stored in the DTD data processing device.
  • the MGA call graph building module constructed from the FC class files a GA call graph relating to the application to be validated. Each arc connects a calling method to a called method and is annotated by a call statement of the called method.
  • the call graph GA is for example constructed by means of a devirtualization operation, since methods are called indirectly through objects whose class is not necessarily known before the execution.
  • the call graph construction module MGA modifies the call graph by replacing each annotated arc with a call instruction connecting a calling method to an action recording method MEA as a called method. by a set of arcs annotated by the same call instruction connecting the calling method to the different MR callback methods that may be triggered in response to the call of the MEA action record method.
  • the interest of this change in the call graph is to include all callback methods that respond to internal events and are indirectly invoked by the runtime environment. Indeed, as illustrated in FIG.
  • a called MEA action registration method can activate an intermediate method launching a timed thread whose creation is managed by the execution environment, and the timed thread can execute a method recalling a critical method.
  • the source method initially linked to the MEA action recording method is then linked to the recall method which is itself linked to the critical method.
  • the identification module MI identifies in the call graph the critical method MC and callback methods MR called in response to external events, such as a solicitation of a softkey by the user. 'user.
  • step E4 the evaluation module ME estimates in the call graph GA a number of calls NA of the identified critical method MC for each callback method identified MR according to an approximation on the number of calls of method described below in steps E41 to E44.
  • step E41 the evaluation module ME determines call loops in the call graph GA, for example using the "Tarjan algorithm” (see the article by RE Tarjan titled “Depth First Search and Linear Graph Algorithm ", SIAM Journal on Computing 1 (2), pp. 146-160, 1972) for calculating strongly related components of a graph.
  • the evaluation module ME annotates with a star "*" every call graph methods that are part of a certain loop in the call graph.
  • step E42 the evaluation module ME constructs a GFC control flow graph for each calling method.
  • the "control flow graph" of a calling method is a graph whose nodes represent the instructions of the calling method and the arcs represent the dummy execution of a destination instruction immediately after a source statement, during an execution of the calling method.
  • the evaluation module ME determines loops in the GFC control flow graph of the calling method. Then the evaluation module ME annotates with a star "*" all the calling instructions relating to the calling method and associated as labels to the arcs of the call graph, which belong to a loop of the flow graph. control of the calling method.
  • step E43 the evaluation module ME identifies all the paths without a loop in the call graph GA. For each path linking a so-called “source” callback method to the so-called “target” critical method, the path is weighted by a coefficient equal to "1" if no method or instruction belonging to the path is annotated by a star. In the opposite case, the path is weighted by a coefficient equal to "*", which is a fictitious value.
  • step E44 for each pair consisting of an MR recall method and the critical method MC, the evaluation module ME estimates the sum of the coefficients of the paths connecting the callback method to the critical method.
  • Each sum represents an estimate of the upper bound on the number of calls NA of a critical method MC when executing a given MR recall method.
  • step E5 the evaluation module ME compares all the estimated call numbers NA respectively allocated to the identified callback methods and determines an upper bound BS as the maximum value of the estimated call numbers NA of the critical method MC .
  • the data processing device DTD invalidates the application if the upper bound BS exceeds a predetermined threshold SP.
  • the predetermined threshold SP can be set by the operator and is for example "3" for a critical method relating to a short message sending. In this case, the application is rejected and returned to the service company that developed the application.
  • the data processing device DTD can validate the application; it can then be made available, for example in a server, so that it can be downloaded to mobile terminals of client users of the operator.
  • the invention described herein relates to a method and a device for determining an upper bound of call numbers of a critical method of an application.
  • the steps of the method of the invention are determined by the instructions of a computer program incorporated in a data processing device such as the DTD device.
  • the program comprises program instructions which, when said program is executed in the device whose operation is then controlled by the execution of the program, carry out the steps of the method according to the invention.
  • the invention also applies to a computer program, including a computer program on or in an information carrier, adapted to implement the invention.
  • This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code such as in a partially compiled form, or in any other form desirable to implement the method according to the invention.
  • the information carrier may be any entity or device capable of storing the program.
  • the medium may comprise storage means or recording medium on which is recorded the computer program according to the invention, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a USB key, or a magnetic recording means, for example a floppy disk or a hard disk.
  • the information carrier can be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means.
  • the program according to the invention can in particular be downloaded to an Internet type network.
  • the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in carrying out the method according to the invention.

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)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Virology (AREA)
  • Debugging And Monitoring (AREA)

Abstract

ABREGE Détermination de nombres d'appels de méthode critique dans une application en langage objet Pour déterminer une borne supérieure des nombres d'appels d'une méthode critique d'une application en langage orienté objet entre deux interactions entre l'application et un utilisateur, l'application s'exécutant dans un environnement d'exécution appelant des méthodes de rappel en réponse à un évènement externe ou un évènement interne lié à un appel de méthode d'enregistrement d'action, un graphe d'appels est construit tel que chaque arc reliant une méthode appelante à une méthode appelée de l'application et ayant une méthode d'enregistrement d'action comme méthode appelée soit remplacé par un ensemble d'arcs reliant la méthode appelante à différentes méthodes de rappel susceptibles d'être déclenchées en réponse à l'appel de la méthode d'enregistrement d'action. La borne supérieure est déterminée comme la valeur maximale des nombres d'appels estimés de la méthode critique pour chaque méthode de rappel identifiée dans le graphe d'appels. (Figure 4)

Description

Détermination de nombres d'appels de méthode critique dans une application en langage objet
La présente invention est relative à l'analyse automatique d'applications écrites dans un langage de programmation orienté objet à pseudo-code typé. Plus particulièrement, elle a trait à une détermination de nombres d'appels d'une méthode critique d'une application à installer dans un terminal mobile entre deux interactions entre un utilisateur du terminal mobile et l'application.
Des applications installées dans un terminal mobile d'un utilisateur ont accès à des fonctionnalités du terminal mobile au travers de points d'accès sécurisés. Certaines fonctionnalités sont dites critiques soit parce qu'elles représentent un risque pour les données de l'utilisateur, tel qu'un enregistrement ou une fuite d'information sur le réseau, soit parce que l'utilisation des fonctionnalités est payante ; par exemple un envoi de message court SMS ("Short Message Service" en anglais) est facturé par l'opérateur du réseau.
La politique de sécurité standard spécifie que l'accès à une fonctionnalité critique via une méthode, dite méthode critique de l'application, doit être autorisé explicitement par l'utilisateur ; par exemple, une validation est demandée sous forme de question sur l'écran du terminal. Cependant l'opérateur du réseau ou le fabricant du terminal mobile peut apposer une signature sur des applications, certifiant ainsi la qualité de ces dernières. Ainsi, une application signée aura éventuellement accès à plus de fonctionnalités du terminal mobile et moins de messages de validation seront présentés à l'utilisateur.
En général, les applications sont développées par un développeur et l'opérateur de réseau doit valider et signer ces applications avant de les mettre à disposition des utilisateurs clients de l'opérateur. Par exemple, un utilisateur peut être désorienté par le nombre de messages de validation ou par le nombre d'opérations qu'il a déjà engagées, et peut accepter sans réfléchir une action de l'application utilisant une fonctionnalité critique du terminal mobile. L'utilisateur peut en outre retirer par mégarde une protection installée dans le terminal mobile, permettant alors l'exécution en boucle d'une fonctionnalité dangereuse. La validation a priori et la signature d'application contribuent ainsi à éliminer des applications potentiellement dangereuses en raison de ces aspects psychologiques.
En outre, puisque la signature d'une application limite le nombre de messages de validation que verra l'utilisateur, l'opérateur s'engage donc à ce que l'application ne fasse aucune action à laquelle l'utilisateur n'aurait pas consenti s'il avait eu un message de validation. L'utilisateur ne protégeant que ses intérêts, l'opérateur peut néanmoins refuser une application qui porte atteinte à son réseau, par exemple une application déclenchant des tentatives de dénis de service.
Des systèmes de validation d'applications connus identifient seulement des appels aux méthodes critiques d'une application lors d'une phase de dévirtualisation (le mot "dévirtualisation" est défini ci-après), sans calculer les nombres d'appels des méthodes sur toutes les exécutions possibles du pseudo-code de 1 ' application .
Par ailleurs, des outils de calcul du pire temps d'exécution WCET (initiales des mots anglais "Worst Case Execution Time"), tels que les outils aiT de la société ABSINT, qui sont utilisés pour vérifier des propriétés en temps réel de systèmes embarqués, peuvent calculer le nombre d'appels de méthodes par exemple en considérant comme nul le temps d'exécution d'autres fonctions et en donnant arbitrairement une valeur unitaire pour l'appel de l'une des méthodes. Le nombre d'appels des méthodes est calculé pour le temps global d'exécution du pseudo-code d'une application, mais pas pour le temps d'exécution du pseudo-code entre deux interactions entre l'application et l'utilisateur. Par conséquent, bien que plusieurs messages courts puissent être envoyés au cours de l'exécution de l'application, celle-ci n'est pas considérée comme dangereuse puisque les envois de ces messages courts peuvent faire partie de transactions indépendantes dont chacune a pu être autorisée par l'utilisateur.
Les systèmes de validation d'applications actuels ne garantissent aucun nombre maximal d'appels ou d'exécution d'une méthode critique entre deux interactions entre l'application et l'utilisateur, et assurent tout au plus une borne inférieure du nombre d' appel .
Pour remédier à ces inconvénients, l'invention propose un procédé pour déterminer une borne supérieure de nombres d'appels d'une méthode critique d'une application entre deux interactions entre l'application et un utilisateur, l'application étant écrite dans un langage orienté objet s 'exécutant dans un environnement d'exécution appelant des méthodes de rappel de l'application en réponse soit à un événement interne à l'environnement lié à un appel de méthode d'enregistrement d'action de l'environnement, soit à un événement externe, ledit procédé comprenant une construction d'un graphe d'appels dont chaque arc relie une méthode appelante à une méthode appelée de l'application. Le procédé est caractérisé en ce qu'il comprend les étapes de : remplacer dans le graphe d'appels chaque arc ayant une méthode d'enregistrement d'action comme méthode appelée par un ensemble d'arcs reliant la méthode appelante de l'arc à des méthodes de rappel susceptibles d'être déclenchées en réponse à l'appel de la méthode d'enregistrement d'action, identifier dans le graphe d'appels des méthodes de rappel appelées en réponse à des événements externes à l'environnement, estimer des nombres d'appels de la méthode critique identifiée dans le graphe d'appels respectivement pour les méthodes de rappel identifiées, et déterminer la borne supérieure des nombres d'appels estimés de la méthode critique.
L'invention prend avantageusement en compte toutes les méthodes de rappel qui réagissent indirectement à des événements externes et qui sont appelées par l'environnement d'exécution. Un événement externe est par exemple une action de l'utilisateur sur le terminal mobile, telle qu'une validation d'une opération, ou une réception de données par le terminal mobile. Un événement interne est par exemple une temporisation (c'est-à-dire une exécution retardée d'une méthode appelée), ou le lancement d'un "thread".
En effet, entre deux interactions entre l'application et un utilisateur, des méthodes de rappel peuvent être déclenchées aussi bien en réponse à des appels de méthode d'enregistrement d'action qu'en réponse à des événements externes. Par conséquent, tous les appels de méthodes critiques considérées comme potentiellement dangereuses sont prises en compte par le procédé selon l'invention.
Grâce à l'invention, on détermine, pour une application à installer dans un terminal d'utilisateur, une borne supérieure des nombres d'appels de méthodes critiques considérées comme potentiellement dangereuses pendant un segment d'exécution de l'application où l'utilisateur n'a pas le contrôle de l'application.
On notera que ladite application écrite dans un langage orienté objet peut avantageusement avoir été compilée en un pseudolangage (comme expliqué ci- dessous) ; il peut s'agir en particulier d'une application compilée de manière à pouvoir être interprétée par une machine virtuelle Java (marque déposée) . Le procédé selon l'invention peut être effectué lors d'une phase de validation de l'application avant le téléchargement de celle-ci par des utilisateurs clients de l'opérateur mettant à disposition l'application, l'application étant par exemple une application téléchargeable sur un terminal mobile.
Ainsi, l'opérateur — ou la Société de Services et d'Ingénierie en Informatique (SSII) chargée de tester l'application — est incité (e) à valider l'application en la signant numériquement lorsque la borne supérieure est inférieure ou égale à un seuil prédéterminé.
La validation ou l'invalidation de l'application découle donc d'une procédure de test mettant en œuvre un procédé tel que décrit succinctement ci-dessus.
C'est pourquoi l'invention vise également un procédé de validation par un opérateur de réseau ou par une SSII d'une application écrite dans un langage orienté objet.
Ce procédé est caractérisé en ce qu'il comprend les étapes suivantes : tester l'application au moyen d'un procédé selon l'invention, et valider l'application si la borne supérieure des nombres d'appels estimés de la méthode critique est inférieure ou égale à un seuil prédéterminé, et l'invalider dans le cas contraire.
On notera que ladite application peut se présenter sous toute forme utile, par exemple (comme mentionné ci-dessus) sous la forme d'un logiciel qui a été compilé en un pseudolangage.
Par ailleurs, la phase de validation réalisée suivant le procédé selon l'invention peut être directement introduite dans des règles de programmation établies par l'opérateur et imposées à des développeurs fournissant des applications à l'opérateur.
L'invention a également pour objet un dispositif de traitement de données pour déterminer une borne supérieure de nombres d'appels d'une méthode critique d'une application entre deux interactions entre l'application et un utilisateur, l'application étant écrite dans un langage orienté objet s 'exécutant dans un environnement d'exécution appelant des méthodes de rappel de l'application en réponse soit à un événement interne à l'environnement lié à un appel de méthode d'enregistrement d'action de l'environnement, soit à un événement externe, ledit dispositif comprenant un moyen pour construire un graphe d'appels dont chaque arc relie une méthode appelante à une méthode appelée de l'application. Le dispositif est caractérisé en ce qu'il comprend : un moyen pour remplacer dans le graphe d'appels chaque arc ayant une méthode d'enregistrement d'action comme méthode appelée par un ensemble d'arcs reliant la méthode appelante de l'arc à des méthodes de rappel susceptibles d'être déclenchées en réponse à l'appel de la méthode d'enregistrement d'action, un moyen pour identifier dans le graphe d'appels des méthodes de rappel appelées en réponse à des événements externes à l'environnement, un moyen pour estimer des nombres d'appels de la méthode critique identifiée dans le graphe d'appels respectivement pour les méthodes de rappel identifiées, et un moyen pour déterminer la borne supérieure des nombres d'appels estimés de la méthode critique.
Enfin, l'invention se rapporte à un programme d'ordinateur apte à être mis en œuvre dans un dispositif pour déterminer une borne supérieure de nombres d'appels d'une méthode critique d'une application entre deux interactions entre l'application et un utilisateur, ledit programme comprenant des instructions qui, lorsque le programme est exécuté sur ledit dispositif de traitement de données, réalisent les étapes selon le procédé de l'invention.
D'autres caractéristiques et avantages de la présente invention apparaîtront plus clairement à la lecture de la description suivante de plusieurs réalisations préférées de l'invention, données à titre d'exemples non limitatifs, en référence aux dessins annexés correspondants dans lesquels :
-la figure 1 est un bloc-diagramme schématique d'une plate-forme Java gérant des appels d'une méthode critique d'une application ;
-la figure 2 est un graphe d'appels reliant des méthodes d'une application ;
-la figure 3 est un bloc-diagramme schématique d'un dispositif de traitement de données pour déterminer une borne supérieure de nombres d'appels d'une méthode critique d'une application selon l'invention ; et
-la figure 4 est un algorithme d'un procédé de détermination d'une borne supérieure de nombres d'appels d'une méthode critique d'une application selon 1 ' invention .
Dans la suite de la description, on se référera en tant que langage de programmation à un langage orienté objet, comme le langage de programmation Java, disposant d'un environnement d'exécution et graphique, tel que des bibliothèques pour profil de terminal mobile MIDP ("Mobile Information Device Profile" en anglais). Toutefois, l'invention est applicable à d'autres langages tels que le langage de programmation ".net" (marque déposée) et d'autres environnements d'exécution et graphiques reposant sur la description de l'interface homme-machine par des objets graphiques et des gestionnaires d'événements, tels que la bibliothèque ("package" en anglais) Java AWT (initiales des mots anglais "Abstract Window Toolkit" ) . Toutefois, l'environnement d'exécution et graphique peut être destiné à des terminaux autres que des terminaux mobiles, comme des ordinateurs personnels ou des terminaux de point de vente .
Préalablement, quelques termes et concepts utiles à la compréhension de l'invention sont définis ci-après.
Une plate-forme Java peut être installée dans un microcontrôleur doté d'un environnement d'exécution susceptible d'héberger des applications ayant été développées dans le langage de programmation Java en tant que langage source. En particulier, le microcontrôleur peut être celui d'un terminal mobile pour réseau de radiocommunications cellulaire et la plate-forme peut être une plate-forme J2ME (initiales des mots anglais "Java 2, Micro Edition" ) . En variante, le microcontrôleur peut être celui d'une carte à puce, par exemple une carte SIM ou USIM.
Un programme écrit en Java n'est pas compilé en code natif, mais sous la forme d'un langage intermédiaire indépendant de la plate-forme, appelé pseudo-langage. Le pseudo-langage est composé d'instructions codées sur un octet appelées pseudocodes ("bytecodes" en anglais). L'environnement d'exécution d'une plate-forme Java comprend alors un interpréteur constitué par une machine virtuelle et des bibliothèques de méthodes pour ces programmes mis en œuvre dans les mémoires du microcontrôleur. La machine virtuelle interprète des programmes exécutables Java qui ont été compilés en le pseudolangage afin qu'un processeur du microcontrôleur exécute en code natif les programmes compilés .
En particulier, les pseudo-codes sont typés statiquement, c'est-à-dire la machine virtuelle vérifie avant l'exécution du programme si une exécution d'une partie du programme peut devenir incontrôlée et si l'ensemble des données manipulées respecte certaines règles de bonne formation. Par exemple, les données ne peuvent être utilisées comme code de l'application.
Un programme Java comprend un ensemble de définitions de classes. Chaque classe peut être instanciée à l'exécution en des objets qui sont des structures dynamiques contenant des variables locales propres aux objets et des méthodes propres à la classe. Par ailleurs, les classes utilisent un mécanisme d'héritage, c'est-à-dire des classes descendantes acquièrent les propriétés de classes ascendantes.
En particulier, des processus légers, appelés " threads" en anglais et ci-après, composés de flots d'instructions séquentielles de pseudo-codes, sont exécutables de façon concurrente simultanément. A chaque thread correspond une classe contenant une méthode de rappel qui est appelée à la création du thread. Pour lancer un thread, un objet de ladite classe est créé et placé en argument d'une méthode lançant l'exécution du thread.
L'environnement d'exécution selon l'invention comprend par exemple la bibliothèque MIDP spécialisée pour l'utilisation de la plate-forme J2ME sur des terminaux mobiles. La bibliothèque MIDP fournit des interfaces au terminal mobile telles qu'un gestionnaire de connexions au réseau de radiocommunications cellulaire, une interface homme/machine et un accès permanent à un espace mémoire de données prédéterminé. L'environnement d'exécution peut être tout autre environnement d'exécution figé, afin qu'un programme n'utilise pas des possibilités d'extension de bibliothèques disponibles dans l'environnement d'exécution et que des résultats rendus par des techniques d'analyse statique soient exhaustifs, c'est- à-dire que toutes les exécutions possibles de l'application aient été analysées. En particulier, l'environnement d'exécution doit refuser tout chargement dynamique de nouvelles bibliothèques et tout accès à des mécanismes de réflexivité sur le pseudo-code de l'application permettant de construire dynamiquement des appels de méthodes .
L'exécution d'une application utilisant la bibliothèque MIDP est commandée par un gestionnaire d'événements inclus dans la plate-forme Java. Le gestionnaire d'événements gère une file d'événements externes ou internes à l'application.
Le gestionnaire d'événements active différentes parties du pseudo-code de l'application suivant les événements survenus et respecte des règles de priorité entre les événements survenus. Par ailleurs, le gestionnaire d'exécution commande l'arrêt de l'exécution de l'application.
L'application est codée selon un modèle à événements prédéterminés en réaction desquels des parties de code de l'application sont respectivement exécutées. A chaque affichage sur l'écran du terminal mobile est enregistrée dans l'environnement d'exécution une méthode de rappel gérant des événements liés à l'affichage. Lorsque la méthode de rappel est exécutée, une nouvelle méthode de rappel est appelée et enregistrée, commandant un nouvel affichage.
En particulier, l'application commande un affichage sur l'écran du terminal mobile au moyen d'un objet-afficheur. Le contenu de l'affichage peut être associé à des objets spécialisés au moyen de méthodes particulières à l'objet-afficheur. Des objets spécialisés sont par exemples des commandes qui définissent des boutons logiciels affichés sur l'écran du terminal mobile et qui sont sélectionnées au moyen de touches du terminal mobile, déclenchant alors un événement externe.
D'autres objets spécialisés sont des objets d'écoute d'événement contenant chacun une méthode de rappel qui est appelée à chaque événement externe ou interne. Par exemple, lorsqu'un bouton logiciel affiché sur l'écran est sélectionné par l'utilisateur, une méthode de rappel incluse dans l'un des objets d'écoute d'événement est appelée en ayant comme arguments l'objet-afficheur de l'affichage courant et la commande représentant le bouton générateur de l'événement. La méthode de rappel contient des parties de codes à exécuter, par exemple relatives à des appels d'autres méthodes dont certaines peuvent être critiques, et un appel de méthode pour exécuter l'affichage suivant.
Dans la suite de la description, une interaction entre l'utilisateur et l'application correspond à une action de l'utilisateur sur le terminal mobile, déclenchant un événement externe, et l'intervalle de temps entre deux interactions correspond à un segment d'exécution de l'application où l'utilisateur n'a pas le contrôle de l'application et pendant lequel une méthode critique peut être exécutée plusieurs fois. Comme montré à la figure 1, des appels d'une méthode critique MC qui commande un envoi de message court depuis un terminal mobile sont lancés suite à différents événements survenus au cours du temps représenté par une flèche verticale dirigée vers le bas.
La plate-forme Java PFJ pouvant être exécutée par le microcontrôleur dans le terminal mobile inclut un environnement d'exécution EE comprenant des bibliothèques MIDP, un gestionnaire d'événement GE et différents processus légers, tels qu'un thread auxiliaire TA et un thread temporisé TT.
Initialement, une application est lancée par l'utilisateur du terminal mobile. Suite à un événement externe, tel que l'appui sur une touche du terminal mobile par l'utilisateur, l'environnement d'exécution EE appelle, à un instant tl, une méthode de rappel MR qui appelle la méthode critique MC à l'instant tl' ; la méthode critique MC est exécutée par la machine virtuelle de la plate-forme PFJ sous le contrôle du gestionnaire d'événement GE.
La méthode de rappel appelle ensuite à un instant t2 une méthode d'enregistrement d'action MEA de l'environnement d'exécution EE qui est une temporisation d'un thread qui sera donc exécuté, après un temps prédéterminé, à un instant t5. La méthode de rappel MR appelle en outre à un instant t3 une méthode de création MCTA d'un thread auxiliaire TA qui exécute automatiquement la méthode critique MC. A un instant t4, le gestionnaire d'événement GE arrête l'exécution de la méthode de rappel MR pour traiter par exemple un nouvel événement externe.
A l'expiration du temps prédéterminé, l'environnement d'exécution appelle, à un instant t5, un thread temporisé TT qui exécute automatiquement la méthode critique MC.
La figure 1 illustre non seulement l'appel de la méthode critique MC à l'instant tl' pour commander l'envoi d'un message court selon l'exécution du pseudocode par le gestionnaire d'événement, mais aussi les envois de deux messages courts indirectement générés par l'événement externe aux instants t3 et t5. Ainsi, pendant un segment d'exécution de l'application où l'utilisateur n'a pas le contrôle de l'application, par exemple entre les instants tl et t4, l'envoi de trois messages courts a été commandé.
Dans cet exemple, la méthode de rappel MR appelée à l'instant tl déclenche deux événements internes liés au thread auxiliaire et au thread temporisé pour envoyer deux autres messages courts.
Par conséquent, une estimation des différents appels à des méthodes critiques requiert une analyse du code de l'application pour chaque segment d'exécution de celle-ci qui s'étend entre deux interactions successives entre l'utilisateur et l'application, en accord avec l'objectif de l'invention.
La figure 2 représente un graphe d'appels d'une partie de code d'une application telle que celle décrite précédemment en référence à la figure 1.
Le graphe d'appels comprend des nœuds correspondant respectivement aux différentes méthodes relatives à l'application et des arcs reliant chacun une méthode appelante à une méthode appelée. Chaque arc peut être annoté par l'instruction d'appel dans le code de la méthode appelante utilisée pour appeler la méthode appelée.
Par exemple, la méthode de rappel MR est reliée directement à la méthode critique MC puisqu'elle appelle cette dernière. De même, la méthode de rappel MR est reliée directement à la méthode d'enregistrement d'action MEA et à la méthode de création de thread auxiliaire MCTA. La méthode d'enregistrement d'action MEA déclenchera par la suite un appel à une méthode de création de thread temporisé TT de manière indirecte par un mécanisme interne à l'environnement d'exécution. Par conséquent, il n'existe pas de lien dans le graphe d'appels entre la méthode d'enregistrement d'action MEA et la méthode de création de thread temporisé TT.
En outre, la méthode de rappel MR peut être reliée à une première méthode appelée MAI qui appelle une deuxième méthode MA2. Eventuellement, la deuxième méthode appelée MA2 peut appeler la méthode de rappel MR, créant ainsi une boucle d'appels dans le graphe d'appels due à des appels récursifs de la méthode de rappel MR.
En référence à la figure 3, un dispositif de traitement de données DTD pour déterminer une borne supérieure du nombre d'appels d'une méthode critique d'une application entre deux interactions entre un utilisateur et l'application selon une réalisation préférée de l'invention comprend une unité centrale UC, un module de construction de graphe d'appels MGA, un module d'identification MI, un module d'évaluation ME et au moins un fichier de classes FC.
Le dispositif de traitement de données DTD selon l'invention est un ordinateur du type ordinateur personnel, ou serveur, ou terminal, ou une combinaison de ces derniers.
Les fichiers de classe FC comprennent des informations définissant des classes de l'application à tester et sont mis à disposition de l'unité centrale UC et du module de construction de graphe d'appels MGA dans le dispositif DTD pour effectuer une analyse statique du code de l'application. L'analyse statique est un ensemble d'opérations pour obtenir des propriétés sur les exécutions possibles du code sans effectuer la moindre exécution réelle.
En particulier, une analyse statique peut être une "dévirtualisation" qui détermine pour chaque appel d'une méthode sur un objet les mises en œuvre possibles de la méthode qui pourraient être utilisées lors de l'appel de la méthode. En d'autres termes, la dévirtualisation détermine les classes qui répondent au cours de l'exécution à un appel de méthode, c'est-à- dire les classes contenant une méthode susceptible de répondre à l'appel de méthode. Lors de l'exécution réelle du code, seulement l'une de ces classes sera activée en réponse à l'appel de méthode.
Le module de construction de graphe d'appels MGA construit et mémorise un graphe d'appels GA relatif à l'application à tester, dont des parties peuvent être analogues au graphe simple montré à titre d'exemple à la figure 2. A partir du graphe d'appels GA, le module d'identification MI identifie au moins une méthode critique MC et des méthodes de rappel MR de l'application et le module d'évaluation ME détermine une borne sur le nombre d'appels de la méthode critique MC.
En référence à la figure 4, le procédé selon l'invention pour déterminer une borne supérieure de nombres d'appels d'une méthode critique d'une application entre deux interactions entre l'application et un utilisateur comprend des étapes El à E7 exécutées sous le contrôle de l'unité centrale UC dans le dispositif de traitement de données DTD et mises en œuvre par des instructions d'un programme d'ordinateur enregistré sur un support d'enregistrement lisible par le dispositif de traitements de données. Initialement, l'application développée par un développeur est transmise à une SSII chargée de tester l'application, sous forme de fichiers de classe FC qui sont mémorisés dans le dispositif de traitement de données DTD. A l'étape El, le module de construction de graphe d'appels MGA construit à partir des fichiers de classe FC un graphe d'appels GA relatif à l'application à valider. Chaque arc relie une méthode appelante à une méthode appelée et est annoté par une instruction d'appel de la méthode appelée. Le graphe d'appels GA est par exemple construit au moyen d'une opération de dévirtualisation, puisque des méthodes sont appelées indirectement à travers des objets dont la classe n'est pas nécessairement connue avant l'exécution. A l'étape E2, le module de construction de graphe d'appels MGA modifie le graphe d'appels en remplaçant chaque arc annoté par une instruction d'appel reliant une méthode appelante à une méthode d'enregistrement d'action MEA comme méthode appelée, par un ensemble d'arcs annotés par la même instruction d'appel reliant la méthode appelante aux différentes méthodes de rappel MR susceptibles d'être déclenchées en réponse à l'appel de la méthode d'enregistrement d'action MEA. L'intérêt de cette modification dans le graphe d'appels est d'y inclure toutes les méthodes de rappel qui réagissent à des événements internes et qui sont indirectement appelées par l'environnement d'exécution. En effet, comme illustré à la figure 1, une méthode d'enregistrement d'action MEA appelée peut activer une méthode intermédiaire lançant un thread temporisé dont la création est gérée par l'environnement d'exécution, et le thread temporisé peut exécuter une méthode de rappel appelant une méthode critique. La méthode source initialement reliée à la méthode d'enregistrement d'action MEA est alors reliée à la méthode de rappel qui est elle-même reliée à la méthode critique. A l'étape E3, le module d'identification MI identifie dans le graphe d'appels la méthode critique MC et des méthodes de rappel MR appelées en réponse à des événements externes, tels qu'un e sollicitation d'un bouton logiciel par l'utilisateur.
A l'étape E4, le module d'évaluation ME estime dans le graphe d'appels GA un nombre d'appels NA de la méthode critique identifiée MC pour chaque méthode de rappel identifiée MR selon une approximation sur les nombres d'appels de méthode décrite ci-après dans les étapes E41 à E44.
A l'étape E41, le module d'évaluation ME détermine des boucles d'appels dans le graphe d'appels GA, par exemple en utilisant "l'algorithme de Tarjan" (cf. l'article de R. E. Tarjan intitulé "Depth First Search and Linear Graph Algorithme" , SIAM Journal on Computing 1(2), pages 146 à 160, 1972) pour le calcul des composantes fortement connexes d'un graphe. Le module d'évaluation ME annote par une étoile "*" toutes les méthodes du graphe d'appels faisant partie d'une boucle déterminée dans le graphe d'appels.
A l'étape E42, le module d'évaluation ME construit un graphe de flot de contrôle GFC pour chaque méthode appelante. Le "graphe de flot de contrôle" d'une méthode appelante est un graphe dont les nœuds représentent les instructions de la méthode appelante et les arcs représentent l'exécution fictive d'une instruction de destination immédiatement après une instruction de source, au cours d'une exécution de la méthode appelante. Le module d'évaluation ME détermine des boucles dans le graphe de flot de contrôle GFC de la méthode appelante. Puis le module d'évaluation ME annote par une étoile "*" toutes les instructions d'appels relatives à la méthode appelante et associées en tant qu'étiquettes aux arcs du graphe d'appels, qui appartiennent à une boucle du graphe de flot de contrôle de la méthode appelante.
A l'étape E43, le module d'évaluation ME repère tous les chemins sans boucle dans le graphe d'appels GA. Pour chaque chemin reliant une méthode de rappel dite "source" à la méthode critique dite "cible", le chemin est pondéré par un coefficient égal à "1" si aucune méthode ou instruction appartenant au chemin n'est annotée par une étoile. Dans le cas contraire, le chemin est pondéré par un coefficient égal à "*", qui est une valeur fictive.
A l'étape E44, pour chaque paire constituée d'une méthode de rappel identifiée MR et de la méthode critique MC, le module d'évaluation ME estime la somme des coefficients des chemins reliant la méthode de rappel à la méthode critique. En particulier, le module d'évaluation ME utilise l'approximation suivante : Vn, * + n = *, où n est un entier naturel correspondant à la somme partielle des coefficients des chemins. Dès qu'un chemin comporte une étoile, le nombre d'appels de la méthode critique n'est plus borné ; le nombre d'appels est représenté par la valeur fictive "*", et l'estimation de la somme est alors interrompue. Chaque somme représente une estimation de la borne supérieure sur le nombre d'appels NA d'une méthode critique MC lors de l'exécution d'une méthode de rappel MR donnée.
A l'étape E5, le module d'évaluation ME compare tous les nombres d'appels estimés NA respectivement attribués aux méthodes de rappel identifiées et détermine une borne supérieure BS comme la valeur maximale des nombres d'appels estimés NA de la méthode critique MC.
Si l'un des nombres d'appels estimés a la valeur fictive "*", alors la borne supérieure est l'infini.
A une étape optionnelle E6, le dispositif de traitement de données DTD invalide l'application si la borne supérieure BS excède un seuil prédéterminé SP. Le seuil prédéterminé SP peut être fixé par l'opérateur et vaut par exemple "3" pour une méthode critique relative à un envoi de message court. Dans ce cas, l'application est refusée et renvoyée à la société de service ayant développé l'application.
Si en revanche la borne supérieure BS est inférieure ou égale au seuil prédéterminé SP, le dispositif de traitement de données DTD peut valider l'application ; celle-ci peut alors être mise à disposition, par exemple dans un serveur, afin de pouvoir être téléchargée dans des terminaux mobiles d'utilisateurs clients de l'opérateur. L'invention décrite ici concerne un procédé et un dispositif pour déterminer une borne supérieure de nombres d'appels d'une méthode critique d'une application. Selon une implémentation préférée, les étapes du procédé de l'invention sont déterminées par les instructions d'un programme d'ordinateur incorporé dans un dispositif de traitement de données tel que le dispositif DTD. Le programme comporte des instructions de programme qui, lorsque ledit programme est exécuté dans le dispositif dont le fonctionnement est alors commandé par l'exécution du programme, réalisent les étapes du procédé selon l'invention.
En conséquence, l'invention s'applique également à un programme d'ordinateur, notamment un programme d'ordinateur sur ou dans un support d'informations, adapté à mettre en œuvre l'invention. Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable pour implémenter le procédé selon l'invention.
Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage ou support d'enregistrement sur lequel est enregistré le programme d'ordinateur selon l'invention, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore une clé USB, ou un moyen d'enregistrement magnétique, par exemple une disquette (floppy dise) ou un disque dur.
D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type internet.
Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé selon 1 ' invention .

Claims

REVENDICATIONS
1 - Procédé pour déterminer une borne supérieure (BS) de nombres d'appels d'une méthode critique (MC) d'une application entre deux interactions entre l'application et un utilisateur, l'application étant écrite dans un langage orienté objet s 'exécutant dans un environnement d'exécution appelant des méthodes de rappel (MR) de l'application en réponse soit à un événement interne à l'environnement lié à un appel de méthode d'enregistrement d'action (MEA) de l'environnement, soit à un événement externe, ledit procédé comprenant une construction (El) d'un graphe d'appels (GA) dont chaque arc relie une méthode appelante à une méthode appelée de l'application, caractérisé en ce qu'il comprend les étapes de : remplacer (E2) dans le graphe d'appels chaque arc ayant une méthode d'enregistrement d'action (MEA) comme méthode appelée par un ensemble d'arcs reliant la méthode appelante de l'arc à des méthodes de rappel (MR) susceptibles d'être déclenchées en réponse à l'appel de la méthode d'enregistrement d'action (MEA), identifier (E3) dans le graphe d'appels (GA) des méthodes de rappel (MR) appelées en réponse à des événements externes à l'environnement, estimer (E4) des nombres d'appels (NA) de la méthode critique identifiée (MC) dans le graphe d'appels (GA) respectivement pour les méthodes de rappel (MR) identifiées, et déterminer (E5) la borne supérieure (BS) des nombres d'appels estimés (NA) de la méthode critique. 2 - Procédé conforme à la revendication 1, comprenant en outre des étapes de : déterminer (E41) des boucles d'appels dans le graphe d'appels (GA), pour chaque méthode appelante, déterminer (E42) des boucles dans un graphe de flot de contrôle (GFC) contenant des instructions d'appel de la méthode appelante, pondérer (E43) des chemins reliant une méthode de rappel identifiée (MR) à la méthode critique (MC) dans le graphe d'appels (GA) respectivement par des coefficients en fonction des boucles déterminées dans le graphe d'appels et dans le graphe de flot de contrôle (GFC) de chaque méthode appelante, et pour chaque méthode de rappel identifiée, estimer (E44) le nombre d'appels (NA) de la méthode critique (MC) en calculant la somme des coefficients des chemins.
3 - Procédé conforme à la revendication 1 ou à la revendication 2, caractérisé en ce que ladite application écrite dans un langage orienté objet a été compilée en un pseudolangage.
4 - Procédé conforme à l'une quelconque des revendications 1 à 3, selon lequel ledit environnement d'exécution comprend des bibliothèques pour profil de terminal .
5 - Procédé conforme à l'une quelconque des revendications 1 à 4, selon lequel l'application est téléchargeable dans un terminal.
6 - Dispositif de traitement de données pour déterminer une borne supérieure (BS) de nombres d'appels d'une méthode critique (MC) d'une application entre deux interactions entre l'application et un utilisateur, l'application étant écrite dans un langage orienté objet s 'exécutant dans un environnement d'exécution appelant des méthodes de rappel (MR) de l'application en réponse soit à un événement interne à l'environnement lié à un appel de méthode d'enregistrement d'action (MEA) de l'environnement, soit à un événement externe, ledit dispositif comprenant un moyen (MGA) pour construire un graphe d'appels (GA) dont chaque arc relie une méthode appelante à une méthode appelée de l'application, caractérisé en ce qu'il comprend : un moyen (MGA) pour remplacer dans le graphe d'appels (GA) chaque arc ayant une méthode d'enregistrement d'action (MEA) comme méthode appelée par un ensemble d'arcs reliant la méthode appelante de l'arc à des méthodes de rappel (MR) susceptibles d'être déclenchées en réponse à l'appel de la méthode d'enregistrement d'action (MEA), un moyen (MI) pour identifier dans le graphe d'appels (GA) des méthodes de rappel (MR) appelées en réponse à des événements externes à l'environnement, un moyen (ME) pour estimer des nombres d'appels (NA) de la méthode critique identifiée (MC) dans le graphe d'appels (GA) respectivement pour les méthodes de rappel (MR) identifiées, et un moyen (ME) pour déterminer la borne supérieure (BS) des nombres d'appels estimés (NA) de la méthode critique .
7 - Programme d'ordinateur comportant des instructions pour l'exécution des étapes du procédé selon l'une quelconque des revendications 1 à 5, lorsque ledit programme est exécuté par un dispositif de traitements de données.
8 - Support d'enregistrement lisible par un dispositif de traitement de données sur lequel est enregistré un programme d'ordinateur comportant des instructions pour l'exécution des étapes du procédé selon l'une quelconque des revendications 1 à 5.
9 - Procédé de validation par un opérateur de réseau ou par une société de services et d'ingénierie en informatique d'une application écrite dans un langage orienté objet, caractérisé en ce qu'il comprend les étapes suivantes : tester l'application au moyen d'un procédé conforme à l'une quelconque des revendications 1 à 5, et valider l'application si la borne supérieure (BS) des nombres d'appels estimés de la méthode critique est inférieure ou égale à un seuil prédéterminé (SP), et l'invalider dans le cas contraire.
EP07766022A 2006-05-18 2007-05-10 Determination de nombres d'appels de methode critique dans une application en langage objet Withdrawn EP2018610A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0651821A FR2901378A1 (fr) 2006-05-18 2006-05-18 Determination de nombres d'appels de methode critique dans une application en langage objet
PCT/FR2007/051242 WO2007135316A1 (fr) 2006-05-18 2007-05-10 Determination de nombres d'appels de methode critique dans une application en langage objet

Publications (1)

Publication Number Publication Date
EP2018610A1 true EP2018610A1 (fr) 2009-01-28

Family

ID=37708265

Family Applications (1)

Application Number Title Priority Date Filing Date
EP07766022A Withdrawn EP2018610A1 (fr) 2006-05-18 2007-05-10 Determination de nombres d'appels de methode critique dans une application en langage objet

Country Status (3)

Country Link
EP (1) EP2018610A1 (fr)
FR (1) FR2901378A1 (fr)
WO (1) WO2007135316A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112395603B (zh) * 2019-08-15 2023-09-05 奇安信安全技术(珠海)有限公司 基于指令执行序列特征的漏洞攻击识别方法、装置及计算机设备

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2007135316A1 *

Also Published As

Publication number Publication date
WO2007135316A1 (fr) 2007-11-29
FR2901378A1 (fr) 2007-11-23

Similar Documents

Publication Publication Date Title
US10990461B2 (en) Application interaction method, interaction method and apparatus
KR100972270B1 (ko) 사용자 인터페이스 컴포넌트들을 무선 디바이스들에 다운로드하기 위한 시스템 및 방법
US9116608B2 (en) Activation of dormant features in native applications
CN102073507B (zh) 微件Widget调用的方法、装置和系统
US10481964B2 (en) Monitoring activity of software development kits using stack trace analysis
US20150332043A1 (en) Application analysis system for electronic devices
CN113055492A (zh) 服务灰度链路的控制方法、装置、计算机设备和存储介质
US20130160126A1 (en) Malware remediation system and method for modern applications
US10437577B2 (en) Systems and methods for mobile application installation
US11886600B2 (en) Testing instrumentation for intrusion remediation actions
US12164588B2 (en) Enhanced navigation in a web browser while avoiding redirects
CN108089870A (zh) 用于修复应用的方法和装置
CN113010892A (zh) 小程序恶意行为检测方法和装置
WO2005084202A2 (fr) Execution de programmes non verifies dans un environnement d'exploitation de dispositif sans fil
CN120010913B (zh) 一种面向微前端的通用基础能力适配方法、设备及存储介质
CN105512552B (zh) 参数检测方法及装置
EP2018610A1 (fr) Determination de nombres d'appels de methode critique dans une application en langage objet
CN112131085B (zh) 互联网业务过程记录与回放的方法、系统及装置
US20140149488A1 (en) System and method for engaging a mobile device
CN104978214B (zh) 一种组件加载方法、装置及终端
US11520866B2 (en) Controlling processor instruction execution
CN111124627A (zh) 应用程序的调起者确定方法、装置、终端及存储介质
CN114969723B (zh) 沙箱防御方法、装置、电子设备和计算机可读存储介质
CN117633789A (zh) 应用程序的安全检测方法、装置、设备和存储介质
CN119598214A (zh) 违规广告识别方法、装置、电子设备及存储介质

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20081021

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC MT NL PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA HR MK RS

RIN1 Information on inventor provided before grant (corrected)

Inventor name: CACHERA, DAVID

Inventor name: PICHARDIE, DAVID

Inventor name: SCHNEIDER, GERARDO

Inventor name: JENSEN, THOMAS

Inventor name: ALVARADO, CUIHTLAUAC

Inventor name: CREGUT, PIERRE

RIN1 Information on inventor provided before grant (corrected)

Inventor name: CACHERA, DAVID

Inventor name: PICHARDIE, DAVID

Inventor name: SCHNEIDER, GERARDO

Inventor name: JENSEN, THOMAS

Inventor name: ALVARADO, CUIHTLAUAC

Inventor name: CREGUT, PIERRE

DAX Request for extension of the european patent (deleted)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ORANGE

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20141202