I've been working on a program that, if possible, can safely blank out the sensitive properties in the executable.  That could then be called from FinalBuilder before the executable is code signed.  I'll see how it goes.

I don't want to use exe compressors as a lot of security software can flag it as malware (because that's what bad guys sometimes use to hide their true intentions).  And often code signing doesn't work with exe compressors.

= Steve

Steve Gill,

That program that you found that inspects your EXE.

Does the program run against the EXE whilst the EXE is on disk or whilst the EXE is running?

Hi Peter,

<< That program that you found that inspects your EXE.

Does the program run against the EXE whilst the EXE is on disk or whilst the EXE is running? >>

While the EXE is sitting on the disk.

= Steve

Roy Lambert wrote:

> is in the dfm..

Oh noes! Pity that they are not readable by any other application! 8-)

Indeed, so the dfm makes it much easier - you simply search for the property name, and (in a smart way) just delete the line. I say smart, in case it messes up the structure - or is that JSON I have to do that with? Anyway, it isn't hard, just text.

--

Matthew Jones

Would not it be the case of the following?

If you delete the line that mentions the property password then when the EXE runs it will not read the valid password and so the database will not be opened.

Peter Evans wrote:

> If you delete the line that mentions the property password then when the EXE runs it will not read the valid password and so the database will not be opened.

It would indeed be that case. However, being clever, you have included code that, in the module creation, magics up the password from some encrypted or obfuscated source, and applies it to the property before calling Open. Thus disaster is averted.

8-)

The main thing is that the removal should remove the property, typically "Active", that automatically makes the connection.

--

Matthew Jones

"Matthew Jones" wrote:



It would indeed be that case. However, being clever, you have included code that, in the module creation, magics up the password from some encrypted or obfuscated source, and applies it to the property before calling Open. Thus disaster is averted.

Oh, now I understand the solution. Thank you.

Malcolm,

<< Hmm, maybe Tim does not know about that glitch(?) >>

Which glitch are you referring to ?  I've read this thread a few times now, and I'll be darned if I can figure out what the issue is.

Tim Young
Elevate Software
www.elevatesoft.com

Steve,

<< If you have your encryption passwords, database signature, username and password and so on set in the TEDBEngine and/or TEDBSession components then I have come across at least one program that can read these from the executables. >>

I'll see about adding some more information about this in the manual.

In general, I always recommend using the defaults during development, leaving them in place during compilation, and then use an external file (preferably encrypted with a customer-specific key) to populate the values during application/server initialization.  That makes it easier on development, and you can always have EDB Manager sessions set up with the real encryption passwords so that you can work with customer databases, if necessary.

This is probably one of those things that I should automate more, and will look to do so when I move the EDB encryption over to AES.

Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

> Malcolm,
>
> << Hmm, maybe Tim does not know about that glitch(?) >>
>
> Which glitch are you referring to ?  I've read this thread a few
> times now, and I'll be darned if I can figure out what the issue is.
>
>

Hi Tim

I have my Engine.StoreActive=False and that makes sure the program
launches with no unexpected database connections.

But I was doing some debugging sessions recently and was surprised to
find that after Resetting the debug run, making some change, then
launching another debugging run .. the Engine was 'Active' even though
StoreActive was False.  I found I had to specifically set .Active=False
before running the next debug run.

Probably I don't understand quite how it works in the IDE/Debugging?

Malcolm