Hi all,

Anyone have any ideas about this? I have a phone directory on CD and I want to be able to reverse it so that I can put in a number and get back an address and name... I think it might be a Paradox database but I'm not certain. Any help would be good.

Thanks

Hello,

Well, except if the directory is kind of encrypted, this
should not be too hard.

First i would extract 3 or 4 samples of what kind of
data are in the DB using the original soft.

Then, try to figure the way the data are stored, ex :

1st field : Index, 2 byte
2nd field : Name, 30 bytes
3rd field : etc....

Once you have done that, you are ready to write a
little app that will fetch any data in the form you want.

If it's a standard/common DB, good chance that you will
find even some tools to reduce this process

Regards
FoolFox

alternatively, you can use infospace's reverse lookup: http://kevdb.infospace.com/info/wp/reverse.htm

Thanks for the replies. I don't know much about Paradox dbs but I'm pretty certain that it is encrypted. I've run Paradox password crackers on some of the files on the CD but they haven't helped. It is possible that it's not a Paradox db after all... I've no way of knowing (except from what I read elsewhere on the Web regarding this CD, see http://www.hackwatch.com/~kooltek/reversecd.html).
I've tried to import the db into Access but it complains that "The external table is not in the expected format".

As regards using http://kevdb.infospace.com/info/wp/reverse.htm, I don't live in the States, I live in Ireland... And to the best of my knowledge, reverse phone directories aren't permitted here... (they certainly don't exist publicly outside the hands of the telecoms companies and the government).

Is there a way to identify what type of db it is?

Here's a DOS listing of all the files in the data directory of the CD:

Directory of D:\TELECOM3

09/10/1998 13:55 <DIR> .
01/01/1601 00:00 <DIR> ..
18/09/1998 00:30 921,768 A1.ADH
17/09/1998 23:26 24,857,638 A1.ADJ
18/09/1998 00:49 2,214,696 A1.BRO
18/09/1998 00:18 922,148 A1.HHH
17/09/1998 23:30 262,162 A1.HSH
18/09/1998 00:48 12,979,170 A1.IND
09/10/1998 09:57 233 COMPWIN.SET
20/07/1998 11:25 223,535 Crp.bro
18/09/1998 00:06 4,024 DC.HHH
17/09/1998 22:38 262,162 DC.HSH
18/09/1998 00:48 3,402,103 DC.IND
18/09/1998 00:48 379 DCP.BRO
18/09/1998 00:06 4,024 DCP.HHH
17/09/1998 22:40 262,162 DCP.HSH
18/09/1998 00:48 3,402,103 DCP.IND
09/10/1998 09:57 1,280 FULLWIN.TEM
18/09/1998 00:32 145,340 IT.ADH
17/09/1998 23:37 1,214,697 IT.ADJ
18/09/1998 00:49 334,981 IT.BRO
18/09/1998 00:18 144,544 IT.HHH
17/09/1998 23:37 262,162 IT.HSH
18/09/1998 00:49 625,179 IT.IND
20/07/1998 11:25 101,122 Icp.bro
31/07/1998 10:09 67,162 Inp.bro
20/07/1998 11:24 100,516 Irp.bro
18/09/1998 00:46 1,082,384 MA.ADH
18/09/1998 00:39 25,960,045 MA.ADJ
18/09/1998 00:48 2,339,924 MA.BRO
18/09/1998 00:33 973,444 MA.HHH
18/09/1998 00:32 262,162 MA.HSH
18/09/1998 00:48 13,496,450 MA.IND
18/09/1998 00:23 705,416 NM.ADH
17/09/1998 22:55 17,394,207 NM.ADJ
18/09/1998 00:06 703,996 NM.HHH
17/09/1998 22:58 262,162 NM.HSH
18/09/1998 00:48 9,072,617 NM.IND
18/09/1998 00:06 42,992 NMF.HHH
17/09/1998 23:05 262,162 NMF.HSH
18/09/1998 00:48 8,326,394 NMF.IND
18/09/1998 00:48 15,710,343 NMP.BRO
18/09/1998 00:16 5,342,672 NMP.HHH
17/09/1998 23:01 262,162 NMP.HSH
18/09/1998 00:48 13,000,496 NMP.IND
09/10/1998 09:57 133 PROG_RUN.LOG
18/09/1998 00:48 339 RT.BRO
18/09/1998 00:06 4,024 RT.HHH
17/09/1998 22:42 262,162 RT.HSH
18/09/1998 00:48 3,402,076 RT.IND
18/09/1998 00:32 4,036 SD.ADH
17/09/1998 23:34 6,806,846 SD.ADJ
18/09/1998 00:49 475 SD.BRO
18/09/1998 00:18 4,036 SD.HHH
17/09/1998 23:35 262,162 SD.HSH
18/09/1998 00:49 3,403,454 SD.IND
17/09/1998 22:13 18 STOPWORD.DAT
18/09/1998 00:06 9,792,060 SY.HHH
17/09/1998 22:36 262,162 SY.HSH
18/09/1998 00:47 16,048,694 SY.IND
18/09/1998 00:49 71,324,014 TELECOM3.DAT
17/09/1998 22:13 275 TELECOM3.DEF
18/09/1998 00:48 50 TELECOM3.ENK
17/09/1998 19:09 291 TELECOM3.FB4
18/09/1998 00:49 420 TELECOM3.FDL
17/09/1998 22:17 3,402,068 TELECOM3.IND
17/09/1998 22:17 34,020,980 TELECOM3.INF
17/09/1998 22:30 45,927,864 TELECOM3.NOD
20/09/1998 10:24 5 TELECOM3.QA
17/09/1998 19:09 99 TELECOM3.RB4
18/09/1998 00:49 118 TELECOM3.RB5
18/09/1998 00:49 118 TELECOM3.REC
18/09/1998 00:49 218 TELECOM3.RUP
18/09/1998 00:48 63,848,448 TELECOM3.TTI
09/10/1998 09:57 0 TEMDOS.MNU
09/10/1998 09:57 21 TEMWIN.MNU
05/07/1993 16:14 1,417 VALIDCHS.DAT
75 File(s) 426,694,401 bytes
2 Dir(s) 0 bytes free


Do any of these file names/extensions mean anything to anyone?

How would I begin to solve this?

Many thanks,

narnar2000

I do not know most of the file names and extensions you posted but:

Look at the bigger files (they should contain most of the databases) They tend to be in the form:

A1.ADJ and then you find a A1.IND about half the size.

Keep looking and you see NM.ADJ and lower down NM.IND

and so on. Smells to me that the ADJ files contain the bulk of the data and the IND files are indexes for the correspondent data. There are some .IND files that do not correspond to an .ADJ file, but their name is a derivative of an .ADJ file i.e.

There is one NM.ADJ

but you find NM.IND, NMF.IND NMP.IND, all of them bulky files, but around half the size of the .ADJ.

Look at the contents of each .ADJ files with an hex editor. If it is a database, it may contain a header and then some recurring structure: the records.
It may or may not be encrypted. Chances are, this being a commercial product, it is encrypted.

One course of action would be decrypting and reconstructing the database(s), then designing your own reverse searcher.

An interesting and True-Blood Reverse Code Engineering project.

Hello,

About h**p://www.hackwatch.com/~kooltek/reversecd.html,
well, i wouldn't take that as a fact. From what it appears to
me, someone told someone that probably this may be a
paradox DB. Without even 1 clue about what have made
someone guess that.

So far, i think that focusing on Paradox only with one info
like that would be too restrictive. You may loose much time
trying all paradox related stuff where you may have a
totally different DB.

As have said naides, look at the big files. And if they look
encrypted, then you'll have to dig the exe that is grabbing
the info from the DB.... have you already take a look at the
main app ??

Regards
FoolFox

Some observations (may be obviously made by others) that I'd like to mention:

1. Look at PROG_RUN.LOG (looks like some king of log where in you can gather some "inside" info)
2. AD/MN ==> A-to-D, M-to-N??? alphabetically
3. Just open the .DAT files in a hex editor and see if you can find regular text. If yes, chances are it is not encrypted.

Also, the best way to verify if it is Paradox Db is to get a "real" paradox Db and search for "signatrue" strings and see if these are present in the .DAT philes

Signed,
-- FoxThree

Thanks again for the replies...

I looked in *.ADJ with WinHex - names and addresses are stored in plantext here... Along with a whole load of non-alphanumeric bytes. The names are stored alphabetically, as you'd find them in a phone book, but following each name are many 'garbage' bytes (I've noticed the number of such bytes correlates to the frequency of the surname, ie SMITH has thousands of bytes immediately after its listing, whereas an uncommon name like SMIROV has only a few). The names of areas, towns etc are also stored in this fashion.

