Browse Prior Art Database

Method to Securely Validate Dynamic Libraries Disclosure Number: IPCOM000022453D
Original Publication Date: 2004-Mar-15
Included in the Prior Art Database: 2004-Mar-15
Document File: 1 page(s) / 5K

Publishing Venue



In byte-compiled programming languages, the source code can be reverse engineered into machine instructions using disassemblers. In Python, such a disassembler is even shipped with the core library set. The problem is, how can the integrity of the source code be protected while maintaining the dynamic nature of the interpreted language. Such protection is necessary to preserve intellectual property and fulfill contractual obligations to ensure that reasonable efforts are made to secure the code from piracy. Current code hardening techniques which employ a randomizing time-based algorithm to prevent code inspection are difficult to implement, because they require many man months to develop per application. Other implementations that use gating functions, are easy to defeated by examining the assembly code and bypassing the gate with a jump. Our method is easier to implement and faster to load than the first method. Our method is more secure than the second method. The idea involves encrypting the byte-compiled libraries and signing them. The libraries are then validated and decrypted dynamically during the import process. The standard language import mechanism is modified to detect both standard and encrypted libraries and handle them appropriately.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 100% of the total text.

Page 1 of 1

Method to Securely Validate Dynamic Libraries

The idea is to take byte-compiled code objects and encrypt them. The encrypted blob is then signed. A magic header is then added to the blob containing the signature, encryption information, and potentially additional information that would identify the blob as a valid "encrypted" library for this interpreter.

The import feature of the interpreted language is overloaded to look for the magic header. If no such magic header is detected, then the language default import mechanism is used. If the magic header is detected, then the header is stripped off and parsed to validate and decrypt the code object in memory. If the code object successfully passes authorization and authentication, then it is then loaded using the default import mechanism from memory. If it fails authorization or authentication, then the library is deemed corrupt and an invalid library exception is raised.