extracting data from a foxapp? 
Author Message
 extracting data from a foxapp?

I've purchased a book which came with a CD - basically the book's
tables are buried in a foxapp on the CD.  The app is a royal pain,
built with stupid things like absolute paths which generates error
dialogs and won't save configuration data.

It has been suggested that the data should be seperate from the
application, and that in this case, a program like refox shouldn't be
nessecary.  However, the only file of any significant size is the exe
- at 322MB.  I don't really care about the source code, I just want
the data so that I can build an app that actually works.

There are two extra files:

2002-09-18  15:38             1,337 FOXUSER.DBF
2002-09-18  15:38            16,256 FOXUSER.FPT

which contain some kind of non-sensical structure data which I was
able to grab through an ODBC connection.  Other than that, I've been
unable to figure out hth to get the data out of this thing.  Blowing
400$/non-refundable for an app (refox) that might not work isn't
really something I'd like to try.  I do have a copy of Visual FoxPro
Studio something or other, but I'm not sure how to make that work for
a situation like this.

Any suggestions or help anyone could provide would certainly be
appreciated.

thanks!
-rj

(lose the x-'s)



Mon, 07 Mar 2005 23:43:12 GMT  
 extracting data from a foxapp?
richard hornsby nous a audacieu{*filter*}t crit :

Quote:

> 2002-09-18  15:38             1,337 FOXUSER.DBF
> 2002-09-18  15:38            16,256 FOXUSER.FPT

these two files are resource files mainly used to save (internally by fox)
browse windows positions and other stuff like configurations of the system
toolsbars etc...

Do you have a file calle CONFIG.FPW and if yes, what is its content
(notepad)?

Fred



Tue, 08 Mar 2005 00:01:37 GMT  
 extracting data from a foxapp?
Are you looking to write an application, or reverse engineer one?

FOXUSER is the standard FoxPro control table that is used to store preferences for window positions etc. That's not usually part of the application data.

There is what amounts to a virtual filing system inside the executable. The VFP runtime is capable of finding embedded files as if they came from your real disk drives.
I don't know of any tools to extract the embedded .DBF files.

Not being able to easily get the data out is a good thing for those of us who write applications and want to preserve copyright. Embedding critical data in the application is one way of making it harder to copy.
I worked on a CD database where all the data in the tables was encrypted, but the indexes were built using the unencrypted files. So the searching used plain text, but the database contents were unreadable.
Theoretically it would be possible to extract some of the data from the index it's true, but not all the data. It was a good compromise that left the data and application separate, but still secured the valuable data.



Tue, 08 Mar 2005 00:09:28 GMT  
 extracting data from a foxapp?
What book was it?  What are you trying to get from the book and from the
sample app?


Tue, 08 Mar 2005 21:38:29 GMT  
 extracting data from a foxapp?

Quote:

> > 2002-09-18  15:38             1,337 FOXUSER.DBF
> > 2002-09-18  15:38            16,256 FOXUSER.FPT

> these two files are resource files mainly used to save (internally by fox)
> browse windows positions and other stuff like configurations of the system
> toolsbars etc...

yeah, you're right - thats kinda what the information I was able to
glean from the files seemed to suggest.

Quote:
> Do you have a file calle CONFIG.FPW and if yes, what is its content
> (notepad)?

nope. :/


Wed, 09 Mar 2005 15:00:17 GMT  
 extracting data from a foxapp?
sorry, but amongst the questions I'm going to rant a bit.

Quote:

> Are you looking to write an application, or reverse engineer one?

If I can get the data out of this thing, then I will write an app for
the data that a) works properly and b) actually makes a bit of damn
sense.

I found a suggestion on the manuf/author's website on fixing the
Invalid path errors the app is throwing: changing the temp and tmp
environment variables to point to the windows system directory.  That
is NOT an acceptable fix.  The whole point of those variables is that
the programs are supposed to read them and make use of them.  If the
variable says use directory "X" to write temporary files, then dammit,
write the temp files there.

