locked
keep track of application runs RRS feed

  • Question

  • Is there a way of keeping track how many times an application was executed?

     

    let's take a trial version of a software for exemple that can only be started, let's say, 30 times. How can I keep track how many times the application was started without writing a Registry key or writing to a file?

     

    Could you also please give me an exemple?

     

    thx a lot Wink

    Thursday, June 21, 2007 9:57 PM

Answers

  • I don't think it's really possible in a managed application.

     

    There's all sorts of ways to inject code into other applications, as a result knowing that they've been run.  None are really doable in a managed application.

     

    One thing that could be done from a managed application is to create a low-level hook for which you get information about mouse and keyboard events that are received by a particular application (the application with focus for keyboard and mouse messages and the application under the mouse cursor for some mouse messages).  By intercepting that you could track applications.  You'd have to track which applications you've received messages for and decide whether it's newly run or not.  You could use the Process.Exited event to try and capture application exits once you know a process is running.

     

    You could simply run a timer and check what applications are running every time slice.  That would affect system performance though.

     

    In either case, I don't think you'd be guaranteed of seeing all application starts or exits.

     

    What you want can really only be implemented in native code.

    Saturday, June 23, 2007 4:26 PM
    • Managed Code

      Managed code is written to target the services of the managed runtime execution environment (like
      Common Language Runtime in .NET Framework). The managed code is always executed by a managed runtime execution environment rather than the operating system directly. Managed refers to a method of exchanging information between the program and the runtime environment. Because the execution of code is governed by the runtime environment, the environment can guarantee what the code is going to do and provide the necessary security checks before executing any piece of code. Because of the same reason the managed code also gets different services from the runtime environment like Garbage Collection, type checking, exception handling, bounds checking, etc. This way managed code does not have to worry about memory allocations, type safety, etc. Applications written in Java, C#, VB.NET, etc target a runtime environment which manages the execution and the code written using these types of languages is known as Managed Code. Managed code is always compiled into an Intermediate Language (MSIL in case of .NET Framework). The compiler used by .NET framework to compile managed code compiles it into Intermediate Language and generates the necessary metadata, symbolic information that describes all of the entry points and the constructs exposed in the Intermediate Language (e.g., methods, properties) and their characteristics. The Common Language Infrastructure (CLI) Standard describes how the information is to be encoded, and programming languages that target the runtime emit the correct encoding.

      In .NET Framework Managed Code runs within the .Net Framework’s CLR and benefits from the services provided by the CLR. When we compile the managed code, the code gets compiled to an intermediate language (MSIL) and an executable is created. When a user runs the executable the Just In Time Compiler of CLR compiles the intermediate language into native code specific to the underlying architecture. Since this translation happens by the managed execution environment (CLR), the managed execution environment can make guarantees about what the code is going to do, because it can actually reason about it. It can insert traps and sort of protection around, if it's running in a sandboxed environment, it can insert all the appropriate garbage collection hooks, exception handling, type safety, array bounce, index checking and so forth.

      Managed code also provides platform independence. As the managed code is first compiled to intermediate language, the CLR’s JIT Compiler takes care of compiling this intermediate language into the architecture specific instructions.
    • Unmanaged Code

      Unmanaged code is directly executed by the Operating System. Typically applications written in VB 6.0, C++, C, etc are all examples of unmanaged code. Unmanaged code typically targets the processor architecture and is always dependent on the computer architecture. Unmanaged code is always compiled to target a specific architecture and will only run on the intended platform. This means that if you want to run the same code on different architecture then you will have to recompile the code using that particular architecture. Unmanaged code is always compiled to the native code which is architecture specific. When we compile unmanaged code it gets compiled into a binary X86 image. And this image always depends on the platform on which the code was compiled and cannot be executed on the other platforms that are different that the one on which the code was compiled. Unmanaged code does not get any services from the managed execution environment.

      In unmanaged code the memory allocation, type safety, security, etc needs to be taken care of by the developer. This makes unmanaged code prone to memory leaks like buffer overruns and pointer overrides and so forth.

      Unmanaged executable files are basically a binary image, x86 code, loaded into memory. The program counter gets put there and that’s the last the Operating System knows. There are protections in place around memory management and port I/O and so forth, but the system doesn’t actually know what the application is doing.

     

    Please read this thread for more details about the difference between native/unmanaged code and managed code.

    Monday, June 25, 2007 10:05 AM

