True, i realised that this file is not the real firmware file, its the first part of downloading firmware and i was told that this part (this file) purpose is to program a microcontroller in the board to make it able to connect through ethernet to continue downloading the second file of firmware with TFTP, but i dont beleive this, because the kernel is already existing in (i think) a kind of microcontroller embedded as a microOS.
I see the content of the first file as : a first part of it is unreadable, make me remember HEX files translated from a microchip PIC program so it could be a program for the second microcontroller of the STB, the second part is readable and i guess it gives how the STB will treat the second file, this is a sample of the communication in this level:




If i knew, i could do better understood this protocol, i only have the linux executable application and not a code, i asked before if there is somehow to analyse a code from an executable application, a kind of reverse engineering, found nothing.

this is what i'm working on using Labwindows/cvi, i'm just simulating this protocol without success till the moment coz of something strange in this communication.

---------- Post updated at 06:13 AM ---------- Previous update was at 03:34 AM ----------

Problem solved.
I thought that the linux PC is the master of this communication so that the response from the STB is just a report, as i didnt get what kind of protocols it is, and didnt found out how the cheks are calculated i ignored the response and sent the file continuously block by block, but when i thinked what if the STB was the master and it is probably the master as it sends the file name first as a request, so waiting the STB response before continuing transfer process is maybe needed.
So as i know that the STB will certenly respond with the known answers (t0,t1,...,t128) i didnt controlled them but just inserted a delay of 0.1 s between blocks to let the STB send the request and then be able to receive the next block.

It was my bad.
But the source of problem was that the spying link that i made is not in the middle, it was in the PC rs232 side , so i left 2 meters of the existing link on the STB side, so the communication that i got contain a retard in the STB frames :



so as you can see the 150 bytes of data made me think that the response for header A is just a report and that the STB can still receive data continuously without a breack to calculate the checks and give the response.

Now i have two options :

1- i copy parts of the communication ( file blocks and headers) and use them as they are in my application ( the stupid way of emulation)

2- search more for this strange protocol to find out how it calculates checksums and make my application autonomous.

all the headers contain 3 parts [command of 4bytes]+[file position / size loaded ] + [checksum of 4bytes]
i can let the command part as it is, the position or the size could be just incremented,
what do you think about the checksums? a 4 bytes checksum that is calculated from something that could be a block of 1024 bytes or a serie of blocks ?

I found the next: the checksum given by the STB is not a checksum, its a static answer, i tried the download with two versions of this file, one with 127 kb and one with 126 kb and i found that those are the same unless that the 127 have one more and always the last one does not contain a static checksum but the contains the number of bytes loaded in hexadecimal for exemple for the 127k file the last is 0x00 0x01 0xFD 0x22 = 130338 which is the real number of bytes contained in the file, so the response checksum doesnt make any trouble. i guess its a confirmation static code.

but for the checksum sent by the PC i didnt found any clue,