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.
>
>
>
>>In case your FLL simply returns a True or False, then yes I understand Jos's concern.
>>
>>There is an encryption method that will encrypt the original string and decrypt if sent the encrypted string. In that case, this algorithm could be used to check whether the FLL is not merely an interceptor.
>>
>>

key  = 'sdfdfgdgdfg'
>>a1   = 'sdfsdf'
>>a2   = routine( a1, key )
>>a3   = routine( a2, key )
>>okay = ( a1 == a3 ) and not ( a1 == a2 )

>>
>>In case this would be considered overactivity if done for each instance of encryption, it could be done on init, merely to check whether we're dealing here with the right FLL. A third parameter could be the instruction to the FLL for this mode.