Any interest in sw modding?

[jvvh5897]

I see that there not much posting in this section, but would anyone like to play with the pansat 9200 software?
There was a question about adding IKS feature to the box, so I disassembled the last factory file I could find. Along the way I modded the cwtool source code to pack and unpack the files, so I could post that at least if there is interest. So far I have found that that "factory" file has a default key area and RSA keys and that ecm handling code is in the file and is installed at startup, so most of what one needs for IKS seems there which is very un-like what one would expect in a factory file--now I don't know if the box actually pulls in cmd07 packets or if one could do rq-sssp but if there were some folks interested and willing to test, I've found the mute button code and the system information code that could be good spots to make the box do a RAM dump which is the first step in testing IMO. It might be better to work with a BL file--I see a few online from a google search, but not at sites that I can download files from, so what I have now is all I'm likely to try to get. I don't have a box and don't do IKS myself, but if you guys have interest....

[folcan99]

Nice to see you around again bro. I wish you could find a way for the nfusion HD but again nice to see you still around.

[DualTest]

I have one kicking around here somewhere. It doesn't have an HD module and I have only booted it up once since I got it given to me. But I am willing to give it a shot.

[skywalker999]

I also have one around with the 8psk turbo HD module and i use it sometimes for true fta me to I am willing to give it a try

[kijiji]

I'm in too as long as it dosen't hurt lol............Hey jvvh5897 now you have 2 thanks lol.

[DualTest]

I found a BL file for the 9200 it is here:

http://www.satfix.net/showthread.php...77#post1000977

[jvvh5897]

OK, I will disassemble that file and post the pack and unpack source/programs. Good to see folks willing to test!!!

In the 9200HD_090223_1219_api_pvr file I found routines like:
002E8AEC ; Get_ecm_pidEcm--NULL sub'ed
002622E8 ; "MECM "
0027A994 ; do MECM
0033C990 ; autoroll? 901 key
00339C2C ; do RSA decrypt
00260220 ; CAid test and decrypt?
002DB0E4 ; spot to try a send of ecm packet?
0029DE9C ; ecm handler?
0027EEA0 ; N2 decrypt
002625E0 ; develop idea key

So, I'm pretty sure that the file could be modded to dump RAM and see the ecm packets in there. But the serial port routines seemed limited to just sending out data--but did not look more than a few hours. As that file has been looked at how about a little testing to see what you find?

Try hooking up box's serial port to PC and capture what comes out, the 1219 file would be good, but what you have in there now would be just fine. Hyperterm would be a good program to use but RealTerm would be better and it is free from sourceforge site. Try 115.2 kbaud 8,N,1 settings.

Another good test would be to see what the blue button does when you are on the system info screen--I think it just pulls up the time of sw compile.

There is a factory test in the code, so do you guys know if anyone has ever been able to get into it? Not sure from the code how to do it, it could be a combo of front button presses--maybe at a specific time in the startup of the box. I do see that there are a number of remotes supported in the code--5 I think--and I've read a post that you can select 4 possible remote codes on your remotes, so that last remote might have been a "factory test" remote.

[DualTest]

From RealTerm as the receiver is plugged in:

CCodeldr(370) : Start Check Button
USB_Init(474)
(1352)USB_HOST_MODE:0x0
Check_USB_Device_INT(1373) Error : Not Plugged !!
Usb_Init(480) Check_USB_Device_INT() Fail !!
---------------------------------
STB has no USB Device !!
---------------------------------
Flash Header: 55 66 96 FF 92 12 20 09 03 28 33 14 A3 C3 D0 E9
Main Image : 55 66
Version : 9212
YYYY,MM,DD : 2009, 03, 28
Switching to 'C' code...
Disabling interrupts via the interrupt controller...

Initializing ROM controller registers...

Initializing ISA controller registers...

Setting the RTC clock...

Setting the System clock...

Initializing the GPIO pins...

KAL early initialization...

Initializing exception vectors...

Initializing OS variables...

Starting OS initialization...




******
Trace output port opened

MODULE_SERIAL_FAILURE
MODULE_SERIAL_FAILURE
MODULE_SERIAL_FAILURE
E3cmd_init
Dish Backdoor key:
Bev Backdoor key:
Sata init CMD Rx..
8. delay_count = 200
sata init faile..

[DualTest]

OK, I will disassemble that file and post the pack and unpack source/programs. Good to see folks willing to test!!!

