[Asterisk-Users] Re: Grandstream v1.0.4.68 firmware

[Stephen R. Besch]

Serge Oleinikov wrote:

> I was trying to replace the header. But looks like header contains some kind
> of CRC
> 
>>The format the rings are at are after what I found out uLaw compressed
>>8bit 8000hz mono
>>samples. But they also have a header infront of the file. I will play
>>arround with it later. Maybe
>>there is a way to chop off the header of the ones that come with it and
>>put it infront of a regular
>>file.
>>
I did a little detective work and here is a summary of what I found out. 
In version .63 of the firmware, the ringtone files are all nearly 
identical (at least they contain the same audio data stream). From this, 
and from the format of the hex data in the header, I was able to 
discover the location and format of the checksum. The idea is that the 
only differences in the files were the file name field, the checksum 
word and one other value (the 00C8 at offset 26). From this it was 
possible to compute the difference in checksum expected and show that 
the only value in the file that changed appropriately was at offset 2. 
It also revealed the means of calculating the checksum. Here is a 
partially decoded header:

Hex Offset  Typical Value  Function
00		0000       ? Always zero (6 sample files)
02		7F90       File length in 16-bit words (bigendian)
04		3450       Checksum (see below)
06		01000000   Version number
0A		07D4       Always this value (6 samples)
0C		0419 or 0505 ?
0E		82A, 140B, 142C  ?
10		Text       filename (eg ring1.bin)
19-25		0's	   ?
26		0 or 00C8  ?
28-FF	 	0	   ?
100		0100	   **See below
102		7F90	   repeat of length
104-127		0's	   ?
128		Text	   String describing file
147-1FF		0's	   ?
200-end		Audio Data

The checksum is the value that must be put into location 2 so that a 
16-bit sum of the entire file, ignoring overflow, is exactly 0. It is 
essentially the negative of the sum of the file computed with a zero 
value in the checksum.

The value in location 100 is interesting. I suspect that it is either 
the length of the buffer which follows and contains the file comment, or 
it is simply the offset to the data stream.  Since is sits at location 
100, it is impossible to tell which.  Some further experimentation might 
resolve the issue.  If anyone can fill in the remaining fields, it would 
be cool.

Hope this helps.

Stephen R. Besch