TELECOM3.DAT contains no names, addresses or numbers in plaintext format.

The string 'Paradox' is not in any of the files, so maybe it's no Paradox db after all.

None of the files in the directory contains my phone number in plaintext, so it seems the phone numbers table is encrypted.

I'll see if I can glean anything from the app with SoftICE, but I was hoping I wouldn't have to go down that route...

For what it's worth, here are the contents of some of the smaller plaintext files:

PROG_RUN.log
Command REM done

Command SET_LOGFILE done

Command SET_DIR done

Encrypting...
Encryption Complete.
Command ENCRYPT done


TELECOM3.RUP
DC VC 8
RT VC 8
NM VC 8
BD VC 8
A1 VC 8
SD VC 8
PH VC 8
IT VCR124 8
SL VCR124 8
SY VCS 7
MERGED MA C A1 IT


TELECOM3.FDL
DC 1 C 0 * Type:
RT 1 C 0 * Record Type:
NM 1 C 0 * Name:
BD 1 C 0 * Business Desc:
A1 1 C 0 * Address:
SD 1 C 0 * Directory Area:
PH 1 C 0 * Telephone Number:
IT 1 C 0 * Address:
SL 1 C 0 * Indent phone No's:
MA 1 C 0 * Address:


TELECOM3.DEF
field NM 0 25 0
title 'Name'
tab-stop
text ' '
title ' '
tab-stop
field A1 0 30 27
title 'Address'
tab-stop
text ' '
title ' '
tab-stop
field DC 0 11 59
title 'Type'
tab-stop
text ' '
title ' '
tab-stop
field SD 0 4 71
title 'Area'
tab-stop
newline


