WO2004097603A1 - Protecting a java application - Google Patents

Protecting a java application Download PDF

Info

Publication number
WO2004097603A1
WO2004097603A1 PCT/GB2004/001887 GB2004001887W WO2004097603A1 WO 2004097603 A1 WO2004097603 A1 WO 2004097603A1 GB 2004001887 W GB2004001887 W GB 2004001887W WO 2004097603 A1 WO2004097603 A1 WO 2004097603A1
Authority
WO
WIPO (PCT)
Prior art keywords
classfile
operable
additional
execution
application
Prior art date
Application number
PCT/GB2004/001887
Other languages
French (fr)
Inventor
John Aram Safa
Original Assignee
Bitarts 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 Bitarts Limited filed Critical Bitarts Limited
Publication of WO2004097603A1 publication Critical patent/WO2004097603A1/en

Links

Classifications

    • 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/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/12—Protecting executable software
    • G06F21/121—Restricting unauthorised execution of programs
    • G06F21/125—Restricting unauthorised execution of programs by manipulating the program code, e.g. source code, compiled code, interpreted code, machine code

Definitions

  • the present invention relates to a method of protecting a Java application, and to apparatus associated therewith.
  • Java Virtual Machine Java Virtual Machine
  • any Java application can be executed on any JVM and is thus platform independent.
  • Each JVM is not platform independent, being required to translate between the platform independent Java code, and the necessary instructions to execute the Java instruction on the local physical machine.
  • the platform independence has led to Java being widely used in networks to which many users gain access by means of a range of different equipment, such as the internet and wireless communication networks.
  • the present invention provides a method of protecting a Java application prior to delivery to a wireless device, comprising the steps of: obtaining a compiled Java ClassFile of the application to be protected; introducing additional bytecode into the ClassFile, the additional bytecode being operable on a Java Virtual Machine to perform at least one security function; and modifying register data held within the ClassFile to reflect the presence of the additional bytecode, whereby the modified ClassFile will, upon execution by a JVM within a wireless device, implement the security function.
  • the additional bytecode contains at least one additional method.
  • the additional bytecode may include a Call instruction operable to call the or an additional method.
  • the additional bytecode is preferably introduced into the ClassFile after the methods contained in the unmodified
  • the security function may be operable upon execution of the application on a wireless device, to determine if the execution is authorised, and to prevent further execution in the event that it is not.
  • Authorisation may be determined by reference to the identity of the device or user, to the time of use, or to the number of authorised executions which have been completed.
  • Authorisation may include making access to a remote system by means of a wireless network with which the device is in communication, the remote system being operable to participate in determining authorisation.
  • the remote system may be operable to execute a payment function.
  • the invention also provides software which, when installed on a computer system, is operable to perform the method as set out in the preceding definitions.
  • the invention also provides a carrier medium carrying software as aforesaid.
  • the carrier medium may be a data storage device.
  • the invention also provides a Java application protected by application to it of the method set out above.
  • the invention also provides a carrier medium carrying software as just defined.
  • the carrier medium may be a data storage device.
  • the carrier medium may be a transmission medium, the software being carried by a signal propagating over the medium.
  • the present invention also provides an apparatus for protecting a Java application prior to delivery to a wireless device, comprising: storage means for containing a compiled Java ClassFile of the application to be protected; modifying means operable to introduce additional bytecode into the
  • the additional bytecode being operable on a Java Virtual Machine to perform at least one security function, and further operable to modify register data held within the ClassFile to reflect the presence of the additional bytecode, whereby the modified ClassFile will, upon execution by a JVM within a wireless device, implement the security function.
  • the modifying means introduces additional bytecode containing at least one additional method.
  • the additional bytecode may include a Call instruction operable to call the or an additional method.
  • the additional bytecode is preferably introduced into the ClassFile after the methods contained in the unmodified ClassFile.
  • the security function may be operable upon execution of the application on a wireless device, to determine if the execution is authorised, and to prevent further execution in the event that it is not.
  • Authorisation may be determined by reference to the identity of the device or user, to the time of use, or to the number of authorised executions which have been completed.
  • Authorisation may include making access to a remote system by means of a wireless network with which the device is in communication, the remote system being operable to participate in determining authorisation.
  • the remote system may be operable to execute a payment function.
  • the invention also provides software which, when installed on a computer system, is operable to provide apparatus as set out in the preceding definitions.
  • the invention also provides a carrier medium carrying software as aforesaid.
  • the carrier medium may be a data storage device, or may be a transmission medium, the software being carried by a signal propagating on the medium.
  • FIG. 1 is a simple schematic diagram of a wireless communication network which is an example of the environment with which the present invention may be used;
  • Fig. 2 is a simplified schematic diagram of a wireless device of the system of Fig. 1 , enabled to execute Java applications;
  • Fig. 3 is a schematic diagram of the server of the system of Fig. 1 ;
  • Fig. 4 is a flow diagram of the steps implemented in a method according to the present invention.
  • Figs. 5A and 5B are schematic illustrations of unmodified and modified ClassFiles, respectively.
  • Fig. 6 is a flow diagram of the steps for executing a Java application protected in accordance with the invention.
  • Fig. 1 illustrates a communication system 10 which includes wireless devices 12 and a wireless communication network 14, by means of which the devices 12 may communicate with each other and with a server 16.
  • the wireless devices 12 incorporate a JVM and are able to request Java applications to be delivered from the server 16 for execution on the devices 12.
  • Java applications may be games, for example.
  • the Java applications are provided in a protected form, so that they will execute on the device 12 for which they are intended, but are protected against execution after copying onto an alternative device.
  • Fig. 2 illustrates one of the devices 12, in more detail.
  • the device 12 is based around a processor 18.
  • Memory 20 is associated with the processor 18.
  • a bus 22 provides communication between the processor 18 and input/output systems 24 (particularly a radio transceiver for wireless communication with the network 14), and with user facilities such as a display 26 and user controls 28.
  • the memory 20 is divided into permanent memory 20A, containing an operating system 30 and a JVM 32, and temporary memory 20B which may contain a Java application 34 or another application 36.
  • a user may use the device 12 to request a Java application 34 to be obtained from the apparatus 16, for execution within the device 12.
  • the Java application 34 may be a game to be played on the device 12.
  • Fig. 3 schematically illustrates those components within the server 16, which contribute to the performance of the invention.
  • the server 16 is based around a processor 38 having temporary memory 40 and permanent memory 42.
  • the processor 38 communicates with the permanent memory 42 by means of a bus 44 which also allows communication with input/output systems at 46, for communication with the network 14 at 48.
  • the permanent memory 42 contains a Java application 50, such as a game, which is available for downloading to a wireless device when a request is received over the network 14.
  • the Java application 50 is stored in memory 42 in compiled form, i.e. as a bytecode ClassFile. It is envisaged that the application 50 may be a proprietary application written by a software house which is independent of the owner and operator of the server 16, which may be a re-seller of the software 50. It is thus important to note that the application 50 is not a source code file, that the operator of the server 16 may not have access to source code for the application 50, and that the operator of the server 16 does not need to have access to the source code, in order to implement the present invention.
  • the memory 42 may include a library of Java applications 50, from which a user of a wireless device may select, such as a library of different games.
  • the memory 42 also includes application software 52 for execution by the processor 38 to treat the Java application 50, in order to protect the application 50, in accordance with the invention, as will be described. This requires access to one or more additional Java methods, stored in a library of methods 54.
  • the memory 42 also includes a software application 55 for authorisation purposes, which will be described below.
  • the operation begins at step 56 with the receipt at 46 of a request from a device 12 for delivery of a Java application 50.
  • a request For example, a user may wish to play a game and requires the Java application 50 in order to do so.
  • the treatment application 52 is loaded to temporary memory 40 for execution, at step 58.
  • Execution of the treatment application 52 commences at 60 under control of the operating system 61.
  • the Java application 50 (or the particular application specified in the request received) is copied to temporary memory 40, at 62, to be readily accessible by the treatment application 52.
  • the application to be treated is schematically illustrated in Fig. 5A.
  • the application 62 is a Java ClassFile which includes a number of methods 64, executable by a JVM.
  • the software 62 also includes data at 66, here referred to as a header, for simplicity.
  • the header 66 includes data relating to the ClassFile and in a standard format for access by the JVM.
  • the header 66 includes components such as a count of the number of methods within the ClassFile.
  • the contents of the header 66 must relate correctly with the contents of the ClassFile 62 (as set out in the specification for the Java language), otherwise the ClassFile will be corrupt and will not execute correctly.
  • one or more methods is copied from the method library 54 and added to the ClassFile 62 (step 72) as an additional method (NEW METHOD) at the end of the modified ClassFile 62', that is, after the methods of the unmodified ClassFile 62.
  • the NEW METHOD may be inserted in a gap identified at 68.
  • Further bytecode is added to the ClassFile 62' at step 74, immediately after the header 66 to provide a CALL command. By virtue of the position, the CALL command will execute as the first instruction when the ClassFile is executed, and is written to call the NEW METHOD for execution before any of the methods from the unmodified ClassFile.
  • the resulting modified ClassFile 62' shown in Fig. 5B, will, at this stage, be corrupt because it has been extended in length, and the boundaries of the original methods have moved, by virtue of the insertion of the CALL instruction. Consequently, the contents of the header 66 will not correspond correctly with the modified ClassFile.
  • the modified ClassFile 62' now has the protection of the invention, by virtue of the inclusion of the NEW METHOD method and can therefore be delivered at 78 to the device 12 which made the request, by propagating a signal over the network 14.
  • the device 12 will therefore receive a Java ClassFile which incorporates the whole of the ClassFile of the proprietary application 50, and the additional security provided from the library 54, but still in correct, uncorrupted and executable form by virtue of the modifications made to the header 66.
  • the modified application 62 received by the device 12, can be executed by means of the JVM 32, as will now be described with reference to Fig. 6.
  • the header 66' is first analysed in conventional manner (and will be found to be in accordance with the language specification by virtue of the modifications made). Execution then continues at 82 by executing the CALL function to call NEW METHOD, executed at 83. Execution of NEW METHOD executes various security steps 84 to 92 illustrated in Fig. 6 and which may be present in various combinations. Some may be omitted. These steps seek to determine if the execution is authorised, and to prevent further execution in the event that it is not. Thus, the following are examples of steps which may be taken to determine correct authorisation: 1. Identify the device 12 (step 84), to determine if the device is the device for which the modified application 62' was provided.
  • step 86 Identify the user (step 86), to determine if the user is the user for which the modified application 62' was provided.
  • step 86 Identify the current time (step 86) and determine if a time limitation has expired.
  • step 90 Identify the number of times the modified application 62' has been executed (step 90), to determine if execution based credit has expired.
  • step 92 Identify (step 92) if finance-based credit has expired.
  • One or more of the security checks set out above may require a user to enter information into the device 12, such as a pin number, a credit card number (for charging purposes) or the like. Furthermore, one or more of the steps may require access to outside resources to complete the authorisation operation. This is achieved by communication over the network 14. In the example being described, communication is established again with the server 16, but it is to be understood that it is not an essential feature of the invention for the features which are now to be described to be implemented on the same server which prepared the application 50 for delivery to the device 12.
  • receipt of a message from a device 12, relating to authorisation, causes the authorisation software 55 to be loaded from the memory 42 to the temporary memory 40 for execution by the processor 38.
  • Execution of the software 55 determines if the execution of the Java application is authorised. This will require the device to send information relevant to one or more of the tests set out above, for analysis by the authorisation software 55, which may, for example, have access to a database of users, credit status, device identities etc. In addition, there may be access to appropriate systems for implementing a payment, such as by charging a credit card or other account to pay for the execution being requested, or to pay for unlimited execution during a set period of time, or to pay for a number of executions during an unlimited period of time in the future.
  • the checks which are made can be implemented primarily within the authorisation software 55 and thus be inaccessible to a user seeking to circumvent the security. This further enhances the protection of the software.

