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?

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

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.

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.

[quote author=TheMinistered link=topic=14466.msg147926#msg147926 date=1141854869]
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[/quote]

Thank you.

[quote author=TheMinistered link=topic=14466.msg147926#msg147926 date=1141854869]
But, since I highly doubt you know how to even do this in assembly[/quote]

Why?  ;)

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.

[quote author=RealityRipple link=topic=14466.msg147950#msg147950 date=1141867134]
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.
[/quote]

Thanks Andy. And hi.

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

...

[quote author=RealityRipple link=topic=14466.msg147955#msg147955 date=1141870872]
Hey, guess what? Your e-girlfriend is my e-girlfriend's best friend IRL. :D
[/quote]

...

[quote author=Permaphrost link=topic=14466.msg147966#msg147966 date=1141875530]
[quote author=RealityRipple link=topic=14466.msg147955#msg147955 date=1141870872]
Hey, guess what? Your e-girlfriend is my e-girlfriend's best friend IRL. :D
[/quote]

...
[/quote]
...

[quote author=RealityRipple link=topic=14466.msg147955#msg147955 date=1141870872]
Hey, guess what? Your e-girlfriend is my e-girlfriend's best friend IRL. :D
[/quote]

LOL


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

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

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

Handling? You're ignoring errors

You are handling them, nonetheless. You are instructing the program what to do if an error occurs - not handling them would be to simply let them occur and be unable to execute your code.

On Error Resume Next  is not handling an Error, as Warrior stated is simply ignoreing all Errors and just moving on.. also by not having all your errors handled, you wont beable to find what the exact errors are to fix the problems if any, using it this way wont always let your program run properly..

Reminds me of a geek philosophy on life I made up... Universe: Uni Verse... One verse... verses can be lines... lines of code... On Error Resume Next is a line of code... and it explains how the universe works... When something happens, just move on to the next thing....

Annnnyway... On Error Resume Next, whether it is handling or not, is still bad coding practice unless the errors do NOT matter, like on Form_Resize in most cases. However, Error handlers should include Resume Next at the end, otherwise the rest of the procedure is ignored. HOWEVER this has NOOOOTHING to do with what we were talking about. It was just a stupid response to a stupid statement.

[quote author=RealityRipple link=topic=14466.msg148023#msg148023 date=1141950773]
Reminds me of a geek philosophy on life I made up... Universe: Uni Verse... One verse... verses can be lines... lines of code... On Error Resume Next is a line of code... and it explains how the universe works... When something happens, just move on to the next thing....

Annnnyway... On Error Resume Next, whether it is handling or not, is still bad coding practice unless the errors do NOT matter, like on Form_Resize in most cases. However, Error handlers should include Resume Next at the end, otherwise the rest of the procedure is ignored. HOWEVER this has NOOOOTHING to do with what we were talking about. It was just a stupid response to a stupid statement.
[/quote]

...

This is why you should stay on the Brutalnet boards.

[quote author=Permaphrost link=topic=14466.msg148014#msg148014 date=1141939646]
You are handling them, nonetheless. You are instructing the program what to do if an error occurs - not handling them would be to simply let them occur and be unable to execute your code.
[/quote]

How are you handling them if you are making the errors be supressed. Nothing is being fixed, you just are suppresing the errors from showing. If your application is going to hang, it's going to hang regardless of how many times you type "On Error Resume Next". At the least it will produce unexpected results when an error occurs.

Horrible, horrible coding habbit to get into.

[quote author=Warrior link=topic=14466.msg148029#msg148029 date=1141955010]

How are you handling them if you are making the errors be supressed. Nothing is being fixed, you just are suppresing the errors from showing. If your application is going to hang, it's going to hang regardless of how many times you type "On Error Resume Next". At the least it will produce unexpected results when an error occurs.

Horrible, horrible coding habbit to get into.
[/quote]

You're right, it is a nasty coding habit to get into. I'm not implying that "handling" errors by supressing them in this way is going to correct anything, simply stating that if you instruct a program to take action on an error, it is error handling.

You're instructing it to do nothing..
It's only handled if you take care of the error, you just skip over it potentially producing unwanted results.

Warrior, calm down.  He acknowledged it already.  :)

[quote author=Warrior link=topic=14466.msg148044#msg148044 date=1141963306]
It's only handled if you take care of the error
[/quote]

I am not trying to pick at what you're saying, so I do hope it doesn't seem that way. But error handling can be anything from reporting the error or saving information about the error, to functions that deal with certain errors to prevent them from adversely affecting the program. It does not have to fix the problem.

Anyway, sorry that this topic strayed off on a bit of a tangent here. Thank you to those who helped with the original question.