All replies

  • Well in orde to do this, some state data needs to be preserved beyond the lifetime of the process (app) that you are starting.

     

    If you know that the OS was never rebooted then there might be some way, but I doubt this is a likely scenario, so you need to preserve the info not just acrorss process creates/destroys but OS starts/shutdowns.

     

    There are only a handful of plces that one can put the data:

     

    1) Somewhere on a hard disk

    2) Some external memory stick or something

    3) Via a network to some other storage service.

    4) Motherboard's non-volatile RAM

     

    I would really lean toward a file, and if you think about your need, you can avoid all IO.

     

    You can simply see if a file called: my_app_invocations*.txt (or whatever) exist in some defined folder.

     

    If it does, then assuming a naming convention like: my_app_invocations_00.txt, you can extract the 00 (or whatever it may be).

     

    then simply rename the file to: my_app_invocations_01.txt each time it starts.

     

    eventually you will see: my_app_invocations_30.txt and know it has run 30 times.

     

    to prevent users messing this up, simply make sure the file is always installed (with 00 in name) and if the file is missing, refuse to start etc.

     

    You could do many things along these lines, but your options really are limited (the file name could actually be encrypted, so a casual user would have NO idea what the file was for: "wTyyTTnnn788jU8Yhjg.txt" for example.

     

    Regards

     

     

    Friday, June 22, 2007 7:01 PM
  • You can store as registry key, but not in some usual place with meaning name, but hide it somewhere. You can also do this with file with same goal to hide the file in some secret place with meaningless name.
    Secure way of doing this is that your application is connecting to your webservice and store that in your database.
    Saturday, June 23, 2007 10:27 AM
  • is there no other way?
    Saturday, June 23, 2007 3:53 PM
  • I don't think it's really possible in a managed application.

     

    There's all sorts of ways to inject code into other applications, as a result knowing that they've been run.  None are really doable in a managed application.

     

    One thing that could be done from a managed application is to create a low-level hook for which you get information about mouse and keyboard events that are received by a particular application (the application with focus for keyboard and mouse messages and the application under the mouse cursor for some mouse messages).  By intercepting that you could track applications.  You'd have to track which applications you've received messages for and decide whether it's newly run or not.  You could use the Process.Exited event to try and capture application exits once you know a process is running.

     

    You could simply run a timer and check what applications are running every time slice.  That would affect system performance though.

     

    In either case, I don't think you'd be guaranteed of seeing all application starts or exits.

     

    What you want can really only be implemented in native code.

    Saturday, June 23, 2007 4:26 PM
  • could you please link me something about native code? i don't really know what the difference is between native and managed code

     

    thx a lot for your answer

    Saturday, June 23, 2007 8:01 PM
    • Managed Code

      Managed code is written to target the services of the managed runtime execution environment (like
      Common Language Runtime in .NET Framework). The managed code is always executed by a managed runtime execution environment rather than the operating system directly. Managed refers to a method of exchanging information between the program and the runtime environment. Because the execution of code is governed by the runtime environment, the environment can guarantee what the code is going to do and provide the necessary security checks before executing any piece of code. Because of the same reason the managed code also gets different services from the runtime environment like Garbage Collection, type checking, exception handling, bounds checking, etc. This way managed code does not have to worry about memory allocations, type safety, etc. Applications written in Java, C#, VB.NET, etc target a runtime environment which manages the execution and the code written using these types of languages is known as Managed Code. Managed code is always compiled into an Intermediate Language (MSIL in case of .NET Framework). The compiler used by .NET framework to compile managed code compiles it into Intermediate Language and generates the necessary metadata, symbolic information that describes all of the entry points and the constructs exposed in the Intermediate Language (e.g., methods, properties) and their characteristics. The Common Language Infrastructure (CLI) Standard describes how the information is to be encoded, and programming languages that target the runtime emit the correct encoding.

      In .NET Framework Managed Code runs within the .Net Framework’s CLR and benefits from the services provided by the CLR. When we compile the managed code, the code gets compiled to an intermediate language (MSIL) and an executable is created. When a user runs the executable the Just In Time Compiler of CLR compiles the intermediate language into native code specific to the underlying architecture. Since this translation happens by the managed execution environment (CLR), the managed execution environment can make guarantees about what the code is going to do, because it can actually reason about it. It can insert traps and sort of protection around, if it's running in a sandboxed environment, it can insert all the appropriate garbage collection hooks, exception handling, type safety, array bounce, index checking and so forth.

      Managed code also provides platform independence. As the managed code is first compiled to intermediate language, the CLR’s JIT Compiler takes care of compiling this intermediate language into the architecture specific instructions.
    • Unmanaged Code

      Unmanaged code is directly executed by the Operating System. Typically applications written in VB 6.0, C++, C, etc are all examples of unmanaged code. Unmanaged code typically targets the processor architecture and is always dependent on the computer architecture. Unmanaged code is always compiled to target a specific architecture and will only run on the intended platform. This means that if you want to run the same code on different architecture then you will have to recompile the code using that particular architecture. Unmanaged code is always compiled to the native code which is architecture specific. When we compile unmanaged code it gets compiled into a binary X86 image. And this image always depends on the platform on which the code was compiled and cannot be executed on the other platforms that are different that the one on which the code was compiled. Unmanaged code does not get any services from the managed execution environment.

      In unmanaged code the memory allocation, type safety, security, etc needs to be taken care of by the developer. This makes unmanaged code prone to memory leaks like buffer overruns and pointer overrides and so forth.

      Unmanaged executable files are basically a binary image, x86 code, loaded into memory. The program counter gets put there and that’s the last the Operating System knows. There are protections in place around memory management and port I/O and so forth, but the system doesn’t actually know what the application is doing.

     

    Please read this thread for more details about the difference between native/unmanaged code and managed code.

    Monday, June 25, 2007 10:05 AM
  • thanks! Wink
    Tuesday, June 26, 2007 9:46 AM