Abstract

A Java application is protected for security reasons, before delivery. The ClassFile (62) is extended to include an additional method (NEW METHOD), either at the end of the ClassFile (62') (as shown), or in gaps within the ClassFile (62). Data within the header (66) is then modified to provide the header (66'), so that the contents of the header (66') correspond correctly with the content of the modified ClassFile (62'). The NEW METHOD method includes security checks, encryption or the like, thus protecting the modified ClassFile (62').

Description

Protecting a Java Application
The present invention relates to a method of protecting a Java application, and to apparatus associated therewith.
The present invention arises from the recent success of the Java programming language. A Java application is written for execution by a Java Virtual Machine (JVM), which is itself a software component resident on the relevant physical machine. In principle, any Java application can be executed on any JVM and is thus platform independent. Each JVM is not platform independent, being required to translate between the platform independent Java code, and the necessary instructions to execute the Java instruction on the local physical machine. The platform independence has led to Java being widely used in networks to which many users gain access by means of a range of different equipment, such as the internet and wireless communication networks.
As the range of uses for wireless communication devices has increased, it has been proposed to provide each device with a JVM to allow the user to execute more complex tasks, such as playing games. However, the platform independence of Java applications presents a problem for potential suppliers of commercial Java applications, which can readily be copied from one wireless device to another, thus preventing the supplier from achieving the appropriate level of income from the application.
The present invention provides a method of protecting a Java application prior to delivery to a wireless device, comprising the steps of: obtaining a compiled Java ClassFile of the application to be protected; introducing additional bytecode into the ClassFile, the additional bytecode being operable on a Java Virtual Machine to perform at least one security function; and modifying register data held within the ClassFile to reflect the presence of the additional bytecode, whereby the modified ClassFile will, upon execution by a JVM within a wireless device, implement the security function.
Preferably the additional bytecode contains at least one additional method. The additional bytecode may include a Call instruction operable to call the or an additional method. The additional bytecode is preferably introduced into the ClassFile after the methods contained in the unmodified
ClassFile.
The security function may be operable upon execution of the application on a wireless device, to determine if the execution is authorised, and to prevent further execution in the event that it is not. Authorisation may be determined by reference to the identity of the device or user, to the time of use, or to the number of authorised executions which have been completed. Authorisation may include making access to a remote system by means of a wireless network with which the device is in communication, the remote system being operable to participate in determining authorisation. The remote system may be operable to execute a payment function.
The invention also provides software which, when installed on a computer system, is operable to perform the method as set out in the preceding definitions. The invention also provides a carrier medium carrying software as aforesaid. The carrier medium may be a data storage device.
The invention also provides a Java application protected by application to it of the method set out above. The invention also provides a carrier medium carrying software as just defined. The carrier medium may be a data storage device. The carrier medium may be a transmission medium, the software being carried by a signal propagating over the medium.
The present invention also provides an apparatus for protecting a Java application prior to delivery to a wireless device, comprising: storage means for containing a compiled Java ClassFile of the application to be protected; modifying means operable to introduce additional bytecode into the
ClassFile, the additional bytecode being operable on a Java Virtual Machine to perform at least one security function, and further operable to modify register data held within the ClassFile to reflect the presence of the additional bytecode, whereby the modified ClassFile will, upon execution by a JVM within a wireless device, implement the security function.
Preferably the modifying means introduces additional bytecode containing at least one additional method. The additional bytecode may include a Call instruction operable to call the or an additional method. The additional bytecode is preferably introduced into the ClassFile after the methods contained in the unmodified ClassFile.
The security function may be operable upon execution of the application on a wireless device, to determine if the execution is authorised, and to prevent further execution in the event that it is not. Authorisation may be determined by reference to the identity of the device or user, to the time of use, or to the number of authorised executions which have been completed. Authorisation may include making access to a remote system by means of a wireless network with which the device is in communication, the remote system being operable to participate in determining authorisation. The remote system may be operable to execute a payment function.
The invention also provides software which, when installed on a computer system, is operable to provide apparatus as set out in the preceding definitions. The invention also provides a carrier medium carrying software as aforesaid. The carrier medium may be a data storage device, or may be a transmission medium, the software being carried by a signal propagating on the medium.
Examples of the present invention will now be described in more detail, by way of example only, and with reference to the accompanying drawings, in which: Fig. 1 is a simple schematic diagram of a wireless communication network which is an example of the environment with which the present invention may be used;
Fig. 2 is a simplified schematic diagram of a wireless device of the system of Fig. 1 , enabled to execute Java applications;
Fig. 3 is a schematic diagram of the server of the system of Fig. 1 ;
Fig. 4 is a flow diagram of the steps implemented in a method according to the present invention;
Figs. 5A and 5B are schematic illustrations of unmodified and modified ClassFiles, respectively; and
Fig. 6 is a flow diagram of the steps for executing a Java application protected in accordance with the invention.
Fig. 1 illustrates a communication system 10 which includes wireless devices 12 and a wireless communication network 14, by means of which the devices 12 may communicate with each other and with a server 16. In particular, the wireless devices 12 (to be described more fully below) incorporate a JVM and are able to request Java applications to be delivered from the server 16 for execution on the devices 12. These applications may be games, for example. In accordance with the invention, the Java applications are provided in a protected form, so that they will execute on the device 12 for which they are intended, but are protected against execution after copying onto an alternative device.
Fig. 2 illustrates one of the devices 12, in more detail. The device 12 is based around a processor 18. Memory 20 is associated with the processor 18. A bus 22 provides communication between the processor 18 and input/output systems 24 (particularly a radio transceiver for wireless communication with the network 14), and with user facilities such as a display 26 and user controls 28.
The memory 20 is divided into permanent memory 20A, containing an operating system 30 and a JVM 32, and temporary memory 20B which may contain a Java application 34 or another application 36. During use, a user may use the device 12 to request a Java application 34 to be obtained from the apparatus 16, for execution within the device 12. For example, the Java application 34 may be a game to be played on the device 12.
Fig. 3 schematically illustrates those components within the server 16, which contribute to the performance of the invention.
The server 16 is based around a processor 38 having temporary memory 40 and permanent memory 42. The processor 38 communicates with the permanent memory 42 by means of a bus 44 which also allows communication with input/output systems at 46, for communication with the network 14 at 48.
The permanent memory 42 contains a Java application 50, such as a game, which is available for downloading to a wireless device when a request is received over the network 14. The Java application 50 is stored in memory 42 in compiled form, i.e. as a bytecode ClassFile. It is envisaged that the application 50 may be a proprietary application written by a software house which is independent of the owner and operator of the server 16, which may be a re-seller of the software 50. It is thus important to note that the application 50 is not a source code file, that the operator of the server 16 may not have access to source code for the application 50, and that the operator of the server 16 does not need to have access to the source code, in order to implement the present invention.
In a commercial realisation of the invention, the memory 42 may include a library of Java applications 50, from which a user of a wireless device may select, such as a library of different games. The memory 42 also includes application software 52 for execution by the processor 38 to treat the Java application 50, in order to protect the application 50, in accordance with the invention, as will be described. This requires access to one or more additional Java methods, stored in a library of methods 54.
The memory 42 also includes a software application 55 for authorisation purposes, which will be described below.
The method by which the apparatus which has been described may be used to protect the Java application 50, prior to delivery to a wireless device 12, may now be described with particular reference to Figs. 3 and 4.
The operation begins at step 56 with the receipt at 46 of a request from a device 12 for delivery of a Java application 50. For example, a user may wish to play a game and requires the Java application 50 in order to do so.
In response to the request, the treatment application 52 is loaded to temporary memory 40 for execution, at step 58. Execution of the treatment application 52 commences at 60 under control of the operating system 61. First, the Java application 50 (or the particular application specified in the request received) is copied to temporary memory 40, at 62, to be readily accessible by the treatment application 52.
The application to be treated is schematically illustrated in Fig. 5A. The application 62 is a Java ClassFile which includes a number of methods 64, executable by a JVM. The software 62 also includes data at 66, here referred to as a header, for simplicity. The header 66 includes data relating to the ClassFile and in a standard format for access by the JVM. For example, the header 66 includes components such as a count of the number of methods within the ClassFile. The contents of the header 66 must relate correctly with the contents of the ClassFile 62 (as set out in the specification for the Java language), otherwise the ClassFile will be corrupt and will not execute correctly.
Execution of the application 52 continues with the optional step 68 of identifying gaps within the ClassFile 62, the purpose of which will become apparent.
At step 70, one or more methods is copied from the method library 54 and added to the ClassFile 62 (step 72) as an additional method (NEW METHOD) at the end of the modified ClassFile 62', that is, after the methods of the unmodified ClassFile 62. Alternatively, the NEW METHOD may be inserted in a gap identified at 68. Further bytecode is added to the ClassFile 62' at step 74, immediately after the header 66 to provide a CALL command. By virtue of the position, the CALL command will execute as the first instruction when the ClassFile is executed, and is written to call the NEW METHOD for execution before any of the methods from the unmodified ClassFile.
The resulting modified ClassFile 62', shown in Fig. 5B, will, at this stage, be corrupt because it has been extended in length, and the boundaries of the original methods have moved, by virtue of the insertion of the CALL instruction. Consequently, the contents of the header 66 will not correspond correctly with the modified ClassFile.
This is corrected at step 76 by modifying the data within the header 66, to reflect parameters such as the total size of the ClassFile, the number of methods within the ClassFile (which is now increased) and the like.
The modified ClassFile 62' now has the protection of the invention, by virtue of the inclusion of the NEW METHOD method and can therefore be delivered at 78 to the device 12 which made the request, by propagating a signal over the network 14. The device 12 will therefore receive a Java ClassFile which incorporates the whole of the ClassFile of the proprietary application 50, and the additional security provided from the library 54, but still in correct, uncorrupted and executable form by virtue of the modifications made to the header 66.
The modified application 62, received by the device 12, can be executed by means of the JVM 32, as will now be described with reference to Fig. 6.
When execution begins at 80, the header 66' is first analysed in conventional manner (and will be found to be in accordance with the language specification by virtue of the modifications made). Execution then continues at 82 by executing the CALL function to call NEW METHOD, executed at 83. Execution of NEW METHOD executes various security steps 84 to 92 illustrated in Fig. 6 and which may be present in various combinations. Some may be omitted. These steps seek to determine if the execution is authorised, and to prevent further execution in the event that it is not. Thus, the following are examples of steps which may be taken to determine correct authorisation: 1. Identify the device 12 (step 84), to determine if the device is the device for which the modified application 62' was provided.
2. Identify the user (step 86), to determine if the user is the user for which the modified application 62' was provided.
3. Identify the current time (step 86) and determine if a time limitation has expired.
4. Identify the number of times the modified application 62' has been executed (step 90), to determine if execution based credit has expired.
5. Identify (step 92) if finance-based credit has expired.
In the event that any of these security checks are failed, execution of the modified application 62' ceases at 94. In the event that all security checks are passed, execution hands to METHOD 1 at 96, to begin normal execution of the bytecode inherited from the unmodified, proprietary Java application 50. Thus, after the security checks have been made, and only if they are passed, the game or other application becomes available to the user.
One or more of the security checks set out above may require a user to enter information into the device 12, such as a pin number, a credit card number (for charging purposes) or the like. Furthermore, one or more of the steps may require access to outside resources to complete the authorisation operation. This is achieved by communication over the network 14. In the example being described, communication is established again with the server 16, but it is to be understood that it is not an essential feature of the invention for the features which are now to be described to be implemented on the same server which prepared the application 50 for delivery to the device 12.
In this example, receipt of a message from a device 12, relating to authorisation, causes the authorisation software 55 to be loaded from the memory 42 to the temporary memory 40 for execution by the processor 38.
Execution of the software 55 then determines if the execution of the Java application is authorised. This will require the device to send information relevant to one or more of the tests set out above, for analysis by the authorisation software 55, which may, for example, have access to a database of users, credit status, device identities etc. In addition, there may be access to appropriate systems for implementing a payment, such as by charging a credit card or other account to pay for the execution being requested, or to pay for unlimited execution during a set period of time, or to pay for a number of executions during an unlimited period of time in the future.
Thus, the checks which are made can be implemented primarily within the authorisation software 55 and thus be inaccessible to a user seeking to circumvent the security. This further enhances the protection of the software.
Java and Java-related terms are trade marks of Sun Microsystems. Whilst endeavouring in the foregoing specification to draw attention to those features of the invention believed to be of particular importance it should be understood that the Applicant claims protection in respect of any patentable feature or combination of features hereinbefore referred to and/or shown in the drawings whether or not particular emphasis has been placed thereon.

Claims

1. A method of protecting a Java application prior to delivery to a wireless device, comprising the steps of: obtaining a compiled Java ClassFile of the application to be protected; introducing additional bytecode into the ClassFile, the additional bytecode being operable on a Java Virtual Machine to perform at least one security function; and modifying register data held within the ClassFile to reflect the presence of the additional bytecode, whereby the modified ClassFile will, upon execution by a JVM within a wireless device, implement the security function.
2. A method according to claim 1 , wherein the additional bytecode contains at least one additional method.
3. A method according to claim 2, wherein the additional bytecode includes a Call instruction operable to call the or an additional method.
4. A method according to any preceding claim, wherein the additional bytecode is introduced into the ClassFile after the methods contained in the unmodified ClassFile.
5. A method according to any preceding claim, wherein the security function is operable upon execution of the application on a wireless device, to determine if the execution is authorised, and to prevent further execution in the event that it is not.
6. A method according to claim 5, wherein authorisation is determined by reference to the identity of the device or user, to the time of use, or to the number of authorised executions which have been completed.
7. A method according to claim 5 or 6, wherein authorisation includes making access to a remote system by means of a wireless network with which the device is in communication, the remote system being operable to participate in determining authorisation.
8. A method according to claim 7, wherein the remote system is operable to execute a payment function.
9. Software which, when installed on a computer system, is operable to perform the method according to any of claims 1 to 8.
10. A carrier medium carrying software according to claim 9.
11. A carrier medium according to claim 10, wherein the carrier medium is a data storage device.
12. A carrier medium according to claim 10, wherein the carrier medium is a transmission medium, the software being carried by a signal propagating over the medium.
13. Apparatus for protecting a Java application prior to delivery to a wireless device, comprising: storage means for containing a compiled Java ClassFile of the application to be protected; modifying means operable to introduce additional bytecode into the
ClassFile, the additional bytecode being operable on a Java Virtual Machine to perform, at least one security function, and further operable to modify register data held within the ClassFile to reflect the presence of the additional bytecode, whereby the modified ClassFile will, upon execution by a JVM within a wireless device, implement the security function.
14. Apparatus according to claim 13, wherein the modifying means introduces additional bytecode containing at least one additional method.
15. -Apparatus according to claim 14, wherein the additional bytecode includes a Call instruction operable to call the or an additional method.
16. Apparatus according to claim 14 or 15, wherein the additional bytecode is introduced into the ClassFile after the methods contained in the unmodified ClassFile.
17. Apparatus according to any of claims 13 to 16, wherein the security function is operable upon execution of the application on a wireless device, to determine if the execution is authorised, and to prevent further execution in the event that it is not.
18. Apparatus according to claim 17, wherein authorisation is determined by reference to the identity of the device or user, to the time of use, or to the number of authorised executions which have been completed.
19. Apparatus according to claim 17 or 18, wherein authorisation includes making access to a remote system by means of a wireless network with which the device is in communication, the remote system being operable to participate in determining authorisation.
20. Apparatus according to claim 19, wherein the remote system is operable to execute a payment function.
21. Software which, when installed on a computer system, is operable to provide apparatus according to any of claims 13 to 20.
22. A carrier medium carrying software as defined in claim 21.
23. A carrier medium according to claim 22, wherein the carrier medium is a data storage device.
24. A carrier medium according to claim 22, wherein the carrier medium is a transmission medium, the software being carried by a signal propagating on the medium.
25. A method of protecting a Java application, substantially as described above, with reference to the accompanying drawings.
26. Software which, when installed on a computer system, is operable to perform the method of claim 25.
27. Apparatus for protecting a Java application, substantially as described above, with reference to the accompanying drawings.
28. Any novel subject matter or combination including novel subject matter disclosed herein, whether or not within the scope of or relating to the same invention as any of the preceding claims.
PCT/GB2004/001887 2003-05-02 2004-04-30 Protecting a java application WO2004097603A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB0310144.1 2003-05-02
GB0310144A GB0310144D0 (en) 2003-05-02 2003-05-02 Protecting a java application

Publications (1)

Publication Number Publication Date
WO2004097603A1 true WO2004097603A1 (en) 2004-11-11

Family

ID=9957396

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB2004/001887 WO2004097603A1 (en) 2003-05-02 2004-04-30 Protecting a java application

Country Status (2)

Country Link
GB (1) GB0310144D0 (en)
WO (1) WO2004097603A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105335151A (en) * 2014-08-14 2016-02-17 优视科技有限公司 Installation file protection method and apparatus

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0893758A2 (en) * 1997-07-25 1999-01-27 Sun Microsystems, Inc. Detachable java applets
US6026237A (en) * 1997-11-03 2000-02-15 International Business Machines Corporation System and method for dynamic modification of class files
US6141698A (en) * 1997-01-29 2000-10-31 Network Commerce Inc. Method and system for injecting new code into existing application code
US20020007482A1 (en) * 1998-08-20 2002-01-17 Wily Technology, Inc. System for modifying object oriented code
WO2002084947A2 (en) * 2001-02-26 2002-10-24 4Thpass Inc. Method and system for transmission-based billing of applications

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6141698A (en) * 1997-01-29 2000-10-31 Network Commerce Inc. Method and system for injecting new code into existing application code
EP0893758A2 (en) * 1997-07-25 1999-01-27 Sun Microsystems, Inc. Detachable java applets
US6026237A (en) * 1997-11-03 2000-02-15 International Business Machines Corporation System and method for dynamic modification of class files
US20020007482A1 (en) * 1998-08-20 2002-01-17 Wily Technology, Inc. System for modifying object oriented code
WO2002084947A2 (en) * 2001-02-26 2002-10-24 4Thpass Inc. Method and system for transmission-based billing of applications

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105335151A (en) * 2014-08-14 2016-02-17 优视科技有限公司 Installation file protection method and apparatus

Also Published As

Publication number Publication date
GB0310144D0 (en) 2003-06-04

Similar Documents

Publication Publication Date Title
US8185918B2 (en) Method and system for managing access to add-on data files
AU722463B2 (en) Using a high level programming language with a microcontroller
US6499035B1 (en) Licensing java objects
KR101185130B1 (en) Method and apparatus for managing policies for time-based licenses on mobile devices
CA2333613C (en) Method of controlling usage of software components
RU2377634C2 (en) Licensing program interface
US20030033539A1 (en) Mobile code security architecture in an application service provider environment
US20080263366A1 (en) Self-verifying software to prevent reverse engineering and piracy
US20080300887A1 (en) Usage Model of Online/Offline License for Asset Control
EP1318488A2 (en) IC card with capability of having plurality of card managers installed
CN101233486A (en) Method, software and apparatus for activating resident applications
US6671809B1 (en) Software-defined communications system execution control
CN101228531A (en) Execution device
WO2012054252A2 (en) Application usage policy enforcement
KR101487176B1 (en) System for providing code block for separating execution based contents, method thereof and computer recordable medium storing the method
CN104680075A (en) Framework for fine-grain access control from high-level application permissions
AU2001257276A1 (en) Software-defined communications system execution control
US20020194132A1 (en) Renting a computing environment on a trusted computing platform
US6490720B1 (en) Sequence numbering mechanism to ensure execution order integrity of inter-dependent smart card applications
CN111222122A (en) Application authority management method and device and embedded equipment
WO2004097603A1 (en) Protecting a java application
US20030177377A1 (en) Protecting computer software
Requet AB model for ensuring soundness of a large subset of the Java Card virtual machine
EP1977551A2 (en) Binding a protected application program to shell code
JP2001356835A (en) Method for managing computer and device for conducting the same and recording medium having its processing program recorded thereon

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DPEN Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed from 20040101)
122 Ep: pct application non-entry in european phase