TELECOM3.FB4
DC 1 C 0 * Type:
RT 1 C 0 * Record Type:
NM 1 C 0 * Name:
BD 1 C 0 * Business Desc:
A1 1 C 0 * Address:
SD 1 C 0 * Directory Area:
PH 1 C 0 * Telephone Number:
IT 1 C 0 * Address:
SL 1 C 0 * Indent phone No's:


Thanks,

narnar2000

OK narnar.

What yu describe in the .ADJ files sounds more like the structure of an index file, in which a search term i.e 'SMITH' is associated with all the occurrences of such term in the actual database i.e a lot while other search terms like 'SMIROV' is associated with a few occurences.

These findings suggest that the true database is perhaps TELECOM3.DAT, the biggest file in the lot, bu it does not contain actual alphanumeric data, only tokens to the search terms, which are stored in the indexes.

That is bad news.
Good News:

Relational databases coding is quite an involved procedure. A company in their right mind would not re-invent the wheel and come up witha brand-new database system when other, very powerful and thoroughly debugged and tested systems are available.

Look in the web site of the company that made the CD. Look in their help files, look in their patent lists, try to find out what database format they used.

I AM NOT SURE THAT THE WORD 'PARADOX' IS THE SIGNATURE OF PARADOX DATABASES.

The number of commonly used db in windows is small. search and dig their organization and signatures, then try to identify the db system your CD uses

>TELECOM3.DAT contains no names, addresses or
>numbers in plaintext format.

This is probably the root database file, and may contain pointers to all the other files. I don't know how large an area the data base covers, but my guess would be that htis would be the root place for selecting area codes, or however it is selected.

>None of the files in the directory contains my phone
>number in plaintext, so it seems the phone numbers
>table is encrypted.

If there is stuff in there in plain text, then I doubt the numbers are plain text, or encrypted. A more compact way of storing numbers would be as binary numbers. A 64 bit number would be large enough to store the number of almost any phone number within an area code. If an area code is part of the number then that may be a seperate 16 or 24 bit number.

Another thing you may wish to consider, is how the plain text strings are stored. My pick would be that there will be a length code of some sort, a byte is probably sufficient, to store the length of a string in a field. If there is no length byte, then the possibility of storing lots of spaces unneccessarily exists.

If this is the case you may be able to take a short cut into reading the table using pascal.

Just a quick tip - I've seen databases store large numbers (eg. phone numbers) using nibbles before now, this way you can easily store 2 digits of the number per byte. Other's just store it as an unsigned long or the like.