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?141505-HD-9200BL_pvr_090607_9219_api_femu&p=1000977#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.

http://i953.photobucket.com/albums/ae11/TestinForNow/capture.jpg (http://s953.photobucket.com/user/TestinForNow/media/capture.jpg.html)

[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.

[jvvh5897]

I created a program last night to mod the file at the second background image and will post it. We should think about moving down to the advanced section--they have easier file posting rules for experimenters. Reason I made up the program was because the space used for the radio image might be handy to use for code and other storage needs, but the space needs are pretty small--maybe a kbyte or two, so may as well put a pretty image in the unused 50 odd k bytes.

Good to hear the modded bin did not brick the box--should be able to do lots of things to the code if all the checksums are really fixed! One of the next steps should be to dump the contents of RAM for a few mega bytes, then try a mod at the start of one of the N2 decrypt routines to see if the code execution still gets to that point and to dump the stack info if it does--if the code execution does not get to the00282DA0 ; N2 decrypt routine there are a couple of calling routines that could be tried till we get one that gives output . Once those two steps are done it should be just a matter of getting the outgoing and incoming packets from rq-client on PC working.

I was able to find a few links to ultra background mods with google of "Fortec background" found old program on a site in Asia.

[DualTest]

I didn't have much luck with the hexv_mpg program. But searching 00 00 01 b3 for the start and 00 00 01 b7 as the end, using XVI32, I was able to find two instances of them. So a couple of questions. If I open the img01.mpg in XVI32 and copy that to the clipboard. Then block edit those spots of the test file. Will that work? And secondly I notice that after the second 00 00 01 b7 the code is filled with a large amount of FF. Are they there to keep the size of the file consistent (filler for lack of a better word)? And will I have to add more since the new mpg is smaller. I am assuming I will.

[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.

I finally found where to change the Build/Compile date. Feeling kinda foolish after that one seeing as it was in plain text and staring at me this whole time. But I learned to look at the whole file not just the Hex and that most of what is in the menu will be in text.

[DualTest]

I didn't have much luck with the hexv_mpg program. But searching 00 00 01 b3 for the start and 00 00 01 b7 as the end, using XVI32, I was able to find two instances of them. So a couple of questions. If I open the img01.mpg in XVI32 and copy that to the clipboard. Then block edit those spots of the test file. Will that work? And secondly I notice that after the second 00 00 01 b7 the code is filled with a large amount of FF. Are they there to keep the size of the file consistent (filler for lack of a better word)? And will I have to add more since the new mpg is smaller. I am assuming I will.

I have answered some of my own question. Block editing and adding the mpg background on its own will not work. And I believe that is because of the file size being smaller after editing out the old pic and adding the smaller one. Lesson learned. So now I need to learn about crc and checksum. I also discovered that these receivers are relatively easy to recover, without the need to jtag.

[jvvh5897]

You can't just delete the existing mpg and put a smaller file in its place--you have to keep the pansat file size exactly the same size. The radio background is the second of the two 00 00 01 b3 hits.

Here is script to mod the file to dump RAM starting near the end of the filein RAM and going for 2 m byte--I hope.


REM Put in Uart_Read, Uart_WaitTXdone, Uart_Write
REM uses txQueueCount-0x30 as base addr 5AA45C-30 = 5AA42C
REM rxQueue 0x005A9C5C 2048 (0x800) bytes
REM and txQueue 0x005A8C5C 4096 (0x1000) bytes
REM and calls task_time_sleep @2C9EC4 change 24 F0 8C F9 (@0x20) and 24 F0 47 F9 (@0x74)

REM lets try putting the code in 2nd mpg image starting at 004A7000

REM task_time_sleep 2C9EC4, critical_section_begin 2C8920, __call_via_r0 2419EC, critical_section_end 2C8930



ADR $265C00
REM ADR $0
REM 4a7000 UART_Read
OVERWRITE F7 B5 07 1C 15 1C 00 26 1F E0 00 24 0B E0 00 2D
OVERWRITE 05 D0 AC 42 03 D3 01 20 FE BC 08 BC 18 47 0A 20
OVERWRITE 22 F6 50 FF 0A 34 0B 4A 50 6C 11 6C 88 42 EE D0
OVERWRITE 10 6C 09 4B 41 1C 18 5C 38 70 01 37 48 05 40 0D
OVERWRITE 10 64 50 6B 01 30 50 63 01 36 01 98 86 42 DC D3
OVERWRITE 00 20 E1 E7 2C A4 5A 00 5C 9C 5A 00

REM 4A705C Uart_WaitTXdone
OVERWRITE 70 B5 05 1C
OVERWRITE 00 24 08 4E 09 E0 AC 42 03 D3 01 20 70 BC 08 BC
OVERWRITE 18 47 0A 20 22 F6 26 FF 0A 34 30 6B 00 28 F2 D1
OVERWRITE F4 E7 00 00 2C A4 5A 00

REM 4A7088 UART_Write
OVERWRITE F7 B5 06 1C 0C 1C 03 D1
OVERWRITE C8 43 FE BC 08 BC 18 47 00 25 19 4F 08 E0 02 98
OVERWRITE 85 42 01 D3 01 20 F4 E7 0A 20 22 F6 0B FF 0A 35
OVERWRITE 01 21 38 6B 09 03 08 1A A0 42 F0 D3 21 F6 30 FC
OVERWRITE 05 1C 10 48 0A E0 33 78 F9 6B 01 36 4A 1C 43 54
OVERWRITE 11 05 09 0D F9 63 39 6B 01 31 39 63 01 3C F2 D2
OVERWRITE 08 48 30 38 00 68 00 28 04 D0 C0 68 00 28 01 D0
OVERWRITE 9A F5 7C FC 28 1C 21 F6 1B FC 00 20 C9 E7 00 00
OVERWRITE 2C A4 5A 00 5C 8C 5A 00

REM 4A7108
OVERWRITE FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
OVERWRITE FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
OVERWRITE FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
OVERWRITE FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF


REM 4A7148 Hex_Dump
OVERWRITE FF B5 0B 4D 00 24 B0 23 DB 03 E0 02 80 21 A0 22
OVERWRITE C0 18 09 01 D2 01 FF F7 93 FF FA 20 80 00 01 34
OVERWRITE FF F7 78 FF AC 42 EE D1 FF BC 08 BC 18 47 00 00
OVERWRITE 01 04 00 00

REM below are to system info OSD to add red button to do RAM dump
ADR $5DAB4
OVERWRITE 25
FIND 2F D1
OVERWRITE 1c
FIND FB 21
OVERWRITE D7 28 10 D1 C0 46 08 F2 23 F9

I'm assuming that you have either modded file with a smaller radio background or defeated the use of the radio background with the main as in earlier script. The red/mode button shoud kick off the serial dump of RAM contents. My guess is that most of the interesting parts of RAM are up around the 8M area, so you might want to modify the
OVERWRITE 01 04 00 00 line to something like 01 08 to increase the size of the dump to 4M.

[DualTest]

I'm assuming that you have either modded file with a smaller radio background or defeated the use of the radio background with the main as in earlier script.

I did both. First spot seems to have no effect at all and using the smaller file in the second spot crashed the receiver. It is kind of what I thought would happen. Anyway I will put that on the back burner for now.

[DualTest]

Okay here is where I am at and what I have done. I finally managed to get the 01.mpg into the bin and made the file the same size as the original. Then I ran the above script. Then repacked, renamed the file HD-9200BL_pvr_090607_9220Ram_api_femu. Flashed the file to the receiver and all went well. Radio wallpaper is now blades of grass. But pressing the red mode button only changes the mode. Nothing else happens. Realterm shows the same responses as before. I also tried it again replacing the 01 04 00 00 to 01 08 00 00 and same result. I will attach the file here so you can take a look at it, in case I missed something.

I took out the file because it locks up the receiver in the system information menu

[jvvh5897]

Sorry I'm in pain today. I should have pointed out that you have to press the red button while in the System information display--the one where the green button gets you time info on the compile. Be sure that you only run the code once per file!! The script looks for stuff in the sys info OSD routine and changes it, so if you run it again that info would not be in the routine so it would look for a match somewhere else--could really screw something up!

Oh, my, what a long name for the file. I usually use things like BL_9220_1. Enough to remind me of the starting point and to make it clear the level of mods involved.

The compression step has two checksums at the end of the resultant file--crc32 and adler32--I don't know if pansat code actually tests them. But the checksum that is in the header is a simple sum (1+2+3=5 ish). The cwtool source has a simple 32 bit sum routine and I just trimmed it to just have the lowest significant byte of that and it goes in the 3rd byte of the file as one of the last steps in the pack tool. I know hexworkshop has a sum32. and I seem to recall there is a free hexeditor that has some sum features--saw a note about it over at openwrt site--um, "hw" maybe, no looks like "HxD" or maybe Tiny Hexer....

[DualTest]

Here is the file that locks up the receiver in the system information screen after pressing the red/mode button.

http://www.satfix.net/showthread.php?141799-BL-9200_pvr1&p=1002729#post1002729

I went back to the beginning and modded the original file. Took out the radio background, put in the new one. Added FF strings until the uncompressed file was the same size as the original uncompressed file. Ran the script. Saved as Bl-9200_pvr1. Repacked and loaded it to the receiver. So is it my modding or the script that is causing it to lock up? I suspect it is me lol but want to make sure.

[jvvh5897]

Since I am not the one testing, it is hard to say. Experimenting with modding code is trial and error process. I would say it is likely my code.

Here is what I tried in the previous script: I took the UART_Read, UART_WaitTxDone, and UART_Write from the coolsat5000 compiled source code and modified the addresses used in those three routines to use the addresses used in the llser that is used to install traceout in your code and to call the equivalent routines that I find in your code--I could have screwed up any of those even with my disessembling the code to check them. Once I had those in place and looking correct I built a little code to loop around using UART_Write and UART_WaitTxDone to send 0x800 bytes at a time out the serial port and to do that till 0x200000 bytes had been sent out. Compiled that C code with WinARM and inserted that machine code into the stuff I lifted from coolsat code--made a few minor mods by hand to make sure all the registers would return with the value that they had at the first call.

I put all of that code in the space freed by one of the background images. Could be a code error, could be that the code did not like being executed in the spot that it was placed, could be that you did not get the mods in place correctly. Hard to know.

Lets try something simpler. Here is basic mod to force one of the spots in N2 decryption to send a message out the serial port:

call to put message on serial port used for "E3cmd_init" seen in serial capture posted earlier: 34E7C0

Part of ROM:00282DA0 ; GC N2 decrypt:

ROM:00282DFA LDR R0, =aGcRun__
ROM:00282DFC BL sub_2B306C ; debug message

Lets change the call to 2B306C to call 34E7C0

FIND 14 22 21 1C 34 48 BF F7 B5 FA 34 48 30 F0 36 F9
FIND 30 F0 36 F9
OVERWRITE CB F0 E0 FC


And then see if when you point the dish at a 1800 CAid prov, globecast radio on 97 degree sat, then maybe one of the TV channels that is N3 on 97 degrees or one of the others like 109 or 119 degrees and have a channel scan done not too long ago, maybe that debug message will come out the serial port. It might be very often, it might be every 15 seconds or so, it might not come out at all. That is what experimenting is like.

Meanwhile I will look at that previous mod and see if I can spot something that I did wrong.

[jvvh5897]

Well, I looked at the file that was posted down in advanced section and I would suggest that that file be deleted by anyone that has it. It is a mess. My best guess is that the script was run twice on it--something that should not have been done. BUT, I have no idea of how one could get to where that file got to even if one ran the script twice. Toss it in the trash and start fresh.

I don't see how even that file could have been at fault in box rebooting--I still blame the code that I used and not the work done by DualTest. My best guess so far is that the pansat 9200 code does a step that was not in the UART_Write code. I think I can rip a part of the 9200's code out and modify it to get something like UART_Write though, so I'll try that. Still leaves UART_Read hanging--the 9200 code does not have anything close to that in its code, so I was hoping that the UART_Write would work and imply that the UART_Read code would function. Think I will have to create a series of steps to test what can be done and where things fail.

Might need some of the others that said that they would be willing to test to step up and do so. DualTest has been the only one trying.

[DualTest]

On the off chance that I may have modded the original file and saved it after running the script, which would account for it having been run twice, I deleted all that I had and download the file again and started from the complete start. And it still does the same thing, the receiver hangs after pressing the red button while in the system information screen. Should I even bother posting the file?

[DualTest]

I have posted 3 files here:

http://www.satfix.net/showthread.php?141891-Pansat-9200HD-Modded-Bins&p=1003371#post1003371

HD-9200BL_pvr2 is just the radio background changed. Nothing else.
HD-9200BL_pvr3 is the added FF strings to make the file the same size as the original
HD-9200BL_pvr4 is after running the script.

To me the script seemed to do what was intend. I could be wrong, but it still locks up the receiver after pressing the red/mode button so does not work. For the time being I am just going to work on trying to learn more about the mods and see what I can do. Hopefully someone else will take up the cause also.

[jvvh5897]

I mentioned that the box locking up is most likely my code.

Lets try a different way of getting a RAM dump. This time I tried something simple.


ADR $4a7000
OVERWRITE 38 B5 04 1C 0D 1C C0 46 02 E0 38 BC 08 BC 18 47
OVERWRITE 00 2D FA D1 20 78 04 49 09 68 4A 6A 01 21 9A F5
OVERWRITE E7 FC 01 34 01 3D F3 E7 24 8B 5A 00


REM 4A7148 Hex_Dump
OVERWRITE FF B5 0B 4D 00 24 B0 23 DB 03 E0 02 80 21 A0 22
OVERWRITE C0 18 09 01 D2 01 FF F7 4F FF 01 34 c0 46 c8 20
OVERWRITE 22 F6 AC FE AC 42 EE D1 FF BC 08 BC 18 47 00 00
OVERWRITE 02 00 00 00

REM below are to system info OSD to add red button to do RAM dump
ADR $5DAB4
OVERWRITE 25
FIND 2F D1
OVERWRITE 1c
FIND FB 21
OVERWRITE D7 28 10 D1 C0 46 08 F2 23 F9

Again, you only run the script once. You run it on a femu file with either the radio background disabled or replaced with a smaller image.

This time I took the traceout routine code and modified it to run for a number of bytes that I specify rather than to the end of a NULL terminated string--that modded traceout is put at 0x4a7000. At 4a7148 is the routine that sends the new traceout 0x800 bytes at a time and waits for the code to finish sending, but this time there is no waitTxdone call, instead it calls the task_time_sleep for 173 millisec. I changed OVERWRITE 01 04 00 00 to OVERWRITE 02 00 00 00 for you in the above to make the first attempt only dump 0x800 bytes. If that first dump does what is wanted, go ahead and change back to let the dump do 0x401 rounds of 0x800 sends--or follow the earlier suggesting to do 0x801 rounds and 4MBytes worth of a dump.

---------------------------------------------------------------------------------------

If the above still locks up the box with red button is pressed from Sys info screen, try a file with this script:


REM below are to system info OSD to add red button to do RAM dump
ADR $5DAB4
OVERWRITE 25
FIND 2F D1
OVERWRITE 1c
FIND FB 21
OVERWRITE D7 28 10 D1 C0 46 C0 46 C0 46

This one mods the sys info OSD area to test for the red button, but if red buttonpress is found is just drops down to run the exit routine that is in there already, it does not try to call into the 2nd mpg space at all.

[DualTest]

---------------------------------------------------------------------------------------

If the above still locks up the box with red button is pressed from Sys info screen, try a file with this script:


REM below are to system info OSD to add red button to do RAM dump
ADR $5DAB4
OVERWRITE 25
FIND 2F D1
OVERWRITE 1c
FIND FB 21
OVERWRITE D7 28 10 D1 C0 46 C0 46 C0 46

This one mods the sys info OSD area to test for the red button, but if red buttonpress is found is just drops down to run the exit routine that is in there already, it does not try to call into the 2nd mpg space at all.


That locks up the receiver.



ADR $4a7000
OVERWRITE 38 B5 04 1C 0D 1C C0 46 02 E0 38 BC 08 BC 18 47
OVERWRITE 00 2D FA D1 20 78 04 49 09 68 4A 6A 01 21 9A F5
OVERWRITE E7 FC 01 34 01 3D F3 E7 24 8B 5A 00

Is this address correct, $4a7000? All of my files end at $35e8ab

[DualTest]

Comparing this script to the first script I edited the first part of it and ran it with the same result.

ADR $265c00
REM $4A7000
OVERWRITE 38 B5 04 1C 0D 1C C0 46 02 E0 38 BC 08 BC 18 47
OVERWRITE 00 2D FA D1 20 78 04 49 09 68 4A 6A 01 21 9A F5
OVERWRITE E7 FC 01 34 01 3D F3 E7 24 8B 5A 00

[DualTest]

I ran this script on the original femu

REM below are to system info OSD to add red button to do RAM dump
ADR $5DAB4
OVERWRITE 25
FIND 2F D1
OVERWRITE 1c
FIND FB 21
OVERWRITE D7 28 10 D1 C0 46 C0 46 C0 46

And it worked. Pressing the red/mute button exited out to the main menu.

UPDATE: That does work in the modified bin.

And just for testing purposes I modded the last line of the original ram dump script from

D7 28 10 D1 C0 46 08 F2 23 F9 to D7 28 10 D1 C0 46 C0 46 C0 46 and the red/mode button does exit out of the menu as intended. So the problem seems to lie with the 4 strings 08 F2 23 F9, at least that is what it seems in my limited knowledge.

[jvvh5897]

Oh boy, I guess I need some sleep and for my foot to stop hurting. My bad--they are wrong addresses. I should have put in addresses that the file uses rather than addresses that the code is in RAM. 0x4a7000 is a RAM address and would be 0x4a7000-0x241400 in file (==265C00). And it looks like I missed having an address setting line for the 0x4a7148 located routine too--there should have been a line with ADR $265D48 (that is 4a7148-241400 of course).

Good that you figured out the red button mod though!!

so lets try the script post again:


REM $4a7000
ADR $265C00
OVERWRITE 38 B5 04 1C 0D 1C C0 46 02 E0 38 BC 08 BC 18 47
OVERWRITE 00 2D FA D1 20 78 04 49 09 68 4A 6A 01 21 9A F5
OVERWRITE E7 FC 01 34 01 3D F3 E7 24 8B 5A 00


REM 4A7148 Hex_Dump
ADR $265D48
OVERWRITE FF B5 0B 4D 00 24 B0 23 DB 03 E0 02 80 21 A0 22
OVERWRITE C0 18 09 01 D2 01 FF F7 4F FF 01 34 c0 46 c8 20
OVERWRITE 22 F6 AC FE AC 42 EE D1 FF BC 08 BC 18 47 00 00
OVERWRITE 01 04 00 00

REM below are to system info OSD to add red button to do RAM dump
ADR $5DAB4
OVERWRITE 25
FIND 2F D1
OVERWRITE 1c
FIND FB 21
OVERWRITE D7 28 10 D1 C0 46 08 F2 23 F9

[DualTest]

Okay I just noticed something, I am not sure if this is because of the different script or if this has always been happening. I ran the new file, done with the script above. And the receiver locked up again. But this time I got distracted and just left it. In 4-5 minutes the receiver exits out the system information screen on its own and everything functions again. RealTerm still does show anything happening in this time though.

I let file with the original ram dump script sit and it did not exit out of the system information screen. Only after a reboot would it respond again.

[jvvh5897]

Well, I would expect the box to "lock up" while it is sending stuff to the serial port. A 2Meg dump would take a few minutes (0x200000*10/115200 is about 3 minutes ) but if the code is set to only send out two kbytes, then it would not take long for the system info screen to exit as it should at the end of the serial send (0.18 seconds or so for just 0x800 bytes). But as pointed out the first code had problems--why still try it when I say it had problems? Thanks for trying, but if I say to leave it be, please do so.

Hum, nothing coming out the serial port...what the heck? Guess you should try that "gc running" mod while I think about it.

[DualTest]

This one? I am really not sure how to interpret that. I know how to convert a ram address (0xramaddress-0x241400) thanks. But I don't know what to do with ROM addresses.

Part of ROM:00282DA0 ; GC N2 decrypt:

ROM:00282DFA LDR R0, =aGcRun__
ROM:00282DFC BL sub_2B306C ; debug message

Lets change the call to 2B306C to call 34E7C0

FIND 14 22 21 1C 34 48 BF F7 B5 FA 34 48 30 F0 36 F9
FIND 30 F0 36 F9
OVERWRITE CB F0 E0 FC

[jvvh5897]

You should not have to convert ROM addresses with the gc running mod, just run the script (the three lines with FIND/FIND and OVERWRITE in them) on unpacked femu file that we have been playing with and save and repack. It does not require an address to go to, it does a FIND to get to where it needs to make a mod.

The "ROM" shown in the post was part of the IDA disassembly. I just tell the program that the code I'm disassembling is in ROM but that is something that makes no diff to you, the address is the RAM addr.

But since you asked about ROM addresses. It looks like the base address for the flash in the pansat 9200 is 0xf0000000--I think.
I've found lots of routines that deal with addresses up around 0xf0600000 for storage of channel list, key data, sat/TP data:

routine addr; label:
0034EC40 ; read from F0640000 8b8e0 bytes ch data? move to C8 AE 71 00 in RAM
002B396C ; read 8d80 bytes from F0620000 --sat data?
0027CC94 ; read 1800 bytes from F06D0000 -- key data

[DualTest]

The Realterm capture. I scanned sats. Put in on a DN encrypted channel. Flashed the modded file with the above script. And the same results.

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 27 FF 12 19 20 09 02 24 35 15 E8 78 AC CC
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
bAudioDelayReceived/bVideoDelayReceived/dramdelay = 1/1/1

[jvvh5897]

Well, drat! Darn and heck! Maybe even rats! About all I can think to do for serial port dump of RAM is to grab the low level serial transmit routine from the boot and try that--it uses registers and should work regardless of how the operating system is controlling I/O. From the last post I think that traceport system is pretty much defeated, and I'm thinking that the problem with putting code up in the mpg image space is not going to work, so have to take over a routine in code space. I'll see what I can work out and get back with it.

[bryan35]

Great to see some guys working on getting the 9200 going! I have one collecting dust but no knowledge of programing. Can't help out but good luck!

[jvvh5897]

Dual test has no programming knowledge but he is helping--seems to be little excuse!!

[bryan35]

how can one help?

[jvvh5897]

Well, it would be of interest to just see the files that result from downloading to usb such things as key data and channel lists.
Others could try to run script on the femu files when they are posted--no reason that DualTest has to do ALL the work for all the owners of the 9200.

[DualTest]

While I have had some time I have been trying to find a way into the factory test screen. Upon start up I have found two things. Pressing the volume up button, with the API_FILE.bin in the main directory of the USB, is a recovery procedure. I put that file and instructions in the Pansat 9200HD Loaders section. And pressing the volume up and menu button put the letters uPLd on the receiver LCD display. Upload what and from where I haven't figured out yet. The TV is blank during this.

[jvvh5897]

uPLd is likely the serial port loader, so if you had a loader program running on your PC and a serial cable to the box, you could upload a recovery file.

Well, here is the latest try to do a serial dump from the femu program--I'm still stupidly perhaps trying to use the mpg 2nd image space for the code, so you need to have defeated the 2nd image or put in a smaller mpg in that space. Still using the sys info OSD red button code as you have seen it before. Hope it works, hope the stupidity level of the code is not bad. You should also see the hexdump code is largely the same as before too--it still calls for 0x800 bytes to be dumped at a time for 0x401 loops and 0x200000 bytes total--you can change the number of loops it takes if you like.


REM write a byte to serial port lifted from 01E0D31C in 2nd part of MBOOT 7
REM call with R0 = 2 for the right uart port
REM R1 = byte to write
REM Little endian ARM code



ADR $265C00
REM $4a7000
OVERWRITE 03 00 50 E3 01 00 00 1A 44 C0 9F E5 01 00 00 EA
OVERWRITE 40 20 9F E5 00 C6 82 E0 00 20 9C E5 20 00 12 E3
OVERWRITE FC FF FF 0A 1C 00 12 E3 01 00 00 0A 00 00 A0 E1
OVERWRITE 1E FF 2F E1 03 00 50 E3 01 00 00 1A 1C 00 9F E5
OVERWRITE 01 00 00 EA 18 20 9F E5 00 06 82 E0 00 10 80 E5
OVERWRITE 1E FF 2F E1 14 00 04 E0 14 00 41 E0 40 6D E1 01
OVERWRITE 00 00 04 E0 00 00 41 E0

REM call above with R0=2 from 01E14848 in boot

OVERWRITE 08 40 2D E9 00 10 A0 E1 02 00 A0 E3 E1 FF FF EB
OVERWRITE 08 40 BD E8 00 00 A0 E3 1E FF 2F E1

REM Add to below to go from Thumb code to ARM
OVERWRITE 78 47 C0 46

REM use above 01E14848 to loop writing n bytes, from 1E14890 in boot
REM R1 with number of bytes, R0 points to buffer

OVERWRITE 38 40 2D E9 01 40 A0 E1 00 50 A0 E1 01 00 D5 E4
OVERWRITE F2 FF FF EB 01 40 44 E2 00 00 54 E3 FA FF FF 1A
OVERWRITE 38 40 BD E8 00 00 A0 E3 1E FF 2F E1

REM 4A7148 Hex_Dump
ADR $265D48

OVERWRITE FF B5 0B 4D 00 24 B0 23 DB 03 E0 02 80 21 A0 22
OVERWRITE C0 18 09 01 D2 01 FF F7 91 FF 01 34 c0 46 c8 20
OVERWRITE 22 F6 AC FE AC 42 EE D1 FF BC 08 BC 18 47 00 00
OVERWRITE 01 04 00 00


REM below are to system info OSD to add red button to do RAM dump
REM entry point for above 004A7084
ADR $5DAB4
OVERWRITE 25
FIND 2F D1
OVERWRITE 1c
FIND FB 21
OVERWRITE D7 28 10 D1 C0 46 08 F2 23 F9

[DualTest]

I think you are onto something there. I won't post the entire capture. Just the first few lines after the usual stuff.

bAudioDelayReceived/bVideoDelayReceived/dramdelay = 0/1/0

ž]VGD�MaJWežY—D›HM\VB\˜@E�™VŒSŸ—M—B™“ŒXFYWG™Œ›�žSPb“ XŒLbH—O_ž\‹R^˜Œ@›Œ–GWLFD“™@STŒH˜Ÿ_NXYXS™›F˜—SWTž@Y ^WG\‹ZDXWJ“Q;—W˜›žO“YSWSZ›V^LHIO–ŒžBP�WL_‹›FJL]C\_]LVŒ@MV–™\FOE‚CO�“JTOT“BFž\FJ�D@C—M_M\bDFDZSVNF›Œ™T OP]–Z]™˜J™\@Y]DM—@ŒX_™eP\—M^YXZLS–DO_�NŸ�ŒHI›^VGWŒ^�BCŒŸIL‹FTGŒB @I^\™WJL\@‹WXNPWB�OeWVWŒ›PFIY]W]Xž\@AONPŸOCT@^GPT›DG@�NY‹ŒMO“\™WIF“bVBSMB[�˜;H_5Ÿ›@SMN–ZES‹V^Œ@ZW\Y˜^“_–DbY\V]^L›TMVHJPKžJ™\“
ÿÿÿÿÿ
€T€T€T€T€ i€i€i€|€r€{€T€T€T€{€T€T€|€|€i€T€T è fTé f^ê fhë fqí f»è fTì fîè fTë fq è fTé f^ê fhë fq€±€Ó€ß��!�C�Q�‰���·�Å�Ñ`

 
c˜a
b9
f

`

X

`

b
e
 p
c
d
q





ˆ
`


c a
b
@
f

`

 8

abc

9
:
 `

 H
`

c 
e
f
 p
a
b
@
  A
�*
h
d



ˆ
`

h8
 9
`

ch a
b
f
d
 `

 8
 `

8  `

 € ÿÿÿÿ¨¿´‰   ÿÿcc
 
�> �> ff �" ’
’
� ’“ ’² ff ’î ff g¶ g× gŽ g– h h i i! i5 i? ff gþ h h hN h h« iJ iJ‚‰ ‚˜
‚ž‚±‚½‚Ê‚å‚ï‚úÿ

˜cab9 
 
bpecdqˆ 
c ab
@

abc89: 
c ab
�*dhpe@Aˆ 
h 9 
ch a

8
    @ €
(c) 2002 NagraCard S.A.ïAýØtG&ïû"³Ø„9¬§`bÁͺ\–�Y;z…@ýÈ犋!ÚCdŸ-±rõ[ȶœ7vì9*£RnÙ§Ý
xžã•`66Où`Z£$Ò‡ÈRuì»ÁLº$þ�Úf¯IÐ�Œjû‘7�
x¿Iô#åÎ;U¼¢Wè"tÎ,êÁ¿J$ÂyG¢|¶Ùh€V]
3ýô®Þ0›åƒ›hI´.ƒµ|¢Øå|/ƒÚ÷k�þÄ
Z—a¦=@Xæ=MѲ(½äxöJ“‹Ѥ:ìÉ5“V~ËU *þl‰bbK±´ÞчÉ<J~¨â}*Ÿö\j �ðãS%•6(Ë 




  
(3$.6'2, /+0&7!4-)1# 
2ÆKÇh3îßdà4��ïLqÈøiÁ}µù¹'jMä¦ršÉ xe/Š!á$ð‚E5“ÚŽ–�Û½6ÐΔ\Òñ@Fƒ8fÝý0¿‹b³%â˜"ˆ‘~nHã¶B:k(Tú…=º+y
›Ÿ^ÊNÔ¬åós§W¯X¨PôêÖtO®éÕçæ*è,×uzëõYË_°œ©Q*öoÄIìØC-¤v{·Ì»>Zû`±†;R¡lªU)�—²‡�a¾Üü¼•ÏÍ7?[ÑS9„<A¢mG*ž]VòÓ«D’Ù# .‰´|¸&w™ã¥gJíÞÅ1þ
cŒ€À÷p
3Uÿ.r–¡ø5_á8HØs•¤÷
"fªå4\ä7Yë&j¾Ùp�«æ1Sõ<DÌOÑh¸Ón²ÍLÔg©à;M×b¦ñ(xˆƒž¹Ðk½Ü�˜³ÎIÛvšµÄWù0Pð'i»Öa£þ+}‡’*ì/q“®é `*û:NÒm·Â]ç2Vú?AÃ^â=GÉ@À[í,tœ¿ÚuŸºÕd¬ï*~‚�¼ßzŽ‰€›¶ÁXè#e¯ê%o±ÈCÅTü!c¥ô -w™°ËFÊEÏJÞy‹†‘¨ã>BÆQó6Zî){�Œ�Š…”§ò
9KÝ|„—¢ý$l´ÇRö
c|w{òkoÅ0
g+þ׫vÊ‚É}úYGð*Ô¢¯œ¤rÀ· ý“&6?÷Ì4¥åñqØ1Ç#Öš€âë'²u ƒ,nZ*R;Ö³)ã/„SÑ í ü±[j˾9JLXÏÐïªûCM3…EùP<Ÿ¨Q£@�’�8õ¼¶Ú!ÿóÒÍì_—Dħ~=d]s`�OÜ"*�ˆFî¸Þ^Ûà2:
I$\ÂÓ¬b‘•äyçÈ7m�ÕN©lVôêez®ºx%.¦´ÆèÝtK½‹Šp>µfHöa5W¹†Ážáø˜iÙŽ”›‡éÎU(ߌ¡‰
¿æBhA™-°T»R jÕ06¥8¿@£ž�ó×û|ã9‚›/ÿ‡4ŽCDÄÞéËT{”2¦Â#=îL•BúÃN.¡f(Ù$²v[¢Im‹Ñ%røöd†h˜Ô¤\Ì]e¶’lpHPýí¹Ú^FW§��„�Ø« Œ¼Ó
÷äX¸³EÐ,�Ê?Á¯½
Šk:‘AOgÜê—òÏÎð´æs–¬t"ç*5…âù7èußnGñq)ʼno·bª¾üV>KÆÒy šÛÀþxÍZôݨ3ˆÇ1±Y'€ì_`Q©µJ
-åzŸ“Éœï*à;M®*õ°Èë»<ƒS™a+~ºwÖ&áicU!}




 @€6lØ«Mš/^¼cÆ—5jÔ³}úïÅ‘ ?ÿ• ÿ‘�qÿG DNASP102 ˆç ˆðˆÿ‰

‰‰‰#‰)ÿ
ch d
abcphde

bpde
`
h 9

@abcf
` 
`8





âpäcéaîbódøÿ ÿàãàç ø
 c pcðaôbøfŠÿcðfŠaôbøÿ
 @€ €@À *`à�PÐ0°pðˆHÈ(¨hè˜XØ8¸xø„DÄ$¤dä”TÔ4´tôŒLÌ,¬lìœ\Ü<¼|ü‚BÂ"¢bâ’RÒ2²rò
ŠJÊ*ªjêšZÚ:ºzú†FÆ&¦fæ–VÖ6¶vöŽNÎ.®nîž^Þ>¾~þ
�AÁ!¡aá‘QÑ1±qñ ‰IÉ)©ié™YÙ9¹yù…EÅ%¥eå•UÕ5µuõ
�MÍ-*mí�]Ý=½}ýƒCÃ#£cã“SÓ3³só‹KË+«kë›[Û;»{û‡GÇ'§gç—W×7·w÷�OÏ/¯oïŸ_ß?¿ÿ





 
 
    ` 
 h 8ÿÿÿÿÿ ÿÿ9!àäø äã `™V'È?z縧*—|@ùƒ“ƒÑØú°Ô,’wzŒL예O_0ýs ½™êŠ¬†¿Å5b þ–°vÒ|aB>Øæ@‚ÝТ ﲫr¤0<ðÄϡЄÀ+ÝGêÙZÀ{•ˆÔö¤¼S).ubð˜ØÄAQ}Ñ¥Ê8¡L†¨ŒZñª
–MÆ© .  QÝ2€©™*5³-mv0/÷Œþ¬˜w;š > @ûá×&–:¶Î¾.ŸÚeFñ
‹\bY*ÿgડ ØÖ}¡d¯M‚yÚÙH“t©Ú«õÈç…õ@r‚iŽUr¬ .�j=ÖY
óf»Í jm ¯ûS®Ð2Ðh >`%ñÙÄœ>çƒkaHZ©Nëz¢ÑE™7f¯†ßÊËíú½éIñO(Vûaœ)õÊY”Æqÿ·öX¦›ewž<MÄís4T<&úÚ$ø

[DualTest]

Nevermind....

[DualTest]

Ignore that above post, I am going to let it run until finished. And I will zip it and post it in the advanced section when done.

I changed the 01 04 to 01 08 and am running that now.

I hope I did that correctly. There seems to be a lot of 0's in the files. Anyway the first file is the unedited script and the second one is with the 01 08 edit. They are here:

http://www.satfix.net/showthread.php?142332-RealTerm-capture-9200HD

I also ran 01 10 if we need it.

[cw78836]

Thought this would be a great box when it first arrived on the scene. I have two of these boxes, collecting dust. I would be interested in any experiments for educational purposes.

[cw78836]

Thought that was to enable cloning one receiver from another. Not sure, but I remember doing something similar to clone my second receiver to my first receiver.

[jvvh5897]

Yep, I bet that other key press from boot would be good for clone of one box to another. I think the format of the serial transfer is just xmodem--hyperterm can do a file exchange under xmodem, so if anyone wants to try a serial upload to box of a file ,I think that xmodem (if there are multiple format xmodem settings try the CRC one) setting under hyperterm and use the same files as one would via usb.

Looking at the factory test screen again, I think you get into it from the "normal" screen, much as one watches a channel and calls up the menu screen from it, the factory test is called up from the normal loop. But I'm still not sure how one does that--there is a value that has to be matched 0xfffe" and only if that is matched do you get the factory test. I've looked around and found where you can get -0xfffe, but it is part of the factory test--so it looks like you have to be in the factory test to get the factory test. A bit hard to figure from just the machine code though, it could be that I'm missing something. Maybe a remote control button, maybe a press of a number of front buttons, maybe a jumper on the mother board. Maybe one of the older files has a way in that is more obvious, like an option under the menus--not sure that it matters if we can use the mpg space for code as that last serial capture suggests.

[DualTest]

Ignore that above post, I am going to let it run until finished. And I will zip it and post it in the advanced section when done.

I changed the 01 04 to 01 08 and am running that now.

I hope I did that correctly. There seems to be a lot of 0's in the files. Anyway the first file is the unedited script and the second one is with the 01 08 edit. They are here:

http://www.satfix.net/showthread.php?142332-RealTerm-capture-9200HD

I also ran 01 10 if we need it.


Yep, I bet that other key press from boot would be good for clone of one box to another. I think the format of the serial transfer is just xmodem--hyperterm can do a file exchange under xmodem, so if anyone wants to try a serial upload to box of a file ,I think that xmodem (if there are multiple format xmodem settings try the CRC one) setting under hyperterm and use the same files as one would via usb.

Looking at the factory test screen again, I think you get into it from the "normal" screen, much as one watches a channel and calls up the menu screen from it, the factory test is called up from the normal loop. But I'm still not sure how one does that--there is a value that has to be matched 0xfffe" and only if that is matched do you get the factory test. I've looked around and found where you can get -0xfffe, but it is part of the factory test--so it looks like you have to be in the factory test to get the factory test. A bit hard to figure from just the machine code though, it could be that I'm missing something. Maybe a remote control button, maybe a press of a number of front buttons, maybe a jumper on the mother board. Maybe one of the older files has a way in that is more obvious, like an option under the menus--not sure that it matters if we can use the mpg space for code as that last serial capture suggests.

Are these the correct files? I am not sure if you have had a chance to look at them yet.

[jvvh5897]

Got them a little bit ago and posted notes about them in advanced section. Good work overall. Think we do need a bigger dump based on what I saw--it looks like the cmd07 packets might be just a little further up than I thought--not a lot, but going to a 8 meg dump would definately get them. Notes in advanced section also suggest you record and post what channel number you were on and leave it run for a while before starting RealTerm capture.

[DualTest]

I added the 8 meg dump in the capture thread. Once I know that everything with that file and the ram dump are good I will post the ram dump file down in the advanced section with all the proper mods done.

[lenonh]

OH Man! Almost shot a load in my pants! I am interested to if anyone can bring this back to life

[jvvh5897]

One other thing that might be of help--try a 2Meg dump, but before you start it, send "qwerty" to the box with RealTerm. If it shows up in the RX buffer that would mean the rx handler is listening to the port and if not then the rxhandler is doing something else. The dumps I've looked at so far have helped a lot! Still not sure why the traceout mod did not give a dump though, now that I can see what routines it calls I think it should have worked.

[jvvh5897]

If there is interest in disassembling the code too....you can use a cracked copy of IDA to disassemble the femu code after running the unpack program. The MBoot 7 is not compressed but you have to break it into two parts as the first part executes in flash, but the second part is moved to RAM for execution I'll post notes from the boot disasembly I've done--the boot would be a good place to start looking at disassembly as it is small.



Mboot_07_US.zip

Looks like the boot expects mainsw at R8, =0xF0040000
So, flash base addr is 0xf0000000
There is a second part to the boot that starts at f0010000 that is moved to RAM at 1e00000

ROM:01E047C0 LDRB R1, [R8,R0]
ROM:01E047C4 ADD R2, SP, #8
ROM:01E047C8 STRB R1, [R2,R0]
ROM:01E047CC ADD R0, R0, #1
ROM:01E047D0 CMP R0, #0x10
ROM:01E047D4 BCC loc_1E047C0
ROM:01E047D8 LDR R0, =aFlashHeader
ROM:01E047DC BL sub_1E11258 ; debug message
ROM:01E047E0 LDR R7, =a02x
ROM:01E047E4 MOV R4, #0

So, first ten bytes of header are moved to stack starting at SP+8

Byte in SP+8 and 9 are MainImage "Main Image : %02X %02X" 55 66
Bytes +C and D are version # "Version : %02X%02X" 1208 for example
Bytes +E,F,10,11 "YYYY,MM,DD : %02X%02X, %02X, %02X" 2008, 04, 02

ROM:01E048BC LDR R1, [SP,#0x18] ; this would have 0x241400 in it
ROM:01E048C0 BL sub_1E024B0


01E0D31C ; write to serial port
01E14828 ; get byte from serial port with timeout
01E0C9A4 ; read from serial port
01E14778 ; delay based on timer?
01E14890 ; write n bytes to serial port
01E14848 ; write byte to port 2
01E14864 ; write a string to serial port
01E05804 ; normal entry to write a string to port 2
01E06474 ; put a string on front panel LEDs? ex:"upld"
01E0D588 ; send to front LEDs
01E04554 ; convert text/numbers and LED display
01E04490 ; convert numbers/txt and LED display
01E104C4 ; xmodem
01E1015C ; continue download
01E0CBB0 ; upld serial
01E053EC ; usb load file--bin, boot, DATA...


See, not a lot in there that I've found, but I was looking for the header info and serial stuff with a little interest in how the front LEDs could help figure some of that out.

For the main code of the femu file I have lots more routines that I've located.


HD-9200BL_pvr_090607_9219_api_femu

0x241400 base arrd in RAM
ARM code, IDA Pro used to disassemble
EOF at 59FCAC

0027DD40 ; blue time button/Time set
002A7EC8 ; menu system?
0024A5F0 ; Audio button L/R OSD

0024E140 ; key data display and edit
0024B0B4 ; keycode button handling
0024B278 ; keycode/autoroll menu
0027C4AC ; "key edit control"
0024E374 ; CAS SYSTEM

002A7484 ; video mode--pal_ntsc:%d, PAL_NTSC:%d, old_tv_mode:%d%"

0029EEA0 ; SystemInfo button handling
0025FF14 ; display on screen
00346974 ; clean up OSD/exit
0024C6C0 ; put mpg image onscreen
00359548 ; mpg display
002B4090 ; BMP display (BM start at 141c08 bytes into file 42 4D 78 1E 00 00 continue to about 21f71c)

0028575C ; Normal control
00362254 ; "E2PROM Test
00362624 ; ch3/4 select
00361E3C ; factory test
002AEEC8 ; do audio mute/unmute?
002ECF14 ; put OSD window on screen
0024BD30 ; Big signal strength display (includes time update)
0025F430 ; uses [%d%%] (part of scanning)
0029D770 ; includes Q and S% as 0th
0025179C ; can call 0029D770 ; includes Q and S% as 0th
0035A3A8 ; startup "normal"\menu\factory mode


002F8974 ; copy RSA keys...
002F4A90 ; get RSA keys and decrypt?

00361E2C ; delay
002963E8 ; copy CWs
0034AA64 ; parse decrypted ecm for cws
002C9594 ; sem put
002C94E0 ; sem_get
002C8940 ; error_log--just returns zero
00248B58 ; debug message-- Null sub
00248B34 ; error log--transition ARM to thumb code
002C96BC ; strncmp?

00282DA0 ; GC N2 decrypt
00260AD0 ; provID check and N2 decrypt if 1801
002DED44 ; process ecms
002A2168 ; ecm handler

002A66C4 ; traceport init
0035D850 ; rx handler
00364258 ; tx handler
0034EFFC ; traceout
00345478 ; llser_open
00366810 ; vprintf
002C9EC4 ; task_time_sleep

0034E7C0 ; call vprintf (used for "D EEPROM is re-program.." and "E3cmd_init")
0034F03C ; i.putstringQ
00363A1C ; call vprintf (only 3 xref)
002B306C ; debug message (uses vprintf)

002C95F8 ; _sprintf
00367AB0 ; "total bytes ="--all serial sends Null sub

0031683C ; IOlib: uses the 2nd call to llser--maybe usb comms?
00314964 ; IOLib create image
00316758 ; "IOLIB: internal_iolib_open"
00316F10 ; "IOLIB: Thread processing %s for instance
003161BC ; IOLib handler

002C8920 ; critical_section_begin
002C8930 ; critical_section_end
002419EC ; __call_via_r0
002419EE ; __call_via_r1
002419F0 ; __call_via_r2
002419F2 ; __call_via_r3
002419F4 ; __call_via_r4
002419F6 ; __call_via_r5
002419F8 ; __call_via_r6
002419FA ; __call_via_r7
002C4678 ; cnxt_gpio_set_output_level
0029D310 ; "setup segment"-- Front LEDs
0027CE48 ; display on front LEDs
0035A244 ; main init?
0029CAF4 ; put up mpg if needed/blue swoop/front panel LED 00000
0027E154 ; show "Init" on front LEDs and do init
002C83CC ; IOLib set visibility?
0026C900 ; set visibility?
002C7CB0 ; "IOLIB: cnxt_iolib_cls"
0026C8D0 ; call 002C7CB0 ; "IOLIB: cnxt_iolib_cls"
0027CE48 ; display "----" on front LEDs (part of init)
0026C0D4 ; convert numbers/txt and dislay on LEDs
0026C0AC ; disp REC on LEDs
0026C084 ; disp PLAY on LEDs
0026C05C ; disp HDD on front LEDs
002425C0 ; 16_divide
002425C4 ; divide
0027D538 ; LNB 14/18 Volt setting
0027D558 ; LNB power ON/Off


00242308 ; mem clear
0024280C ; strlen
002AAA10 ; Language string select for menu
00282EE0 ; Autoroll/femu?
002DF240 ; AutoRoll/femu 1800/1801/b00
002A21B4 ; EMM handler?
00260A00 ; EMM TASK install
002605F0 ; Ecm_parseq install
002C9304 ; nupkal_sem
002605B0 ; install EMM and ECM tasks
002F49FC ; install "EPG_MGR"
002F298C ; filter_init
002DF8A0 ; install "SAT_TUNER" task
002C92DC ; SendToMessage
002C9728 ; task create
0031F274 ; "internal_queue_create"
002C90FC ; call "internal_queue_create"
002F8E94 ; TRC1 install
00363A0C ; TRC1 handler
002F58A0 ; "hwtimer_create"
002F597C ; "hwtimer_set
002F5AB4 ; "hwtimer_start
00341450 ; "ISR error and trace handler
002B742C ; Audio task install
002B9710 ; "data_mngr" task install
002BB354 ; cnxt_demod_init
002C305C ; cnxt_dvblib_init
002C7A8C ; "ISMQUEUE"
002C85B0 ; "FTIR" task install
002C886C ; QDTV startup thread
002C8A10 ; "KPRSEM" task install
002CA384 ; cnxt_pcm_init
002CAD08 ; "PLYCTL" playback control task
002D56FC ; cnxt_sata_init
002D5CC8 ; cnxt_svclist_dvb_init
002D7E98 ; cnxt_ui_controls_init
002DF8A0 ; "SAT_TUNER"
002F8DB8 ; "EPG_PARSE"
00303484 ; demod_phantom task install
00331FD4 ; hdmi_private task install
003638EC ; "TRSM" trace task install

002604FC ; update the D EEPROM/"backdoor key"
(note flash addrs F06E0000 and F06F0000)
0026C008 ; flash write w/0x55 0xaa header
0027CCBC ; write key data to F06D0000
0028573C ; write to F0700000
002B398C ; write to F0620000
002DFF9C ; write to F0610000
00345458 ; write to F0600000
0034EC60 ; write to F0640000
00285718 ; read 0x2710 bytes from F0700000
0034543C ; read from F0600000
002F30FC ; read from flash
0034EC40 ; read from F0640000 8b8e0 bytes ch data? C8 AE 71 00 in RAM
002B396C ; read 8d80 bytes from F0620000 sat data?
0027CC94 ; read 1800 bytes from F06D0000 key data to 0x7FB998
002F30DC ; read the flash for sat/ch/key data...

0034C060 ; cnxt_eeprom_read
0034C0F4 ; cnxt_eeprom_write? (0xA0 i2c addr)
00361C14 ; mem copy a word (4 bytes)

002A1E04 ; put TV or RADIO BMP in info OSD?
002A4C08 ; put up clock BMP
00287534 ; put up the blue swoop BMPs--part of info
002ACFF4 ; Video resolution and scrambled/lock..status--info OSD
0034ACCC ; put time text +AM/PM on info screen
002AC9F0 ; put up upper blue swoop/tv/radio BMPs
0027FADC ; select then BMP for main menu
00249884 ; lookup channel info? task?
00249934 ; another chanell lookup task
0024DDF4 ; still another ch lookup
0024DE4C ; and ch lookup task
0024F85C ; show channel list
0024F620 ; show Radio channel list
002E1C88 ; show TP and PID channel info
002E18E8 ; show channel name
002E1ECC ; channel list with fav/lock/delete BMPs
0035E220 ; TV/Radio OSD
00284E68 ; setup slot and parse channel in scan
0026BD04 ; build filter
00284010 ; new channel positiner/scramble tick
0028C430 ; channel number and name
0034A524 ; radio channel number and name?
002EFDC0 ; do 0034A524 ; radio channel number and name?
002AA8CC ; do sendtomessage

0034534C ; [link_getdata]cnxt_iic_read_
003453B4 ; [link_setdata]cnxt_iic_write_indexed_reg



--------------------------------------------
Factory test
1. 22Khz....
2. LNB power.....
3. Modulator Channel
4. DVB-S Live
5. H.264(DVB-S) Stream..
6. Terrestrial Stream....
7. Front LED USB Test..... Front key test.....

--------------------------------------------

[DualTest]

One other thing that might be of help--try a 2Meg dump, but before you start it, send "qwerty" to the box with RealTerm. If it shows up in the RX buffer that would mean the rx handler is listening to the port and if not then the rxhandler is doing something else. The dumps I've looked at so far have helped a lot! Still not sure why the traceout mod did not give a dump though, now that I can see what routines it calls I think it should have worked.

That worked. I sent qwerty 3 times to the receiver and it showed up in the capture. I added that capture to the other thread.

[jvvh5897]

Cool!!

To make sure everyone has in mind what needs to be done to get IKS working with coolsat format--you need to receive a packet from the rq-sssp client program that looks like:
A5 17 00 30 C3 C2 C1 C0 E0 01 02 03 04 05 06 07 08 11 12 13 14 15 16 17 18 A5
where the first A5 is a "sync" byte
17 is the number of bytes that follow
30 is the "command" byte
the 01-08 is one CW and 11-18 is the other
That last A5 is a checksum, but you don't have to test it. The Cx, E0 bytes can be ignored.

And the box has to send out a packet that looks like:
SSSP|ECM|%08X|%02X|%04X|%04X|%04X|%s\n
the %s at the end is the ecm packet in the clear in ascii hex form.
The %08x and %02x are constants as far as we know and it works OK with some thing like SSSP|ECM|00000001|00|1816|0079|1022|80308F078D...5 C.
The three %04x are for CAid, Vpid and channel number that you are watching as prov numbers it.

------------------------------------------------
So, where are we? There is a possible CW save routine noted in the femu stuff just posted, but still have to determine how to use it and to capture the packet from PC.
Still haven't seen an ecm packet in the RAM dumps--not sure why, but the info for the box says that the RAM is pretty big, so might not be looking in the right places yet. I have avoided femu files because it trys to force packets into a form that cards would use--could be what I see in RAM are ecm packets but modded to something not as obvious. But we do have a couple of possible routines to send out a pure ascii packet as needed. And we have the channel number VPID and possible provID found in RAM dumps with "hard coded addresses" so they should always be found there:

Found at:
2346A0 == 7B46A0 I can find 0x7B46AC in code!
2346A0 00 00 00 00 00 00 11 00-00 00 00 00 00 00 72 00 --0x72 == 114 decimal
2346B0 04 10 00 00 08 00 21 00-00 00 22 1A 23 1A 22 1A --Vpid 1a22, Apid 1a23
2346C0 0A 02 00 00 01 00 65 6E-67 00 00 00 00 00 00 00
And
@ --0x7FEE22 used in "process ecm" 002DED44
27EE20 00 00 00 00 00 00 00 00-00 00 00 09 04 18 40 E1 --1840 provID
27EE30 35 09 04 18 16 E0 35 09-04 18 40 E1 35 09 04 18 --both 1816 and 1840
27EE40 16 E0 35 00 00 00 00 00-00 00 00 00 00 00 00 00


And the code to send out the packet to PC could be in one of only a few spots in code:
00282DA0 ; GC N2 decrypt
00260AD0 ; provID check and N2 decrypt if 1801
002DED44 ; process ecms
002A2168 ; ecm handler

SO, that is the basic plan from here for folks wanting to add IKS feature. Find which of the above routines to modify. Figure out how to make up and send the packet. Find the spot with ecm packets (likely a mod at the start of one of the above routines that dumps the info passed to the routine will have the address to use to get the ecm packet). As ecm packets come in often, it would be good if the spot modded pre-filters out duplicate ecm packets for you, and that is more likely in the later executing routines (the first two of the four above). Once the box is sending out packets, RealTerm can send a packet to the box and how to capture and save CWs finishes out the mods, unless you want to do some menu mods to turn things on and off (or have a special serial packet to do such a thing).

[jvvh5897]

Say, DualTest, I see in the code that there is an autoroll menu and that it might have a "keycode" on/off option sort of like in pansat 2700--you don't happen to have the keycode off do you? If so, the box will not pick up ecm packets. You can have the autoroll options off, but keycode should be on.

Looking at the RAM dump with qwerty sent to the box I see:
029C50 00 00 00 00 00 00 00 00-00 00 00 00 71 77 65 72 qwer
029C60 74 79 71 77 65 72 74 79-71 77 65 72 74 79 00 00 tyqwertyqwerty
in the rx buffer.
A little later in the dump:
02A450 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
02A460 EE 07 00 00 DC 01 00 00-DC 01 00 00 00 00 00 00
02A470 12 00 00 00 01 00 00 00-00 00 00 00 00 00 DC FE

There are 0x12 bytes in the RX buffer and 0x7ee bytes free in the buffer.
BUT, rxOutdex @5aa46C (2A46C in above) shows that zero bytes have been processed.
(as opposed to DC 01 00 00-DC 01 00 00 where the txindex and txoutdex are the same, So all buffer contents have been sent to serial port.)

Where:

txqueue 5A8C5C 0x1000 buffer size
rxqueue 5A9C5C 0x800 buffer size
txQueueCount 5AA45C
rxQueueFree 5AA460
txOutdex 5aa464
txIndex 5aa468
rxOutdex 5aa46C
rxIndex 5aa470

So, it looks like we could just lift the UART_Read from coolsat code with a few mods and use it to read bytes from the currently unused rx buffer.

-------------------------------------------------------

A couple tests to see which of two of the ecm routines might be active. Pick one or the other and make the mods to a file and see if you get serial output of the string "gc run..". If no output on the 260AD0 provID check mod, the other would not work either as the 260ad0 routine calls the 282DA0 GC N2 decrypt routine. The mods take over the first part of the routine and just exits back to the calling routine when the call to debug message is done, so either mod defeats the ecm decrypt process from the point that it is inserted on.

--------------------------------
ADR $0
REM Find the start of 00260AD0 provID check and N2 decrypt if 1801
FIND F0 B5 FF B0 84 B0 05 22
FIND FF B0
REM put in code to call 2B306C debug message I'm just pointing to the "GC run.." string
OVERWRITE 03 48 52 F0 CA FA
REM exit code
OVERWRITE F0 BC 08 BC 18 47 00 00
REM pointer to "gc run..."
OVERWRITE 40 37 49 00


-----------------OR-----------------------------
ADR $0
REM find the start of 00282DA0 GC N2 decrypt
FIND FE B5 04 1C 0D 1C 00 20
FIND 04 1C
REM call debug message routine with "gc run.." string to send
OVERWRITE 03 48 30 F0 62 F9
REM exit code
OVERWRITE FE BC 08 BC 18 47 00 00
REM pointer to "gc run..."
OVERWRITE 40 37 49 00


For those interested, here is the disassembly of the first:


ROM:00260AD0 PUSH {R4-R7,LR}
ROM:00260AD2 LDR R0, =0x493740
ROM:00260AD4 BL 0x2B306C
ROM:00260AD8 POP {R4-R7}
ROM:00260ADA POP {R3}
ROM:00260ADC BX R3
ROM:00260ADC ; ---------------------------------------------------------------------------
ROM:00260ADE DCB 0
ROM:00260ADF DCB 0
ROM:00260AE0 dword_260AE0 DCD 0x493740 ; DATA XREF: ROM:00260AD2r

The "gc run.." string is at 0x493740.

I am assuming that the box has keycode ON set.

[skywalker999]

jvvh5897 what changes are done with xvi32 and what parts with realterm I'm confused here

[DualTest]

jvvh5897 what changes are done with xvi32 and what parts with realterm I'm confused here

xvi32 is for editing the unpacked file and realterm is for monitor what is going on with the receiver. No editing is done with realterm, only monitoring and for capturing the ram dump output.

[DualTest]

Say, DualTest, I see in the code that there is an autoroll menu and that it might have a "keycode" on/off option sort of like in pansat 2700--you don't happen to have the keycode off do you? If so, the box will not pick up ecm packets. You can have the autoroll options off, but keycode should be on.

Looking at the RAM dump with qwerty sent to the box I see:
029C50 00 00 00 00 00 00 00 00-00 00 00 00 71 77 65 72 qwer
029C60 74 79 71 77 65 72 74 79-71 77 65 72 74 79 00 00 tyqwertyqwerty
in the rx buffer.
A little later in the dump:
02A450 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
02A460 EE 07 00 00 DC 01 00 00-DC 01 00 00 00 00 00 00
02A470 12 00 00 00 01 00 00 00-00 00 00 00 00 00 DC FE

There are 0x12 bytes in the RX buffer and 0x7ee bytes free in the buffer.
BUT, rxOutdex @5aa46C (2A46C in above) shows that zero bytes have been processed.
(as opposed to DC 01 00 00-DC 01 00 00 where the txindex and txoutdex are the same, So all buffer contents have been sent to serial port.)

Where:

txqueue 5A8C5C 0x1000 buffer size
rxqueue 5A9C5C 0x800 buffer size
txQueueCount 5AA45C
rxQueueFree 5AA460
txOutdex 5aa464
txIndex 5aa468
rxOutdex 5aa46C
rxIndex 5aa470

So, it looks like we could just lift the UART_Read from coolsat code with a few mods and use it to read bytes from the currently unused rx buffer.

-------------------------------------------------------

A couple tests to see which of two of the ecm routines might be active. Pick one or the other and make the mods to a file and see if you get serial output of the string "gc run..". If no output on the 260AD0 provID check mod, the other would not work either as the 260ad0 routine calls the 282DA0 GC N2 decrypt routine. The mods take over the first part of the routine and just exits back to the calling routine when the call to debug message is done, so either mod defeats the ecm decrypt process from the point that it is inserted on.

--------------------------------
ADR $0
REM Find the start of 00260AD0 provID check and N2 decrypt if 1801
FIND F0 B5 FF B0 84 B0 05 22
FIND FF B0
REM put in code to call 2B306C debug message I'm just pointing to the "GC run.." string
OVERWRITE 03 48 52 F0 CA FA
REM exit code
OVERWRITE F0 BC 08 BC 18 47 00 00
REM pointer to "gc run..."
OVERWRITE 40 37 49 00


-----------------OR-----------------------------
ADR $0
REM find the start of 00282DA0 GC N2 decrypt
FIND FE B5 04 1C 0D 1C 00 20
FIND 04 1C
REM call debug message routine with "gc run.." string to send
OVERWRITE 03 48 30 F0 62 F9
REM exit code
OVERWRITE FE BC 08 BC 18 47 00 00
REM pointer to "gc run..."
OVERWRITE 40 37 49 00


For those interested, here is the disassembly of the first:


ROM:00260AD0 PUSH {R4-R7,LR}
ROM:00260AD2 LDR R0, =0x493740
ROM:00260AD4 BL 0x2B306C
ROM:00260AD8 POP {R4-R7}
ROM:00260ADA POP {R3}
ROM:00260ADC BX R3
ROM:00260ADC ; ---------------------------------------------------------------------------
ROM:00260ADE DCB 0
ROM:00260ADF DCB 0
ROM:00260AE0 dword_260AE0 DCD 0x493740 ; DATA XREF: ROM:00260AD2r

The "gc run.." string is at 0x493740.

I am assuming that the box has keycode ON set.

I am going to be busy today, but really want to take a look at all of that. Hopefully tonight or tomorrow. Thanks.

[jvvh5897]

Thank you for the work you have put in, DualTest. No hurry. It would be nice if those that said they also would help out would. I am working in the dark a lot--I have screen shots from an old review of the pansat9200, but it leaves a lot of the menu out and is for the file they used for the review and not the femu. Not having a box to play with means that lots of stuff that I would just test and never mention has to be tried in public--so, testers have to make an effort.

There could be an easier way to test some of this--the serial port method is good, but I found the pop up window routine for messages the other day--you know the one that shows "Scrambled Channel" or "No signal" messages. I was thinking that the code could overwrite the "Scrambled or bad channel" text string with something else on the fly, then you could just watch the screen to see what is going on. If I were to try to use the box for other testing, I might make creative use of the menu system. I found the stack in the dump that has the return addresses for the added code up in the image space--it is interesting how the menu seems to work. I've also extracted all the bmp images that the menu system uses and found the routine that selects the strings to use in the menus for diff languages--those help figure things out too and could be fun to play with.

[DualTest]

Thank you for the work you have put in, DualTest. No hurry. It would be nice if those that said they also would help out would. I am working in the dark a lot--I have screen shots from an old review of the pansat9200, but it leaves a lot of the menu out and is for the file they used for the review and not the femu. Not having a box to play with means that lots of stuff that I would just test and never mention has to be tried in public--so, testers have to make an effort.

There could be an easier way to test some of this--the serial port method is good, but I found the pop up window routine for messages the other day--you know the one that shows "Scrambled Channel" or "No signal" messages. I was thinking that the code could overwrite the "Scrambled or bad channel" text string with something else on the fly, then you could just watch the screen to see what is going on. If I were to try to use the box for other testing, I might make creative use of the menu system. I found the stack in the dump that has the return addresses for the added code up in the image space--it is interesting how the menu seems to work. I've also extracted all the bmp images that the menu system uses and found the routine that selects the strings to use in the menus for diff languages--those help figure things out too and could be fun to play with.

Yes that is interesting. I like that ability to customize.

[bryan35]

I may be able to help out a bit. Hopefully soon.......three kids under 3 running around. Will dig out the 9200 this weekend.

[DualTest]

Say, DualTest, I see in the code that there is an autoroll menu and that it might have a "keycode" on/off option sort of like in pansat 2700--you don't happen to have the keycode off do you? If so, the box will not pick up ecm packets. You can have the autoroll options off, but keycode should be on.

Looking at the RAM dump with qwerty sent to the box I see:
029C50 00 00 00 00 00 00 00 00-00 00 00 00 71 77 65 72 qwer
029C60 74 79 71 77 65 72 74 79-71 77 65 72 74 79 00 00 tyqwertyqwerty
in the rx buffer.
A little later in the dump:
02A450 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
02A460 EE 07 00 00 DC 01 00 00-DC 01 00 00 00 00 00 00
02A470 12 00 00 00 01 00 00 00-00 00 00 00 00 00 DC FE

There are 0x12 bytes in the RX buffer and 0x7ee bytes free in the buffer.
BUT, rxOutdex @5aa46C (2A46C in above) shows that zero bytes have been processed.
(as opposed to DC 01 00 00-DC 01 00 00 where the txindex and txoutdex are the same, So all buffer contents have been sent to serial port.)

Where:

txqueue 5A8C5C 0x1000 buffer size
rxqueue 5A9C5C 0x800 buffer size
txQueueCount 5AA45C
rxQueueFree 5AA460
txOutdex 5aa464
txIndex 5aa468
rxOutdex 5aa46C
rxIndex 5aa470

So, it looks like we could just lift the UART_Read from coolsat code with a few mods and use it to read bytes from the currently unused rx buffer.

-------------------------------------------------------

A couple tests to see which of two of the ecm routines might be active. Pick one or the other and make the mods to a file and see if you get serial output of the string "gc run..". If no output on the 260AD0 provID check mod, the other would not work either as the 260ad0 routine calls the 282DA0 GC N2 decrypt routine. The mods take over the first part of the routine and just exits back to the calling routine when the call to debug message is done, so either mod defeats the ecm decrypt process from the point that it is inserted on.

--------------------------------
ADR $0
REM Find the start of 00260AD0 provID check and N2 decrypt if 1801
FIND F0 B5 FF B0 84 B0 05 22
FIND FF B0
REM put in code to call 2B306C debug message I'm just pointing to the "GC run.." string
OVERWRITE 03 48 52 F0 CA FA
REM exit code
OVERWRITE F0 BC 08 BC 18 47 00 00
REM pointer to "gc run..."
OVERWRITE 40 37 49 00


-----------------OR-----------------------------
ADR $0
REM find the start of 00282DA0 GC N2 decrypt
FIND FE B5 04 1C 0D 1C 00 20
FIND 04 1C
REM call debug message routine with "gc run.." string to send
OVERWRITE 03 48 30 F0 62 F9
REM exit code
OVERWRITE FE BC 08 BC 18 47 00 00
REM pointer to "gc run..."
OVERWRITE 40 37 49 00


For those interested, here is the disassembly of the first:


ROM:00260AD0 PUSH {R4-R7,LR}
ROM:00260AD2 LDR R0, =0x493740
ROM:00260AD4 BL 0x2B306C
ROM:00260AD8 POP {R4-R7}
ROM:00260ADA POP {R3}
ROM:00260ADC BX R3
ROM:00260ADC ; ---------------------------------------------------------------------------
ROM:00260ADE DCB 0
ROM:00260ADF DCB 0
ROM:00260AE0 dword_260AE0 DCD 0x493740 ; DATA XREF: ROM:00260AD2r

The "gc run.." string is at 0x493740.

I am assuming that the box has keycode ON set.

I don't see an autoroll or keycode option in any of the menu screens.

UPDATE: Found it under Menu/User Setup/Parental Controls/Second Pin. And all of options were set to on. Keycode, and the 3 provider autoroll options.

Ran a capture of the first script and added to the capture thread in the advanced section.

[jvvh5897]

Well, if keycode is on and you are pointed at either of the major providers then where are the ecm packets in the dumps? Makes no sense, they have to be in there. Specifications for the 9200 show: Flash Memory 8 Mbyte, SDRAM 128 Mbyte, EEPROM 32 Kbit. I suppose we could just keep dumping RAM till all 128 megabytes are availible and look for the 8x 30 a2 07 a0 or 8x 30 8f 07 8d sequences start showing up (8x is 80 or 81 for DN and 8e or 8f for 3ev), but 128 meg would take a couple of hours of dumping at 1.5 minutes per meg. And you would want to keep the file sizes small to make the loading and searching resonable. If there is something in the capture of the first script then maybe a dump of the stack would help using that ecm routine, if not then the file is not pulling in any ecm packets at all and we should move on to another file.

Well, on another topic, I think I found a way to pull up the factory test screen:

to get factory test using the Yellow/multi button:
FIND 00 00 00 00 D9 00 00 00 00 00 00 00 D3 00 00 00
FIND D9
OVERWRITE AC

What is going on in the above is that there is a table in the data section of the file that takes you from the button code sent by the remote to an internal code used by the menu system and the above rewrites the internal code returned for the yellow button (0xd9) to instead return the 0xac code--I think that is the only way to get to the factory test.

For reference to any that might like to disassemble the file and look for internal button code use:


func button code, internal code used
0-9 30-39


PAGE UP 60, 8C
PAGE DOWN E2, 8D
TV/RADIO 10, 90
AUDIO 50, 91
FAV BA, 92
HDD - A0, 93
PAUSE PVR 72, 94
REWIND 12, 95
FORWARD 92, 96
PAUSE TV 3A, 9E

REC F2, A2
POWER 00, B0
EPG 98, B3
OK A8, B4
EXIT C0, B5
PLAY 52, B8
STOP D2, B9
MENU D0, BA
LAST e0, BE
mute, 20, C3
INFO 58, C6
CH UP/ UP ARROW 48, D3
DOWN ARROW/ CH DOWN C8, D4
VOL -/ LEFT ARROW 28, D5 (C2 does the same)
VOL +/ RIGHT ARROW 68, D6 (C1 does the same)
RED MODE 30, D7
GREEN SIG B0, D8
YELLOW MULTI 08, D9
BLUE TIME 88, DA
SAT (TV/VCR) D8, DD

[DualTest]

Well, if keycode is on and you are pointed at either of the major providers then where are the ecm packets in the dumps? Makes no sense, they have to be in there. Specifications for the 9200 show: Flash Memory 8 Mbyte, SDRAM 128 Mbyte, EEPROM 32 Kbit. I suppose we could just keep dumping RAM till all 128 megabytes are availible and look for the 8x 30 a2 07 a0 or 8x 30 8f 07 8d sequences start showing up (8x is 80 or 81 for DN and 8e or 8f for 3ev), but 128 meg would take a couple of hours of dumping at 1.5 minutes per meg. And you would want to keep the file sizes small to make the loading and searching resonable. If there is something in the capture of the first script then maybe a dump of the stack would help using that ecm routine, if not then the file is not pulling in any ecm packets at all and we should move on to another file.

I am going run the entire 128 meg capture tonight. I won't be using the TV or computer at the time anyways. I am still on DN channel 114, which is on 119W and am positive that I am pointing at it. Maybe I am just not waiting long enough, I will leave it sit on the channel for 20 minutes before running the dump. And in the keycode section it has the following under Nagravision 2

Dish Network
Provider ID 01 01
Key Number 00 00
Key Data 0A 97 6F 38 72 30 FB 6B
B6 79 0C 5B D7 84 DF 7C

[DualTest]

to get factory test using the Yellow/multi button:
FIND 00 00 00 00 D9 00 00 00 00 00 00 00 D3 00 00 00
FIND D9
OVERWRITE AC

What is going on in the above is that there is a table in the data section of the file that takes you from the button code sent by the remote to an internal code used by the menu system and the above rewrites the internal code returned for the yellow button (0xd9) to instead return the 0xac code--I think that is the only way to get to the factory test.


This works, by pressing the yellow/multi button

Test Processing....
EPROM Test OK
1. 22khz ON
2. LNB Power 18 volt
3. Modulator Channel CH-3
4. DVB-S Live Play
5. H.264 (DVB-S) Stream
6. Terrestrial Stream
7. Front LED
USB Test Empty
Front Key Test

And then the femu info.

[DualTest]

I add the full 128 Meg dump to the capture thread.

[jvvh5897]

Interesting that the factory test can be gotten to that way. From what I see in the remote code, it is no longer possible to use the remote to get to it. There are three lookup tables and the 0xac value is in one of them, but the rest of the tests would not let one get to that lookup table even if you have the correct remote. There is another routine that looks for info from the uhf plug on the back panel but that has still another custom code and lookup table and does not let one get to the 0xac value either. It is like the sw was not cleaned up much at all, but just enough done to let the pansat remote work.

Well, I downloaded those 4 parts of the 128 M dump. Did you just change the size parameter of the existing code, or did you change it to start before the 0x580000 point that I coded in?

The disassembly of the main calling routine looks like:

ROM:004A7148 PUSH {R0-R7,LR}
ROM:004A714A LDR R5, =0x401
ROM:004A714C MOV R4, #0
ROM:004A714E
ROM:004A714E loc_4A714E ; CODE XREF: ROM:004A716Ej
ROM:004A714E MOVL R3, 0x580000
ROM:004A7152 LSL R0, R4, #0xB
ROM:004A7154 MOV R1, #0x80
ROM:004A7156 MOV R2, #0xA0
ROM:004A7158 ADD R0, R0, R3
ROM:004A715A LSL R1, R1, #4
ROM:004A715C LSL R2, R2, #7
ROM:004A715E BL sub_4A7088
ROM:004A7162 MOVL R0, 0x3E8
ROM:004A7166 ADD R4, #1
ROM:004A7168 BL sub_4A705C
ROM:004A716C CMP R4, R5
ROM:004A716E BNE loc_4A714E
ROM:004A7170 POP {R0-R7}
ROM:004A7172 POP {R3}
ROM:004A7174 BX R3
ROM:004A7174 ; ---------------------------------------------------------------------------
ROM:004A7176 DCB 0
ROM:004A7177 DCB 0
ROM:004A7178 dword_4A7178 DCD 0x401 ; DATA XREF: ROM:004A714Ar

Where ROM:004A714E MOVL R3, 0x580000 sets the starting address of the dump and DCD 0x401 sets the size.
The movl command is actually two instructions, it loads a constant and then does a shift left to get it to the final value (B0 23 DB 03 in hexdump I think, so if you change the 0xb0 to 0x00 it should start with address 0x00 in RAM)

[DualTest]

I just change the size parameters to 01 80 @$265D79 in the ram dump file. Then started the capture just before pressing the red button.


Where ROM:004A714E MOVL R3, 0x580000 sets the starting address of the dump and DCD 0x401 sets the size.
The movl command is actually two instructions, it loads a constant and then does a shift left to get it to the final value (B0 23 DB 03 in hexdump I think, so if you change the 0xb0 to 0x00 it should start with address 0x00 in RAM)

So if I change 0xb0 @265d4a of the ram dump file to 0x00, and leave the size parameter as 80 @$265d79, that should start at 0x00 of the ram and get the full ram dump?

Well hopefully I got it right this time. Thanks for being so patient, I know this remedial stuff can't be much fun for you.

[jvvh5897]

Well, no sign of cmd07s in the dumps that I've looked at so far and no sign that the code is reaching the mod made to N2 ecm processing routine. I'm thinking that it is time to move to another file--one pre-femu but still N2. It looks to me that the only place with such files is in archive section of preferredbypete--maybe around the 08111_9296 file or somethng from a few months earlier. I don't know which might be better EPG or might have bugs but that seems to be around when the #7 boot came out too, so they might have gotten things worked out around there. Maybe someone has such a file in their hard drive or is a member of pete or will join there to get a file or files and test to see what might be a good one to try.

[zelig]

id-discussion has old files

[DualTest]

Okay I have the 08111_9296 file and have started to mod it. I have replaced the radio backgroud. And now attempting to mod the ram dump script. I have highlighted the two spots I have changed so far. I just picked two spots within the space created by the radio background. As you probably already know that doesn't get me the ram dump. I am assuming that since these files are different sizes that the code for the buttons are in a different place. It may take me awhile to find that.

REM write a byte to serial port lifted from 01E0D31C in 2nd part of MBOOT 7
REM call with R0 = 2 for the right uart port
REM R1 = byte to write
REM Little endian ARM code



ADR $253C00
REM $4a7000
OVERWRITE 03 00 50 E3 01 00 00 1A 44 C0 9F E5 01 00 00 EA
OVERWRITE 40 20 9F E5 00 C6 82 E0 00 20 9C E5 20 00 12 E3
OVERWRITE FC FF FF 0A 1C 00 12 E3 01 00 00 0A 00 00 A0 E1
OVERWRITE 1E FF 2F E1 03 00 50 E3 01 00 00 1A 1C 00 9F E5
OVERWRITE 01 00 00 EA 18 20 9F E5 00 06 82 E0 00 10 80 E5
OVERWRITE 1E FF 2F E1 14 00 04 E0 14 00 41 E0 40 6D E1 01
OVERWRITE 00 00 04 E0 00 00 41 E0

REM call above with R0=2 from 01E14848 in boot

OVERWRITE 08 40 2D E9 00 10 A0 E1 02 00 A0 E3 E1 FF FF EB
OVERWRITE 08 40 BD E8 00 00 A0 E3 1E FF 2F E1

REM Add to below to go from Thumb code to ARM
OVERWRITE 78 47 C0 46

REM use above 01E14848 to loop writing n bytes, from 1E14890 in boot
REM R1 with number of bytes, R0 points to buffer

OVERWRITE 38 40 2D E9 01 40 A0 E1 00 50 A0 E1 01 00 D5 E4
OVERWRITE F2 FF FF EB 01 40 44 E2 00 00 54 E3 FA FF FF 1A
OVERWRITE 38 40 BD E8 00 00 A0 E3 1E FF 2F E1

REM 4A7148 Hex_Dump
ADR $253D48

OVERWRITE FF B5 0B 4D 00 24 B0 23 DB 03 E0 02 80 21 A0 22
OVERWRITE C0 18 09 01 D2 01 FF F7 91 FF 01 34 c0 46 c8 20
OVERWRITE 22 F6 AC FE AC 42 EE D1 FF BC 08 BC 18 47 00 00
OVERWRITE 01 04 00 00


REM below are to system info OSD to add red button to do RAM dump
REM entry point for above 004A7084
ADR $5DAB4
OVERWRITE 25
FIND 2F D1
OVERWRITE 1c
FIND FB 21
OVERWRITE D7 28 10 D1 C0 46 08 F2 23 F9

[skywalker999]

i think i have all the pansat 9200hd bins if you guys need any version just ask :yes:
i wish i could help a bit more but I'm still not sure how maybe a small demo with pic would be great

[jvvh5897]

Well, skywalker999, you could learn to use the hexeditor and use the pack and unpack and mpg modding programs without much help, yes?--don't see how they need much in the way of guides. About all you need to know is drag and drop and that you can open a command window by going to start, hit run and type in cmd. And testing files means just loading them into the box--we don't know that the file DualTest is trying is the one to use, but a little playing with it would tell you if it has a good EPG on prov, looking at serial output might tell you if it is processing ecms pointed at 97 degree sat and tuning in radio channels that are still N2 (you might even find a file that with the right key would get the N2 radio too--that for sure tells you it is processing N2 ecm).

On modifying the current dump script: there are two problems with moving the code around, the sys info code has to call into it and that call has to be modified for the new position, and there is still one call in the hexdump code to a task_time_sleep routine and that call would have to modified to call the right place. I cheat and just use WinARM to compile a small bit of code to give me the machine code for those calls, but yuou can calculate the calls (subtract the destination and location of the call and subtract 4 from that to adjust for the pre-fetch that the processor does, then take the lower 12 bits of the result divide by 2 and OR into F800 for one of the two instructions needed then take the next 12 bits of the result and OR into f000 for the other instruction--it takes some playing to get it right and that is just for Thumb code, ARM code is a little different--you can see why I cheat, yes?)

Sys info code can be found easily and the task_time_sleep routine as well--easier if you have done an IDA disassembly first though.

[skywalker999]

jvvh5897 and Dualtest i use a program called advance serial port and i loaded pansat bin HB-9200BL_030119_9233
provider DN and every time i changed channel this is what this program was logging on serial port com3 where the the p9200 is connected i don't know if this helps

<20131106203038.518 RX>
------------------------------- [len=31]
<20131106203038.533 RX>
<LF> #### av_stop #### [len=22]
<20131106203038.533 RX>
<LF>-------------------------------- [len=33]
<20131106203038.533 RX>
<LF>03.17.039: QDTV: Muting audio and stopping decoder [len=51]
<20131106203038.533 RX>
<LF>03.17.052: QDTV: Blanking video for output 0 [len=45]
<20131106203038.533 RX>
<LF>03.17.052: QDTV: Video blanked [len=31]
<20131106203038.549 RX>
<LF>-------------------------------- [len=33]
<20131106203038.549 RX>
<LF> #### av_stop #### [len=22]
<20131106203038.549 RX>
<LF>-------------------------------- [len=33]
<20131106203038.549 RX>
<LF>03.17.064: QDTV: Muting audio and stopping decoder [len=51]
<20131106203038.565 RX>
<LF>03.17.066: 0x00000000: Warning from ... (file D:\Cnxt_hd\SRC920~1\apps\qdtv\qdtv.c, line 3556) [len=95]
<20131106203038.565 RX>
<LF>03.17.065: QDTV: Blanking video for output 0 [len=45]
<20131106203038.565 RX>
<LF>03.17.066: QDTV: Video blanked [len=31]
<20131106203038.580 RX>
<LF>03.17.066: QDTV: Function cnxt_dmx_set_pcr_channel (video off) returned CNXT_STATUS_BAD_HANDLE (4) for output 0 at line 3556 of file D:\Cnxt_hd\SRC920~1\apps\qd----------------------------------------------- [len=208]
<20131106203038.611 RX>
<LF> SECTION_CAT received (01) [len=30]
<20131106203038.611 RX>
<LF>----------------------------------------------- [len=48]
<20131106203038.611 RX>
<LF>0 pid [len=6]
<20131106203038.689 RX>
<LF>-------------------------------- [len=33]
<20131106203038.689 RX>
<LF> #### av_start #### [len=23]
<20131106203038.689 RX>
<LF>-------------------------------- [len=33]
<20131106203038.689 RX>
<LF>QDTV: Video format MPEG2 (0), audio format AUTO (0) [len=52]
<20131106203038.689 RX>
<LF>qdtv_start_audio_and_video(3162) : VideoFormat = MPEG2(0), bAVSyncEnabled = 1 [len=78]
<20131106203038.721 RX>
<LF>-------------: uNumAudioStreams = 1, audio format AUTO (0) [len=59]
<20131106203038.721 RX>
<LF>03.17.224: QDTV: New video PTS delay is 33355uS [len=48]
<20131106203038.721 RX>
<LF>03.17.224: QDTV: Video decode started. [len=39]
<20131106203038.721 RX>
<LF>03.17.225: QDTV: Starting audio for instance 0 with new PID 0x1123, format AUTO (0) [len=84]
<20131106203038.736 RX>
<LF>(2549) dolby = 0 [len=17]
<20131106203038.736 RX>
<LF>(2550) pInst->uOutput = 0 [len=26]
<20131106203038.736 RX>
<LF>(2551) AudioMode = 3 [len=21]
<20131106203038.736 RX>
<LF>(2552) AudioFormat = 0 (AUTO) [len=30]
<20131106203038.736 RX>
<LF>(2669) Mode = 2 [len=26]
<20131106203038.752 RX>
<LF>(2670) hAudio = 10982016 [len=33]
<20131106203038.752 RX>
<LF>(2671) hAC3Audio = 10982272 [len=33]
<20131106203038.752 RX>
<LF>(2672) AudioFormat = 0 [len=26]
<20131106203038.752 RX>
<LF>(2673) bAVSyncEnabled = 1 [len=26]
<20131106203038.752 RX>
<LF>03.17.238: AUDIO: internal_audio_start() Format: 0x00000000 [len=60]
<20131106203038.767 RX>
<LF>03.17.247: QDTV: Muting audio and stopping decoder [len=51]
<20131106203038.767 RX>
<LF>03.17.260: QDTV: Starting audio for instance 0 with new PID 0x1123, format AUTO (0) [len=84]
<20131106203038.767 RX>
<LF>(2549) dolby = 0 [len=17]
<20131106203038.783 RX>
<LF>(2550) pInst->uOutput = 0 [len=26]
<20131106203038.783 RX>
<LF>(2551) AudioMode = 3 [len=21]
<20131106203038.783 RX>
<LF>(2552) AudioFormat = 0 (AUTO) [len=30]
<20131106203038.783 RX>
<LF>(2669) Mode = 2 [len=26]
<20131106203038.783 RX>
<LF>(2670) hAudio = 10982016 [len=33]
<20131106203038.783 RX>
<LF>(2671) hAC3Audio = 10982272 [len=33]
<20131106203038.783 RX>
<LF>(2672) AudioFormat = 0 [len=26]
<20131106203038.814 RX>
<LF>(2673) bAVSyncEnabled = 1 [len=26]
<20131106203038.814 RX>
<LF>03.17.272: AUDIO: internal_audio_start() Format: 0x00000000 [len=60]
<20131106203038.814 RX>
<LF>03.17.281: QDTV: Audio delay not reported, video delay reported. Sync update not performed [len=91]
<20131106203038.814 RX>
<LF>
<20131106203052.199 RX>
-------------------------------- [len=33]
<20131106203052.199 RX>
<LF> #### av_stop #### [len=22]
<20131106203052.199 RX>
<LF>-------------------------------- [len=33]
<20131106203052.215 RX>
<LF>03.30.721: QDTV: Muting audio and stopping decoder [len=51]
<20131106203052.215 RX>
<LF>03.30.736: QDTV: Blanking video for output 0 [len=45]
<20131106203052.230 RX>
<LF>03.30.736: QDTV: Video blanked [len=31]
<20131106203052.230 RX>
<LF>-------------------------------- [len=33]
<20131106203052.230 RX>
<LF> #### av_stop #### [len=22]
<20131106203052.230 RX>
<LF>-------------------------------- [len=33]
<20131106203052.230 RX>
<LF>03.30.748: QDTV: Muting audio and stopping decoder [len=51]
<20131106203052.246 RX>
<LF>03.30.751: 0x00000000: Warning from ... (file D:\Cnxt_hd\SRC920~1\apps\qdtv\qdtv.c, line 3556) [len=95]
<20131106203052.246 RX>
<LF>03.30.750: QDTV: Blanking video for output 0 [len=45]
<20131106203052.261 RX>
<LF>03.30.750: QDTV: Video blanked [len=31]
<20131106203052.261 RX>
<LF>03.30.751: QDTV: Function cnxt_dmx_set_pcr_channel (video off) returned CNXT_STATUS_BAD_HANDLE (4) for output 0 at line 3556 of file D:\Cnxt_hd\SRC920~1\apps\qd----------------------------------------------- [len=208]
<20131106203052.293 RX>
<LF> SECTION_CAT received (01) [len=30]
<20131106203052.308 RX>
<LF>----------------------------------------------- [len=48]
<20131106203052.308 RX>
<LF>0 pid [len=6]
<20131106203052.402 RX>
<LF>-------------------------------- [len=33]
<20131106203052.402 RX>
<LF> #### av_start #### [len=23]
<20131106203052.402 RX>
<LF>-------------------------------- [len=33]
<20131106203052.402 RX>
<LF>QDTV: Video format MPEG2 (0), audio format AUTO (0) [len=52]
<20131106203052.402 RX>
<LF>qdtv_start_audio_and_video(3162) : VideoFormat = MPEG2(0), bAVSyncEnabled = 1 [len=78]
<20131106203052.417 RX>
<LF>-------------: uNumAudioStreams = 1, audio format AUTO (0) [len=59]
<20131106203052.433 RX>
<LF>03.30.934: QDTV: New video PTS delay is 33355uS [len=48]
<20131106203052.433 RX>
<LF>03.30.935: QDTV: Video decode started. [len=39]
<20131106203052.433 RX>
<LF>03.30.935: QDTV: Starting audio for instance 0 with new PID 0x1023, format AUTO (0) [len=84]
<20131106203052.449 RX>
<LF>(2549) dolby = 0 [len=17]
<20131106203052.449 RX>
<LF>(2550) pInst->uOutput = 0 [len=26]
<20131106203052.449 RX>
<LF>(2551) AudioMode = 3 [len=21]
<20131106203052.449 RX>
<LF>(2552) AudioFormat = 0 (AUTO) [len=30]
<20131106203052.449 RX>
<LF>(2669) Mode = 2 [len=26]
<20131106203052.449 RX>
<LF>(2670) hAudio = 10982016 [len=33]
<20131106203052.449 RX>
<LF>(2671) hAC3Audio = 10982272 [len=33]
<20131106203052.464 RX>
<LF>(2672) AudioFormat = 0 [len=26]
<20131106203052.464 RX>
<LF>(2673) bAVSyncEnabled = 1 [len=26]
<20131106203052.464 RX>
<LF>03.30.949: AUDIO: internal_audio_start() Format: 0x00000000 [len=60]
<20131106203052.464 RX>
<LF>03.30.960: QDTV: Muting audio and stopping decoder [len=51]
<20131106203052.480 RX>
<LF>03.30.972: QDTV: Starting audio for instance 0 with new PID 0x1023, format AUTO (0) [len=84]
<20131106203052.480 RX>
<LF>(2549) dolby = 0 [len=17]
<20131106203052.480 RX>
<LF>(2550) pInst->uOutput = 0 [len=26]
<20131106203052.495 RX>
<LF>(2551) AudioMode = 3 [len=21]
<20131106203052.495 RX>
<LF>(2552) AudioFormat = 0 (AUTO) [len=30]
<20131106203052.511 RX>
<LF>(2669) Mode = 2 [len=26]
<20131106203052.511 RX>
<LF>(2670) hAudio = 10982016 [len=33]
<20131106203052.511 RX>
<LF>(2671) hAC3Audio = 10982272 [len=33]
<20131106203052.511 RX>
<LF>(2672) AudioFormat = 0 [len=26]
<20131106203052.511 RX>
<LF>(2673) bAVSyncEnabled = 1 [len=26]
<20131106203052.511 RX>
<LF>03.30.984: AUDIO: internal_audio_start() Format: 0x00000000 [len=60]
<20131106203052.511 RX>
<LF>03.30.994: QDTV: Audio delay not reported, video delay reported. Sync update not performed [len=91]
<20131106203052.511 RX>
<LF>

[jvvh5897]

A little busy of a serial capture, but interesting.

--------------------------------------------------------------------------
I took apart the 081111 file and will include the routines that I've found so far. I largely looked for serial, ecm handling routines , and those that have info of use for IKS mods. Note that the end of file is before 0x580000 so it would be a good idea to mod the RAM dump routine to start a little earlier than that used before--say 0x570000 (change the 0xb0 to 0xae I think). I found where the privID and channel data should be stored. The serial receive routine seems as missing in this file as the femu one.

Below is a suggested mod to the file to let it use either the debug message routine or the traceout routine to send some debug messages to the serial port that currently are not getting there because the code made the debug calls to a routine that he removed at some point in the evolution. If the first mod does not get ecm messages out the serial port when box is on channel and dish is pointed to prov then try the other--one of the mods will let you test if the call works when exiting out of the sys info OSD.




------------------------
REM 081111 9296 BL file
REM find the 263A74 ; "ECM --> Start" routine and replace null sub call
REM with a call to 2B0AC0 ; debug message

ADR $0
FIND F9 37 2A 00 10 B5 12 48 86 F0 42 FA 14 21 11 48
FIND 86 F0 42 FA
OVERWRITE 4D F0 22 F8

REM find the sys info null sub call @2A052E and replace w call to debug message
FIND 20 1C C2 F7 83 FF 13 E0 FE 21 0E 48 10 30 49 F0 E7 FC
FIND 49 F0 E7 FC
OVERWRITE 10 F0 C7 FA

REM find 2EEF6C ; "[get_ecm_pid]ECM Pid = 0x%x" and change null sub call
REM to call debug message
FIND 07 21 09 02 40 18 04 89 21 1C 04 48 FA F7 C0 FF
FIND FA F7 C0 FF
OVERWRITE C1 F7 A0 FD

-------------------------------
------------------------
REM 081111 9296 BL file
REM find the 263A74 ; "ECM --> Start" routine and replace null sub call
REM with a call to traceout

ADR $0
FIND F9 37 2A 00 10 B5 12 48 86 F0 42 FA 14 21 11 48
FIND 86 F0 42 FA
OVERWRITE DF F0 42 FE

REM find the sys info null sub call @2A052E and replace w call to traceout
FIND 20 1C C2 F7 83 FF 13 E0 FE 21 0E 48 10 30 49 F0 E7 FC
FIND 49 F0 E7 FC
OVERWRITE A3 F0 E7 F8

REM find 2EEF6C ; "[get_ecm_pid]ECM Pid = 0x%x" and change null sub call
REM to call traceout
FIND 07 21 09 02 40 18 04 89 21 1C 04 48 FA F7 C0 FF
FIND FA F7 C0 FF
OVERWRITE 54 F0 C0 FB



And here are the routines found in the 081111:


081111 9296 BL file
Used IDA Pro to disassemble, ARM processor setting, installed to ROM @0x241400
Used modded sv_idc2 to aid in disassembly.

end of file @00573218

mpg img 01 at ROM:0048327C unk_48327C
mpg img 02 at ROM:004875F3 unk_4875F3

0034CC1C ; display mpg image
0024FA6C ; display main or radio background mpg

002EE15C ; read from flash
002419D4 ; sprintf
00353AEC ; factory test
00287360 ; do factory test
002857B8 ; normal
003536D4 ; factory test OSD?
002A04D0 ; sys info OSD
002CC2C0 ; task_time_sleep
(search B3 05 00 00 to find "task_time_sleep")
003536C4 ; delay


00241F18 ; memcmp
00242224 ; rt_memclr
002422C8 ; rt_memcpy
002423F0 ; rt_memmove
00242434 ; rt_memset
0024262C ; strcat
00242650 ; strcmp
002426F0 ; strcpy

002E7D74 ; POP UP window w/ text
002516F4 ; save key data OSD
0024B470 ; "Keycode" OSD
00251928 ; "CAS SYSTEM" OSD
002E998C ; place OSD window with title
00263A74 ; "ECM --> Start"
00263A2C ; "ECM_PARSEQ" and ECM TASK install
002CBB24 ; task_create
002A37F8 ; ecm handler
002EEF6C ; "[get_ecm_pid]ECM Pid = 0x%x"
002E0F58 ; process ecm
00263F2C ; test provID and decrypt ecm
00266668 ; copy idea string (Nagravision S.A.) and decryp
00266370 ; MECM 40 or 60 test/idea decryp
0027EC84 ; Execute MECM
00342EF4 ; "key valide ..\n" if MECM executed OK
00340188 ; load RSA keys 01 09 C1
00340228 ; 1 9 c1 prov N2 decryp
00282A44 ; mem compare and do N2 decryp
(above called from 263F2C "test provID and decrypt ecm")
00296E70 ; save CWs?
00290170 ; parse decrypted ecm for cws


002A7DB0 ; open TracePort
00350558 ; rx handler
00354FBC ; tx handler
0033D34C ; llser_open
00343700 ; traceout
00343740 ; i.putstringQ
00242868 ; vsprintf
00357400 ; vprintf
002B0AC0 ; debug message
00343174 ; call vprintf (used for "D EEPROM is re-program..")
00248A18 ; ARM entry to 00343174 ; call vprintf
0035479C ; call vprintf (only 3 xref)
002DE454 ; "sata init faile.."
002B0554 ; do audio mute/unmute?
002A95B8 ; menu system?
0029E120 ; put up mpg if needed
0027C990 ; LNB power ON/Off
002C6A98 ; cnxt_gpio_set_output_level
002E1700 ; "SAT_TUNER"
00263A14 ; install EMM and ECM tasks
00263E5C ; EMM TASK install
002EDC24 ; filter_init
002CB990 ; sem put
002CB8DC ; sem_get
002ABF60 ; do sendtomessage
002CB6D8 ; SendToMessage
00242524 ; divide
002B1630 ; BMP display
002E930C ; put OSD window on screen

002B1198 ; display channel data

---------------------------------------------
(channel info @ 0x747C10 )
(0x78C5DA should have provIDs)
----------------------------------------------

0x57C1C8 txqueue buffer 0x1000
0x57D1C8 rx queue buffer 0x800
0x57D9C8 txQueueCount
0x57D9CC rxQueueFree
0x57D9D0 txOutdex
0x57D9D4 txIndex
0x57D9D8 rxOutdex
0x57D9DC rxIndex

[jvvh5897]

Here is how I would write the mods to the RAM dump for the 081111 file:


REM write a byte to serial port lifted from 01E0D31C in 2nd part of MBOOT 7
REM call with R0 = 2 for the right uart port
REM R1 = byte to write
REM Little endian ARM code


ADR $254500
REM $495900
OVERWRITE 03 00 50 E3 01 00 00 1A 44 C0 9F E5 01 00 00 EA
OVERWRITE 40 20 9F E5 00 C6 82 E0 00 20 9C E5 20 00 12 E3
OVERWRITE FC FF FF 0A 1C 00 12 E3 01 00 00 0A 00 00 A0 E1
OVERWRITE 1E FF 2F E1 03 00 50 E3 01 00 00 1A 1C 00 9F E5
OVERWRITE 01 00 00 EA 18 20 9F E5 00 06 82 E0 00 10 80 E5
OVERWRITE 1E FF 2F E1 14 00 04 E0 14 00 41 E0 40 6D E1 01
OVERWRITE 00 00 04 E0 00 00 41 E0

REM call above with R0=2 from 01E14848 in boot

OVERWRITE 08 40 2D E9 00 10 A0 E1 02 00 A0 E3 E1 FF FF EB
OVERWRITE 08 40 BD E8 00 00 A0 E3 1E FF 2F E1

REM Add to below to go from Thumb code to ARM
OVERWRITE 78 47 C0 46

REM use above 01E14848 to loop writing n bytes, from 1E14890 in boot
REM R1 with number of bytes, R0 points to buffer

OVERWRITE 38 40 2D E9 01 40 A0 E1 00 50 A0 E1 01 00 D5 E4
OVERWRITE F2 FF FF EB 01 40 44 E2 00 00 54 E3 FA FF FF 1A
OVERWRITE 38 40 BD E8 00 00 A0 E3 1E FF 2F E1

REM 495A48 Hex_Dump
ADR $254648

OVERWRITE FF B5 0B 4D 00 24 AE 23 DB 03 E0 02 80 21 A0 22
OVERWRITE C0 18 09 01 D2 01 FF F7 91 FF 01 34 c0 46 c8 20
OVERWRITE 36 F6 2A FC AC 42 EE D1 FF BC 08 BC 18 47 00 00
OVERWRITE 01 04 00 00


REM below are to system info OSD to add red button to do RAM dump

ADR $0
FIND F0 B5 91 B0 04 1C 0D 1C 00 26 28 68 00 28 38 D1
FIND 20 D0
OVERWRITE 25
FIND 2F D1
OVERWRITE 1c
FIND FE 21 0E 48 10 30
OVERWRITE D7 28 10 D1 C0 46 F5 F1 8B FA

Assuming that there is clear area at end of 2nd mpg image. You will see that I changed the way the XVI32 script finds the sys info OSD routine, but the code put in is the same save for the values used in the call to the image area at the end. Up in the image area the code is the same but for the call to task_time_sleep and the absolute addresses used to locate the code in the area. Oh, and I change the start addr for the dump to 0x570000 with 0xae in the hexdump code too.

[DualTest]

Okay I finally have some time to do this again. I am going to run the script above on the modded 081111, with just the radio background changed. I will post the file down in the advanced section if anyone else wants to trying running the script on the file in xvi32.

[skywalker999]

well i have bad news on my end my pany is stuck on b 07 i have tried so many times to boot from the usb stick with just the API_FILE.bin and no luck so testing for me right know is on the back burner i even tried the pansat 250sm GTrom loader it gives me error ini2 guess i have see if i can find a cheep one on ebay and then do a clone :doh:

[DualTest]

well i have bad news on my end my pany is stuck on b 07 i have tried so many times to boot from the usb stick with just the API_FILE.bin and no luck so testing for me right know is on the back burner i even tried the pansat 250sm GTrom loader it gives me error ini2 guess i have see if i can find a cheep one on ebay and then do a clone :doh:

I have killed this receiver so many times I have lost count. USB with the API.bin in the main folder (meaning not in folder). And when it says hold the volume up button > softly do just that. The first time it took me a few times. But I will say this receiver is the most forgiving receiver to work on and a perfect one to learn on. Don't give up it is savable.

[DualTest]

I ran this script on the file modded with only the radio background changed.



REM 081111 9296 BL file
REM find the 263A74 ; "ECM --> Start" routine and replace null sub call
REM with a call to 2B0AC0 ; debug message

ADR $0
FIND F9 37 2A 00 10 B5 12 48 86 F0 42 FA 14 21 11 48
FIND 86 F0 42 FA
OVERWRITE 4D F0 22 F8

REM find the sys info null sub call @2A052E and replace w call to debug message
FIND 20 1C C2 F7 83 FF 13 E0 FE 21 0E 48 10 30 49 F0 E7 FC
FIND 49 F0 E7 FC
OVERWRITE 10 F0 C7 FA

REM find 2EEF6C ; "[get_ecm_pid]ECM Pid = 0x%x" and change null sub call
REM to call debug message
FIND 07 21 09 02 40 18 04 89 21 1C 04 48 FA F7 C0 FF
FIND FA F7 C0 FF
OVERWRITE C1 F7 A0 FD


And got this result in RealTerm

[SystemInfo_Control 254] ENTER/EXIT_Key pressed

ECM --> Start

[get_ecm_pid]ECM Pid = 0x0

[jvvh5897]

YES!! That means that the debug message serial routine is giving output and that the code is processing ecms, so they are going to be in RAM dump somewhere.

Don't see them though. I see the RealTerm strings in the RX buffer and a little bit of output in the TX buffer. Maybe a mod to dump the stack and capture the registers somewhere in the ecm processing path will give us a clue of where they hide.

[skywalker999]

Dualtest finally fixed the b 07 error the way it worked for me instead of pressing volume strait up i pressed between volume up and forward at first i got failed message then i changes memory stick and this time right away i got the API on the front display and thats how it worked for me
and as for your scrip it is giving me the same result that you posted and i tested with pansat-rq-sssp client and it still not getting the requests from the receiver well it's close but no cigar

[DualTest]

Dualtest finally fixed the b 07 error the way it worked for me instead of pressing volume strait up i pressed between volume up and forward at first i got failed message then i changes memory stick and this time right away i got the API on the front display and thats how it worked for me
and as for your scrip it is giving me the same result that you posted and i tested with pansat-rq-sssp client and it still not getting the requests from the receiver well it's close but no cigar

We aren't even close to having a working IKS file. We are only trying to get the information out of the receiver that may eventually lead to a working file at the moment.

I am glad you got your receiver working. And figured out how to run the script. A little (very little) of what I figured about hex, is the way addresses are laid out. It starts with an address of 0, the next would be 1,2,3 up to 9. Then it changes to letters A through F. Then it goes 10, 11, 12 up to 19 then it is 1A, 1B etc to 1F, then 20 and so on. If you look at the first line it starts at 0 and the next line starts at the address 26. And if you count it out like I explained above you should see what I mean.

[jvvh5897]

"next line starts at the address 26."--if you are talking about the addresses displayed by XVI32, then that is adjustable in the options. I set mine up to display 16 bytes per line so that each line starts with an "even" hexadecimal number: 0x10, 0x20, 0x30....

[DualTest]

"next line starts at the address 26."--if you are talking about the addresses displayed by XVI32, then that is adjustable in the options. I set mine up to display 16 bytes per line so that each line starts with an "even" hexadecimal number: 0x10, 0x20, 0x30....

That does make it little easier to get around.

[jvvh5897]

Looking at the decryption chain in the 081111 file and having refreshed my memory of how pansat code decrypts in 2700 code, the following seems to be copying the ecm packet from one location to another:


ROM:00340252 LDRB R0, [R5,#2] --if packet has 80 30 8f 07 8d at start than this would get the 0x8f size info
ROM:00340254 ADD R2, R0, #3 --number of bytes
ROM:00340256 ADD R1, R5, #0 --start addr of packet =0x7F3EEE
ROM:00340258 LDR R0, =0x7F41EE --destination addr
ROM:0034025A BL sub_2422C8 ; rt_memcpy

So, I'm guessing that if the code get to that part of the chain, you should see the packets at both 0x7F3EEE and 0x7F41EE in a RAM dump. Since the 2 meg dump only gets to 570000 +200000 = 770000 it would seem that another meg byte or so of RAM contents in a dump should get there.

[DualTest]

I just went ahead and did a 4 meg capture. I figured it might come in handy later on.

I have been trying to figure out IDA. I have a copy of IDA Pro. I know that the processor is ARM. It is the other settings that I am not sure about.

From a previous post. I see "installed to ROM @0x241400" and "and end of file @00573218".

Under ROM
Create ROM section is checked off
ROM starting address 0x241400? or is this the base address 0xf0000000
ROM size ? Not sure

Under Input file
Loading address 0x241400? or is this the base address 0xf0000000
File Offset ? Not sure
Loading size ? Not sure

[jvvh5897]

Yes, you put in 0x241400 in both the ROM addrs and the loading addr if you are working with the main software. You don't have to fill in anything in the size spots--IDA will fill it in for you.

The processor is ARM (actually ARM9TDmi-- the ARM setting is ARM7 and works just fine) and mixed Thumb and ARM code. What that means is that some of the code is 32 bit ARM code and some is 16 bit Thumb mode ARM code.

To disassemble the code requires lots of playing if you don't use an IDC to help out but you can do it. You have to learn how to spot Thumb code and ARM code and manually go through the file for hours and hours (days) changing the mode setting with alt-G and entering 1 for Thumb and 0 for ARM then starting off disassembly at the new spot. SO, needless to say I would recommend using an IDC. A basic IDC only has to search out odd addresses in the code section of the file and go there and start disassembly--it seems calls to Thumb mode code from ARM have to be to odd addresses (least significant bit == 1) and that will give you a half-way good disassembly--maybe 90% of the code.

Here is such an IDC search with a few other bells and whistles:



#include "IDC.IDC"

static main(void)
{
auto StartAddr, EndAddr;
StartAddr=0x241400;
//find the ISA string as start of data section
EndAddr = FindBinary(StartAddr,SEARCH_DOWN,"20 49 53 41 20")-38;

//EndAddr=AskLong (EndAddr,"is this right?");

find_util(StartAddr,EndAddr);

find_odd_addr(StartAddr+0x800,EndAddr-0x1000);
find_bx_pc(StartAddr,EndAddr);
find_push(StartAddr,EndAddr);
MakeStrings(StartAddr,EndAddr);
//Use_string_table(StartAddr,EndAddr);
}


static find_odd_addr(StartAddr,EndAddr)
{
auto temp1, temp2;

temp1=StartAddr;
SetReg(temp1,"T",1);
while(temp1<EndAddr)
{
temp2 = Dword(temp1);
if((temp2>StartAddr)&&(temp2<EndAddr)&&((temp2%2)==1))
{
MakeCode(temp2-1);
Wait();
}
temp1=temp1+4;
} //end of while

}

static find_push(StartAddr,EndAddr)
{
auto j,temp1, temp2;
j=1;
temp1=StartAddr;
SetReg(temp1,"T",1);
while(temp1<EndAddr)
{
temp2 = (Word(temp1))&0xfc00;
if((temp1>StartAddr)&&(temp1<EndAddr)&&(temp2==0xb400))
{
MakeCode(temp1);
//MakeRptCmt(temp1,ltoa(j,10));
j++;
Wait();
}
temp1=temp1+4;
} //end of while

}

static find_bx_pc(StartAddr,EndAddr)
{
auto temp1, temp2;

temp1=StartAddr;

while(temp1<EndAddr)
{
temp2 = Word(temp1);
if(temp2==0x4778)
{
SetReg(temp1,"T",1);
MakeCode(temp1);
Wait();
}
temp1=temp1+4;
} //end of while

}

static find_util(StartAddr,EndAddr)
{
auto temp1, temp2;

temp1=StartAddr;
temp2=FindBinary(StartAddr,SEARCH_DOWN,"10 B4 04 2A 0E D3 03 1C");
if(temp2!=BADADDR){MakeRptCmt(temp2, "memcmp");}
temp2=FindBinary(StartAddr,SEARCH_DOWN,"78 47 00 00 00 20 A0 E3 04 00 51 E3");
if(temp2!=BADADDR){MakeRptCmt(temp2, "rt_memclr");}
if(temp2!=BADADDR){MakeRptCmt(temp2+4, "rt_memclr");}
temp2=FindBinary(StartAddr,SEARCH_DOWN,"78 47 00 00 03 00 52 E3 3E 00 00 9A");
if(temp2!=BADADDR){MakeRptCmt(temp2, "rt_memcpy");}
if(temp2!=BADADDR){MakeRptCmt(temp2+4, "rt_memcpy");}
temp2=FindBinary(StartAddr,SEARCH_DOWN,"78 47 00 00 01 30 40 E0 02 00 53 E1");
if(temp2!=BADADDR){MakeRptCmt(temp2, "rt_memmove");}
if(temp2!=BADADDR){MakeRptCmt(temp2+4, "rt_memmove");}
temp2=FindBinary(StartAddr,SEARCH_DOWN,"78 47 00 00 FF 30 01 E2 02 10 A0 E1");
if(temp2!=BADADDR){MakeRptCmt(temp2, "rt_memset");}
if(temp2!=BADADDR){MakeRptCmt(temp2+4, "rt_memset");}
temp2=FindBinary(StartAddr,SEARCH_DOWN,"0F B4 30 B5 91 B0");
if(temp2!=BADADDR){MakeRptCmt(temp2, "sprintf");}
temp2=FindBinary(StartAddr,SEARCH_DOWN,"03 78 02 1C 00 2B");
if(temp2!=BADADDR){MakeRptCmt(temp2, "strcat");}

temp2=FindBinary(StartAddr,SEARCH_DOWN,"78 47 00 00 03 00 10 E3 03 00 11 03");
if(temp2!=BADADDR){MakeRptCmt(temp2, "strcmp");}
if(temp2!=BADADDR){MakeRptCmt(temp2+4, "strcmp");}
temp2=FindBinary(StartAddr,SEARCH_DOWN,"02 1C 03 1C 0B 43");
if(temp2!=BADADDR){MakeRptCmt(temp2, "strcpy");}

/*
temp2=FindBinary(StartAddr,SEARCH_DOWN,"");
if(temp2!=BADADDR){MakeRptCmt(temp2, "");}
*/

}

//next two borrowed from procst20.idc
static isPrint(c)
{
return ((c >= ' ' && c < 0x7F) || c == 0x0a || c == 0x09);
}


static MakeStrings(StartAddr,EndAddr)
{
auto ea, endea, startea;

Message("Searching for strings...\n");
SetLongPrm(INF_STRTYPE, ASCSTR_TERMCHR);

ea = EndAddr;
endea = MaxEA();;
while (ea < endea && ea != BADADDR) {
ea = FindUnexplored(ea, SEARCH_DOWN);

// data aligned on 32bit boundary
if ((ea & 3) == 0) {
if (isPrint(Byte(ea))) {
startea = ea;
while (ea != BADADDR && isPrint(Byte(ea)))
ea++;
if (Byte(ea) == 0x0 && ea - startea > 4)
MakeStr(startea, ea + 1);
}
}
}
Message("Finished searching for strings.\n");
}


static Use_string_table(StartAddr,EndAddr)
{
auto ea, endea, temp1, pointer, temp2;

Message("Searching for strings...\n");
SetLongPrm(INF_STRTYPE, ASCSTR_TERMCHR);

ea = 0x53C51C; //0x596F1C;
endea = 0x53EB68; //0x599598;
while (ea < endea && ea != BADADDR) {
temp2 = Dword(ea);
temp1=temp2;
while (temp1 != BADADDR && isPrint(Byte(temp1)))
temp1++;
if (Byte(temp1) == 0x0 )
{MakeStr(temp2, temp1+1);
add_dref(ea,temp2,dr_T );
}
ea=ea+4;
}
Message("Finished searching for strings.\n");
}

[DualTest]

I keep getting an error when running that as a script file in IDA Pro, Max depth of includes is 32.

[jvvh5897]

Never seen that--don't know what it means. You might try to simplify the IDC--comment out calls in main (like the one that calls to use a string table is commented out).

[DualTest]

I found out what it was, the file name was too long. I shortened it and the includes error is gone. Now I get a brace error but I will figure that out.

[DualTest]

Just to check in to say I am still trying to wrap my head around IDA and disassembly. I have been doing a lot of reading, and less of it seems like Greek now. But still a long way to go. If there is anything I can do to move this project along in the meantime though, I am open to suggestions.

[DualTest]

I Finally!!! managed to run most of that script and managed to disassemble about 60% of the 81119 file. I was getting brace errors on these two lines:

31 if((temp2>StartAddr)&&(temp2<EndAddr)&&((temp2%2)= =1))

50 if((temp1>StartAddr)&&(temp1<EndAddr)&&(temp2==0xb 400))

So I commented them out.

[jvvh5897]

With any line commented out the whole routine is compromised. I'll attach the idc as a txt file in advanced section. The IDC for ARM has been posted in other sections too BTW--sv, cw, coolsat5000, CNX, viewsat all have conexant processor boxes that use ARM and have had projects that involved disassembly.

As for the project, none of the RAM dumps have had ecm packets in them. Not sure if that is due to not having the box on long enough on a particular channel , or the wrong channel or not the right spot in RAM or keycode not on or just that the code does not like the newer ecm packets. None of the dumps have had ALL the RAM, and I'm not sure I want to look at ALL the 128 megabytes of RAM as that is something you guys can do--it is not hard to dump RAM now and all you have to do is search for the hex sequences of 8f 07 8d and a2 07 a0 as pointed out earlier, if they have 80 30 or 81 30 in front of the sequence then you have found DN ecm packets , 8e 30 or 8f 30 and you have 3ev ecm packets. There should be the provID of 0101 or 0901 close by too. Old file or the femu is tester's choice.

There could be code mods to the ecm routines to see where they might show execution reaching them, but from what I can tell from the code, if there is no ecm in the RAM dumps that I've seen then the code to handle ecms wasn't running very far--all the code shows addresses that should have packets in the range of RAM within 8 megabytes of the end of the file ( EOF 0x580000 roughly). I did see one addr in the RAM that might suggest ecm packets really high in RAM--let's see 128 M should be 0x8000000 and I think the addr I saw was 1a00000 or so--not that sure at the moment. With the playing I did on old pansat code there were two tasks that handled ecms, the regular ecm decode path and the si filter or "EM Smart" task, even with keycode off the second still had ecms passing through. The mods I suggested a while ago that spit out ECM Start and ecm pid strings were the equivalent of the second I think so that routine is doing something and might be a place to look for ecms but they are not as obvious in code as seeing a packet in RAM and figuring out where the code that put it there is.

[jvvh5897]

And don't forget that you can try for the N2 radio channels on 97 degree sat, I'm pretty sure that the 081111 file can get the N2 radio chs if you put in the right keys. The ecm packets for them are 67 07 65 sequence and the correct keys are posted in the thread:
http://www.satfix.net/showthread.php?144353-EMU-for-starchoice&p=1012948#post1012948
If you go to N3 channels on the TV side of 97 degrees, the sequence to look for is same as DN.

[skywalker999]

jvvh5897 and dualtest i need some help do we run all this script with xvi32script


REM 081111 9296 BL file
REM find the 263A74 ; "ECM --> Start" routine and replace null sub call
REM with a call to 2B0AC0 ; debug message

ADR $0
FIND F9 37 2A 00 10 B5 12 48 86 F0 42 FA 14 21 11 48
FIND 86 F0 42 FA
OVERWRITE 4D F0 22 F8

REM find the sys info null sub call @2A052E and replace w call to debug message
FIND 20 1C C2 F7 83 FF 13 E0 FE 21 0E 48 10 30 49 F0 E7 FC
FIND 49 F0 E7 FC
OVERWRITE 10 F0 C7 FA

REM find 2EEF6C ; "[get_ecm_pid]ECM Pid = 0x%x" and change null sub call
REM to call debug message
FIND 07 21 09 02 40 18 04 89 21 1C 04 48 FA F7 C0 FF
FIND FA F7 C0 FF
OVERWRITE C1 F7 A0 FD


or just this part

ADR $0
FIND F9 37 2A 00 10 B5 12 48 86 F0 42 FA 14 21 11 48
FIND 86 F0 42 FA
OVERWRITE 4D F0 22 F8

FIND 20 1C C2 F7 83 FF 13 E0 FE 21 0E 48 10 30 49 F0 E7 FC
FIND 49 F0 E7 FC
OVERWRITE 10 F0 C7 FA

FIND 07 21 09 02 40 18 04 89 21 1C 04 48 FA F7 C0 FF
FIND FA F7 C0 FF
OVERWRITE C1 F7 A0 FD

Next what are the settings on realterm for the ram dump
and is the ram dump done true the serial port on the back or the usb in front

PS it's confirmed the bin 081111_9296 does work on the GC radio stations with that key

[DualTest]

Run this entire script on the unpacked 81111 file with the radio background mod in xvi32:

REM write a byte to serial port lifted from 01E0D31C in 2nd part of MBOOT 7
REM call with R0 = 2 for the right uart port
REM R1 = byte to write
REM Little endian ARM code


ADR $254500
REM $495900
OVERWRITE 03 00 50 E3 01 00 00 1A 44 C0 9F E5 01 00 00 EA
OVERWRITE 40 20 9F E5 00 C6 82 E0 00 20 9C E5 20 00 12 E3
OVERWRITE FC FF FF 0A 1C 00 12 E3 01 00 00 0A 00 00 A0 E1
OVERWRITE 1E FF 2F E1 03 00 50 E3 01 00 00 1A 1C 00 9F E5
OVERWRITE 01 00 00 EA 18 20 9F E5 00 06 82 E0 00 10 80 E5
OVERWRITE 1E FF 2F E1 14 00 04 E0 14 00 41 E0 40 6D E1 01
OVERWRITE 00 00 04 E0 00 00 41 E0

REM call above with R0=2 from 01E14848 in boot

OVERWRITE 08 40 2D E9 00 10 A0 E1 02 00 A0 E3 E1 FF FF EB
OVERWRITE 08 40 BD E8 00 00 A0 E3 1E FF 2F E1

REM Add to below to go from Thumb code to ARM
OVERWRITE 78 47 C0 46

REM use above 01E14848 to loop writing n bytes, from 1E14890 in boot
REM R1 with number of bytes, R0 points to buffer

OVERWRITE 38 40 2D E9 01 40 A0 E1 00 50 A0 E1 01 00 D5 E4
OVERWRITE F2 FF FF EB 01 40 44 E2 00 00 54 E3 FA FF FF 1A
OVERWRITE 38 40 BD E8 00 00 A0 E3 1E FF 2F E1

REM 495A48 Hex_Dump
ADR $254648

OVERWRITE FF B5 0B 4D 00 24 AE 23 DB 03 E0 02 80 21 A0 22
OVERWRITE C0 18 09 01 D2 01 FF F7 91 FF 01 34 c0 46 c8 20
OVERWRITE 36 F6 2A FC AC 42 EE D1 FF BC 08 BC 18 47 00 00
OVERWRITE 01 04 00 00


REM below are to system info OSD to add red button to do RAM dump

ADR $0
FIND F0 B5 91 B0 04 1C 0D 1C 00 26 28 68 00 28 38 D1
FIND 20 D0
OVERWRITE 25
FIND 2F D1
OVERWRITE 1c
FIND FE 21 0E 48 10 30
OVERWRITE D7 28 10 D1 C0 46 F5 F1 8B FA

Realterm the setup is explained earlier in the thread but it is:

change the baud to 115200 (and change the port if you need to)
then click change
then I go to the capture tab and uncheck direct capture
Then I switch over the receiver and put it in the system information screen
Then back to realterm and the capture tab and click start overwrite
And finally hit the red mode button on the remote

It is done by the serial port

[DualTest]

I do not have access to 97W in my location if someone else would like to try what jvvh suggested.

[skywalker999]

dualtest i have access to 97w and tested the 81111 bin on the globcast radio stations and can confirm that it works with the keys provided on another tread

[DualTest]

dualtest i have access to 97w and tested the 81111 bin on the globcast radio stations and can confirm that it works with the keys provided on another tread


And don't forget that you can try for the N2 radio channels on 97 degree sat, I'm pretty sure that the 081111 file can get the N2 radio chs if you put in the right keys. The ecm packets for them are 67 07 65 sequence and the correct keys are posted in the thread:
http://www.satfix.net/showthread.php?144353-EMU-for-starchoice&p=1012948#post1012948
If you go to N3 channels on the TV side of 97 degrees, the sequence to look for is same as DN.

So try the ram dump while sitting on one of those stations. I am not sure if it is necessary to let it sit on the channel for 15 mins before starting but can't hurt.

[skywalker999]

dualtest what are the settings to get 4 mg or 128meg dump
do i stay on the radio station or one of the ng channels

[DualTest]

dualtest what are the settings to get 4 mg or 128meg dump
do i stay on the radio station or one of the ng channels


OVERWRITE 01 04 00 00 line to something like 01 08 to increase the size of the dump to 4M.

If you look at the script the last line under Hex Dump has the size. The script as posted earlier is the 2 meg one and shouldn't take too long to dump. I would try both.

[skywalker999]

well i found this sequence of keys on the capture dump on one of the radio stations 3 0r 4 times has posted by jvvh The ecm packets for them are 67 07 65 sequence

[DualTest]

well i found this sequence of keys on the capture dump on one of the radio stations 3 0r 4 times has posted by jvvh The ecm packets for them are 67 07 65 sequence

There is a thread down in the advanced section with other captures for the 9200HD, post the capture there.

[skywalker999]

will do that asap

[jvvh5897]

You could try a similar dump while on one of the N3 GC TV channels too and see if you get the N3 packets in the same spots as you got the N2 radio channel's. I've seen the 8f 07 8d sequences on GC with the box's I have but haven't spotted the a2 07 a0--can't say that I was looking though as I don't do IKS (I was looking at something else).

[skywalker999]

ok guys just aded a new 8mgb capture of 97W parked on tv polonia channel i din't find 8f 07 8d but found a2 07 a0

[jvvh5897]

Well, just like the earlier atempts to find the N3 ecm packets in the RAM the new 8 M dump doesn't get it. The only hit I get on a2 07 a0 is not an ecm packet. There is some info on the provider in the same spot as found (and expected from the code) in the GC radio dump, but that is it. Again, I suggest that a FULL dump of RAM be made and you should search for the cmd07 packets in it. You might want to do a FULL 128 mega byte dump of the box running GC radio channel to see where in it the circular buffer for cmd07 packets is located in it. Then do a full dump with TV N3 channel on and look in the same area for the circular buffer. Box code almost always has a circular buffer as the first place it puts packets of each types and then the packets are pulled from circular buffer into a linear buffer for further processing, all I have seen in GC dump is the linear buffer.

[skywalker999]

jvvh and dualtest what are the changes to get the full 128 mgb dump

OVERWRITE 01 04 00 00

[DualTest]

hxxp://www.statman.info/conversions/hexadecimal.html

Will convert to hex. 128 converts to 80 but I found that ended before the end of ram. Try

01 87 00 00

[skywalker999]

tanks will try that

[jvvh5897]

You should also change the starting address re:
http://www.satfix.net/showthread.php?141441-Any-interest-in-sw-modding&p=1008968#post1008968
Then check that the main software starts at 0x241400. Maybe leave the number of times it goes around the loop the same as for 8 Meg dump, but change the starting address a number of times. The value 0xb0 is shifted left 0xb to get 0x580000 as I recall--to get 8 meg shift in address might mean more than a little change in code...hum, might be more of a pain than I thought. Make the 0xb0 smaller and shift it more would work--load 0x58 and shift 0xc would do it, then for 8 meg at a time....no then youy could not easily shift a bunch of times....um, maybe 0xe shifts with starting value of 0x16. Hum, maybe I should just write a new C source for it and compile it.

BTW, I have been playing with old coolsat4000 file that does get GC radio ecm packets but no N3 packets and looking for why that is--it seems to be something that might explain why the pansat 9200 does not seem to be getting them either. Seems to be something about how the coolsat code sets up the slots (think of a mailbox system--the slots are for particular type of packets and route them into memory directly). To get the coolsat code to set up slot correctly I think you have to change the 1801 CAid that it uses---not sure about that though even with source code to look at.

[skywalker999]

yes jvvh i also think it would be best if post the the script with the right changes tanks
but i did run the mode that dualtest posted had to cancel the dump 62 mgb it was to late @ 1 AM had get up at 5.30 am to go to work
but will try again today and see what the results will be maybe we should start thinking of moving to another file

[DualTest]

This is the Hex Dump portion of the script.



REM 495A48 Hex_Dump
ADR $254648

OVERWRITE FF B5 0B 4D 00 24 AE 23 DB 03 E0 02 80 21 A0 22
OVERWRITE C0 18 09 01 D2 01 FF F7 91 FF 01 34 c0 46 c8 20
OVERWRITE 36 F6 2A FC AC 42 EE D1 FF BC 08 BC 18 47 00 00
OVERWRITE 01 04 00 00


And as jvvh said



Oh, and I change the start addr for the dump to 0x570000 with 0xae in the hexdump code too.




You should also see the hexdump code is largely the same as before too--it still calls for 0x800 bytes to be dumped at a time for 0x401 loops and 0x200000 bytes total--you can change the number of loops it takes if you like.


So I assume AE is the start of the dump. 04 is the amount of loops of 200000 bytes. So if we want to change the starting point and size of the dump, those are the only two things we need to worry about. I have already mentioned changing the 04 to 87 to get all of ram. And as jvvh suggested we should try different starting points. AE is what we need to change to get a different starting point.



ROM:004A714E MOVL R3, 0x580000


You can just change it in the script or unpacked file in the xvi32. The spot in the unpacked file can be found by subtracting the ROM address and 214400 as pointed out earlier in this thread. 4A714E-214400=292D4E.

Now what to change it to is where we are at. I have some time on my hands today so going to play around a little with it. And yes it does take a long time to dump the 128megs.

[jvvh5897]

Well, the solution was not that hard, I changed the code directly to load a value from the end of the routine and then shift left enough to make it easy to get to 8 mega bytes or whatever address to start with that you want.


REM 495A48 Hex_Dump
ADR $254648

OVERWRITE FF B5 0B 4D 00 24 0B 4B 1B 03 E0 02 80 21 A0 22
OVERWRITE C0 18 09 01 D2 01 FF F7 91 FF 01 34 c0 46 c8 20
OVERWRITE 36 F6 2A FC AC 42 EE D1 FF BC 08 BC 18 47 00 00
OVERWRITE 01 04 00 00 00 08 00 00

REM ROM:00495A4E LDR R3, =0x800
REM ROM:00495A50 LSL R3, R3, #0xC
REM use 01 10 00 00 for 8 M per and 00 08 00 00 at the end sets starting addr

The machine code to load 0xb0 to R3 and then shift left 0xf times is not the LDR r3, from the 00000800 value at the end of the routine and then shift left 0xc times to get to 0x800000 in the above example. And in the remarks I have the value to use to do 8 megabytes per loop of the above (0x1001 is the compare value used in place of 0x400 for 8 meg and 2 meg respectively).

[skywalker999]

sorry to keep you guys waiting now for some odd reason realterm or the pany stops dumping i still haven't bean able to get the full 128mgb ram dump the best i got was 69mgb maybe i'm doing something wrong
maybe if it's possible if one of you guys could upload the 81111 bin with all the modes already done this way i could test it and see if i get the full ram dump :noidea: but i'm gone keep on trying no time to quit know

[jvvh5897]

I would not try to dump the full RAM in one go, dump 8 or 10 Meg at a go.

BTW, how fast does the download go? If full 115 K baud then you should get 10k bytes per second or so. But the code has a delay in there--calling task_sleep because that is what the code in the box seemed to use. If that sleep time is not needed or can be reduced then the dump would go faster. You could test changing the c8 20 to 64 20 in the task time sleep call at the end of the line:

OVERWRITE C0 18 09 01 D2 01 FF F7 91 FF 01 34 c0 46 c8 20

[skywalker999]

I'm having trouble uploading the ram dump at 3.8 mgbyts times five i don't know if there's a limit per file on the forum
but so far i don't see anything different so i'm going to try the 8 or 10 mgb dump till i get to 128
jvvh and dualtest i tried to mode HD_9200BL_pvr_080721_9277 and i can't find the hex string [FIND FE 21 0E 48 10 30 ]

ADR $0
FIND F0 B5 91 B0 04 1C 0D 1C 00 26 28 68 00 28 38 D1
FIND 20 D0
OVERWRITE 25
FIND 2F D1
OVERWRITE 1c
FIND FE 21 0E 48 10 30
OVERWRITE D7 28 10 D1 C0 46 F5 F1 8B FA

[DualTest]

I think there is a four attachment limit per post. I don't know much about the 080721 file, haven't looked at it. But why are you doing it by hand? Copy the entire script from the post here. Paste it to notepad and save it with a .xsc extension. Then open the unpacked file in xvi32 and go to the XVIscript/editor from the menu then load and execute the script from there.

[skywalker999]

Dualtest that's exactly what i'm doing i have no problems with file 081111
but i tried loading that script on that file 080721 just to see if what would happen and the only error i'm getting is that one
maybe we should start to mode another file to see if we get different results

tanks for the heads up for the file limit upload but i'm getting upload failure it starts to upload and then it stops maybe the forum is to busy or firefox on my laptop is acting up again

[DualTest]

Not having seen that file I would assume that the code for the remote buttons is in a different place or coded differently.

[skywalker999]

tanks for the quick reply and how do you find the codes for buttons on the bin

[jvvh5897]

The way I do it is by doing a disassembly of the file, then look for the same code that I've seen on previous disassemblies.

The script you are trying to insert is for the system info OSD. There are specific text messages in that routine and that is the first thing I look for--the string says something like "Enter or exit key pressed" (think I posted part of the string in earlier posts). Once I find that part of the code I look around to be sure I'm in the same routine and then I go to the start to see if the same code will work. Odds are that they have never made a change to the code in that routine, but just because the code does not change does not mean that the machine code generated stays the same. The code has relative jumps and calls that will change.

The code will have a pointer to the string used at the end of the routine (or somewhere within the range of the indexing system they use) so if you can find the string, then you can compute the address of the string as far as the code sees it (just add 0x241400 to the location in the file), then do a search for that address (reverse the byte order)--that should find the sys info OSD routine. I would still disassemble it to see how to mod it and to be sure I had the right spot.

Oh, and why bother to post the files of the dump? Lots and lots of those posted already. Just search the dump for the suggested sequence of bytes and if you do find them, then you might want to post a part of the dump, but you have a dump that has GC N2 radio ecm packets so you know what they look like, if the GC dump does not have very similar packets, then you know that that part of a dump is not really of interest for IKS mod needs. If you do find the packets then if a similar dump of the box with the N3 channel selected gives packets, then you know you have a spot of interest.

No need to keep coming to me, or having me look at RAM dumps, you should have a good idea of what is needed at this point. You guys should be asking about WinARM and how to compile your own code by now, or making machine code mods on your own, doing disassemblies on your own.

[skywalker999]

jvvh and Dualtest i have a question, is it important if we use a strait db rs232 or null rs232 modem cable

[skywalker999]

now i have another question how to change the file size of the moded bin to he same size as the original bin
the original size of the bin is 1,307 kb and the moded one is 1,259 kb

[DualTest]

jvvh and Dualtest i have a question, is it important if we use a strait db rs232 or null rs232 modem cable

You would use a null cable, and you obviously are or you wouldn't get anything on the capture. The file size, I am not too sure about but having looked at the original file and the modded radio background file I see that everything is in it's proper place so it shouldn't matter.

[jvvh5897]

The file gets compress before you can load it into the box. The compressed size is put into the header. The loader and the box reads off that header and its checksum to determine whether it is OK to load. Now the size of the file BEFORE compression needs to be the same size as you started with--everything in the uncompressed file is position dependent.

[skywalker999]

ok guys so far there is no good new for bin 81111 i still have not seen the ecm packs 8f 07 8d not even on gc
i have been trying bin BL 081123 and so far i have not been able to find packs 8f 07 8d but ecm packs a2 07 a0 are there but there is no 80 30 or 81 30 nor 01 01 nearby and provider id 01 01 always has 80 30 or 81 30 very close by
and another thing jvvh tanks for the hexv_mpg program it does work has intended to change the radio background pic :thumbsup: and the bin file size even if it's smaller after repacking it still loads fine on to the receiver dualtest was right about that one :noidea: why
i'm going to try bin BL_081123 again sometime today and then move to bin BL_081124 after that i'm going move to the femu ones i keep crossing my fingers and hope that the next file will be the one that gets what we need
PS: is there a particular channel on 97 gc that is nvision3 all of them say only nvision and i only see one that says n3 and i don't think it's GC channel i it' called fight box

[jvvh5897]

I'm sure the porn channels are N3, but I usually just use the channel right next to Ebru on the same TP. or hook up a dish and point it at 110 degrees.

I've been exploring the code some more and I think I see the problem--not 100% sure though. There are two places where you get a hit on 10 18 00 34 12 00 00 sequence, one is in the ecm decode path and one is in the filter builder path--they seem to look for the CAid 1800 and 1810 and decide if the filter should run or not. I think they are not looking at the right place in the packet, or are getting 1840 (or something not 1800 or 1810) and causing the ecm filter to shut down. Maybe a quick check would be to change both 10 18 00 00 sequences to 40 18 00 00, but I think there needs to be a small code change to look in the right spot in the packet too.

[skywalker999]

today i did another ram dump of 130 mgbyts file 081123 same result everything is there except 8f 07 8d got the same results as the earlier post instead i'm finding 8f 07 9b that's on dn 110 ch105 usa and 01 01 3 or 4 lines up or down
and the red button script is acting different on this bin even if you change the script to get a ram dump of 2, 4, or 8 mgbyts it wont stop it keeps dumping the ram until i stop it myself
maybe tomorrow i'm going to try bin 081124 after this one it's the femu ones:redcomp:

here is a pict
20220

[skywalker999]

ok today i fund out that the 81111 red button script doesn't work on bin 081124 when i press the red button on the system info screen
it lock's up the receiver and nothing info comes out the serial port so i'm stuck cant test that bin
now are we working on a script fix for 81111 bin :noidea::thumbsup:

[jvvh5897]

Well, is that a surprise? I've pointed out that the code uses task_time_sleep and the code is position dependent--that means you have to MODIFY the code for the file. I did not make it position independent and have never indicated that it could be used in ANY file other than the one it was built for. If you would like to try to make a file mod that is position independent have at it.

The mods to make the code work on another file are small. You have to find the task_time_sleep routine and figure out the call for it or eliminate the call to it . You have to figure out the call from the sys info OSD code into the image area. There are better ways to do the code than I did it for relocatable use, but I figured it was pretty much a one-off--an exercise for the reader to mod for another file. Do the homework.

[skywalker999]

jvvh and dualtest today i did a small change to the 81111 bin i changed the two strings 10 18 00 00 on the bin for the 40 18 00 00
and did a 20 mgbyts ram dump on globcast channel tv polonia i still can't find the 8f 07 8d but this time the string 80 30 a2 07 a0 and 81 30 a2 07 a0 is there at list ten times if you guys think that it's wort uploading just ask and here is a pic

20239

[jvvh5897]

The a5 sized packets should do the job. Now, you have to check to see where it might be good to mod the ecm decrypt routine(s). I'm guessing that you see the a2 07 a0 sequence at the locations pointed out for the "gc run" part of the decryption? I posted two addresses that should have copies of the last received ecm a while ago, if you check those locations and find them, then I could put together a mod you could try.

[jvvh5897]

It would be interesting to see if changing the code from 1810 to 1815 or 1816 for the two NA prov might give different results.

But, assuming the code does get to the memcpy point noted earlier:


ROM:00340252 LDRB R0, [R5,#2] --if packet has 80 30 8f 07 8d
ROM:00340254 ADD R2, R0, #3 --number of bytes
ROM:00340256 ADD R1, R5, #0 --start addr of packet =0x7F3EEE
ROM:00340258 LDR R0, =0x7F41EE --destination addr
ROM:0034025A BL sub_2422C8 ; rt_memcpy

search term: C2 1C 29 1C 88 48 02 F7 35 F8

Then we can change that to call into the 2nd image area--lets try 495400/254000 which is about 0x500 bytes earlier than that RAM dump code 495900.

First thing to do is mod the call to memcpy to 495900 and in the code we add call to memcpy to replace the call we take over, then make up the all ascii string with the ecm packet using the size and location info from the memcpy call--something like:

void hex_A( char* Dest, char* pData, unsigned int uCnt)
{
char* pHexA=0x4954c0;
unsigned int i,temp;
memcy( Dest, pData, uCnt);
for (i = 0; i < uCnt; ++i)
{

temp=((pData[i]&0xf0)>>4)+0x30;
pHexA[i*2]=temp;
if(temp>0x39) pHexA[i*2]=temp+7;
temp=(pData[i]&0xf)+0x30;
pHexA[i*2+1]=temp;
if(temp>0x39) pHexA[i*2+1]=temp+7;
}
pHexA[(uCnt+1)*2]=0;
s_port("SSSP|ECM|00000001|00|%04X|%04X|%04X|%s\n",*(short *)0x747C12,*(short *)0x747C1e,*(short *)0x78CA4e,pHexA);
}

where I've set up the parameters passed to hex_A to match those used by memcpy. memcy is is a dummy routine as is s_port--I replace the calls to the dummy routines with calls to the real memcpy and debug message routines manually after I compile the hex_A code with WinARM.

Taking the results of the compile and doing a little modifying to get things right I end up with the following mod for 081111:


REM to output a serial rq-sssp string from 081111 bl file
REM $495400
ADR $254000

OVERWRITE F0 B5 15 1C 81 B0 0C 1C AC F5 5E FF 00 2D 19 D0
OVERWRITE 19 49 00 20 0F 26 03 5D 1A 09 13 1C 30 33 0B 70
OVERWRITE 39 2B 01 D9 07 33 0B 70 03 5D 1A 1C 32 40 13 1C
OVERWRITE 30 33 4B 70 39 2B 01 D9 07 33 4B 70 01 30 02 31
OVERWRITE 85 42 E8 D1 0D 4A 6B 00 9B 18 00 22 1A 70 0C 4B
OVERWRITE 19 88 0C 33 1A 88 0B 4B 1B 88 07 4C 09 04 12 04
OVERWRITE 1B 04 09 48 09 14 12 14 1B 14 00 94 1B F6 28 FB
OVERWRITE 01 B0 F0 BC 01 BC 00 47 C0 54 49 00 C2 54 49 00
OVERWRITE 12 7C 74 00 4E CA 78 00 8C 54 49 00 53 53 53 50
OVERWRITE 7C 45 43 4D 7C 30 30 30 30 30 30 30 31 7C 30 30
OVERWRITE 7C 25 30 34 58 7C 25 30 34 58 7C 25 30 34 58 7C
OVERWRITE 25 73 0A 00

REM mod the 34025A BL sub_2422C8 ; rt_memcpy call to call the above

ADR $0
FIND C2 1C 29 1C 88 48 02 F7 35 F8
FIND 02 F7 35 F8
OVERWRITE 55 F1 D1 F8


With any luck, if the code gets to the code location it will output the required sssp string to the serial port. Cross fingers for sure though.

If things do go well with it, it is important to see if it sends out the packet every 15 seconds or so, or if it sends out the packet every time a cmd07 packet comes in and that might be very very often. Either would be ok--if we need to add a mem compare step that is not hard to do, and we could check to see if there was anything waiting in the rx queue at that point, or if just every 15 sec or so, then we mod somewhere else to check rx queue for returned CW packet from rq-sssp client.

[skywalker999]

jvvh i'm a bit confused about the 1810 do you want to find and overwrite the strings 18 10 00 00 to 18 15 00 00 or to 18 16 00 00
i found tree spots with the 18 10 00 00 string and they are around tree quarts down at the end of the 81111 bin anyway i'm going to run that script and see what happens

[skywalker999]

:thumbsup:ok never mind i changed the tree spots where the 18100000 and changed for the 18 15 00 00 that worked the 8030 and 81 30 a2 07 a0 but no 8f 07 8d i uploaded the 8mgbyt ram dump it's on the advance section check it out
and now for the script it's not sending nothing out the serial port am i suppose to do a ram dump with the 81111 with that script or just wait and see if it's asking or sending info

at least we are moving forward very slowly but moving :thumbsup:

[DualTest]

I think it was this string that had to be changed.


jvvh and dualtest today i did a small change to the 81111 bin i changed the two strings 10 18 00 00 on the bin for the 40 18 00 00 and did a 20 mgbyts ram dump on globcast channel tv polonia i still can't find the 8f 07 8d but this time the string 80 30 a2 07 a0 and 81 30 a2 07 a0 is there at list ten times if you guys think that it's wort uploading just ask and here is a pic

I changed it to 16 18 00 00, ran the script, and tested it on the south provider and nothing came out of the serial port with realterm. I will give it another go tomorrow.

[skywalker999]

dualtest the strings for the nort and south providers they are not on the same spot, the globcast ones they are at the start of the bin and nort and south are the end of the bin do this Find 18 10 00 00 you will find them 3 times and change them to overwrite 18 15 00 00, just in case, the first one is at adr 10B818 the second is @ ADR 23AD80 and the third one is @ ADR 2572FC

and the globcast ones are 10 18 00 00 at ADR 526A0 and ADR 114A08
change them to 40 18 00 00 just go to edit overwrite string and put in the new strings :yes::thumbsup:

[jvvh5897]

So, if nothing is coming out the serial port where the mod was put in place that tells me that the code does not get that far, because we know the debug message call should give output (that was tested with the ECM Start mod done a while ago and when channel change was done serial port had output that had to come from the debug message routine). There is an earlier point where ecm packets get a mem compare step, could try a mod there.

I'll take a look at the latest dump post and see what I see.

[DualTest]

Like this?

REM to output a serial rq-sssp string from 081111 bl file
REM $495400
ADR $254000

OVERWRITE F0 B5 15 1C 81 B0 0C 1C AC F5 5E FF 00 2D 19 D0
OVERWRITE 19 49 00 20 0F 26 03 5D 1A 09 13 1C 30 33 0B 70
OVERWRITE 39 2B 01 D9 07 33 0B 70 03 5D 1A 1C 32 40 13 1C
OVERWRITE 30 33 4B 70 39 2B 01 D9 07 33 4B 70 01 30 02 31
OVERWRITE 85 42 E8 D1 0D 4A 6B 00 9B 18 00 22 1A 70 0C 4B
OVERWRITE 19 88 0C 33 1A 88 0B 4B 1B 88 07 4C 09 04 12 04
OVERWRITE 1B 04 09 48 09 14 12 14 1B 14 00 94 1B F6 28 FB
OVERWRITE 01 B0 F0 BC 01 BC 00 47 C0 54 49 00 C2 54 49 00
OVERWRITE 12 7C 74 00 4E CA 78 00 8C 54 49 00 53 53 53 50
OVERWRITE 7C 45 43 4D 7C 30 30 30 30 30 30 30 31 7C 30 30
OVERWRITE 7C 25 30 34 58 7C 25 30 34 58 7C 25 30 34 58 7C
OVERWRITE 25 73 0A 00

REM mod the 33FD04 BL sub_2422C8 ; rt_memcpy call to call the above

ADR $0
FIND 09 90 EF 4C 2C 22 EF 49 F0 48
FIND 02 F7 E0 FA
OVERWRITE 55 F1 D1 F8

[jvvh5897]

At the start of 00282A44 "mem compare and do N2 decryp" there is a mem compare that test 0x14 bytes copied form the last different ecm packet and if the same jumps to exit the routine and if not it tries to process the new packet--that would be a good point to mod I think rather than try some other memcpy routine since it gets called very often it give one a chance to test for a return packet from the rq-sssp client program.

Here is something to try to see if you can get the SSSP output from the box as it is with that last posted mod from me.



REM 3 mods to force the 081111 code to get to the ecm decode routine
REM 1st changes a prov test MOVL R3, 0x1800 to bypass a conditional branch and take a always-branch as needed
ADR $0
FIND 03 23 DB 02 98 42 1C D1
FIND 1C D1
OVERWRITE 98 42

REM 2nd test changes a prov test LDR R0, =0x1801 to bypass the following branch
ADR $0
FIND 43 48 87 42 06 D1 3F 48
FIND 06 D1
OVERWRITE 87 42

REM 3rd mod makes a provider test always branch
REM 282AA0 CMP R4, #1 becomes CMP R4,R4
FIND 01 2C 1A D0 21 48 84 42
OVERWRITE A4 42

In the last dump posted in the advanced section I see some good things and something bad too. First the bad--the channel info does not seem to have the channel number and VPid in the same spot as previous posted dumps for the 081111 file. The number and pids are close to the same spots but not exactly the same, don't know why that is but something that will either have to be worked around or some other fixed spot to get the data found.

The dump has ecm packets in three areas. The last area has cmd07 packets mixed with with lots of other packet types, it seems to be one big circular buffer for the section code to work with (section as in disection--with slots and filters it cuts up the stream to parse it into different routines as needed). The first area is two copies of the ecm packet 0x100 bytes apart--that seems to be the location the section sends the packets for slot use. In the middle is where the ecm decrypt code has a packet--just one copy as the decrypt code does not get very far before the CAId tests (that I'm trying to work around with the above mod) forces an exit.

[DualTest]

So I have tried the above script with jvvh's script in post 140, no other changes. I tried the same but changed the 3 occurances of 00 08 10 00 to 00 08 15 00 00. I tried it the same way with the post 140 script modded to change the memcmp @ROM:00282A50, with and without the above script and with and without the CAID changes. I have then moved it to ROM:002512C2 and did the same tests and I am still getting nothing coming out of the serial port.

[jvvh5897]

Well, not sure if you have the CaID right in your post--you might have it right in code of course, but you should be looking for
10 18 00 34 12 00 00 sequence and changing the 10 18 at the start to 40 18 not 00 08 15 00 00 or whatever you seem to be trying.

[skywalker999]

jvvh this string 10 18 00 34 12 00 00 is not fund anywhere on the 81111 bin :noidea::no: me to i'm getting confused

i did find something different between bin 81111 and the femu bin 090607 the one posted on the earlier posts at start up when i reboot the receiver with femu bin with the red button script done and the 18 10 00 00 strings changed realterm shows more info then the 81111 bin here is an example

this is the femu at reboot

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
bAudioDelayReceived/bVideoDelayReceived/dramdelay = 1/1/1

and the 81111 bin only shows this at reboot

Trace output port opened

DEMOD:BASEBAND: internal_demod_baseband_hw_init
MODULE_SERIAL_FAILURE
MODULE_SERIAL_FAILURE
MODULE_SERIAL_FAILURE
Sata init CMD Rx..
8. delay_count = 200
sata init faile..

[DualTest]

jvvh this string 10 18 00 34 12 00 00 is not fund anywhere on the 81111 bin :noidea::no: me to i'm getting confused

i did find something different between bin 81111 and the femu bin 090607 the one posted on the earlier posts at start up when i reboot the receiver with femu bin with the red button script done and the 18 10 00 00 strings changed realterm shows more info then the 81111 bin here is an example

this is the femu at reboot

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
bAudioDelayReceived/bVideoDelayReceived/dramdelay = 1/1/1

and the 81111 bin only shows this at reboot

Trace output port opened

DEMOD:BASEBAND: internal_demod_baseband_hw_init
MODULE_SERIAL_FAILURE
MODULE_SERIAL_FAILURE
MODULE_SERIAL_FAILURE
Sata init CMD Rx..
8. delay_count = 200
sata init faile..

It's actually 10 18 00 00 34 12 00 00.

[DualTest]

Good news and bad news here is the capture after changing the two instances of 10 18 00 00 34 12 00 00 to 40 18 00 00 34 12 00 00. Then running this script:



REM to output a serial rq-sssp string from 081111 bl file
REM $495400
ADR $254000

OVERWRITE F0 B5 15 1C 81 B0 0C 1C AC F5 5E FF 00 2D 19 D0
OVERWRITE 19 49 00 20 0F 26 03 5D 1A 09 13 1C 30 33 0B 70
OVERWRITE 39 2B 01 D9 07 33 0B 70 03 5D 1A 1C 32 40 13 1C
OVERWRITE 30 33 4B 70 39 2B 01 D9 07 33 4B 70 01 30 02 31
OVERWRITE 85 42 E8 D1 0D 4A 6B 00 9B 18 00 22 1A 70 0C 4B
OVERWRITE 19 88 0C 33 1A 88 0B 4B 1B 88 07 4C 09 04 12 04
OVERWRITE 1B 04 09 48 09 14 12 14 1B 14 00 94 1B F6 28 FB
OVERWRITE 01 B0 F0 BC 01 BC 00 47 C0 54 49 00 C2 54 49 00
OVERWRITE 12 7C 74 00 4E CA 78 00 8C 54 49 00 53 53 53 50
OVERWRITE 7C 45 43 4D 7C 30 30 30 30 30 30 30 31 7C 30 30
OVERWRITE 7C 25 30 34 58 7C 25 30 34 58 7C 25 30 34 58 7C
OVERWRITE 25 73 0A 00

REM mod the 34025A BL sub_2422C8 ; rt_memcpy call to call the above

ADR $0
FIND C2 1C 29 1C 88 48 02 F7 35 F8
FIND 02 F7 35 F8
OVERWRITE 55 F1 D1 F8


Then this script:



REM 3 mods to force the 081111 code to get to the ecm decode routine
REM 1st changes a prov test MOVL R3, 0x1800 to bypass a conditional branch and take a always-branch as needed
ADR $0
FIND 03 23 DB 02 98 42 1C D1
FIND 1C D1
OVERWRITE 98 42

REM 2nd test changes a prov test LDR R0, =0x1801 to bypass the following branch
ADR $0
FIND 43 48 87 42 06 D1 3F 48
FIND 06 D1
OVERWRITE 87 42

REM 3rd mod makes a provider test always branch
REM 282AA0 CMP R4, #1 becomes CMP R4,R4
FIND 01 2C 1A D0 21 48 84 42
OVERWRITE A4 42


I get this capture:
MODULE_SERIAL_FAILURE
MODULE_SERIAL_FAILURE
MODULE_SERIAL_FAILURE
Sata init CMD Rx..
8. delay_count = 200
sata init faile..
SSSP|ECM|0000000CCodeldr(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 CA FF 12 19 20 09 02 24 33 13 1E AA 18 A5
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

MODULE_SERIAL_FAILURE
MODULE_SERIAL_FAILURE
MODULE_SERIAL_FAILURE
Sata init CMD Rx..
8. delay_count = 200
sata init faile..
SSSP|ECM|0000000CCodeldr(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 CA FF 12 19 20 09 02 24 33 13 1E AA 18 A5
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

MODULE_SERIAL_FAILURE
MODULE_SERIAL_FAILURE
MODULE_SERIAL_FAILURE
Sata init CMD Rx..
8. delay_count = 200
sata init faile..
SSSP|ECM|00000001|00|0072|1A22|0000|8030A207A00115 9600884810BA0AE3DBA4A7AE23F49AC523D1DB8829F4494A8A 84FE339D1A3118709B64E37BD94A2A75A595B9D07B47C276DF 24780FA3753FF1C7280587BA6596D32E7F7E19032AC4C83648 EE7BC082B55093E8616E164C55C6B47779FD6FC2E3736220E0 681FEC0AE8FD2C4EF839E7AF149D6CBF20E4C39D1A09DAE49C D59539D16D59E640E51262586C51D55E529CC6E84B74BD18F1 CFE8674DF24D18F3ÿÿ
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 CA FF 12 19 20 09 02 24 33 13 1E AA 18 A5
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

MODULE_SERIAL_FAILURE
MODULE_SERIAL_FAILURE
MODULE_SERIAL_FAILURE
Sata init CMD Rx..
8. delay_count = 200
sata init faile..
SSSP|ECM|0000000CCodeldr(370) : Start Check Button
USB_Init(474)
(1352)USB_HOST_MODE:0x0

The bad news is that it goes into a boot loop.

[DualTest]

Just out of curiousity I did the 2 CAID changes (correctly this time) and just ran the "rq-sssp string from 081111 bl file" mod. And nothing comes out of the serial port. And no boot loop.

[skywalker999]

dualtest dose two strings are for globcast know i now wy i couldn't find them

[skywalker999]

dualtest you are correct receiver goes into a boot loop only if your on the south provider i tested on 97 globcast and receiver does not go into a boot loop but has soon i change to the south provider it goes into that boot loop
and this is done on bin 81111 with just the radio pic mode, not with the red button script mode

[jvvh5897]

Well, why don't you confirm what the file gets with a RAM dump after doing the 1840 mod and running a south provider? As I pointed out earlier, I was of the opinion that the code would need more of a mod than just the 18 40 put in place of the 1810, but skywalker999 indicated that it got him ecm packets so I figured "what the heck do I know"

[jvvh5897]

For instance do the 1840 mod and then the three CaID mod (the combo of those seems to be getting you ecm packets with either GC or NA prov) but leave off the hexA sssp string mod and do a RAM dump--do you get the section, slot and multiple copies of cmd07 in the ecm decrypt area--do you get the reboot issue? If no reboot then the issue is in the hexA code, so try a defeat of the call to debug message in that code or just remove the %s from near the end of the sssp string (it could be an issue with the length of the message so removing the %s should remove the ecm packet from it and make it very short).

The debug message call is at the end of the hexA code and around the middle of the whole thing: 1B F6 28 FB should be it--maybe replace it with two CMP R4,R4 (A4 42 as seen in the 3 CaID mod).

If you still get the reboot issue, then I could look at the rest of the hexA code, but it doesn't look bad to me. You guys could disassemble it and see what you think--the calls look to be to correct addresses, the return at the end uses R0 rather than the R3 that you see in the code generated by the compiler used for your code, but I don't think that is an issue (lots of file's routines use the call_via_R0 routine and they seem to work just fine). Not much more to the code--the hexA code itself was compiled in a slightly different form for the pansat 2700 IKS mods so it should take the ecm packet and make it ascii OK and then there is the memcpy call--if your RAM dump with the call to debug message defeated shows no reboot and memcpy is called then that would be OK.

That is the sort of testing I would go through anyway.

[DualTest]

All of the following have 10 18 00 00 34 12 00 00 to 40 18 00 00 34 12 00 00 chages. Running the Hex_A script does not cause a reboot. Or running the 3 Caid mod by itself. Caid and Hex_A mods with 1B F6 28 FB change to A4 42 A4 42 does not cause a reboot.

Now as far as removing the %s from near the end of the sssp string. Would that involved WinARM? And will WinARM work with windows 7? Or can I just edit the script?

I will do some looking around and reading in the meantime. I won't have alot of time to play with this over the next couple of days.

Found the answer to will WinARM work in Win7. Yes

[jvvh5897]

The examples of WinARM has a "blinky" as one of its first examples I just use it for all my work. I do have a few changes for it though--to the makefile mainly to get a bin output in place of hex, and to have a disassembled copy of the code as lss file. But to remove the %s does not take a comple, you just go into the modded file and replace %s with two other ascii char like "||" or "00" so that the routine does not see a special set of char that means to look for stuff to tack on the output.

I think I see the problem in the method--there seems to be a limit to how long a string you can create with vsprintf--0x100 (256 decimal) bytes and to output all of the sssp string you need 340 char or so. There might be a quick solution by increasing the buffer area:


REM Bump up the buffer size from 0x100 to 0x1FC -- it uses the stack
FIND 70 B5 C0 B0 05 1C 0E 1C
FIND C0 B0
OVERWRITE FF B0
FIND F6 E7 20 1C 40 B0 70 BC
FIND 40 B0
OVERWRITE 7F B0

[DualTest]

The fisrt two come in pretty fast. As soon as it hits the channel, the second one a few seconds after. The rest were about 15 seconds apart.

---------------------------------
STB has no USB Device !!
---------------------------------
Flash Header: 55 66 3A FF 12 19 20 09 02 24 33 13 1E AA 18 A6
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 vaializing OS vaarting OS initialization...
******
Trace output port opened
MODULE_SERIAL_FAILURE
MODULE_SERIAL_FAILURE
MODULE_SERIAL_FAILURE

Sata init CMD Rx..
8. delay_count = 200
sata init faile..

SSSP|ECM|00000001|00|0072|1A22|0000|8030A207A00113 860008339CC98697E504CC482E8E96
AE47199A9CB124344A130FCFB498DF422BF5214A1CB307F391 8D1F14A0D466E4C9803344F98D1D35
FC23EE1D4C2247A308FD957098721AEAF3D57EB741CD9E627D 535701AD6AA083A01A352E818C9A67
05778ADFEE5DF4341B81ED12EB3ED32EB9B40AC3051C182AD5 6AE857D978AA2FD5554665D7DA0839
B7660B4369A34453DFB5383830FFF9EFD8F7F0F2EB23BFÿÿ

SSSP|ECM|00000001|00|0072|1A22|0000|8130A207A00113 9600082BB7041733166DD9285F4423
E4582E8D42B4986C5D8AB785E85123D136D3DC44C173DE0BBA A1676A474A6BE9A710575774F1EAAB
3FB12F78AC2DD9536B5748054CA0C56E9ABA0979963F5B8743 683E5755F03856624DA337EAF67188
7B4CA9BA8D8031310A7189D0DC69B30D7B86B49B6079C45B39 B0B19A6DCBFF708F527783C4BEF9FE
EFB5E3C67E70839549C85846BCBAF81A56954B28C0C3A2ÿÿ

SSSP|ECM|00000001|00|0072|1A22|0000|8030A207A00114 860008D7D1C424E0F43DE706EC9B4A
D7541568F6A716086433FBA84933921B33FC235AEC1F8AA9CE 671B6B1B3331C86AE603900813ED9B
4DF1F3FD6CFE187EE2D632BF354F19E64B4E933973780F74F6 B7CA50D535990FD87371A01EC52355
0691742426207BCD59A6A2A42B79A5BC104C9FFA46DA523200 8129402EB3D5A1A2EB10C8921A051F
6813211F9994D3E178837905C2F8D9404D083721BEF163ÿÿ

SSSP|ECM|00000001|00|0072|1A22|0000|8130A207A00107 8600885B5490CEFC769B5A1EBAF120
D85D37942C688BBC0AE4E749287C78A398EA0E79D1DA4A3303 9A6972866EBE166BD773539EB36B8C
0FE7AE156064D8967AA3DB37FAC7614DA92B63A70BA4417CC2 82058A0642765F8C79DB467C6242DA
7E76DB459BF616A51F1B1F71F04F4295526D7C69431FF47B9F 962C82F28ED45EBF00C2FB6F4BBEDF
FBBC8FA20A5543F1A15FCD13D88BD24028B181D6D254B8ÿÿ

Thanks jvvh.

I guess I should do a dump of that. I see the caid is missing.

[jvvh5897]

I was hoping that the quick fix would work--the vsprintf had to be doing more than 0x100 bytes to overwrite part of the stack to give the reboot, so bumping up the space it had to work with seemed like it would work, but you never know.

So, it got the ch #, Vpid but not the CaID and the end of the ecm string looks wrong too--so, all in all not bad for the first result!!!
Well, could hard code the CaID--actually you could do that with a mod to the string much like the replacement of %s with something else, you could put..oh, wait there would be the wrong number of parameters in the registers. Well, I will think about the above and see what might be off with it. Should also think about how to do the check of the RX buffer too and the save of the CWs you get back--should the RX buffer check be done in a routine of its own, or move the sssp send to that memcompare spot mentioned a while ago? The way the CW save works seems really easy, hard to believe that that is all it takes, just a call to a routine with the addr of the 0x10 bytes from the rq-sssp client should do it I think.

Hum, you should change channels to see if the ch # and Vpid track with the change and how quick you get the new packet with the info.

[DualTest]

Everything looks similar to the capture before. And the new packet comes as soon as the channel is changed and then about every 15 seconds.

SSSP|ECM|00000001|00|0074|1822|0000|8030A207A0010C 96000885351BAEE8C4055C379E43CA
3A1656041E5077D613C1CF1E6C8F266507BD9E4E0BAA22BC6F C82C8CE0E552CFF31AEC68DDEF4E41
0B2E88BCEE2FA48AFEC182DDDF5B7F278B7A550706867A6BA7 23E553B629BB196C5639EA4B264793
40ED50F50142BDBEB9171CB07670CD5D88445C32034AADD1DF D76A14DEDDC5CD1624E97F587E7DE0
4F5F5E5FBFCBA2DC8FD65B4FE4B3FFB9764906348170ADÿÿ

[skywalker999]

i have been testing the new mode and it looks promising can't wait for the next script or fix so dualtest we went back to the 1B F6 28 FB and not the A4 42 hum but good testing anyway, but from what i see when i change channel video audio pid also change

[jvvh5897]

OK, I think I was off on the CAid location, try 0x78CA4C--you can change it near the end of the hex_A routine in reversed byte order look for 0x78CA4E--Oh, and that might get you 0x1840 as ID which is not what I think you need, you have to find a spot with 1816 or 1816 depending on the prov. And I think there is a small error in where the 0x00 gets put at the end of the ascii form of the ecm packet--try changing the 0x4954C2 to 0x4954C1 right near the above change at the end of routine.

For the next step I'm going to leave it to you guys to compile and get the save of return packet working, it should be a lot like the hex_A code. If you just put the code at that memcmp mentioned earlier you could try something like:


#define RXQUEUESIZE 2048

int read_rx( char* Dest, char* pData, unsigned int uCnt)
{
char* my_buf=0x4953c0;
int my_index=0;
char* rxQueue=0x57D1C8;
int rxQueueFree=*(int*)0x57D9CC;
int rxOutdex=*(int*)0x57D9D8;
int rxIndex=*(int*)0x57D9DC;
int result;
unsigned int i,temp;
result=memcy( Dest, pData, uCnt); //result will be 0 if same
if((result==0)&&(rxIndex != rxOutdex))
{
while(my_index<26)
{
while(rxIndex != rxOutdex)
{
my_buf[my_index] = rxQueue[rxOutdex++];
rxOutdex &= (RXQUEUESIZE -1);
rxQueueFree++;
my_index++;
}
if(my_index<26) waitTx(0x10);
}

if(my_buf[0]==0xa5) save_CW(0x10,my_buf+0x9);
}

return result;
}


Since the return packet always starts with 0xa5 and is a constant length you just need to check if there is something in the rxqueue buffer and copy it off to a buffer of your own--my_buf in the above and with the check to see if rxIndex != rxOutdex. If all of the return packet is not there yet, call waitTX to do task_time_sleep till it is all there and copy as needed. At the end you need to point save_CW at the CW part of the returned packet and let it know there are 0x10 bytes (it could be that the CWs are not in the same order as the decrypt code in the file put them, but odds are 50% that they are and you can always copy them out with memcpy to another spot).

I have checked that the above code compiles, but did not check that the code made sense--I'll look closer later. I will post the full blinky.c and some notes on how I mod WinARM makefile for the ADuC7026_blink winarm example down in advanced section.

[jvvh5897]

Another way to tackle the problem of getting the returned packet out of the rx queue would be to use something like coolsat 5000's UART_Read:

int UART_Read(unsigned char* pBuf, unsigned int uSize, unsigned int uTimeoutInterChar)
{
unsigned int uTime, uIdx;

for (uIdx = 0; uIdx < uSize; ++uIdx)
{
// Wait for information to come into the fifo
for (uTime = 0; rxIndex == rxOutdex; uTime += 10)
{
if (uTimeoutInterChar)
{
if (uTime >= uTimeoutInterChar) return 1;
}

task_time_sleep(10);
}

*pBuf++ = rxQueue[rxOutdex++];
rxOutdex &= (RXQUEUESIZE -1);
rxQueueFree++;
}

return 0;
}


You would use something like the read_rx routine to do the memcmp and test that something is waiting to be received, but I don't think you should be sitting around in the modded memcmp step for the ecm packet to come in. Normally you would have a task just to do the serial receive and it could be looping around waiting for a packet, but in the nagra ecm decrypt code you should just look to see if something was there and if not then exit. So, you might end up with a routine that tests for something in the rx queue, calls UART_Read with a timeout of a few millisec and then if the first byte is 0xa5, and the length is OK, calls save_CW.

[jvvh5897]

Well, I gave up on getting the previous posted code to work--just could not get the casts to do what was needed. So, I stole the UART_Read routine from old coolsat5000 code and made a few changes for the 081111 file. Here is that:

UART_Read from cs5k modded for pansat:
REM put this code at 4953A0
ADR $253FA0
REM 24 F0 8C F9 is the call to task_time_sleep @0x20
REM change to call 2CC2C0 w 36 F6 7E FF
OVERWRITE F7 B5 07 1C 15 1C 00 26 1F E0 00 24 0B E0 00 2D
OVERWRITE 05 D0 AC 42 03 D3 01 20 FE BC 08 BC 18 47 0A 20
OVERWRITE 36 F6 7E FF 0A 34 0B 4A 50 6C 11 6C 88 42 EE D0
OVERWRITE 10 6C 09 4B 41 1C 18 5C 38 70 01 37 48 05 40 0D
OVERWRITE 10 64 50 6B 01 30 50 63 01 36 01 98 86 42 DC D3
OVERWRITE 00 20 E1 E7 98 D9 57 00 C8 D1 57 00

And then I rewrote the previous post to use UART_Read as posted above:
int read_rx( char* Dest, char* pData, unsigned int uCnt)
{
static char my_buf[32];
int nError;

unsigned int rxOutdex=0x57D9D8;
unsigned int rxIndex=0x57D9DC;
int result;
unsigned int temp;

result=memcy( Dest, pData, uCnt); //result will be 0 if same
if((result==0)&&(*(unsigned int*)rxIndex != *(unsigned int*)rxOutdex))
{
nError=UART_Read((unsigned char*)&my_buf,29,1);

if((my_buf[0]==0xa5)&&(nError==0)) save_CW(0x10,my_buf+0x9);
}

return result;
}

Which when compiled and edited a little gave me:

REM put this code at 495300
ADR $253F00
OVERWRITE 30 B5 AC F5 09 FE 05 1C 00 28 10 D1 0D 4B 1A 68
OVERWRITE 04 3B 1B 68 9A 42 0A D0 0B 4C 1D 21 20 1C 01 22
OVERWRITE 01 F6 98 FD 23 78 A5 2B 01 D1 00 28 03 D0 28 1C
OVERWRITE 30 BC 02 BC 08 47 21 1C 09 31 10 20 01 F6 85 FD
OVERWRITE F5 E7 00 00 DC D9 57 00 60 53 49 00

Now all you need it to write the mod to call into 495300 from the memcmp at 282A50.

To test the above you could put the following bytes into a file and use RealTerm to send it to the box:
A5 17 00 30 C3 C2 C1 C0 E0 01 02 03 04 05 06 07 08 11 12 13 14 15 16 17 18 A5

With any luck it will show up at the buffer location you see at the end of last bit of code : 60 53 49 00 that is in the 2nd image area 0x495360 in between the above two code segments and you should see traces of it in the RX Queue as well.

Now the above code to call UART_Read is not very good--it might work but it could be lots better. Say call UART_Read for 1 byte and check that it is 0xa5 and if so read 2 bytes to get the number of bytes that follow in the packet and then call to read only that number of bytes. The call to read 29....hum, I bet that is wrong, I count only 26 (26 == 0x1a so 29 would be 0x1d) maybe you should change 1D 21 on the second line to 1a 21...would likely be not working well if there is any glitch in the RX serial line. And that timeout of only 1 millisec in the call to UART_Read might be too little, you might want to play with that (01 22 not far from the 1d value to change)--you could try 0x0a in place of the 0x01 in that command.

[DualTest]

I will give that a try and post the results tomorrow. WinARM is slowing me right down. I think I have done something wrong in my setup. It is going to take me awhile to wrap my head around this. In the meantime. I am going try to do the caid changes. If we end up with 1840 as the caid, couldn't this line be added to the sssp client 1840=1816?

[jvvh5897]

Sure but then it would send that same ID for GC, 3ev and DN so those with multiple dish setups would have to play around as they switched things. Might as well hard code the box to send one or the other. Or setup one of the menus to change the ID with a remote button press and popup a message on which is active.

[skywalker999]

i don't think it would make any difference since the GC is 4018 and not 1840 hum but just to be sure i'm going to try the 1840 on the south provider and see what happens
PS= jvvh do we use the last two scripts or just the last one posted on #166

this one

Which when compiled and edited a little gave me:

REM put this code at 495300
ADR $253F00
OVERWRITE 30 B5 AC F5 09 FE 05 1C 00 28 10 D1 0D 4B 1A 68
OVERWRITE 04 3B 1B 68 9A 42 0A D0 0B 4C 1D 21 20 1C 01 22
OVERWRITE 01 F6 98 FD 23 78 A5 2B 01 D1 00 28 03 D0 28 1C
OVERWRITE 30 BC 02 BC 08 47 21 1C 09 31 10 20 01 F6 85 FD
OVERWRITE F5 E7 00 00 DC D9 57 00 60 53 49 00

anyway i changed the two first caid strings to 40 18 and the other tree to 18 40 and i'm still getting the ecm packets
and i'm doing a ram dump right know and will check for the caid is it 0101 just to make sure

[DualTest]

Just to update where I am:


OK, I think I was off on the CAid location, try 0x78CA4C--you can change it near the end of the hex_A routine in reversed byte order look for 0x78CA4E--Oh, and that might get you 0x1840 as ID which is not what I think you need, you have to find a spot with 1816 or 1816 depending on the prov. And I think there is a small error in where the 0x00 gets put at the end of the ascii form of the ecm packet--try changing the 0x4954C2 to 0x4954C1 right near the above change at the end of routine.

I understand a little bit more about WinARM now, but the compiled results are not right. For instance if I open ADuC7026_blink project in pn.exe, with the changes mentioned in the advanced section. Then paste the Hex_A routine in the editor box, then run Make All. I open blinky.hex and what is there is nothing like what you ended up with. I know you also edited it but I don't think it is even close to what you are getting. blinky.lss is empty.

So to make those 2 changes I need to be able to compile the changes correctly. But so far I am not having any luck. I will keep at it though.

[jvvh5897]

You don't need to recompile anything, just make the changes to the posted script. The values to change are near the end of the posted script in reverse byte order.

Kind of hard to tell what you might be doing wrong with WinARM from just what you are saying, I'm guessing that the error messages tell you that the compile and link process did not finish if .lss file is empty. Rather than start with a make of hex_A, type in "make" to compile the blinky that came with the example and see if you get a complete compile and link of that--see what output you get, fix makefile is needed to get binary rather than hex file output, make sure you eliminate the include of startup code (it just makes it harder to find the code you are making and getting it editied out as a routine).
Oh, and make sure that you have used "set path" to tell the cmd window that it needs to have the winarm\bin folders in the path. I use a bat file to set these using:

set PATH=c:\winnt;c:\winnt\bin;c:\winarm\bin;c:\winarm \utils\bin

------------------------------------------------------------------------------------------

skywalker999: you use both of the scripts, 1st one is called by the second as pointed out in the post. You will need to add one more mod to it as you have to call the second part of the script from the code of the file--you have to overwrite the memcmp call as mentioned in the post. I'm trying to walk that fine line between giving you guys enough info to get IKS running without giving the prov's rope to hang me by trying to stay within the bounds of free speech and not actually giving you complete code.

[DualTest]

The provider ID is still missing but everything else looks good.

[skywalker999]

i fund why the caid is missing or not on the right place i looked at the pany 3500sd iks bin and apparently the caids are wrong the 1815 caid is for the north provider and 1816 is for the south that's what the readme file says anyway so i'm going to give it a try change the caids to 1816 and do a ram dump and see if there's any difference
just a small update just for testing purposes jvvh look what i fund just by changing the two 40 18 00 00 strings to 1618 and left the other ones at 1816

SSSP|ECM|00000001|00|0069|1022|0000
80308F078D0106860008CC2C6AE0E8210AB3180C5743FB5E61 C0A35CC146E9269B9A3628677A92F5A04C9D6D21980C996A1B 91A9E28CD2A51E33BC8D8DB42616A44873DA5514AB7DD99002 FF64CF19ABDC9A36F477065F18CB85C29684219858D042E932 47F4A62B1A4109E7221F419907A0A622A6790E3CD91F7EAFD6 0CE065D9B8AFC37E04956418A0F566EFB27FA4463Bÿÿ

[DualTest]

i fund why the caid is missing or not on the right place i looked at the pany 3500sd iks bin and apparently the caids are wrong the 1815 caid is for the north provider and 1816 is for the south that's what the readme file says anyway so i'm going to give it a try change the caids to 1816 and do a ram dump and see if there's any difference
just a small update just for testing purposes jvvh look what i fund just by changing the two 40 18 00 00 strings to 1618 and left the other ones at 1816

SSSP|ECM|00000001|00|0069|1022|0000
80308F078D0106860008CC2C6AE0E8210AB3180C5743FB5E61 C0A35CC146E9269B9A3628677A92F5A04C9D6D21980C996A1B 91A9E28CD2A51E33BC8D8DB42616A44873DA5514AB7DD99002 FF64CF19ABDC9A36F477065F18CB85C29684219858D042E932 47F4A62B1A4109E7221F419907A0A622A6790E3CD91F7EAFD6 0CE065D9B8AFC37E04956418A0F566EFB27FA4463Bÿÿ

From post #59



And the box has to send out a packet that looks like:
SSSP|ECM|%08X|%02X|%04X|%04X|%04X|%s\n
the %s at the end is the ecm packet in the clear in ascii hex form.
The %08x and %02x are constants as far as we know and it works OK with some thing like SSSP|ECM|00000001|00|1816|0079|1022|80308F078D...5 C.
The three %04x are for CAid, Vpid and channel number that you are watching as prov numbers it.


So is essentially the same as what I post, the channel number and vpid, because the caid is missing they are shifted over one spot. We need to find where the 18 16 (in this case) is hiding in the ram dump.

[jvvh5897]

From what I could tell from the GC dump, there is a group of bytes near where you see the ecm decrypt cmd 07 packets that is looked at for the filter match--don't think I have anything with me to post to give you an example, but in the GC dump it had 18 40, 18 04 and I seem to remember 09 04 or something like that. Anyway you can find the address to look for that in the routines near that 10 18 00 34 12 00 00 match. As near as I could tell, the CA ID has to be in that sequence of bytes for the filter to match it. The addr is not far from the addr used in the sssp send routine to try to get that 18 40.

Ah! I checked in my notes and did find that I'd copied that area of RAM:
21C5E0 00 00 00 09 04 18 02 F5-63 09 04 18 02 F5 63 09
21C5F0 04 18 40 E1 39 09 04 18-16 E0 39 09 04 18 40 E1
21C600 39 09 04 18 16 E0 39 00-00 00 00 00 00 00 00 00

The code that checks it is:


ROM:00293606 LDR R0, =0x78C43A
ROM:00293608 ADD R0, R0, R6
ROM:0029360A ADD R0, #0xFF
ROM:0029360C ADD R0, #0xA1 --78C5DA
ROM:0029360E LDRB R0, [R0,#0xA] --78C5E4
ROM:00293610 LSL R0, R0, #8
ROM:00293612 LDR R1, =0x78C43A
ROM:00293614 ADD R1, R1, R6
ROM:00293616 ADD R1, #0xFF
ROM:00293618 ADD R1, #0xA1 --0x78C43A + 0x1a0
ROM:0029361A LDRB R1, [R1,#0xB]
ROM:0029361C ORR R1, R0
ROM:0029361E STR R1, [SP,#0x80+var_74]
ROM:00293620 MOVL R0, 0xFF00
ROM:00293624 LDR R1, [SP,#0x80+var_74]
ROM:00293626 AND R1, R0
ROM:00293628 STR R1, [SP,#0x80+var_6C]
ROM:0029362A LDR R1, [SP,#0x80+var_6C]
ROM:0029362C MOVL R3, 0xB00 --the 0xb00 CA ID is tested
ROM:00293630 CMP R1, R3

You can see that it is looking for the CAID up around 0x78C500-78C600 and that is where the RAM dump 21C5E0 area is. I'm not sure if that area is scanned for the ID or if it is looking at one specific pair of bytes, but that is where the ID has to be. It might be copied to other locations in a better format for the debug message routine to pull it from, but that is the key area for filter building.

[DualTest]

Would creating a RAM section in the disassembly with IDA pro be of any use to me? I should have asked that long ago but was hoping to find the answer on my own.

[DualTest]

One thing I notice is that if I change this string


OVERWRITE 12 7C 74 00 4C CA 78 00 8C 54 49 00 53 53 53 50

in the serial script, as suggested in post #164, the spot where the channel number is supposed to be


SSSP|ECM|%08X|%02X|%04X|%04X|%04X|%s\n

changes

For example:

changing it to FD C5 78

SSSP|ECM|00000001|00|0072|1A22|517C|

that last number cycles though differents sets of numbers with each send. Is the change going to that spot because the caid isn't being found?

[jvvh5897]

As far as I know, setting IDA Pro up to do RAM rather than ROM section just changes the string put on the front of the addresses. In some IDC I've played with you do set up a number of sections--like in sti5518 files like the pansat 2500 use, you load the file to a ROM section and then the IDC has a routine that reads something called the section table and uses that to create a RAM section and moved the code to RAM based on the info in the section table, but the disassembly of the code does not change with whether it is in RAM section or ROM.

Um, the channel number in your example is 0072 and it is where it is supposed to be. The last %04x is for the CAId and what is stored at 78c5fd is unknown to me--I'm thinking it is something pulled from the stream, so it could be part of the packet sent about network info (stuff with channel list info), but packets have verifier strings and other stuff in them. BTW I think using an odd number as address is OK for a half-word load command, but I usually just see it used for even addresses, so you might use something ending in 2,4,6,8,a,c,e but not d.

[skywalker999]

ok guys maybe we are going to change the 4018 for the 1618
now if we need to change the ecm packets it's an easy fix i already posted how to the 4018 gives us 8030a207a0
and the 1618 will give us the 8f078d
i'm doing a ram dump right now on the pany9200hd and see if there is a big difference

Ok guys here is a realterm cap of a pany 3500sd loaded with the 316iksbin as you can see the ecm are not the same take a look

mpeg_picture_count = 0
SSSP|ECM|00000001|00|1816|0069|1022|80308F078D3BCF 2359FB5A09F87B9E57E0F653087F8090B2588C2104CB817C00 46F8D03A13AEDC991D4FD9566EB7481E3632DC37EF5720118E 98DFB4053035EEF65D83AEA36A4BD71BC4657A2B8441864C60 4F8ED997E789906D5C518AE953A99C092D32BF189B4A7313E0 8B34B8F948E4C0356B65AA2C59E3470C8DEC9AC26CDC9BEBCC 317939D982CB4B71FDF3D99D8333
!!!!!!!!!!! scramble channel !!!!!!!!!!!!
mpeg_picture_count = 0
!!!!!!!!!!! scramble channel !!!!!!!!!!!!
mpeg_picture_count = 0
SSSP|ECM|00000001|00|1816|0069|1022|81308F078D3AC3 210FDB8696527594E1C939EC09F010BC9E785696F4354FD82F 4A3867124D04B4F6C40D6811BEE3C43EFB8B972B47BC7247CE 8A703A3B9568ED0776A87A25C35A55DB1F6863EAA9B5DD6913 17ECE181EE34F081A89C97A6F27459B5219ADE0B3BC9636419 CAF7594776401D393CFE589D74262850E4EDD075D0FE816650 E41B0610C841D609818048B80A40
!!!!!!!!!!! scramble channel !!!!!!!!!!!!
mpeg_picture_count = 0
!!!!!!!!!!! scramble channel !!!!!!!!!!!!
mpeg_picture_count = 0
!!!!!!!!!!! scramble channel !!!!!!!!!!!!
mpeg_picture_count = 0
SSSP|ECM|00000001|00|1816|0069|1022|80308F078DFC01 2D4AEC99F649B4B2C6E14EFCE01DF92AF1E247E61E4050C0B9 B7330E596955FEBF69C20717BCEE5C90A1D5642AB5BF653832 4D63268C37CD0C1F8423CF3E925EA458204503080A9ECD8DD9 1E06F27B6D3C58268E3765F4748F07610852F1052590CCF8F4 83AA3DFC357BE631E9A2ABF1E91254C4291FD3839E154DC00F 6C48DDFD4CBAA821951A4B6DAC11
!!!!!!!!!!! scramble channel !!!!!!!!!!!!
mpeg_picture_count = 0

[DualTest]

I am having trouble understanding this line

ROM:0029362C MOVL R3, 0xB00

After some reading I am pretty sure that I understand what MOVL means and the R3. But the simplest part of it is baffling me, even if break down the macro and get ,0x#b and ,#8. I am not sure what that means. Any help would be appreciated. I really don't want to test 80 bins so would like to be able to find it in the disassembly.

[DualTest]

ok guys maybe we are going to change the 4018 for the 1618
now if we need to change the ecm packets it's an easy fix i already posted how to the 4018 gives us 8030a207a0
and the 1618 will give us the 8f078d
i'm doing a ram dump right now on the pany9200hd and see if there is a big difference

Ok guys here is a realterm cap of a pany 3500sd loaded with the 316iksbin as you can see the ecm are not the same take a look

mpeg_picture_count = 0
SSSP|ECM|00000001|00|1816|0069|1022|80308F078D3BCF 2359FB5A09F87B9E57E0F653087F8090B2588C2104CB817C00 46F8D03A13AEDC991D4FD9566EB7481E3632DC37EF5720118E 98DFB4053035EEF65D83AEA36A4BD71BC4657A2B8441864C60 4F8ED997E789906D5C518AE953A99C092D32BF189B4A7313E0 8B34B8F948E4C0356B65AA2C59E3470C8DEC9AC26CDC9BEBCC 317939D982CB4B71FDF3D99D8333
!!!!!!!!!!! scramble channel !!!!!!!!!!!!
mpeg_picture_count = 0
!!!!!!!!!!! scramble channel !!!!!!!!!!!!
mpeg_picture_count = 0
SSSP|ECM|00000001|00|1816|0069|1022|81308F078D3AC3 210FDB8696527594E1C939EC09F010BC9E785696F4354FD82F 4A3867124D04B4F6C40D6811BEE3C43EFB8B972B47BC7247CE 8A703A3B9568ED0776A87A25C35A55DB1F6863EAA9B5DD6913 17ECE181EE34F081A89C97A6F27459B5219ADE0B3BC9636419 CAF7594776401D393CFE589D74262850E4EDD075D0FE816650 E41B0610C841D609818048B80A40
!!!!!!!!!!! scramble channel !!!!!!!!!!!!
mpeg_picture_count = 0
!!!!!!!!!!! scramble channel !!!!!!!!!!!!
mpeg_picture_count = 0
!!!!!!!!!!! scramble channel !!!!!!!!!!!!
mpeg_picture_count = 0
SSSP|ECM|00000001|00|1816|0069|1022|80308F078DFC01 2D4AEC99F649B4B2C6E14EFCE01DF92AF1E247E61E4050C0B9 B7330E596955FEBF69C20717BCEE5C90A1D5642AB5BF653832 4D63268C37CD0C1F8423CF3E925EA458204503080A9ECD8DD9 1E06F27B6D3C58268E3765F4748F07610852F1052590CCF8F4 83AA3DFC357BE631E9A2ABF1E91254C4291FD3839E154DC00F 6C48DDFD4CBAA821951A4B6DAC11
!!!!!!!!!!! scramble channel !!!!!!!!!!!!
mpeg_picture_count = 0

If we wanted to make a seperate bin for each provider, at least to my limited understanding, that would be one way to do it. But what we are trying to do is find where the caid is stored in ram. That way to packet and caid would change automatically. At least that is my understanding.

[jvvh5897]

As I understand it, setting the filter and ecm string 40 18 00 00 34 12 00 00 gives you all provider's ecm packets--that would be good! Then you only have to get the right CAId in the outgoing string to match--so you search out the required Id in RAM dump.

[jvvh5897]

I am having trouble understanding this line

ROM:0029362C MOVL R3, 0xB00

After some reading I am pretty sure that I understand what MOVL means and the R3. But the simplest part of it is baffling me, even if break down the macro and get ,0x#b and ,#8. I am not sure what that means. Any help would be appreciated. I really don't want to test 80 bins so would like to be able to find it in the disassembly.

I'm not sure what you mean in the last sentence. MOV command just moves a value in to a register. R3 is the register that will get the 0xb00 value in it. Eventually that value will be tested to see if the contents of another register has 0xb00 in it. 0xb00 is the CAId for one of the providers--later in the same routine 0x1800 is looked for as is 0x1801 and 0x1810 (that last is the value that you are changing to 1840).

BTW, with xmas and New Year's coming I will not be on-line much. I'll check in when I can though.

[jvvh5897]

Just looked at an old capture from coolsat 4000 running rq-sssp file. Here is what was coming out:
SSSP|ECM|00000001|00|1816|0079|1022|80308F078D....

So, sorry it should be CAid|Channel Number|VPid as the three %04X.

[DualTest]

I did try just shift the three around but end up getting the reboot issue. It shouldn't be a hard problem to fix though.

[skywalker999]

Dualtest take it easy i wish i could help more i guess i quit school to soon what string are we looking for anyway

[DualTest]

Dualtest take it easy i wish i could help more i guess i quit school to soon what string are we looking for anyway

This is the script we will be changing.



REM to output a serial rq-sssp string from 081111 bl file
REM $495400
ADR $254000

OVERWRITE F0 B5 15 1C 81 B0 0C 1C AC F5 5E FF 00 2D 19 D0
OVERWRITE 19 49 00 20 0F 26 03 5D 1A 09 13 1C 30 33 0B 70
OVERWRITE 39 2B 01 D9 07 33 0B 70 03 5D 1A 1C 32 40 13 1C
OVERWRITE 30 33 4B 70 39 2B 01 D9 07 33 4B 70 01 30 02 31
OVERWRITE 85 42 E8 D1 0D 4A 6B 00 9B 18 00 22 1A 70 0C 4B
OVERWRITE 19 88 0C 33 1A 88 0B 4B 1B 88 07 4C 09 04 12 04
OVERWRITE 1B 04 09 48 09 14 12 14 1B 14 00 94 1B F6 28 FB
OVERWRITE 01 B0 F0 BC 01 BC 00 47 C0 54 49 00 C2 54 49 00
OVERWRITE 12 7C 74 00 4E CA 78 00 8C 54 49 00 53 53 53 50
OVERWRITE 7C 45 43 4D 7C 30 30 30 30 30 30 30 31 7C 30 30
OVERWRITE 7C 25 30 34 58 7C 25 30 34 58 7C 25 30 34 58 7C
OVERWRITE 25 73 0A 00

REM mod the 34025A BL sub_2422C8 ; rt_memcpy call to call the above

ADR $0
FIND C2 1C 29 1C 88 48 02 F7 35 F8
FIND 02 F7 35 F8
OVERWRITE 55 F1 D1 F8


It contains the 3 peices of info. And if you look at post #140. The very last line of the code used to make the script.



s_port("SSSP|ECM|00000001|00|%04X|%04X|%04X|%s\n", *(short *)0x747C12,*(short *)0x747C1e,*(short *)0x78CA4e,pHexA);


It contains the RAM addresses for the channel number (in hex format), vpid (which I assume is always in the same place) and caid (which is the address we are looking for, and then changed in the script). The addresses are in reverse order. It really isn't that big of a deal to find it. It is just finding the time at this time of the year to do it. Maybe this evening I will have some time. I basically know where it is.

[jvvh5897]

Don't know if you will need it, but decided to add a small change to the sys info routine to test for the number 1 and 2 buttons and change a RAM location from 1840 to 1815 or 1815 depending on the key pressed. The mod is to part of the routine not used by the RAM dump mod so you should be able to use both. The location of the code called by the mod is up in the 2nd image area, but before the other uses of the space so should be OK with any other mods that use that space too.

REM call from 002A04E0 to 2nd image space 495280
ADR $0
FIND F0 B5 91 B0 04 1C 0D 1C 00 26 28 68 00 28 38 D1
FIND 68 68 B5 28
OVERWRITE F4 F1 CE FE

ADR $253E80
OVERWRITE 68 68 B5 28 03 D0 31 28 06 D0 32 28 00 D0
OVERWRITE 70 47 04 4A 05 4B 1A 80 FA E7 04 4A 03 4B 1A 80
OVERWRITE F6 E7 00 00 00 00 15 18 00 00 70 53 49 00 16 18 00 00

ADR $253E70
OVERWRITE 40 18 00 00

The above comes from compiling:

void change_ID(int button)
{
if (button==0xb5) return;
if (button==0x31) *(short *)0x495370=0x1816;
if (button==0x32) *(short *)0x495370=0x1815;
}

I added one instruction to the code after I compiled and made a couple of manual mods because of that, but it basically is just the C code. If you wanted to use the saved CAId that it gives, you would point the sssp routine to use 0x495370. If you wanted to move the storage area around or use some other initial ID all that is right there at the end of the routine.

I thought about adding a pop up to give one feedback on the remote press, but that would have been hard in the sys info routine. You could also use the autoroll/keycode menu :
0024B2AC ; keycode OSD key handling
search term 06 DC B4 28 6F D0 B5 28 6E D0 D3 28 6D D1 04 E0
in a similar way or just read off the auto roll settings to set the sssp's CAId. In the 081111 dumps of RAM that start at 0x570000 look around 1D17DC or at 21AA47--those are two spots that have settings for autoroll (7417DC and 0x78AA47 actual RAM addrs ).

[DualTest]

Don't know if you will need it, but decided to add a small change to the sys info routine to test for the number 1 and 2 buttons and change a RAM location from 1840 to 1815 or 1815 depending on the key pressed. The mod is to part of the routine not used by the RAM dump mod so you should be able to use both. The location of the code called by the mod is up in the 2nd image area, but before the other uses of the space so should be OK with any other mods that use that space too.

REM call from 002A04E0 to 2nd image space 495280
ADR $0
FIND F0 B5 91 B0 04 1C 0D 1C 00 26 28 68 00 28 38 D1
FIND 68 68 B5 28
OVERWRITE F4 F1 CE FE

ADR $253E80
OVERWRITE 68 68 B5 28 03 D0 31 28 06 D0 32 28 00 D0
OVERWRITE 70 47 04 4A 05 4B 1A 80 FA E7 04 4A 03 4B 1A 80
OVERWRITE F6 E7 00 00 00 00 15 18 00 00 70 53 49 00 16 18 00 00

ADR $253E70
OVERWRITE 40 18 00 00

The above comes from compiling:

void change_ID(int button)
{
if (button==0xb5) return;
if (button==0x31) *(short *)0x495370=0x1816;
if (button==0x32) *(short *)0x495370=0x1815;
}

I added one instruction to the code after I compiled and made a couple of manual mods because of that, but it basically is just the C code. If you wanted to use the saved CAId that it gives, you would point the sssp routine to use 0x495370. If you wanted to move the storage area around or use some other initial ID all that is right there at the end of the routine.

I thought about adding a pop up to give one feedback on the remote press, but that would have been hard in the sys info routine. You could also use the autoroll/keycode menu :
0024B2AC ; keycode OSD key handling
search term 06 DC B4 28 6F D0 B5 28 6E D0 D3 28 6D D1 04 E0
in a similar way or just read off the auto roll settings to set the sssp's CAId. In the 081111 dumps of RAM that start at 0x570000 look around 1D17DC or at 21AA47--those are two spots that have settings for autoroll (7417DC and 0x78AA47 actual RAM addrs ).

Very nice of you jvvh. Merry Christmas to you and yours.

[skywalker999]

Merry Christmas jvvh and Dualtest and the family's best wishes take care
no time for testing tonight will do tomorrow

:xmhi::xmcold::xmwarn:

[DualTest]

I am starting to wonder if there is something wrong with the ram on my receiver. First there was the ram dumps that never seemed to work out. And now I can't scan the sats properly. At a certain point the scan just hangs, even on a blind scan, even though both Q and S are good. I have flashed this thing with factory files many times, and the boot file, but same result. If someone would be so kind as to upload a channel list, it would be appreciated.

[skywalker999]

i have ad the same problem i think the receiver hangs on the HD transponders i would scan with one of the latest's femu file and then save the channel list to the usb drive and it seems if you scan 119 first then 110 it works better
i'm going to get a good scan and upload

wow i'm having the same problem maybe it's the wrong time of day geez will try later

[jvvh5897]

You could just test with the femu file. We swtiched tothe -081111 file because it was hoped it would get ecm packets, but the mod developed for that should work with the femu file too. If it scans better and gets better EPG (don't know that it does but if it does) use it.

[skywalker999]

just an update even with the femu file i'm having trouble the best way of scanning is in the advance tp scan with network of and scan the tp's one by one

[DualTest]

I am thinking we may have to come up with a cleaner file.

[jeldf]

Merry Christmas jvvh and Dualtest and the family's best wishes take care
no time for testing tonight will do tomorrow

:xmhi::xmcold::xmwarn:

I would like to wish you all a Merry Christmas and say thank you! I'm not into modding but this thread is one of the best reads on this forum imho! My New Years wish for you is to solve this. I look forward to the outcome.

Cheers friends!

[skywalker999]

Dualtest that would be a good idea a systemclean file Don't know if that is going to be possible, but that would be nice the sonicview has one
well i did managed to scan 110 119 118 and 97W with femu file 090607 almost all the channel names come in correctly but there's a some come with tv and the number in front but that's not bad my lnbs are legacy the way it worked for me was to scan 97W first and then the other ones

ps+ i'm doing a ram dump right now with that femu file with the 40180000 changed and red button mode only will let you guys now how it goes and i have lots of time for testing i'm on Christmas vacation until the 6 of january

ho ho ho merry Christmas to you to jeldf :xmhi::xmsnowball:

[DualTest]

Post #188 worked. Now I just need to re-order the caid, vpid and channel number.

[skywalker999]

Dualtest did you manage to get the ca id correctly tanks:noidea:

[DualTest]

So what I need to know is how to split up the caid and vpid in this script



REM to output a serial rq-sssp string from 081111 bl file
REM $495400
ADR $254000

OVERWRITE F0 B5 15 1C 81 B0 0C 1C AC F5 5E FF 00 2D 19 D0
OVERWRITE 19 49 00 20 0F 26 03 5D 1A 09 13 1C 30 33 0B 70
OVERWRITE 39 2B 01 D9 07 33 0B 70 03 5D 1A 1C 32 40 13 1C
OVERWRITE 30 33 4B 70 39 2B 01 D9 07 33 4B 70 01 30 02 31
OVERWRITE 85 42 E8 D1 0D 4A 6B 00 9B 18 00 22 1A 70 0C 4B
OVERWRITE 19 88 0C 33 1A 88 0B 4B 1B 88 07 4C 09 04 12 04
OVERWRITE 1B 04 09 48 09 14 12 14 1B 14 00 94 1B F6 28 FB
OVERWRITE 01 B0 F0 BC 01 BC 00 47 C0 54 49 00 C2 54 49 00
OVERWRITE 12 7C 74 00 4E CA 78 00 8C 54 49 00 53 53 53 50
OVERWRITE 7C 45 43 4D 7C 30 30 30 30 30 30 30 31 7C 30 30
OVERWRITE 7C 25 30 34 58 7C 25 30 34 58 7C 25 30 34 58 7C
OVERWRITE 25 73 0A 00

REM mod the 34025A BL sub_2422C8 ; rt_memcpy call to call the above

ADR $0
FIND C2 1C 29 1C 88 48 02 F7 35 F8
FIND 02 F7 35 F8
OVERWRITE 55 F1 D1 F8


I am assuming that the address for the caid (which I have changed) is pulling 0x08 of data and I need 0x04.

[skywalker999]

Hum Dualtest that's a question that would be better for jvvh and right now with the holidays it's not easy you just have to be very patient but my guess is that there myth be a spot where the 0x04 is instead of the 0x08 just a guess :noidea:
but i'm sure it's an easy fix anyway Dualtest keep up the good work

[jvvh5897]

Do you guys have to rescan after a file load all the time? Or is this just another issue? If file load clears the channel list, can't you dump the channel list before file load and then re-load the channel list?

----------------------------------------------------
On the
So what I need to know is how to split up the caid and vpid in this script question.

Here is disassembly of the last part of the code that I have in my notes and I'll add a few comments on the lines:

ROM:00495444 LDR R2, =0x4954C2
ROM:00495446 LSL R3, R5, #1
ROM:00495448 ADD R3, R3, R2
ROM:0049544A MOV R2, #0
ROM:0049544C STRB R2, [R3] --store NULL at end of the ecm string
ROM:0049544E LDR R3, =0x747C12 --get location of the channel number
ROM:00495450 LDRH R1, [R3] --load 16 byte half-word from the 0x747C12 location
ROM:00495452 ADD R3, #0xC --add 0xc to 0x747C12
ROM:00495454 LDRH R2, [R3] --load half-word channel VPid
ROM:00495456 LDR R3, =0x78CA4E --get location of the CAId
ROM:00495458 LDRH R3, [R3] --load half-word from 0x78CA4E
ROM:0049545A LDR R4, =0x4954C0 --get location of the ecm string
ROM:0049545C LSL R1, R1, #0x10 --these three instructions with the ASR below just shift the contents around to be sure that they have 0x00s where they should, compiler added them and I'm not sure they are needed
ROM:0049545E LSL R2, R2, #0x10
ROM:00495460 LSL R3, R3, #0x10
ROM:00495462 LDR R0, =aSsspEcm0000000 --get location of the format string to use
ROM:00495464 ASR R1, R1, #0x10
ROM:00495466 ASR R2, R2, #0x10
ROM:00495468 ASR R3, R3, #0x10
ROM:0049546A STR R4, [SP] --registers R0 to R3 can be used directly to pass info to sub-routines any more need to be on stack
ROM:0049546C BL 0x2B0AC0 --call the debug message routine
ROM:00495470 ADD SP, SP, #4 --start to exit routine
ROM:00495472 POP {R4-R7}
ROM:00495474 POP {R0}
ROM:00495476 BX R0
ROM:00495476 ; ---------------------------------------------------------------------------
ROM:00495478 dword_495478 DCD 0x4954C0 ; DATA XREF: ROM:00495410r
ROM:00495478 ; ROM:0049545Ar
ROM:0049547C dword_49547C DCD 0x4954C2 ; DATA XREF: ROM:loc_495444r
ROM:00495480 dword_495480 DCD 0x747C12 ; DATA XREF: ROM:0049544Er
ROM:00495484 dword_495484 DCD 0x78CA4E ; DATA XREF: ROM:00495456r
ROM:00495488 off_495488 DCD aSsspEcm0000000 ; DATA XREF: ROM:00495462r

As you can see right at the end is where data used in the routine is stored. To read that data commands like :
ROM:00495456 LDR R3, =0x78CA4E --get location of the CAId
are actually commads to look at an offset of the current instruction pointer (IP) for info. The offset that is part of the instruction is shifted such that it points at word sized data--what do I mean by that? 0B 4B is the command to load R3 with the value located 0xb words (4 bytes per word) from the next instruction (where IP is pointed to). Each instruction in thumb mode is two bytes long except for the BL command to call subroutines--they are 4 bytes long, so if you can count you should be able to find any instruction in the script from a disassembly of the code. If you have IDA that is easy to do.

There are pdf files with info on the command set for ARM--look for the ARM7DTMi instruction set in google.

[DualTest]

I am still working off of a scan I did with the 9219 file. It stays after a file load, until a a factory default is done. I may eventually adapt the scripts for that file, but I would like to get things sorted out with the 081111 first.

[skywalker999]

Let me clear something out jvvh no we don't have to rescan the channels after we load a bin it's just user choice to do a factory default
but the smart way of doing it and easier way of doing it it's to save the channel list to the USB memory flash drive and that is the faster and better choice my guess is that some forget to do it before they do a factory default oops it as happen to me also lol

[jvvh5897]

Added a whole folder for you guys to get compiles with winARM easier down in advanced section.

[DualTest]

Thanks jvvh that helped alot. It's now compiling into a bin file for me.

And I have been able to reproduce the sssp script. I am still not sure what I was doing wrong but will look into more at a later date.

[lapatte]

nic project to revive this very nice receiver

thank'S

[DualTest]

Do you guys have to rescan after a file load all the time? Or is this just another issue? If file load clears the channel list, can't you dump the channel list before file load and then re-load the channel list?

----------------------------------------------------
On the question.

Here is disassembly of the last part of the code that I have in my notes and I'll add a few comments on the lines:

ROM:00495444 LDR R2, =0x4954C2
ROM:00495446 LSL R3, R5, #1
ROM:00495448 ADD R3, R3, R2
ROM:0049544A MOV R2, #0
ROM:0049544C STRB R2, [R3] --store NULL at end of the ecm string
ROM:0049544E LDR R3, =0x747C12 --get location of the channel number
ROM:00495450 LDRH R1, [R3] --load 16 byte half-word from the 0x747C12 location
ROM:00495452 ADD R3, #0xC --add 0xc to 0x747C12
ROM:00495454 LDRH R2, [R3] --load half-word channel VPid
ROM:00495456 LDR R3, =0x78CA4E --get location of the CAId
ROM:00495458 LDRH R3, [R3] --load half-word from 0x78CA4E
ROM:0049545A LDR R4, =0x4954C0 --get location of the ecm string
ROM:0049545C LSL R1, R1, #0x10 --these three instructions with the ASR below just shift the contents around to be sure that they have 0x00s where they should, compiler added them and I'm not sure they are needed
ROM:0049545E LSL R2, R2, #0x10
ROM:00495460 LSL R3, R3, #0x10
ROM:00495462 LDR R0, =aSsspEcm0000000 --get location of the format string to use
ROM:00495464 ASR R1, R1, #0x10
ROM:00495466 ASR R2, R2, #0x10
ROM:00495468 ASR R3, R3, #0x10
ROM:0049546A STR R4, [SP] --registers R0 to R3 can be used directly to pass info to sub-routines any more need to be on stack
ROM:0049546C BL 0x2B0AC0 --call the debug message routine
ROM:00495470 ADD SP, SP, #4 --start to exit routine
ROM:00495472 POP {R4-R7}
ROM:00495474 POP {R0}
ROM:00495476 BX R0
ROM:00495476 ; ---------------------------------------------------------------------------
ROM:00495478 dword_495478 DCD 0x4954C0 ; DATA XREF: ROM:00495410r
ROM:00495478 ; ROM:0049545Ar
ROM:0049547C dword_49547C DCD 0x4954C2 ; DATA XREF: ROM:loc_495444r
ROM:00495480 dword_495480 DCD 0x747C12 ; DATA XREF: ROM:0049544Er
ROM:00495484 dword_495484 DCD 0x78CA4E ; DATA XREF: ROM:00495456r
ROM:00495488 off_495488 DCD aSsspEcm0000000 ; DATA XREF: ROM:00495462r

As you can see right at the end is where data used in the routine is stored. To read that data commands like :
ROM:00495456 LDR R3, =0x78CA4E --get location of the CAId
are actually commads to look at an offset of the current instruction pointer (IP) for info. The offset that is part of the instruction is shifted such that it points at word sized data--what do I mean by that? 0B 4B is the command to load R3 with the value located 0xb words (4 bytes per word) from the next instruction (where IP is pointed to). Each instruction in thumb mode is two bytes long except for the BL command to call subroutines--they are 4 bytes long, so if you can count you should be able to find any instruction in the script from a disassembly of the code. If you have IDA that is easy to do.

There are pdf files with info on the command set for ARM--look for the ARM7DTMi instruction set in google.

That is probably the most informative post in this thread. Something everyone interested in this kind of thing should copy and save.

[jvvh5897]

It is a little more obvious in the disassembly that you get from the winARM compile, but easier to read and follow code in IDA disassembly. And having read the ARM7TDMIe pdf on instruction set doesn't hurt.

[Ineedanewusersname]

LAdies/Gentlemen, which flavor of Winarm do you prefer. I found a 2006 and 2007 beta versions.....tks

[jvvh5897]

Don't know if it makes a difference. I've had the copy I have for a long time, might be 2006. Whatever it is, it had an example folder--I would think that that would not be the first release.

[DualTest]

I am using the 20060606 one.

[DualTest]

Just to update this thread so people don't think this project has been abandoned. I was sick with the flu since roughly the new year, but have managed to pull this out a few times and take a look at it. I am still working on it, still learning new things and still making some progress. I think jvvh has provided as much help in this thread as is needed to get a working file for these receivers. Frankly getting this receiver working on IKS is not a big deal for me, I don't even have a working receiver connected to my dish and stream all of my content these days. But I like this challenge and have always wanted to learn this stuff and that is why I am doing it.

If anyone else has been following along and has questions though please feel free to ask. If you read through this thread from the beginning you will see that much progress has been made from asking stupid questions and not worrying about embarrassing myself lol

[jvvh5897]

I am up to playing with the code for other than IKS. Just point in that direction because that is what people are willing to play with code to get. My last project for myself was to get support for a diff remote on a box, and the one before that was to get the unscrambled audio of another prov.
For your box, you might add serial control of downloading RAM. Or mod the menu system to add downloading on command. Maybe figure out how to do something via USB. Does the box need a web interface?--might not be able to do really fast stuff on the web, but the spi enc28j60 web boards are cheap.

[DualTest]

Okay I have made some progress. With this script.



REM to output a serial rq-sssp string from 081111 bl file
REM $495400
ADR $254000

OVERWRITE F0 B5 15 1C 81 B0 0C 1C AC F5 5E FF 00 2D 19 D0
OVERWRITE 19 49 00 20 0F 26 03 5D 1A 09 13 1C 30 33 0B 70
OVERWRITE 39 2B 01 D9 07 33 0B 70 03 5D 1A 1C 32 40 13 1C
OVERWRITE 30 33 4B 70 39 2B 01 D9 07 33 4B 70 01 30 02 31
OVERWRITE 85 42 E8 D1 0D 4A 6B 00 9B 18 00 22 1A 70 0C 4B
OVERWRITE 19 88 0C 4B 1A 88 0C 33 1B 88 07 4C 1B 04 09 04
OVERWRITE 12 04 09 48 09 14 12 14 1B 14 00 94 1B F6 28 FB
OVERWRITE 01 B0 F0 BC 01 BC 00 47 C0 54 49 00 C1 54 49 00
OVERWRITE 70 53 49 00 12 7C 74 00 8C 54 49 00 53 53 53 50
OVERWRITE 7C 45 43 4D 7C 30 30 30 30 30 30 30 31 7C 30 30
OVERWRITE 7C 25 30 34 58 7C 25 30 34 58 7C 25 30 34 58 7C
OVERWRITE 25 73 0A 00

REM mod the 34025A BL sub_2422C8 ; rt_memcpy call to call the above

ADR $0
FIND C2 1C 29 1C 88 48 02 F7 35 F8
FIND 02 F7 35 F8
OVERWRITE 55 F1 D1 F8


And using this script for the caid (never could find the address for it).



ADR $253E80
OVERWRITE 68 68 B5 28 03 D0 31 28 06 D0 32 28 00 D0
OVERWRITE 70 47 04 4A 05 4B 1A 80 FA E7 04 4A 03 4B 1A 80
OVERWRITE F6 E7 00 00 00 00 15 18 00 00 70 53 49 00 16 18 00 00

ADR $253E70
OVERWRITE 40 18 00 00


All the info is in the correct order:



SSSP|ECM|00000001|00|1816|0072|1A22|81308F078D0111 86008815BC4AA2FD5FE091EE4B16A5
CA243DC4F35B349427C46B5D91ACF2C0BD20653F939DE30212 8B03690E9D000B06DFE2CC7E7BD42C
4BE78890D0C00025AE6192236BCC6784BD505EF1E079B35A6B FAFF7CE8FE9873DB60C2C884095E30
7DFF8761A1744AA9A88ECB5B05ACC35A391D24770D5EA79F6D B0E88EE05BFFDF0D74CDC782B59428
449F855Aÿ


I took the receiver to a friend place, who does IKS. It sends the request successfully but doesn't receive the CW's. I am not sure what could be wrong.

[jvvh5897]

Well, did you install the mod to receive CWs? One was posted, but I only gave it a 50-50 chance of working.

[skywalker999]

if it helps i did get the CWs back also had to go to a friends to test with the latest script sent but not on channel 114 but on ch115 and that's with rq sssp for pansat but no pic yet and receiver goes crazy every time it gets CWs back :crazy::crazy::crazy:

PS= don't know if i should post a pic that i captured

[jvvh5897]

Have either of you tested just sending the return packet example I provided? You could dump the RAM to test if it gets read to the mod. You could mod the mod so that it echos back the packet as read. Rather than take your boxes to another location, you just use your PC and RealTerm. Simplify the mod so that it does not try to save the CWs with the call in there, just pull the bytes from the RX buffer and get that working. Some of this would take a compile of code and fixing it so that it works in the spot modded before, some might just take some machine code re-work to put a NOP or two here or there.

[DualTest]

I saved this as a txt file


A5 17 00 30 C3 C2 C1 C0 E0 01 02 03 04 05 06 07 08 11 12 13 14 15 16 17 18 A5

Then ran all the mods on the radio background modded file. Then just before running the ram dump, I clicked on the send tab in realterm. I browsed to the saved txt file under Dump File to Port. Then clicked Send_File. And proceeded to do an 8 meg dump. The only place it showed up was very early in the dump at D1C8.

I still haven't changed this line though ROM:00282A50 BL sub_495300. Before I start on that I just want to confirm something from post #166. You said:


Now all you need it to write the mod to call into 495300 from the memcmp at 282A50.

So does that mean that ROM:00282A50 BL sub_495300 should read ROM:00282A50 BL sub_495300 ; memcmp ?

After doing some reading. I think that line is as it should be.

So I will give this suggestion a shot.



Have either of you tested just sending the return packet example I provided? You could dump the RAM to test if it gets read to the mod. You could mod the mod so that it echos back the packet as read. Rather than take your boxes to another location, you just use your PC and RealTerm. Simplify the mod so that it does not try to save the CWs with the call in there, just pull the bytes from the RX buffer and get that working. Some of this would take a compile of code and fixing it so that it works in the spot modded before, some might just take some machine code re-work to put a NOP or two here or there.

[jvvh5897]

You don't save the file as txt, you save it as hex in a bin file--just as you look at your box's files as bin files, you should be able to look at the file you want to send to the receiver and see A5 as the hex char 0xa5 not as the ascii char A followed by the ascii char 5 (0x41 and 0x35).


So does that mean that ROM:00282A50 BL sub_495300 should read ROM:00282A50 BL sub_495300 ; memcmp ?
No, it means that at the 282A50 location you insert code to call to code in the mpg image area (495300), where you do eventually do a call to memcmp to replace the call that you took over but along with that replacement call you do other things like test if you should read bytes from the serial RX buffer . Don't you disassemble any of the code examples that I give you?--you should!

[DualTest]

Perhaps I can upload the last disassembly that I have. I always use the latest incarnation of the file for disassembly. Or I can upload the entire script that I am using, in case I have missed something. I haven't wanted to do it out of concerns of who might see it, but seeing as it isn't working I guess it would be okay. What do you think?

[jvvh5897]

What do I think? What does it matter? As far as I know all you are using is something that I've posted or very nearly--so folks should have everything that you would post. As for posting disassembly--up to you, but I'm not going to be reading it because I have a disassembly and I don't think that folks are interested in looking at megabytes of asm code that they could generate for themselves or that the site admin are going to like megabytes of of it clogging things up. By and large the code you would post (of just the mods) is more clearly understood at the C source code level and that is posted here too.

[DualTest]

Well it is a moot point now anyways as the hard drive with everything on it died this morning. Which might not be a bad thing. I have been meaning to go over this thread from the beginning for awhile now.

[DualTest]

I am wondering if now might be a good time to switch back to the femu file, as it scans better. And might be easier to mod for the CW return packet. I am not sure if we ever got a good ram dump of that file though. I tried again to dump that file and still didn't see any of the packets we were looking for, but for some reason I have never been able to do that. Since we had the best luck with the 97W n2 radio 8m capture, maybe someone can do that with femu file. I forgot to mention that the file to mod is down in the advanced section called HD-9200L_pvr3. That is the equivalent to the HD-9200BL081111Rad file. And the ram dump script is on page 3 or of this thread.

[jvvh5897]

With the femu file that we played with before you should be able to do the same 40 18 00 00 34 12 00 00 search and mod that worked with the older file and get the packets you need--up to you guys which you work on. The serial output should be not much different than what you have going. Similar problems in getting the serial input going, but the basic locations to mod are pretty much the same.

[skywalker999]

dualtest i uploaded a new ram dump capture with femu 090607 9219 of south pvdr in advance section if it helps ecm packets are there only with red button script

[skywalker999]

FYI well today i tested all the BL femu Pany9200HD files and found that all of them work on globo N2 radio stations of course with the right keys, but if you change the first key 10 18 00 00 34 12 00 to 40 18 00 00 34 12 it stops working :yes:

[DualTest]

I am just adapting the scripts for this file. Making progress.

[DualTest]

I noticed something in the disassembly of the 081111, while I was comparing it to the 9219 file.

Parts of this script:



REM put this code at 495300
ADR $253F00
OVERWRITE 30 B5 AC F5 09 FE 05 1C 00 28 10 D1 0D 4B 1A 68
OVERWRITE 04 3B 1B 68 9A 42 0A D0 0B 4C 1D 21 20 1C 01 22
OVERWRITE 01 F6 98 FD 23 78 A5 2B 01 D1 00 28 03 D0 28 1C
OVERWRITE 30 BC 02 BC 08 47 21 1C 09 31 10 20 01 F6 85 FD
OVERWRITE F5 E7 00 00 DC D9 57 00 60 53 49 00


Disassembles as this:



ROM:00495324 DCB 0x23 ; #
ROM:00495325 DCB 0x78 ; x
ROM:00495326 DCB 0xA5 ; Ñ
ROM:00495327 DCB 0x2B ; +
ROM:00495328 DCB 1
ROM:00495329 DCB 0xD1 ; -
ROM:0049532A DCB 0
ROM:0049532B DCB 0x28 ; (
ROM:0049532C DCB 3
ROM:0049532D DCB 0xD0 ; -

ROM:00495334 ; End of function sub_495300

ROM:00495336 DCB 0x21 ; !
ROM:00495337 DCB 0x1C
ROM:00495338 DCB 9
ROM:00495339 DCB 0x31 ; 1
ROM:0049533A DCB 0x10
ROM:0049533B DCB 0x20
ROM:0049533C DCB 1
ROM:0049533D DCB 0xF6 ; ÷
ROM:0049533E DCB 0x85 ; à
ROM:0049533F DCB 0xFD ; ²
ROM:00495340 DCB 0xF5 ; )
ROM:00495341 DCB 0xE7 ; t
ROM:00495342 DCB 0
ROM:00495343 DCB 0

So I am assuming that is where I was missing something. I am not really asking a question here (guidance is always appreciated though lol) I need to take a break from this for a couple of days and just wanted to have something to jog my memory at that time. I always find when I am going around and around a problem and not getting results it's just best to step back and take a break.

[jvvh5897]

OK. Well, the code that was to be put at 495300 was the UART_Read source code as compiled by WinARM, so you should have a disassembly of the code if you compile the source that should answer much I would think. It was compiled as 16 bit code "THUMB" code and you should not have gotten an IDA disasssembly like I see in your post if you had used thumb mode. Though you did not provide the whole IDA disassembly, if you don't see the first two bytes: 30 B5 disassemble as
ROM:00495300 CODE16
ROM:00495300 PUSH {R4-R7,LR}
then you have a mode issue. To get thumb mode hit alt-g and put 1 in the window that pops up (to get ARM mode enter 0--just in case you need to do that while doing some manual disassembly).

[DualTest]

Here is the entire 495300 Subroutine for the 081111 file. I have checked and all of it comes up as thumb code (1). I have some time to look at this over the next few days, and hopefully can get it figured out.



ROM:00495300 ; =============== S U B R O U T I N E =======================================
ROM:00495300
ROM:00495300
ROM:00495300 sub_495300 ; CODE XREF: sub_282A44+Cp
ROM:00495300
ROM:00495300 ; FUNCTION CHUNK AT ROM:00296DD4 SIZE 00000006 BYTES
ROM:00495300 ; FUNCTION CHUNK AT ROM:00296E54 SIZE 0000000A BYTES
ROM:00495300
ROM:00495300 PUSH {R4,R5,LR}
ROM:00495302 BL sub_241F18 ; memcmp
ROM:00495306 MOVS R5, R0
ROM:00495308 CMP R0, #0
ROM:0049530A BNE loc_49532E
ROM:0049530C LDR R3, =0x57D9DC
ROM:0049530E LDR R2, [R3]
ROM:00495310 SUBS R3, #4
ROM:00495312 LDR R3, [R3]
ROM:00495314 CMP R2, R3
ROM:00495316 BEQ loc_49532E
ROM:00495318 LDR R4, =unk_495360
ROM:0049531A MOVS R1, #0x1A
ROM:0049531C MOVS R0, R4
ROM:0049531E MOVS R2, #0xA
ROM:00495320 BL loc_296E54
ROM:00495320 ; ---------------------------------------------------------------------------
ROM:00495324 DCB 0x23 ; #
ROM:00495325 DCB 0x78 ; x
ROM:00495326 DCB 0xA5 ; Ñ
ROM:00495327 DCB 0x2B ; +
ROM:00495328 DCB 1
ROM:00495329 DCB 0xD1 ; -
ROM:0049532A DCB 0
ROM:0049532B DCB 0x28 ; (
ROM:0049532C DCB 3
ROM:0049532D DCB 0xD0 ; -
ROM:0049532E ; ---------------------------------------------------------------------------
ROM:0049532E
ROM:0049532E loc_49532E ; CODE XREF: sub_495300+Aj
ROM:0049532E ; sub_495300+16j
ROM:0049532E MOVS R0, R5
ROM:00495330 POP {R4,R5}
ROM:00495332 POP {R1}
ROM:00495334 BX R1
ROM:00495334 ; End of function sub_495300
ROM:00495334
ROM:00495334 ; ---------------------------------------------------------------------------
ROM:00495336 DCB 0x21 ; !
ROM:00495337 DCB 0x1C
ROM:00495338 DCB 9
ROM:00495339 DCB 0x31 ; 1
ROM:0049533A DCB 0x10
ROM:0049533B DCB 0x20
ROM:0049533C DCB 1
ROM:0049533D DCB 0xF6 ; ÷
ROM:0049533E DCB 0x85 ; à
ROM:0049533F DCB 0xFD ; ²
ROM:00495340 DCB 0xF5 ; )
ROM:00495341 DCB 0xE7 ; t
ROM:00495342 DCB 0
ROM:00495343 DCB 0
ROM:00495344 dword_495344 DCD 0x57D9DC ; DATA XREF: sub_495300+Cr
ROM:00495348 off_495348 DCD unk_495360 ; DATA XREF: sub_495300+18r

[jvvh5897]

This is what I have in the notes I have with me at the moment--I could have changed this a bit between the copy of this and the end result but....

ROM:00495300 CODE16
ROM:00495300 PUSH {R4,R5,LR}
ROM:00495302 BL 0x49526C --change to call 241F18
ROM:00495306 ADD R5, R0, #0
ROM:00495308 CMP R0, #0
ROM:0049530A BNE loc_49532E
ROM:0049530C LDR R3, =0x57D9DC
ROM:0049530E LDR R2, [R3]
ROM:00495310 SUB R3, #4
ROM:00495312 LDR R3, [R3]
ROM:00495314 CMP R2, R3
ROM:00495316 BEQ loc_49532E
ROM:00495318 LDR R4, =0x10000 --change to 495300+70
ROM:0049531A MOV R1, #0x1D
ROM:0049531C ADD R0, R4, #0
ROM:0049531E MOV R2, #1
ROM:00495320 BL 0x495270 --change to call 4953A0
ROM:00495324 LDRB R3, [R4]
ROM:00495326 CMP R3, #0xA5
ROM:00495328 BNE loc_49532E
ROM:0049532A CMP R0, #0
ROM:0049532C BEQ loc_495336
ROM:0049532E
ROM:0049532E loc_49532E ; CODE XREF: ROM:0049530Aj
ROM:0049532E ; ROM:00495316j ...
ROM:0049532E ADD R0, R5, #0
ROM:00495330 POP {R4,R5}
ROM:00495332 POP {R1}
ROM:00495334 BX R1
ROM:00495336 ; ---------------------------------------------------------------------------
ROM:00495336
ROM:00495336 loc_495336 ; CODE XREF: ROM:0049532Cj
ROM:00495336 ADD R1, R4, #0
ROM:00495338 ADD R1, #9
ROM:0049533A MOV R0, #0x10
ROM:0049533C BL 0x495268 --296E70 save_CWs
ROM:00495340 B loc_49532E
ROM:00495340 ; ---------------------------------------------------------------------------
ROM:00495342 DCB 0
ROM:00495343 DCB 0
ROM:00495344 dword_495344 DCD 0x57D9DC ; DATA XREF: ROM:0049530Cr
ROM:00495348 dword_495348 DCD 0x10000 ; DATA XREF: ROM:00495318r
ROM:00495348 ; ROM ends

[DualTest]

Well I managed to got it to this stage.

ROM:00495300
ROM:00495300 ; =============== S U B R O U T I N E =======================================
ROM:00495300
ROM:00495300
ROM:00495300 sub_495300 ; CODE XREF: sub_282A44+Cp
ROM:00495300 PUSH {R4,R5,LR}
ROM:00495302 BL sub_241F18 ; memcmp
ROM:00495306 MOVS R5, R0
ROM:00495308 CMP R0, #0
ROM:0049530A BNE loc_49532E
ROM:0049530C LDR R3, =0x57D9DC
ROM:0049530E LDR R2, [R3]
ROM:00495310 SUBS R3, #4
ROM:00495312 LDR R3, [R3]
ROM:00495314 CMP R2, R3
ROM:00495316 BEQ loc_49532E
ROM:00495318 LDR R4, =word_495370
ROM:0049531A MOVS R1, #0x1A
ROM:0049531C MOVS R0, R4
ROM:0049531E MOVS R2, #0xA
ROM:00495320 BL sub_4953A0
ROM:00495324 LDRB R3, [R4]
ROM:00495326 CMP R3, #0xA5
ROM:00495328 BNE loc_49532E
ROM:0049532A CMP R0, #0
ROM:0049532C BEQ loc_495336
ROM:0049532E
ROM:0049532E loc_49532E ; CODE XREF: sub_495300+Aj
ROM:0049532E ; sub_495300+16j ...
ROM:0049532E MOVS R0, R5
ROM:00495330 POP {R4,R5}
ROM:00495332 POP {R1}
ROM:00495334 BX R1
ROM:00495336 ; ---------------------------------------------------------------------------
ROM:00495336
ROM:00495336 loc_495336 ; CODE XREF: sub_495300+2Cj
ROM:00495336 MOVS R1, R4
ROM:00495338 ADDS R1, #9
ROM:0049533A MOVS R0, #0x10
ROM:0049533C BL sub_296E70
ROM:00495340 B loc_49532E
ROM:00495340 ; End of function sub_495300
ROM:00495340
ROM:00495340 ; ---------------------------------------------------------------------------
ROM:00495342 DCB 0
ROM:00495343 DCB 0
ROM:00495344 dword_495344 DCD 0x57D9DC ; DATA XREF: sub_495300+Cr
ROM:00495348 off_495348 DCD word_495370 ; DATA XREF: sub_495300+18r


I did a ram dump and sent this to the receiver (in a bin) by realterm.

A5 17 00 30 C3 C2 C1 C0 E0 01 02 03 04 05 06 07 08 11 12 13 14 15 16 17 18 A5

and the only place that I am seeing it is at the beginning. But it could be that I don't have the subroutine right yet.


http://i953.photobucket.com/albums/ae11/TestinForNow/cwtest.jpg (http://s953.photobucket.com/user/TestinForNow/media/cwtest.jpg.html)

[jvvh5897]

You are still sending the cmd 30 test sequence as ASCII--as pointed out before you don't want it as ascii.

[DualTest]

You are still sending the cmd 30 test sequence as ASCII--as pointed out before you don't want it as ascii.

I fixed that. I always tried increasing the buffer, from 495360 to 495350 with the same result. It is only showing up before the realterm string.

So I want to rewrite some of this c code



int read_rx( char* Dest, char* pData, unsigned int uCnt)
{
static char my_buf[32];
int nError;

unsigned int rxOutdex=0x57D9D8;
unsigned int rxIndex=0x57D9DC;
int result;
unsigned int temp;

result=memcy( Dest, pData, uCnt); //result will be 0 if same
if((result==0)&&(*(unsigned int*)rxIndex != *(unsigned int*)rxOutdex))
{
nError=UART_Read((unsigned char*)&my_buf,29,1);

if((my_buf[0]==0xa5)&&(nError==0)) save_CW(0x10,my_buf+0x9);
}

return result;
}


But even when I try to compile it as is, I get errors. I have attached the blink.c as a text file in the advanced thread. What I would like to do is to put the A5 17 00 30 C3 C2 C1 C0 E0 01 02 03 04 05 06 07 08 11 12 13 14 15 16 17 18 A5 in there. And see how it comes out. This is really my first attempt at altering c code so I am a little lost.

[jvvh5897]

And I am supposed to know what your errors are without seeing them?

I'm guessing that you are just compiling the posted code in above--that does not have the fake memcy, or UART_Read routines, so I would expect errors because of that. I'm a little lost at why and how you want to put the a5...a5 sequence in that code--maybe if you give some clue as to that... You are just not specific enough IMO.

[DualTest]

What I am trying to do is find out where the A5 sequence it coming in after the realterm string, if at all. Because I am not finding it in anywhere in the dumps I am doing. Even a part of the string. And if I knew where to look specifically in the dump it would help, which is where I was going with trying to put that string in the code.

As for the errors I am getting with WinARM.



blinky.c:12: warning: no previous prototype for 'UART_Read'
blinky.c: In function 'UART_Read':
blinky.c:15: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
blinky.c:40: error: storage class specified for parameter 'number'
blinky.c:40: error: parameter 'number' is initialized
blinky.c:41: error: storage class specified for parameter 'base'
blinky.c:41: error: parameter 'base' is initialized
blinky.c:43: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
blinky.c:58: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
blinky.c:68: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
blinky.c:76: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
blinky.c:84: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
blinky.c:93: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
blinky.c:102: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
blinky.c:112: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
blinky.c:132: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
blinky.c:151:2: warning: no newline at end of file
blinky.c:150: error: old-style parameter declarations in prototyped function definition
blinky.c:150: error: expected '{' at end of input
make: *** [blinky.o] Error 1


That is the from the same code that I added to the thread in the advanced thread. And if I put the Uart_Read code in there I still get the warning: no previous prototype for 'UART_Read' error. I will freely admit that alot of the c code is over my head at the moment. But I am willing to learn.

[jvvh5897]

I made a note in advanced section about the blinky you were using. But lets cover some of those error messages--they pretty much tell you what you need to fix.

"blinky.c:151:2: warning: no newline at end of file" tells you that you need to put a return at the last line in the file--don't know why that is needed, but it wants it, so give it to it.

"blinky.c:12: warning: no previous prototype for 'UART_Read'" tells you that you haven't supplied the needed info for UART_Read, but as pointed out in advanced section, that is not the routine used any more. But the real problem in your blinky is the missing semi-colon after your UART_Read prototype at line 12.

[jvvh5897]

What I am trying to do is find out where the A5 sequence it coming in after the realterm string, if at all. Because I am not finding it in anywhere in the dumps I am doing. Even a part of the string. And if I knew where to look specifically in the dump it would help, which is where I was going with trying to put that string in the code.


You have been posting that you find the A5 sequence in the RX buffer (char* rxQueue=0x57D1C8)--you showed it as ascii rather than hex but it seemed in there to me.

Now if you use the right code to read from the RX buffer, then char* my_buf=0x4953c0; specifies were you will copy the sequence. I don't know what part of the RAM you are dumping but that is were the code I suppied will try to put it. That 0x4953c0 address is part of the 2nd image area, so you should be dumping part of RAM with part of your box's code.

BTW, have you tried to do a full dump of your flash with the provided RAM dump code yet? I would have.

[skywalker999]

Well guys there is a good chance that the pany 9200HD project is dead but still good for FTA anyways, i guess it's all up to dualtest now to try and revive the beast, i still have hope that dualtest will figure it out and come out with a fix :thumbsup:

[DualTest]

Well guys there is a good chance that the pany 9200HD project is dead but still good for FTA anyways, i guess it's all up to dualtest now to try and revive the beast, i still have hope that dualtest will figure it out and come out with a fix :thumbsup:

Not dead by a long shot. Things have changed a little with the scripts so it may take me awhile to figure what needs to be done.

[jvvh5897]

Frankly, I have no idea why you are trying to make DualTest do it all alone. There should be discussions about how to do it and how YOU can help.

[DualTest]

There are a few things I would like to add. First of all, thanks to jvvh for the support and free education. skywalker999 figured things out that I haven't figure out. But I know what you are getting at, it's time that everyone that wants to see this project through steps up and adds something. Two heads are better than one, and ten heads would get it done in no time. I have never quit on anything in my life and don't plan to start now. And will eventually finish it, if satellite tv is still around then well... The things I have learned on this project are invaluable to me. Whether I get an Pansat 9200HD IKS bin out of this, really is secondary. I am trying figure out what makes these receivers tick. And having a hell of time doing it. Half the time I am looking at a disassembly wondering what makes this file make my receiver reboot and the other times I am wondering what I did to make the ECM string disappear. Call me crazy but finding out the answers to that is fun to me. I find it very unlikely I am the only one.

[skywalker999]

guys i was only trying to spark up this thread a little bit and from what i read on the advance section it got me worried
so dualtest if you want or need i could post the last script that made the receiver go crazy and maybe jvvh could see what was wrong, to me that script was not far from what it needed it was just a case of sending the cws to the wrong address or processed wrong anyway it's just my thoughts

[DualTest]

This is the script I have to deal with the incoming packet. I am using it to replace the Uart_read script and the other one that was at 459300.



REM put this code at 495300
ADR $253F00
OVERWRITE F0 B5 16 4B 1C 68 04 33 1E 68 FF F7 F7 FF 07 1C
OVERWRITE 00 28 15 D1 B4 42 13 D0 00 25 B4 42 0A D0 10 4B
OVERWRITE E2 5C 10 4B EA 54 62 1C 0F 4B 14 1C 1C 40 01 35
OVERWRITE B4 42 F4 D1 19 2D 07 DD 0A 4B 1B 78 A5 2B 07 D0
OVERWRITE 38 1C F0 BC 02 BC 08 47 10 20 FF F7 D3 FF E4 E7
OVERWRITE 10 20 06 49 FF F7 D0 FF F2 E7 00 00 D8 D9 57 00
OVERWRITE C8 D1 57 00 C0 53 49 00 FF 07 00 00 C9 53 49 00

REM mod the 282A50 BL sub_241F18 ; memcmp call to call the above

ADR $0
FIND BF F7 62 FA
OVERWRITE 12 F2 56 FC


And it looks great. But causes the receiver to reboot as soon as it hits a channel. And looking at the disassembly it would seem that the file loops there and never comes out of this routine. I could be wrong. Anyway just wanted to update where I was at.

[jvvh5897]

I believe the code is looking for 0xa5 sync byte at the start of the packet from PC--if it has to loop through a bunch of "realterm" strings or never finds it then that could be a problem. The UART_Read code is usually set up as a task on its own rather than sitting in a task in ecm handling task--it could be made to work there (and I seem to recall that that is what I tried to do, but every week that has gone by has me remembering less and less), but you guys are going to have to figure it out. Dump the RX circular buffer and see if the data is being read at all (there are RX in and RX out byte counts that tell you if the number of bytes waiting to be read is the same as has been read and if they are the same then the buffer has been read--I've talked about this in the past).

Over at the interesting devices site, you can read old archived thread on how the guys worked on figuring out RSA calculations--really neat to watch lots of folks working to figure out something that was actually hard--working with very big numbers in a math problem, after dumping card contents and reversing the code-lots of work, lots of folks trying. Here it is just a dis-appointment-- no one working together, a simple problem (relatively, after one gets given where one has to mod and given tools)--just sad that so few folks are willing to put in effort to help themselves.

[DualTest]

I have updated Uart_Read/ECM task script.

The changes are:

ROM:0049530A BL sub_241F18 ; memcmp
ROM:0049534A BL sub_2CC2C0
ROM:00495354 BL sub_296E70



REM put this code at 495300
ADR $253F00
OVERWRITE F0 B5 16 4B 1C 68 04 33 1E 68 AC F5 05 FE
OVERWRITE 07 1C 00 28 15 D1 B4 42 13 D0 00 25 B4 42
OVERWRITE 0A D0 10 4B E2 5C 10 4B EA 54 62 1C 0F 4B
OVERWRITE 14 1C 1C 40 01 35 B4 42 F4 D1 19 2D 07 DD
OVERWRITE 0A 4B 1B 78 A5 2B 07 D0 38 1C F0 BC 02 BC
OVERWRITE 08 47 10 20 36 F6 B9 FF E4 E7 10 20 06 49
OVERWRITE 01 F6 8C FD F2 E7 00 00 D8 D9 57 00 C8 D1
OVERWRITE 57 00 C0 53 49 00 FF 07 00 00 C9 53 49 00

REM mod the 282A50 BL sub_241F18 ; memcmp call to call the above

ADR $0
FIND BF F7 62 FA
OVERWRITE 12 F2 56 FC


Which has solved the reboot issue. And will add an 8 meg ram dump of the changes for those interested.

[skywalker999]

and Dualtest what are we looking for on the ram dump :noidea:

[DualTest]

and Dualtest what are we looking for on the ram dump :noidea:

I sent the CW bin to the receiver and this was to check to see if it got copied to the spot pointed to in the script. Which it didn't, but I thought I would upload the dump just in case there was something in there I missed.

[skywalker999]

Well Dualtest looks like your all alone bummer i guess jvvh is right people here don't work together i am sure there is more guys here that could help
Dualtest don't give up :thumbsup: