Repairing 'corrupt' ASE 1.x capture files

Recently I captured a whole bunch of data using an ASE V1 RTU test set to trouble shoot a comms issue, with the intention of analyzing the data once I got back to the office. Well when I did get back to the office and tried to open my files, ASE just sat there, blank, looking at me as if I were stupid. I only had one capture file out of a dozen that actually opened and it happened to be the smallest one. I figured that ASE had an issue opening large capture files, so I fired off an email to support asking for haaaaalp.

I was told that there was no issues viewing large files, but that I had likely following the incorrect procedure for capturing files which must be closed properly.  There was no hope of recovering my data.



Well I accept that I had not followed the correct procedure, however I was not pleased about losing the data and it seemed weird that that the data would be unrecoverable given that the files were not empty.  Lets take a look at the header of a file that does work, and one that doesn't.  This file works:

This file does not:

It would appear that the first 0x100 bytes are the header, and that the capture data starts at 0x100.  The obvious differences in the header are that the two bytes at offsets C, 18 and 1C are different.  After comparing a few more working files that I captured the correct way, I noticed that the data in offsets C and 18 are always the same, and 1C is always 1 greater than C and 18 (data is little-endian), but what do they mean?

After some head scratching, I came to the conclusion that the numbers at C and 18 are simply the total number of exchanges in the message view, and 1C is just that number incremented by one.  you can enter any number less than the actual number of message and the file will open.  If the message number in the header is greater than the actual number of messages then ASE will hang when opening the file.  Further analysis of the file reveals that the four bytes at 0x100 are the address of the next message, and that address is the address of the following message and so on.  We can easily count how many messages are in the file.  The following is a c# console app that will analyse a file and correct the header with the correct message count.

Hopefully this might help someone else that ends up in the same predicament.

| June 30th, 2017 | Posted in Reversing |

Leave a Reply