Crack a DAT

  • Thread starter Thread starter Richard Myers
  • Start date Start date
R

Richard Myers

Hello.

I have a binary DAT file from a clients unsupported legacy inventory
management system. Given i dont know what the
structure of the file is, Im wondering if there is either a best practise
or even a utility that can be used to give hints as to
its structure so i can extract its data.

TIA
Richard
 
Richard,

It starts always with a program that makes it possible to read it and
translate directley possible Hex to Decimal and as well Characters. I don't
have such a one maybe you find one on Google.

Cor
 
Richard Myers said:
I have a binary DAT file from a clients unsupported legacy inventory
management system. Given i dont know what the
structure of the file is, Im wondering if there is either a best practise
or even a utility that can be used to give hints as to
its structure so i can extract its data.

I don't see how this is related to the VB.NET programming language.

What you can try do do is adding/removing data from the file and checking
what's changing using a hex editor, for example. It helps to know what
programming language was used to develop the application that writes the
file, because maybe the application uses the programming language's file
access functions (such as 'Put' and 'Get' in VB6).
 
Hi

I agree with Mr MVP that it isn't a VB.NET question

Are you sure you aren't a cracker?

I suggest you try searching the 'New Order' search engine because if you
want any password crackers/decompliers or other related
software/information/exploits then it will be on there. If you do use 'New
Order' & download anything then make sure its not full of spyware/adware.

Sorry that I cannot be of more help.
 
¤ Hello.
¤
¤ I have a binary DAT file from a clients unsupported legacy inventory
¤ management system. Given i dont know what the
¤ structure of the file is, Im wondering if there is either a best practise
¤ or even a utility that can be used to give hints as to
¤ its structure so i can extract its data.

Their is no standard with respect to DAT files. You can try Herfried's suggestion. Access to the
source code for the inventory management system would probably be even better.


Paul ~~~ (e-mail address removed)
Microsoft MVP (Visual Basic)
 
The .DAT file extension is used by several different applications. You need to be clearer about what type of file it is. If you
have access to the entire application that the file(s) come from, there are other files and extensions that will help identify
the original database system used. I am working on converting a legacy app. that uses the same extension for the datatables.
But, you need to do some research to find what you are working with. List some of the extensions and maybe someone here can
help. If you are writing a new application in VB.NET this is the place to ask for help for coding problems. (has been a great
help to me here)
james
 
O.k Thanks... but if you read my messgae you'll see that those are exactly
the things i dont know, hence my post.
I am basically asking if there is a "discovery" tool which can assist me in
obtaining this knowledge, given that
the application is "an unsupported legacy inventory management system."

You're right about this newsgroup it is a good resource and source of
knowledge.

For those enquiring about the relevance of my question to VB.Net, it was
implicit in posting to this group that i would be using vb.net
to implement the solution and thought there may even be some vb.net
specific namespaces/type to aid me in the "discovery".

Oao
Richard

james said:
The .DAT file extension is used by several different applications. You
need to be clearer about what type of file it is. If you
have access to the entire application that the file(s) come from, there
are other files and extensions that will help identify
the original database system used. I am working on converting a legacy
app. that uses the same extension for the datatables.
But, you need to do some research to find what you are working with. List
some of the extensions and maybe someone here can
help. If you are writing a new application in VB.NET this is the place to
ask for help for coding problems. (has been a great
 
Crouchie1998 said:
Hi

I agree with Mr MVP that it isn't a VB.NET question

Are you sure you aren't a cracker?

I suggest you try searching the 'New Order' search engine because if you
want any password crackers/decompliers or other related
software/information/exploits then it will be on there.

Speaking of unrelated, what has this got to do with "clients unsupported
legacy inventory
management system".
 
Richard Myers said:
O.k Thanks... but if you read my messgae you'll see that those are exactly
the things i dont know, hence my post.
I am basically asking if there is a "discovery" tool which can assist me
in
obtaining this knowledge, given that
the application is "an unsupported legacy inventory management system."

You're right about this newsgroup it is a good resource and source of
knowledge.

For those enquiring about the relevance of my question to VB.Net, it was
implicit in posting to this group that i would be using vb.net
to implement the solution and thought there may even be some vb.net
specific namespaces/type to aid me in the "discovery".

Oao
Richard

I reckon that getting the data out of the machine it's on would probably be
easier than off some DAT file.
You have access to the client's legacy system computer?
What is it?

Do you know for sure what you got on that tape is all you need?
If you go look at whatever is in the vsam/flat/mdb/whatever files on the
actual computer, at least you know you have everything.
It's also more likely you can identify what the files are if you're looking
at separate tables/files.
This would then at least break the problem down into more manageable chunks.
Just because the package is unsupported doesn't mean it necessarily uses
files no odbc driver exists for.

I replaced one system we couldn't get the data out in any useful format.
The simplest way was to print off the data in reports and OCR the stuff in.
A while back, so OCR wasn't 100% reliable and messing around with reams of
fan-fold was rather labour intensive.
However, at least they could throw secretarial (cheaper than me) personnel
at the problem to check and modify dara manually.

The only time i can see working off a tape being the best option would be
where that's all I had access to.
The sort of person most likely to have experience of this sort of thing
would be a hacker/cracker.
 
Richard, so, you are saying the ONLY file(s) you have access to are the .DAT file(s), correct? If that is so, then I don't know
of any tool out there that will be able to tell you what system your legacy file is from. .DAT is too common an extension
(unfortunately) to identify by itself. You have probably already been to one or more of the websites that list file extensions
and found this out for yourself.
If it had been the .DAT that I am working on, there would be other files associated with it, including some with the .TAG
extension. In that case it would probably be an old DATAFLEX database file. And for each .DAT file there would be a
corresponding .TAG file, because each .DAT file only contained a single table and field def's but, NO Field Names. Those are
found in the .TAG file(s) with the corresponding name to the .DAT file. Plus, depending on what version of Dataflex, there
could be other files with .HDR & *.K1 - whatever. With .HDR being a copy of the .DAT file's header info.(but, not always
correct.........groan...) And the *.K1 or higher number.......are Index files.
But, if you only have .DAT file(s) and that is what the original application had with it, then it is not a Dataflex database.
So, at least you could rule that out.
I would look up .DAT at one or more of the extensions websites and find all the databases associated with that extension and
then, I would try to find a sample file of each one and compare the headers to your legacy .DAT file . You might be able to
identify it that way. It would be a lot of work, but, otherwise I see no other way.
james
 
Another clue, is to look at the data file with a Hex editor and see if some of the Data is in Text or even load the file into a
RichTextbox . If some of the data is in plain text then you could at least extract the actual data if all else fails.
james
 
Print a report with that program, capture the output and parse the resulting
file.

There were some utilities to capture PRN to a file in DOS-era.

Best regards,
Alejandro Lapeyre
 
If the program has printing capabilities and you can not caputre the PRN
output maybe you can configure the output to a Serial Printer and then
capture the Serial output (with a second machine connected to the serial
port).
 
Back
Top