[VB] Function Integrity Checks at Runtime

[Permaphrost]

I haven't been seriously working with Visual Basic for too long. An application that I am working on requires a check to ensure that certain functions and/or information have not been altered. I am aware that a competent cracker could make such a check obsolete, but am still interested in including it. I would be capable of doing something like this in assembly, but am not sure how to approach it from a higher level language like VB.

Any thoughts?

[TheMinistered]

If you would be 'comfortable doing this from assembly' you should have all the knowledge you need (except for perhaps vb syntax?) to do this.  But, since I highly doubt you know how to even do this in assembly, i'll send you on you're right way!

You make your application read itself (i.e. readfile) then you should hash the buffer that contains the contents of application.  Then you compare the runtime-generated hash with a pregenerated hash of the file (you can store this in a global var or append it to the end of the file, etc)  If they don't match, there has been an altercation...

This method is fairly simple and easy to crack though

[l2k-Shadow]

you could also store parts of the pregenerated hash in different places and put all sorts of other funky stuff on the program... of course if a good cracker REALLY wanted to crack it, he would be able to overcome such things but it would confuse the hell out of him.

[topaz]

CRC check, encrypting important functions, doing simple checks like If strData <> Decrypt(EncryptedstrData) Then End, and using executable packers would likely foil an amateur cracker.

[Permaphrost]

You make your application read itself (i.e. readfile) then you should hash the buffer that contains the contents of application.  Then you compare the runtime-generated hash with a pregenerated hash of the file (you can store this in a global var or append it to the end of the file, etc)  If they don't match, there has been an altercation...

This method is fairly simple and easy to crack though

Thank you.

But, since I highly doubt you know how to even do this in assembly

Why? 

[RealityRipple]

Hi Mike! My suggestion would be, since you said you could do it in assembley, get a copy of visual c++ (you probably already have it, though), compile the vb EXE, run it, open the process list, find the exe, debug it, and add the check through there.

[Permaphrost]

Hi Mike! My suggestion would be, since you said you could do it in assembley, get a copy of visual c++ (you probably already have it, though), compile the vb EXE, run it, open the process list, find the exe, debug it, and add the check through there.

Thanks Andy. And hi.

[RealityRipple]

Hey, guess what? Your e-girlfriend is my e-girlfriend's best friend IRL.

[Warrior]

...

[Permaphrost]

Hey, guess what? Your e-girlfriend is my e-girlfriend's best friend IRL.

...

[l2k-Shadow]

Hey, guess what? Your e-girlfriend is my e-girlfriend's best friend IRL.

...

...

[Mystical]

Hey, guess what? Your e-girlfriend is my e-girlfriend's best friend IRL.

LOL


btw... End is a bad way to end your program -_-

[RealityRipple]

Indeed... And On Error Resume Next is a bad way to handle errors.

[Permaphrost]

Well no dur. But it is a quick way of handling errors if you want to test the functionality of your program briefly.

[Warrior]

Handling? You're ignoring errors