This is more of a task like many of the scareware authors require that limit the number of times an app can be run before it refuses to start. It requires an INI file installed in the same directory that the app reads then decrements until it becomes zero, then it deletes the INI file. Once the INI file no longer exists, the app will not start.This is shown at its simplest, in a real world application you would write it to an obscure location with an obscure name and probably encrypt the 4 bytes of data in the file. The example has a spare directory that has an extra copy of the INI file so you can copy it into the test directory and run it again.
Something like procmon can tell you where it is, no matter how obscure its location - registry or file.
Encryption is really the only way to secure it.
I like the idea of an encrypted ADS in the exe itself.
Here is a variant with the strings encrypted, the main one was the file name of the count file which could be found in the strings in the binary. I tried both procmon and proc explorer but neither catch the short file read and write, the technique is a snatch and grab which does not leave the file open for long so its no real joy to track.
Hutch,
Pretty clever program. :t
; ---------------------
; encrypt the file name
; ---------------------
mov efnm, rv(count_ini) ; INI file name
I do not understand how it opens the count.ini if the code above is where that happens ?
Is this the encrypted name for count.ini ?
count_ini_pad \
db 124,146,175,92,9,73,165,186,61
Andy
Andy,
No, its the proc that that code is in that does it. What you have shown there is the pad that the is XORRED against the data stored at the address in ESI. Its done with a standard tool from MASM32, mangle.exe.
Thanks.