Run-time call stack verification is used to determine that a code module has been called by a legitimate caller. A return address on the stack indicates where execution is to return upon execution of the next return instruction, and this return address is indicative of where the code module was call
Run-time call stack verification is used to determine that a code module has been called by a legitimate caller. A return address on the stack indicates where execution is to return upon execution of the next return instruction, and this return address is indicative of where the code module was called from. The code module may determine that the call is allowed, or disallowed, based on the location of the return address. A calling convention is provided that allows the code module to be called through an intermediary, while also preserving the original return address that was in effect at the time the intermediary was called and also resisting modification to the call stack during the time that the original return address is being verified.
대표청구항▼
What is claimed: 1. In a runtime environment comprising a first program module, at least one second program module and a call stack, a method of invoking a desired method associated with a desired second program module, comprising: in a third program module associating each of a plurality of stubs
What is claimed: 1. In a runtime environment comprising a first program module, at least one second program module and a call stack, a method of invoking a desired method associated with a desired second program module, comprising: in a third program module associating each of a plurality of stubs respectively with each of a plurality of methods associated with the at least one second program module, wherein each stub comprises a code segment performing a unique non-standard calling convention into the at least one second program module, wherein each stub includes at least a first instruction to push function parameters onto the call stack, a second instruction to call an authenticator module for authenticating that a stub has not been modified and a third instruction comprising embedded unique data for the stub, wherein the embedded unique data comprises a vtable entry descriptor for the desired method, corresponding to a vtable for the third program module, wherein the vtable is covered and comprises a list of function pointers to functions associated with the at least one second program module arranged in a random order, the random order unique for the at least one second program module; and from the first program module, issuing a first call to a stub in the third program module associated with the desired method, whereupon after the first call, the call stack comprises at least a first parameter corresponding to a return address associated with the stub, a second parameter corresponding to a parameter depth (cArgs) and a third parameter corresponding to a return address of the first program module, the first, second and third parameters arranged in a top-down order; wherein the third program module calls the at least one second program module using a non-standard calling convention. 2. The method of claim 1, wherein upon returning to the authenticator module from a jump to the vtable uncovering code, an address associated with the desired method on the call stack automatically causes calling of the desired method associated with the third program module and whereupon completion of the desired method, the return address of the first program module on the call stack automatically causes return to a cleanup function, whereupon completion of the portion of the authenticator module corresponding to the cleanup function, the return address associated with the stub on the call stack causes return to the first program module. 3. The method of claim 1, wherein the desired method performs static authentication of the first program module. 4. The method of claim 3, wherein the desired method performs dynamic authentication of the first program module. 5. The method of claim 1, wherein said authentication comprises: examining the call stack to identify a return address, and determining that the return address is part of a program module that is permitted, according to a standard or rule, to invoke functionality associated with the at least one second program module. 6. The method of claim 5, farther comprising: determining that said return address is from a location or range of locations within said first program module from which invocation of said functionality is permitted to originate. 7. The method of claim 1, farther comprising: verifying that said first program module, or a portion thereof, has not been modified relative to a previously-known state. 8. The method of claim 1, wherein said first program module is, or is part of, an application program. 9. The method of claim 1, wherein said at least one second program module comprises a dynamic-link library. 10. The method of claim 1, whereupon executing the second instruction in the stub, an authenticator module is called, the authenticator module: verifying that the associated stub has not been modified utilizing the return address of the associated stub; if verification is not successful, not calling the second program module and terminating execution; and if verification is successful: inserting a first return address of the first program module on the call stack; replacing the return address associated with the stub on the call stack with an address associated with the desired method; replacing the second parameter (cArgs) on the call stack with a second return address associated with the authenticator module, the second return address corresponding to a portion of the authenticator module for performing a cleanup function; and causing a jump into vtable uncovering code associated with the vtable entry descriptor, causing execution of the desired method, automatically bypassing the authenticator module upon return and automatically calling the cleanup function, wherein the desired method authenticates the first program module using the return address of the first program module having been preserved on the call stack. 11. A method of verifying a context in which a first program module has been called, the method comprising: examining a call stack of a process in which said first program module executes to identify a return address in which control of the process will return upon completion of a call to said first program module; determining that said return address is located within a second program module that is permitted to call said first program module, said determining comprising checking a datum that represents a calling code used by the second program module, the datum being derived from a portion or the entirety of the second program module, the first program module being called by the second program module via a third program module having one or more stubs with code segments that are callable by the second program module as an intermediary, the one or more stubs comprising data required during a verification by the first program module, said data required during said verification being mixed into instruction streams provided by the one or more stubs, the data also comprising information that is used to identify a function that will be invoked after the verification, wherein each stub comprises a code segment performing a unique non-standard calling convention into the second program module, wherein each stub includes at least a first instruction to push function parameters onto the call stack, a second instruction to call an authenticator module for authenticating that a stub has not been modified and a third instruction comprising embedded unique data for the stub, wherein the embedded unique data comprises a vtable entry descriptor for a desired method, corresponding to a vtable for the third program module, wherein the vtable is covered and comprises a list of function pointers to functions associated with the second program module arranged in a random order, the random order unique for the second program module; from the first program module, issuing a first call to a stub in the third program module associated with the desired method, whereupon after the first call, the call stack comprises at least a first parameter corresponding to a return address associated with the stub, a second parameter corresponding to a parameter depth (cArgs) and a third parameter corresponding to a return address of the first program module, the first, second and third parameters arranged in a top-down order; and based on the result of said determining act, permitting execution of said first program module to proceed and returning to said second program module which issued the call and bypassing said third program module and the one or more stubs, wherein said first program module comprises cryptographic functionality that stores and obscures a decryption key and that uses said decryption key to decrypt content. 12. The method of claim 11, further comprising: determining that said second program module, or a portion thereof, has not been modified relative to a previously-known state of said second program module, wherein said act of permitting execution of said first program module to proceed is further based on the determination as to whether said second program module has been modified. 13. The method of claim 11, wherein said first program module includes logic that resists misuse and/or tampering with said first program module, and wherein said determining act is performed by said first program module. 14. The method of claim 11, wherein said first program module is called by a third program module, said third program module having a callable method exposed to said second program module, said callable method causing said first program module to be invoked and passing said return address to said first program module at the time that said first program module is invoked. 15. The method of claim 14, wherein said first program module adjusts the content of said call stack to reflect that said first program module will return to said return address upon completion of execution of said call to said first program module, said call stack reflecting, in the absence of the adjustment, that said first program module will return to an address other than said return address. 16. A program module stored in a computer-readable storage medium comprising: a function that is performable on behalf of a calling entity; and logic that verifies an identity of the calling entity as a condition for performing said function, said logic consulting a call stack in order to identify said calling entity and determining said identity based on a return address on said call stack, said return address representing a location of an instruction to be executed when the program module completes execution, said logic checking a datum that represents a calling code used by the calling entity, the datum being derived from a portion or the entirety of the calling entity; wherein said function is not exposed to said calling entity, and wherein said function is exposed to an intermediate entity that is callable by said calling entity, said intermediate entity calling upon the program module to perform said function on behalf of said calling entity, said intermediate entity comprising one or more stubs that comprise data required by the logic to verify the identity of the calling entity, the data being mixed into instruction streams provided by the one or more stubs, the data also comprising information that is used to identify the function, wherein each stub comprises a code segment performing a unique non-standard calling convention into the program module, wherein each stub includes at least a first instruction to push function parameters onto the call stack, a second instruction to call an authenticator module for authenticating that a stub has not been modified and a third instruction comprising embedded unique data for the stub, wherein the embedded unique data comprises a vtable entry descriptor for a desired method, corresponding to a vtable for the intermediate entity, wherein the vtable is covered and comprises a list of function pointers to functions associated with the program module arranged in a random order, the random order unique for the program module; from the calling entity, issuing a first call to a stub in the program module associated with the desired method, whereupon after the first call, the call stack comprises at least a first parameter corresponding to a return address associated with the stub, a second parameter corresponding to a parameter depth (cArgs) and a third parameter corresponding to a return address of the calling entity, the first, second and third parameters arranged in a top-down order; and wherein the program module upon completing said function bypasses the intermediate entity and returns to the calling entity's return address. 17. The program module of claim 16, wherein said calling entity calls said intermediate entity using a first calling convention, and wherein said intermediate entity calls the program module using a second calling convention different from said first calling convention. 18. The program module of claim 17, wherein said calling entity calls said intermediate entity by calling a function in said intermediate entity and placing a first return address on said call stack, and wherein said intermediate entity calls the program module by calling or jumping to a location in said program module with one or more parameters including said first return address, wherein the program module verifies that said first return address is located within a calling entity that is allowed to call the program module, and wherein the program module adjusts said call stack so that a return address to be followed upon a next return instruction is equal to said first return address. 19. The program module of claim 17, wherein said first calling convention comprises placing a return address on said call stack, and wherein said second calling convention comprises placing a second return address on said call stack and placing data at the location represented by said second return address, said second return address being used to find said data, said data being used to perform at least one of: verification of the identity of the calling entity; and identification of a location at which said function is located. 20. A computer-readable storage medium having stored thereon computer-executable instructions for performing the steps of: examining a call stack of a process in which said first program module executes to identify a return address in which control of the process will return upon completion of a call to said first program module; determining that said return address is located within a second program module that is permitted to call said first program module, said determining comprising checking a datum that represents a calling code used by the second program module, the datum being derived from a portion or the entirety of the second program module, the first program module being called by the second program module via a third program module having one or more stubs with code segments that are callable by the second program module as an intermediary, the one or more stubs comprising data required during a verification by the first program module, said data required during said verification being mixed into instruction streams provided by the one or more stubs, the data also comprising information that is used to identify a function that will be invoked after the verification, wherein each stub comprises a code segment performing a unique non-standard calling convention into the second program module, wherein each stub includes at least a first instruction to push function parameters onto the call stack, a second instruction to call an authenticator module for authenticating that a stub has not been modified and a third instruction comprising embedded unique data for the stub, wherein the embedded unique data comprises a vtable entry descriptor for a desired method, corresponding to a vtable for the third program module, wherein the vtable is covered and comprises a list of function pointers to functions associated with the second program module arranged in a random order, the random order unique for the second program module; from the first program module, issuing a first call to a stub in the third program module associated with the desired method, whereupon after the first call, the call stack comprises at least a first parameter corresponding to a return address associated with the stub, a second parameter corresponding to a parameter depth (cArgs) and a third parameter corresponding to a return address of the first program module, the first, second and third parameters arranged in a top-down order; and based on the result of said determining act, permitting execution of said first program module to proceed and returning to said second program module which issued the call and bypassing said third program module and the one or more stubs, wherein said first program module comprises cryptographic functionality that stores and obscures a decryption key and that uses said decryption key to decrypt content.
연구과제 타임라인
LOADING...
LOADING...
LOADING...
LOADING...
LOADING...
이 특허에 인용된 특허 (17)
De Pauw Wim (Scarborough NY) Cina Vincent J. (Chestnut Ridge NY) Helm Andrew R. (Montreal CAX) Kimelman Douglas N. (Danbury CT) Vlissides John M. (Mohegan Lake NY), Animated display showing execution of object-oriented programs.
Downs Edgar ; Gruse George Gregory ; Hurtado Marco M. ; Lehman Christopher T. ; Milsted Kenneth Louis ; Lotspiech Jeffrey B., Electronic content delivery system.
Andrew T. Jennings ; G. Lawrence Krablin ; Timothy Neilson Fender ; William Stratton, METHOD, APPARATUS, AND COMPUTER PROGRAM PRODUCT FOR REPLACING A DYNAMIC LINK LIBRARY (DLL) OF A FIRST COMPUTING ENVIRONMENT WITH A DLL OF A SECOND COMPUTING ENVIRONMENT THAT CAN BE INVOKED FROM THE F.
Kanamori Atsushi ; Thomason Jon, Method and system for calling one of a set of routines designed for direct invocation by programs of a second type when.
Alexander, III, William Preston; Berry, Robert Francis; Levine, Frank Eliot; Urquhart, Robert John, Method and system for merging event-based data and sampled data into postprocessed trace output.
Ginter Karl L. ; Shear Victor H. ; Sibert W. Olin ; Spahn Francis J. ; Van Wie David M., Systems and methods for secure transaction management and electronic rights protection.
Saunders, Roger C.; Thain, William S. R., Generating one or more clients for generating one or more synthetic transactions with one or more web service operations.
Duvalsaint, Karl J.; Gschwind, Michael K.; Salapura, Valentina, Providing instructions to protect stack return addresses in a hardware managed stack architecture.
※ AI-Helper는 부적절한 답변을 할 수 있습니다.