Abstract: Facilities are provided to secure guest runtime environments (GREs). Security policy specifications may be associated with GREs. A GRE's security policy may be specific to the GRE and may also include security policy inherited from higher levels such as a host operating environment. The security policy of a GRE specifies restrictions and/or permissions for activities that may be performed within the scope of execution of the GRE. A GRE's security policy may limit what the GRE's guest software may do within the GRE. Restrictions/permissions may be applied to objects such as files, configuration data, and the like. Security specifications may be applied to execution initiated within a GRE. A GRE's security specification may restrict/permit executable objects from loading and executing within the GRE. The executability or accessibility of objects may be conditioned on factors such as the health/integrity of the GRE, the host system, requested files, and others.

Abstract: Facilities are provided to secure guest runtime environments (GREs). Security policy specifications may be associated with GREs. A GRE's security policy may be specific to the GRE and may also include security policy inherited from higher levels such as a host operating environment. The security policy of a GRE specifies restrictions and/or permissions for activities that may be performed within the scope of execution of the GRE. A GRE's security policy may limit what the GRE's guest software may do within the GRE. Restrictions/permissions may be applied to objects such as files, configuration data, and the like. Security specifications may be applied to execution initiated within a GRE. A GRE's security specification may restrict/permit executable objects from loading and executing within the GRE. The executability or accessibility of objects may be conditioned on factors such as the health/integrity of the GRE, the host system, requested files, and others.

Abstract: A first process operating on a computer comprises code to be executed in connection therewith, where the code includes at least one triggering device. A digital license corresponds to the first process and sets forth terms and conditions for operating the first process. A second process operating on the computer proxy-executes code corresponding to each triggering device of the first process on behalf of such first process. The second process includes a selection of options to thwart reverse engineering by a debugger if a debugger is detected. The options include execution by a proxy engine of a re-routed call, crashing the first process, detection ad elimination of a debugger related interrupt a call to an arbitrary function.

Abstract: In an example embodiment, executable files are individually encrypted utilizing a symmetric cryptographic key. For each user to be given access to the obfuscated file, the symmetric cryptographic key is encrypted utilizing a public key of a respective public/private key pair. A different public key/private key pair is utilized for each user. Obfuscated files are formed comprising the encrypted executable files and a respective encrypted symmetric cryptographic key. The private keys of the public/private key pairs are stored on respective smart cards. The smart cards are distributed to the users. When a user wants to invoke the functionality of an obfuscated file, the user provides the private key via his/her smart card. The private key is retrieved and is utilized to decrypt the appropriate portion of the obfuscated file. The symmetric cryptographic key obtained therefrom is utilized to decrypt the encrypted executable file.