In the 9200HD_090223_1219_api_pvr file I found routines like:
002E8AEC ; Get_ecm_pidEcm--NULL sub'ed
002622E8 ; "MECM "
0027A994 ; do MECM
0033C990 ; autoroll? 901 key
00339C2C ; do RSA decrypt
00260220 ; CAid test and decrypt?
002DB0E4 ; spot to try a send of ecm packet?
0029DE9C ; ecm handler?
0027EEA0 ; N2 decrypt
002625E0 ; develop idea key

So, I'm pretty sure that the file could be modded to dump RAM and see the ecm packets in there. But the serial port routines seemed limited to just sending out data--but did not look more than a few hours. As that file has been looked at how about a little testing to see what you find?

Try hooking up box's serial port to PC and capture what comes out, the 1219 file would be good, but what you have in there now would be just fine. Hyperterm would be a good program to use but RealTerm would be better and it is free from sourceforge site. Try 115.2 kbaud 8,N,1 settings.

Another good test would be to see what the blue button does when you are on the system info screen--I think it just pulls up the time of sw compile.

There is a factory test in the code, so do you guys know if anyone has ever been able to get into it? Not sure from the code how to do it, it could be a combo of front button presses--maybe at a specific time in the startup of the box. I do see that there are a number of remotes supported in the code--5 I think--and I've read a post that you can select 4 possible remote codes on your remotes, so that last remote might have been a "factory test" remote.

The Blue button while in the system information screen adds the following line:

Compile Date: Mar 28 2009 [14:14:28]

[DualTest]

Just for the purpose of learning I did a capture of the start up in Hex and then opened it in a hex editor and this is the result.

[jvvh5897]

Hum, that last post was unexpected! Not sure what to make of that output.

I've disassembled the BL femu file and it looks a lot like the factory file I took apart. Niether looks to have a serialport receive routine, but I think I can just pull the code out of an old Coolsat5000 Conexant code file that will be needed. But I was thinking that we might just as well clear out the use of one of the two background mpg images for our use. So, to do that I built a little XVI32 hexeditor script to act as a first test of bin modding. XVI32 is a free/register ware hexeditor and I think a copy of it is posted down in the advanced section. Once you open a copy of the unpacked femu file, you can open script files (saved with extension .xsc) and execute it, once the execution ends you save the modded file and pack it up again. Now the pack routine I posted only puts the factory file's version number and creation date in the first 0x10 bytes of the file, and those first 0x10 bytes are not covered by the checksums, so you can change them at will if you want to.

Here is the script that you can run in XVI32:

ADR $0
REM for 9200HD_090223_1219_api_pvr un-remark the below two lines and REM the ones for femu
REM FIND 44 EC 48 00 1B 07 48 00
REM OVERWRITE 40 EC 48 00 A4 C3 47 00

REM for HD-9200BL_pvr_090607_9219_api_femu use below
FIND 94 74 4A 00 6B 8F 49 00
OVERWRITE 90 74 4A 00 F4 4B 49 00
EXIT

REM == remark --line will be ignored
FIND == search for a hex string in the file and move current position to the first matching byte
OVERWRITE == replace the data from the current position
EXIT == end execution
ADR $0 == go to file address that follows, $ indicates address is in hex

Not much to it as it is really just a test of whether you can run script, save, compress and load a modded file to box.
With the script mods in place the box should use the "blue" background rather than the "radio" background when you are set to a radio channel. I put the script for both the old factory file and femu in there, but remarked out all but the femu.

If you like we can place a different mpg image as radio background using programs from the old fortec ultra background modding tools. The current radio background is about 58kbyte in size, the blue background image is only 17 kbyte. Other good testing mods are to change the version name, number, compile time in system info display to something that lets folks know that the file is a modded one.

If anyone would care to try to use IDA to disassemble the femu (or factory) file, I have an IDC to speed things along and a list of routines that I've labeled that I can offer--just ask. Otherwise I will just be posting script with info about what goes on in the modding and it will be se to you guys to run the script and test for results.

[jvvh5897]

Here are notes on the file header:

header:
000000 55 66 00 FF 12 19 20 09-02 24 32 14 60 13 88 04
000010 43 4E 47 5A 88 60 32 00-0E 12 14 00 00 00 00 00
000020 00 14 24 00 88 60 32 00-00 00 00 00 00 00 00 00

0E 12 14 00 number of bytes compressed
88 60 32 00 number of bytes unpacked (in there twice)
00 14 24 00 location in RAM for execution when unpacked
43 4E 47 5A "CNGZ"

12 19 version
20 09 02 24 date code: yr mo day

