from the v4 help:

"The TDBISAMEngine EngineSignature property controls the engine signature
for the engine.  The default engine signature is "'DBISAM_SIG".  The engine
signature in DBISAM is used to "stamp" all tables, backup files, and streams
created by the engine so that only an engine with the same signature can
open them or access them afterwards.  If an engine does attempt to access an
existing table, backup file, or stream with a different signature than that
of the table, backup file, stream, an EDBISAMEngineError exception will be
raised.  The error code that is returned when the access fails due to an
invalid engine signature is 12036 and is defined as DBISAM_BADSIGNATURE in
the dbisamcn unit (Delphi and Kylix) or dbisamcn header file (C++Builder)."

*first question*: where is the signature stored ? i tried looking inside the
..dat , .idx, .blb files with a hex editor but did not find the signature in
any part of the file. Is it encrypted in some way? the tables i examined
were upgraded from v3 - maybe is the upgrade process that does not write the
signature ?

*second question*: if the "upgrade" procedure does write the signature, to
have it changed to my own instead of default, should i customize the engine
before calling the upgrade procedure?

*third question*: with a different signature rather than default, will the
dbsys procedures work? for example can i (or everyone else) perform a
repair, with dbsys or even with external utilities (like DDQM) ?

thanks for your patience
Sandra

I can't answer all of those, but an engine that has a custom signature can read the
standard files, and its own, without problem. But when it creates a file, it writes
the signature, and then no standard app can read it.

> *third question*: with a different signature rather than default,
> will the dbsys procedures work? for example can i (or everyone
> else) perform a repair, with dbsys or even with external utilities
> (like DDQM) ?

A standard dbsys cannot read it. You can though rebuild dbsys with your custom
signature to allow people to edit your files. I added a further mod of requiring a
password for the more advanced options so that end users can't go deleting tables
accidentally.

/Matthew Jones/

Sandra,

<< *first question*: where is the signature stored ? i tried looking inside
the .dat , .idx, .blb files with a hex editor but did not find the signature
in any part of the file. Is it encrypted in some way? the tables i examined
were upgraded from v3 - maybe is the upgrade process that does not write the
signature ? >>

The signature is stored in each table file (.dat, .idx, and .blb) and is
stored as an MD5 hash.

<< *second question*: if the "upgrade" procedure does write the signature,
to have it changed to my own instead of default, should i customize the
engine before calling the upgrade procedure? >>

Yes.

<< *third question*: with a different signature rather than default, will
the dbsys procedures work? for example can i (or everyone else) perform a
repair, with dbsys or even with external utilities (like DDQM) ? >>

You'll have to customize DBSYS (modify the source code) in order to use a
custom signature with it.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:
> The signature is stored in each table file (.dat, .idx, and .blb) and
> is stored as an MD5 hash.

ok, understood! thanks. I guess that the signature is stored in a fixed
position in each file, for example from byte #10 to byte #30, right?
But in this way a "data-cracker" could replace the signature, editing the
file through a hex-editor, with the default signature (that he could obtain
with the stock DBSYS simply creating a table), obtaining a table that could
be opened/repaired/etc. without any problem, isn't it?

Sandra

Alessandra,

<< ok, understood! thanks. I guess that the signature is stored in a fixed
position in each file, for example from byte #10 to byte #30, right?  But in
this way a "data-cracker" could replace the signature, editing the file
through a hex-editor, with the default signature (that he could obtain with
the stock DBSYS simply creating a table), obtaining a table that could be
opened/repaired/etc. without any problem, isn't it? >>

Sure.  The signature is not a replacement for encryption, but rather a
lightweight way of making it so that end users can't use external access
like DBSYS or the ODBC Driver to gain access to the table data.

--
Tim Young
Elevate Software
www.elevatesoft.com