Secondly, pointing those variables to ANY system directories (as
opposed to the user's temp directory) is an ACL violation in 2000 and
XP.  If a user isn't an "Administrator", they can't change those
variables, and even if they could, it wouldn't do jack because they're
not allowed (typically) to write to anything except their own
directories.  So, I'll say it again - the app is broken and was built
poorly.  Hence, wanting to get the data out.  If this means reverse
engineering the app that was bodged (junkyard wars word) together,
then so be it.

Quote:
> Not being able to easily get the data out is a good thing for those of us who
> write applications and want to preserve copyright. Embedding critical data in
> the application is one way of making it harder to copy.

If you're a competent app writer, then it is also good for the
end-user, who is supposed to be the most important part of the
project.  When was it decided that a company protecting itself from a
few hooligans was worth forcing the customers to sacrifice a
reasonable product?  Maybe its a "they'll just have to live with it"
attitude.  I'm paying for the damn thing.  If I want or need to take
it apart because its broken, then why is that not my option?  Is the
hood of my car welded shut?  If I decide that the battery in my car
bites, then I will go to Sears, buy a new one and put it in.  If I
don't like the instrument panel layout (with a whole lot of work) I
can put a new one in that I like.

Places like RadioShack exist because people want to toy and play and
fiddle and make things work right or better.  Resistors and diodes and
capacitors, etc are the building blocks of modern electronics.  Using
those parts, people can fix their TVs if they want (just don't touch
the red wire), or mod the servos in the old Teddy Ruxpin (a teddybear
with a cassette deck sewn into him who had a moving mouth and eyes)
and make him do something else - like read emails from Grandma to your
3 year old kid.  Legos and Capsula and Lincoln logs.

I'm sorry that this seems offtopic, but I think it gets to the heart
of what I'm trying to here - take the pieces of something that are
working right (the data) and meld them with new pieces that suit what
I'm trying to do (the app).  I've seen more than a few messages in
this group touting the "proprietary rights of so-and-so company".  It
gets real old, real fast.

Quote:
> I worked on a CD database where all the data in the tables was encrypted, but
> the indexes were built using the unencrypted files. So the searching used
> plain text, but the database contents were unreadable.

*sigh*  Again.  You seem like you're probably a compenent app writer.
What is the recourse then, for those of us who know how and need to
build a better app than the one that is provided?  Are we just
screwed?  The data itself is public - published by the FCC.  The
format and the fact that it has been gathered into one place is the
work of the authors.

Anyways, now that I've ranted for a while I still don't have the data.
 But if I understand you correctly, what you're saying is that I'm
pretty much stuck with reverse engineering the app to get the data
out.  In doing so, I'll probably going to end up hitting three walls:

  - breaking the EULA (which anyone in this group should just report
me now because I've probably already done that just by trying all of
these things)
  - a virtual file system which is "mounted" only while the app is
running
  - some type of encryption on that filesystem.

If anyone has any information on how to extract the data or reverse
engineer the app, I would appreciate it.  If you don't feel like
posting publicly, feel free to email me rhornsbyAosuedcDorg



Wed, 09 Mar 2005 15:41:54 GMT  
 extracting data from a foxapp?


Quote:
> sorry, but amongst the questions I'm going to rant a bit.




Quote:
> > Are you looking to write an application, or reverse engineer one?

> If I can get the data out of this thing, then I will write an app for
> the data that a) works properly and b) actually makes a bit of damn
> sense.

> I found a suggestion on the manuf/author's website on fixing the
> Invalid path errors the app is throwing: changing the temp and tmp
> environment variables to point to the windows system directory.  That
> is NOT an acceptable fix.  The whole point of those variables is that
> the programs are supposed to read them and make use of them.  If the
> variable says use directory "X" to write temporary files, then dammit,
> write the temp files there.

Make a Config.fpw file that sets the temp directory for VFP and see if it
works, Start the app with the -C switch:
Filename.exe -Cpath\config.fpw

Put this line in config.fpw
TMPFILES = drive:\folder

or
TMPFILES = C:
might work to direct them to the local temp file directory for the user.
Default is the stratup directory which of course is a problem if the exe is
stored on a server.
-Anders



Wed, 09 Mar 2005 20:41:15 GMT  
 extracting data from a foxapp?

Quote:
>Is the hood of my car welded shut?

Effectively in a modern car, yes.

Take mine for example:
Sure I can open it, but the engine has an ECU and not a real carburettor any more. Nothing to adjust.
The throttle pedal isn't even linked to the engine! Just a fly-by-wire potentiometer talking to the Engine computer.
So is the gearstick, just a bunch of hall-effect electronic switches talking to the Gearbox/clutch computer.
There's no clutch pedal at all, totally computerised.
The Engine ECU talks to the Transmission ECU and they know each other's serial number.
Swap one without the manufacturer's software to reprogram them and nothing works.
The Z computer controlling aircon, lights etc talks to the other CUs, and they vote on the car's identity.
If they disagree, it shuts down everything.
Oh and you can't wind the clock back any more to put less miles on it :(

Of course there are hacking/cracking tools available to let you swap parts cheaper than going to the garage.
Its the motor equivalent of ReFox I suppose.

I first thought your analogy flawed in today's world, for 10-15 year old cars with real cables and mechanical parts I'd agree with you.
But then hang on a minute - for 10~15 year old software it'd probably be in the same state, more open and amenable to disassembly.
So yeah, your analogy is spot on.



Sat, 12 Mar 2005 23:21:49 GMT  
 extracting data from a foxapp?
Well, in my case the client wanted to provide data to their customers but protect their investment in compiling it. The company had the results of over 100 years of work tied up in it and wanted to meet two totally incompatible objectives <g> Sell the access to the information to large customers on CD, yet stop them copying the data into their own systems. In the end they compromised on making it easy to copy, but hard to access.

You might be able to solve the temp files issue following Anders' approach of setting up the extra configuration file.

If it's been built with debug information in, and doesn't trap the ESC key then it might be possible to suspend it in mid-flight.
Even then you'd need to be able to run the .EXE under the VFP development environment, and suspend it so that you can use the debugging tools.
Then the development environment would have access to open cursors (if it uses them) in the command window.

But if the authors were competent then that avenue will be closed.



Sat, 12 Mar 2005 23:30:00 GMT  
 
 [ 13 post ] 

 Relevant Pages 

1. ODBC - extracting data from Access .MDB file

2. extracting data from foxpro2.0

3. Extracting data to excel

4. Extract data from delimited text file

5. Messaging and Workflow apps with VFP (aka Extracting data from Exchange)

6. Extract data from MS Excel spreadsheet to Foxpro 2.6 dbf format

7. How to extract the difference data records from two similar tables

8. Extract binary data from a file

9. Extracting data from remote Sql View

10. Extracting Data from Grids

11. Extract Data From a Cursor Into a Textbox

12. Creating an EXE from a APP created by FOXAPP.APP

 

 
Powered by phpBB® Forum Software