00 FF --the 00 is a simple sum single byte wide over the file from 0x10 to end of file. 0xff is always there.

32 14 60 13 88 04 every other byte get the number of bytes unpacked
next set of every other byte is compressed size + 0xf6

[DualTest]

Hum, that last post was unexpected! Not sure what to make of that output.

I've disassembled the BL femu file and it looks a lot like the factory file I took apart. Niether looks to have a serialport receive routine, but I think I can just pull the code out of an old Coolsat5000 Conexant code file that will be needed. But I was thinking that we might just as well clear out the use of one of the two background mpg images for our use. So, to do that I built a little XVI32 hexeditor script to act as a first test of bin modding. XVI32 is a free/register ware hexeditor and I think a copy of it is posted down in the advanced section. Once you open a copy of the unpacked femu file, you can open script files (saved with extension .xsc) and execute it, once the execution ends you save the modded file and pack it up again. Now the pack routine I posted only puts the factory file's version number and creation date in the first 0x10 bytes of the file, and those first 0x10 bytes are not covered by the checksums, so you can change them at will if you want to.

Here is the script that you can run in XVI32:



REM == remark --line will be ignored
FIND == search for a hex string in the file and move current position to the first matching byte
OVERWRITE == replace the data from the current position
EXIT == end execution
ADR $0 == go to file address that follows, $ indicates address is in hex

Not much to it as it is really just a test of whether you can run script, save, compress and load a modded file to box.
With the script mods in place the box should use the "blue" background rather than the "radio" background when you are set to a radio channel. I put the script for both the old factory file and femu in there, but remarked out all but the femu.

If you like we can place a different mpg image as radio background using programs from the old fortec ultra background modding tools. The current radio background is about 58kbyte in size, the blue background image is only 17 kbyte. Other good testing mods are to change the version name, number, compile time in system info display to something that lets folks know that the file is a modded one.

If anyone would care to try to use IDA to disassemble the femu (or factory) file, I have an IDC to speed things along and a list of routines that I've labeled that I can offer--just ask. Otherwise I will just be posting script with info about what goes on in the modding and it will be se to you guys to run the script and test for results.

Well I managed to do that without bricking the receiver. Thanks. I know more today than I did yesterday so feeling pretty good about things.

[DualTest]

BTW since I have changed the file on the receiver to 1219 and modded the radio background. I decided to run Realterm again, with USB inserted. There is no change to the response from the original femu, in case anyone is wondering. Here is the capture plus the file in case anyone is curious.

CCodeldr(370) : Start Check Button
USB_Init(474)
(1352)USB_HOST_MODE:0x0
Check_USB_Device_INT(1377) USB Plugged !!
USBStorageInit(68) : RH_DEV_ADDR = 0x4, devAddr = 0x0
USBStorageInit(100) : devAddr = 0x0
UM_InitMassStorDevice(338)
UM_InitMassStorDevice(547) OK
USBStorageInit(138)
USBStorageInit(170) : FS_Init
(193)FAT_InitFreeCluster
(1400)MODE:0x0, USB_Plugged = 2, sdirCnt = 2, fileCnt = 0
Usb_Init(485) Check_USB_Device_INT() OK !!
---------------------------------
STB has USB Device !!
---------------------------------
Flash Header: 55 66 D3 FF 12 19 20 09 02 24 35 16 E8 39 AC 7D
Main Image : 55 66
Version : 1219
YYYY,MM,DD : 2009, 02, 24
Switching to 'C' code...
Disabling interrupts via the interrupt controller...

Initializing ROM controller registers...

Initializing ISA controller registers...

Setting the RTC clock...

Setting the System clock...

Initializing the GPIO pins...

KAL early initialization...

Initializing exception vectors...

Initializing OS variables...

Starting OS initialization...




******
Trace output port opened

DEMOD:BASEBAND: internal_demod_baseband_hw_init
MODULE_SERIAL_FAILURE
MODULE_SERIAL_FAILURE
MODULE_SERIAL_FAILURE
ChipOpen Start
ChipOpen End...
ChipID = ff
ChipOpen Start
ChipOpen End...
Current TS Clock=9000000 MHz
Final Status = 12
E3cmd_init
Dish Backdoor key:
Bev Backdoor key:
Sata init CMD Rx..
8. delay_count = 200
sata init faile..
bAudioDelayReceived/bVideoDelayReceived/dramdelay = 0/1/0

[DualTest]

I searched for the Ultra background modding tools but couldn't find them anywhere. I do remember that project though. As far as changing the version, compile date etc, I am still looking into that.