Can application be edited? 1

[Mandy_crw]

I have an application build in VFP 9, can you still edit the exe file after building it? (the .exe file itself) Thanks and God bless.....

 

[Mike Lewis]

Hi Mandy,

In theory, it is possible to edit the EXE file to a very limited extent, but it is difficult and not generally advisable. It is much better to edit the original code or to alter the original forms and classes, and then to re-build the EXE. That is what we all do.

Editing the EXE is particularly difficult if it is encrypted, that is, if the "Encrypted" checkbox is ticked in the Project Info dialogue. But even if that is not the case, it is still difficult. To illustrate, try opening the EXE file in a hex editor (like the one that comes with VFP). As you can see, there is no recognisable code. At best, you might see the text of some literal character strings, such as user messages. You can edit those strings, but you have to take care not to alter their length, otherwise you might render the whole EXE useless.

To sum up, it's best not to even think of editing the EXE.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Mike Lewis]

Just to add to the above ....

You might like to take a look at thread184-1806597. As this explains, if you open the EXE in a hex editor, you might be able to see a certain amount of recognisable code (contrary to what I said above), but it is still unlikely that you will be able to edit it without the risk of corrupting the entire EXE. So my above advice stands.

By the way, the hex editor that comes with VFP is called Hex Edit (appropriately enough), and is located in the Tools\Hexedit folder within the VFP executable directory. There is also a HexEdit topic in the Help file that tells you how to use it.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Mandy_crw]

Thanks Mike, my worry is the password that included in the coding, others may see it... but thank you i have understood it well guys... thanks again...

 

[Mike Lewis]

It should be quite easy to obfuscate or encrypt the password. For example, if the password is ABCDEF, you could do something like this:

p1 = "AB"

* then, somewhere else in the code
p2 = "CD"

* and somewhere else again
p3 = "EF"

* at the point where you want to use the password
lcPassword = p1 + p2 + p3

Alternatively, you could apply a simple letter-substitution cipher.

These methods are easy to crack by someone who knows what you are doing. But given that you only need to protect against someone looking for the password within the EXE, that shouldn't be a problem.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Mandy_crw]

Thank you Mike... i will do what you have advised.... Thanks again....

 

[mjcmkrsr]

Hi Mandy,

... or you might want to encrypt it with your own function like below.

First: there is a conversion: you enter the password as characters and you store it as a number
Second: retro-engineering of this functions' result is rather hard to crack

The password should of course have a certain length - at least 8 characters

LParameters eValue, i, j

j = 1
nValue = 0

For i = 1 to length(alltrim(eValue))
	nValue = nValue + ASC(Substr(eValue,i,1))* j
	j = j * 2
EndFor

Return nValue

You may want to save this code snippet as "encrypt.prg"and test it

?encrypt("MandyC") yields 5591 - no obvious relation between the password "MandyC" (which besides you nobody should know) and this number

hth

MarK

 

[Mike Lewis]

Nice function, Mark.

Am I right in saying that you would use this function at design time, and embed the returned value literally in your code?
So, in other words, if your chosen password is MandyC, you would run the funciton to yield 5591, them embed 5591 in the code, rather than MandyC? If that's right, wouldn't you then need another function to reverse the process at run time?

Or have I misunderstood?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[mjcmkrsr]

Hi Mike,

The function is part of the app/exe but its result is stored at design time as number in the password table, which has the following fields: cUsername, iUserlevel, iPWinteger, tDateTime. The actual Password is nowhere stored . Then when lauching the app I check in the login form

e.g. If This.txtName.Value == tblGreenLeaf.cUserName and This.Encrypt(This.txtPassword.Value) == tblGreenLeaf.iPWinteger ...

I know that there are some gotchas with this approach (namely modifying the password or adding new ones - the administrator has to take care of it) but for a small business this works.

hth

MarK

 

[GriffMG]

Slightly off topic, but if I really had to embed a password in an exe, I would tend to use a methodology rather than
a constant. By this I mean that in stead of using a constant like 'TUESDAY' you could use the day of the week (or the next day
of the week) or get more complicated and combine it with the year and month in some way '2021TUESDAYmay' for example.
It would be pretty easy to obfuscate that methodology.

Then you never give anyone the password so much as the way to work it out.

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[Mike Lewis]

