At 11:27 PM 20/08/2005 +0000, you wrote:

>Hi there.
>
>I am a beginner using interbase compared to some of you guys. I don't
>use firebird but Borland Interbase version 5.6.
>
>My question is, is it possible to decrypt a gdb file on binary scale?
>I am not too sure on what kind of encryption gdb files use.

InterBase doesn't encrypt the data it stores. The only encrypted thing is
the user password in isc4.gdb, not decryptable by ordinary humans.

The InterBase architecture doesn't lay down data in neat physical lines of
cells, as file-based data storage systems do. It fills data pages. A data
page is a block of disk space of a prescribed size (PAGE_SIZE, 1Kb by
default in the ODS 9 databases created by IB 5.6). Algorithms are used,
according to data type, to compress the data before it is stored and to
identify the attributes and boundaries of each field and row.

> I wish to do this so when I recover corrupt databases, I can be sure of

any data loss.

Database corruption - fortunately a rare event with the IB/Firebird family
- can come in various forms. At one end of the scale, lost data may be
recoverable. At the other - where corruption has some physical cause such
as a dying disk, faulty memory or network, etc., along with some known
causes that you can read about in the Firebird Getting Started Guide, lost
data won't be recoverable.

There are tools you can use to attempt to repair a corrupt database
yourself. A hex editor is not one of them.

-- A How-To is available at the IBPhoenix website with a procedure for
using the command-line tools gfix and gbak to identify corruption and
attempt to repair it. The URL is
http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_db_corr

-- www.ib-aid.com/interbase/firebird/corruption/guide.html is a handy
checklist and you can download a tool to assist you in identifying the
types and locations of corrupt pages.

If these procedures (carefully followed) fail, then you are probably going
to need expert help. Both IBPhoenix and IB-Aid offer commercial services
for recovering data from corrupt databases.

-- Fortunately, it is a rare-if-ever occurrence, if the database file is
protected according to the recommendations.

-- Unfortunately, most, if not all, professional database recovery work is
on IB 5.6 and IB 6.0.x databases. If you have any say in the choice of
database engine, you should avoid those old, unsupported versions. IB 5.6
was a (1998) bug-fix release for the ill-fated IB 5.5 of 1997. Except for
some tinkering that Borland did using bug-fixes harvested from the Firebird
tree, IB 6.0.x is still beta software with a large number of bugs, many of
them inherited from IB 5.6. IB 6.0.x has been developmentally dead since 2001.

Databases that report themselves as corrupt should be shut down immediately
and repair/recovery efforts attempted on a file-copy of the database file,
the file-copy being performed only on a completely shut-down database.

Of course, there should always be realistically recent, tested gbak backups
to fall back to. The ability to repair and recover physically corrupted
databases is greatly enhanced if a good backup is available.

You should never restore databases using the -R[eplace_database] switch.

./heLen