Decrypting this file format

Hi there,

I am looking at the following files:

http://gdcm.sourceforge.net/elscint1/

they do not seems to be compressed. They all have the exact same
length, but I just can't make any sense out of them. Does anyone sees
any pattern ?

If you skip 0x4 byte, then every 0x40 bytes you find an ASCII string
(sort of), but that's all I can see.

Thanks
-Mathieu

mathieu wrote:
> Hi there,
>
> I am looking at the following files:
>
> http://gdcm.sourceforge.net/elscint1/
>
> they do not seems to be compressed. They all have the exact same
> length, but I just can't make any sense out of them. Does anyone sees
> any pattern ?
>
> If you skip 0x4 byte, then every 0x40 bytes you find an ASCII string
> (sort of), but that's all I can see.

It hasn't been compressed, or even (deliberately) obfuscated. It's just
"some" data format -- binary, with the occasional ASCII string. Since
the associated program is OpenSource (methinks), you can go through the
source and find out how it is formatted. And what it is for -- "GDCM is
an open source DICOM library. It is meant to deal with DICOM files (as
specified in part 10 of the DICOM standard). It offers some
compatibility with ACR-NEMA 1.0 & 2.0 files (raw files)." -- that
doesn't mean much to me :-)

[Jw]

On Aug 20, 5:21 pm, "[Jongware]" <so...@no.spam.net> wrote:
> mathieu wrote:
> > Hi there,
>
> > I am looking at the following files:
>
> >http://gdcm.sourceforge.net/elscint1/
>
> > they do not seems to be compressed. They all have the exact same
> > length, but I just can't make any sense out of them. Does anyone sees
> > any pattern ?
>
> > If you skip 0x4 byte, then every 0x40 bytes you find an ASCII string
> > (sort of), but that's all I can see.
>
> It hasn't been compressed, or even (deliberately) obfuscated. It's just
> "some" data format -- binary, with the occasional ASCII string. Since
> the associated program is OpenSource (methinks), you can go through the
> source and find out how it is formatted. And what it is for -- "GDCM is
> an open source DICOM library. It is meant to deal with DICOM files (as
> specified in part 10 of the DICOM standard). It offers some
> compatibility with ACR-NEMA 1.0 & 2.0 files (raw files)." -- that
> doesn't mean much to me :-)

Jw,

I uploaded this data, a couple of minutes ago. I found them
encapsulated in a DICOM file. DICOM is basically your every day png/
jpg on internet but in the medical field. It is meant to exchange
patient information (most of the time digital image)

Thanks anyway
-M

"mathieu" <mathieu.malaterre@gmail.com> wrote in message
news:b5934852-3af4-4a1f-b982-72ac263d9b61@m44g2000hsc.googlegroups.com...
> On Aug 20, 5:21 pm, "[Jongware]" <so...@no.spam.net> wrote:
> > mathieu wrote:
> > > Hi there,
> >
> > > I am looking at the following files:
> >
> > >http://gdcm.sourceforge.net/elscint1/
> >
> > > they do not seems to be compressed. They all have the exact same
> > > length, but I just can't make any sense out of them. Does anyone sees
> > > any pattern ?
> >
> > > If you skip 0x4 byte, then every 0x40 bytes you find an ASCII string
> > > (sort of), but that's all I can see.
> >
> > It hasn't been compressed, or even (deliberately) obfuscated. It's just
> > "some" data format -- binary, with the occasional ASCII string. Since
> > the associated program is OpenSource (methinks), you can go through the
> > source and find out how it is formatted. And what it is for -- "GDCM is
> > an open source DICOM library. It is meant to deal with DICOM files (as
> > specified in part 10 of the DICOM standard). It offers some
> > compatibility with ACR-NEMA 1.0 & 2.0 files (raw files)." -- that
> > doesn't mean much to me :-)
>
> Jw,
>
> I uploaded this data, a couple of minutes ago. I found them
> encapsulated in a DICOM file. DICOM is basically your every day png/
> jpg on internet but in the medical field. It is meant to exchange
> patient information (most of the time digital image)

My next guess is that's digital thrash. Perhaps the text strings /do/ mean
something (as does the first long integer), but if you examine the 'binary' data
inbetween, you will see they are single floating point numbers in little-endian
format (Intel-wise). The values in toto.raw, for example, start at 0.194995,
next are 891.0, 0.183817, 892.0, 0.172535 .. etc. So, why is this "thrash"?
Because the number right before this list, ending with hex byte 0x44 (just as
the 891.0, 892.0, etc. are), is rudely overwritten by the preceding text string.
The same happens with the next ASCII string -- it also overwrites part of the
next sequence of floats.
If you look at the ASCII strings, you will notice the first one starts at offset
4; the next one at 256; then there is a number of them, with 64 bytes intervals,
where the last one points to a binary '0' -- obviously an end of list. Perhaps
the string starting at 1128 also means something; in one file I checked, it was
"Phantom_Const120Head1.5_dfs.tbl", in another it was (binary 0)
"onstantChannelCorTab" -- the first character is overwritten by a 0.

It's typical programmer's stuff: using an existing memory buffer to store data
in at known offsets, then dumping the entire buffer to disk. No need to clear
the buffer because no-one will ever notice. The first long integer might as well
be a version number (probably just 2.10, perhaps 0.672, or -- for that matter --
6.7.2 or any other notation).

[Jongware]