OK, Mark. I understand it now. In fact, it is very similar to the method I use. But instead of using a custom function to generate the encrypted password, I simply use SYS(2007) to generate a checksum. I don't know if that is more secure, but the principle is the same.

The important point is, as you say, the password is not stored anywhere. Nor is it transmitted over the network. I think this is a good approach, although it goes beyond solving Mandy's immediate problem.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Mandy_crw]

Thank you Mark, Mike and Griff..... overwhelming information... i really need to study it well.. and later on add it to my projects... thanks and Godbless....

 

[Steve Meyerson]

Mandy,
Here's a VFP example to encrypt without pw being stored (except as parameter). I have used a similar version of this successfully. There are numerous versions of this you could create. In this example the encrypted seed can be decrypted using the hard-wired seed (known only by you) before decrypting the rest.

LPARAMETERS cInstring

=RAND(123)  && Hard-wired seed to encrypt/decrypt seed
cOutString = ''
************* Get a unique seed each time
nSeed = INT(1000*(SECONDS()-INT(SECONDS())))  && Get a random seed (1-999)

************* Encrypt this seed using hard-wired (constant) seed
cSeed = TRANS(m.nSeed,'@L 999')  && Always 3 chars
FOR ii = 1 TO LEN(m.cSeed)  && 3 in this case
 ******** Make this char chr(48-57) to chr(48-255)
 newAscii = ASC(SUBSTR(cSeed,m.ii,1)) + INT(199*RAND())
 cOutString = m.outString + CHR(m.newAscii)
ENDFOR

************ Encrypt cInstring & add it to 3-char seed
=RAND(m.nSeed)  && Using new (unique) seed
FOR ii = 1 TO LEN(m.cInString)
 ******* Make this char chr(32-126) to chr(161-255)
 newAscii = ASC(SUBSTR(m.cInString,m.ii,1)) + INT(129*RAND())
 cOutString = m.cOutString + CHR(m.newAscii)
ENDFOR

Steve

 

[Dan Olsson]

Regarding the original question about editing an EXE:
If I recall right, VFP has some sort of checksum on itself and refuses to start if it's tampered with.

 

[GriffMG]

Nah, not so, you can change bits without complaint.

Of course not every bit... or byte B-)

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[Mike Lewis]

Nah, not so, you can change bits without complaint.

Griff's right. I just edited an EXE file, and was able to change a caption and a sort order. It ran without complaint, and with the changes clearly visible.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[mjcmkrsr]

Mike,

I simply use SYS(2007) to generate a checksum.

I wrote this function back in the 1985' for dBase III plus, when there were no SYS()es around, modified it and took it over to FP/VFP. Btw I still have Miriam Liskin's excellent book "Advanced dBase III Plus Programming and Techniques".

although it goes beyond solving Mandy's immediate problem.

Mandy did not want her password to be found in the EXE - hence my hint NOT to store the password anywhere. If it is not stored you can't find it! You could even go further and add a timer to the login screen, which after e.g. 15 sec of inactivity, blanks out the textboxes and releases itself.

MarK

 

[Mandy_crw]

Yes Mark, you're right I do not want my password to be seen if in case EXE is editable.... I want my EXE file to be tamper free... Thanks everyone for the information and teachings....Indeed im learning alot...

 

[Chris Miller]

Sorry for reviving a perfectly complete thread.


But for what reason do you have the paswword in your EXE?

Your EXE could need it for logging in to some API or service or you use it to verify a user log-in to your EXE.

These two different use cases have different solutions, but in both cases a password or API key or any such secret is subject to change and should be stored as data outside of the EXE. Of course not as plaintext.

So that poses a new question - how to do that so this external info isn't even easier to find and misuse. For log in you store a password hash instead of the password. The other case of needing the password for using somethng else needs to store it safelty, ie encryptrd. A problem is that you need to know a key and so it only shifts the problem to securely storing the key to decrypt the password. A practical solution was given by Steve with his hard coded random seed. Even when you know there is such a mechanism it's hard to find in the exe, even when you can decompile it you'll need to find the function that does this.

A solution that doesn't just shift the problem is making use of the Windows Credential Manager. With pros and cons. Before diving too deep into it, please tell more about your use case.

Chriss