Help reverse engineering a data file??

Forums › Desktop computing › Help reverse engineering a data file??

1 | 2

JayADee

2118 posts

Uber Geek

#1717369 8-Feb-2017 20:10

Rikkitic:
JayADee: Google suggests it is a windows 3 Quicken file

I have a feeling that may be just a coincidence. It seems unlikely (never impossible, of course) that a modern business would still be using a Windows 3 programme.

Won't hurt to try. :)

Edit: also those old versions of Quicken run on Win 7 too, it's possible someone is just using an old version of Quicken because it's freely available much like some people use photoshop 2.0

Tradepub

Free professional, reference and technical white papers (affiliate link).

cgreenwood

201 posts

Master Geek

#1717371 8-Feb-2017 20:17

Thanks everyone for your input, looks like this may be getting in the too hard basket quite quickly. Unfortunately the software on the instrument PC will not allow me to make any changes to the file so I can't do any trial and error type experimenting. It looks to me like the file is either encoded or compressed or encrypted so as you say, I am stuffed. Was worth a try :)

P.S the quicken file extension was QNX and this is a QXN :) the Q stands for Quality as this is a quality control reference file and XN is the model number of the instrument in question.

JayADee

2118 posts

Uber Geek

#1717386 8-Feb-2017 20:28

Doh, I even double checked to make sure I didn't mix up the two last letters and still managed to!
Good luck. :)

gzt

16905 posts

Uber Geek

Lifetime subscriber

#1717389 8-Feb-2017 20:29

Try renaming it with a zip extension and opening it. Unlikely but has happened.

More generally I'd guess this is a solved problem. It is unlikely you are the first person with the need.

How are the files loaded to the instruments?

A link to the website might be helpful if that's appropriate for your situation.

ANglEAUT

2293 posts

Uber Geek

Trusted

Lifetime subscriber

#1718020 10-Feb-2017 00:15

JayADee: Doh, I even double checked to make sure I didn't mix up the two last letters and still managed to!
Good luck. :)

Not necessarily your fault. Maybe you just didn't read the line from Google that said "couldn't find enough results for QXN, showing you results for QNX insstead"

Please keep this GZ community vibrant by contributing in a constructive & respectful manner.

ANglEAUT

2293 posts

Uber Geek

Trusted

Lifetime subscriber

#1718022 10-Feb-2017 00:19

gzt: Try renaming it with a zip extension and opening it. Unlikely but has happened.

Thinking the same, but then you should have seen something like !ZIP in the first line of the Hex Editor screen shot. On Unix / Linux you can use

file <filename.ext>

and it will guess the type of file based on those initial first few magic numbers.

Bummer, no info available from http://filext.com/file-extension/QXN either.

Edit: Added filext.com link

Please keep this GZ community vibrant by contributing in a constructive & respectful manner.

frankv

5678 posts

Uber Geek

Lifetime subscriber

#1718037 10-Feb-2017 07:09

gzt: Try renaming it with a zip extension and opening it. Unlikely but has happened.

ZIP definitely won't work... first two bytes of a zip file are always "PK". But maybe RAR or some other compression format?

gzt

16905 posts

Uber Geek

Lifetime subscriber

#1718065 10-Feb-2017 08:05

Do you have some idea of the data you expect to exist in the file? Is there a particular number you want to change or is your desired outcome more complex?

wazzageek

1093 posts

Uber Geek

ID Verified

Trusted

Lifetime subscriber

#1718892 12-Feb-2017 13:58

Can you tell us what the instrument is (manufactuer would be good too) and what you are trying to update? (There could be more than one way to skin the proverbial :-))

kingdragonfly

11003 posts

Uber Geek

Subscriber

#1718906 12-Feb-2017 14:48

I'm guessing this is a dead topic.

A compressed file will have a "Calculated Redundancy Check", CRC. It's just a fancy way of saying read through all the data, use some kind of math, and come with a number.

If any byte changes, the uncompressor ("unzippig" for example) detects the corruption, and stops.

As mentioned the first bytes is usually some kind of header. You'll see headers in JPG and ZIP files, and lots of other formats, and it'll often be a good indication what you're dealing with.

NEVER WORK ON THE ORIGINAL FILE; MAKE A COPY.

To see if it's compressed, use a hex editor, pick a byte near the end, and change it.

If you get a "file corrupted" error, it's either compressed or encrypted or both. Otherwise you're lucky.

If it's uncompressed, and very observant, you may notice some value has changed on your instrument. In that case, congratulations, and keep at it.

If you're unlucky, it's an encrypted file. Most encryption have a "whirlpool" affect, which means changing a single byte makes a huge change over the entire file.

In this case, you'll also get a "corrupt file" error also, but it's much harder break.

If you do break it, at least you'll get bragging rights for your hard work.

cgreenwood

201 posts

Master Geek

#1719908 14-Feb-2017 11:50

Thanks everyone for your continued efforts and advice with this.

Here is a link to the data the file contains: https://dl.dropboxusercontent.com/u/61363055/XN%20CHECK%20ASSAY%20SHEET(63611101).pdf

If anyone is still interested, there is another file format which the analyser uses which may to be able to achieve what I want. This I can change some values in, and viewing it in a hex editor at least reveals some file header info.

It contains similar data to above, here is an example: https://dl.dropboxusercontent.com/u/61363055/R%20Backup%201.tlf

This next link is the same file after having the value 2.45 changed to 2.46: https://dl.dropboxusercontent.com/u/61363055/R%20Backup%20245%20to%20246.tlf

Converting the tlf file type to qxn would be helpful also, have tried simply changing the suffix and trying to load on the analyser, doesn't work.

Bung

6356 posts

Uber Geek

Subscriber

#1719938 14-Feb-2017 12:21

If this is laboratory equipment wouldn't you run into software validation issues if you alter anything in the manufacturer's file? Your change may not affect anything but it may invalidate any certification you rely on.

mm1352000

1149 posts

Uber Geek
Inactive user

#1720045 14-Feb-2017 14:40

The qxn file looks intractable to me, but the tif file shows promise.

unsignedint

69 posts

Master Geek

#1720063 14-Feb-2017 15:17

The .tlf file is the way to go. It looks fairly straightforward and using simple binary encoding of the values as integers. To be more specific...

Look at the difference between the original file and the second file where you changed the RBC TARGET from 2.45 -> 2.46:

11,12c11,12
< 00000160  ff 00 ff fe ff 00 ff fe  ff 00 01 00 00 00 f5 00  |................|
< 00000170  00 00 14 00 00 00 00 00  00 00 e1 3e 01 00 01 80  |...........>....|
---
> 00000160  ff 00 ff fe ff 00 ff fe  ff 00 01 00 00 00 f6 00  |................|
> 00000170  00 00 14 00 00 00 00 00  00 00 95 3d 01 00 01 80  |...........=....|

There are two differences:

(1) "f5" -> "f6". These a hexadecimal numbers, converting to base 10 = 245 and 246 respectively. Bingo.

(2) "e1 3e" -> "95 3d". I don't have time to explore this but at a guess I would say that would be a checksum to verify integrity of the data. (Wikipedia for CRC16)

I suggest going through your "ASSAY SHEET" and locating all the other numbers in there. Note, the byte order is "backwards", e.g. 7.55 decimal => 7.55 * 10 = 755 -> base 16 -> "02f3" -> swap byte order -> "f302" (thats what you look for when you are viewing the hex.. in this case 7.55 can be found at byte offset 1e0)

1 | 2