Memory tracing can also be done with the app's internal code, can't it? Trace the memory while the app is calculating the hash value. When found, it can be used to mislead the app when it checks the file's hash value. That's why I regard it as another problem, rather than as a problem that makes the 'solution' I proposed worthless.

>No. First a hash is not a checksum. But besides that, you would calculate the hash on your own computer of the fll. This is now the correct hash. This you store in your application. Then when the program runs on the user you re-calc the hash before using the fll. If the two hashes match then you know the fll is the original.
>
>The problem you have now is how to hide the hash inside your application. VFP can easily be decompiled and that would reveal the hash. So you can use Molebox, Thinstall, Armadillo, etc to protect the exe itself. Now a cracker must break the exe protection to reveal where you are storing the original hash in order to replace it with the hash of the fake fll. But if a cracker can get that far then they can also get your password that you are sending to to the fll.
>
>
>>Isn't that another discussion? Wouldn't that also be possible with the checksum method?
>>
>>>It will be known. A memory trace of the running application will reveal it.
>>>
>>>
>>>>If the interceptor would know that it is always the second call that should return the received value of call one, then yes it's easilly done. But what if that is not known? E.g.
>>>>
>>>>

key  = 'sdfdfgdgdfg'
>>>>a1   = 'sdfsdf'
>>>>     = routine( 'sdsad', key )
>>>>a2   = routine( a1, key )
>>>>     = routine( 'sdssasd', key )
>>>>     = routine( '345yd', key )
>>>>a3   = routine( a2, key )
>>>>     = routine( '768976', key )
>>>>okay = ( a1 == a3 ) and not ( a1 == a2 )

>>>>
>>>>I assume here that the interceptor is not able to simulate the algorithm that encrypts/decrypts the value.
>>>>
>>>>BTW, I'm not challenging you remark about the MD5/SHA hash method. That one is useful, for sure.
>>>>
>>>>>A person would simply program their interceptor fll/dll to return the correct answer and then trap for your password on the subsequent call. The approach mentioned by others is the best; create a hash of the fll file, using MD5 or SHA as an example, and store this within your application. Then before using the fll/dll calculate the md5/sha hash again and compare. If they match the fll/dll is unchanged. You would need to combine this approach with protecting your VFP app as well otherwise the stored hash could easily be retrieved from the exe and modified. For additional protection including the fll/dll within the packaged application would help.
>>>>>
>>>>>