Any interest in sw modding?

[jvvh5897]

Lack of documentation of what you are up to make it hard to help you. No address of where you started the dump, nothing about where you find the code you put in or the rx buffer, or what you have sent the serial port and in what order. You post 8 meg of stuff that boils down to a few kbyte of actual stuff worth posting.

Once I disassembled the code that tries to read the rx post I find it not doing what it should. Though it does try to read from the serial port rx buffer (I think) it does not try to update the variables that it reads (rxqueuefree or rxindexout). There is at least one variable that it should update that is not in the code at all. The call to memcompare is buried a few instructions into the code rather than first thing after the push of registers. I faintly recall writing a post here about how I had trouble getting the code to compile with casts coming the way they needed to be--I'm guessing you have the same trouble.

[jvvh5897]

YOu might want to look in the box's code for the rx handler--it does pretty much what you have to do. Rx handler pulls in bytes from a buffer (pointed to by R5) stores it in a buffer pointed to rxin index and updates the contents of the in index and subtracts from the rxqueuefree. You have to pull in from the rxqueue, store in a buffer, update rxout index and rxqueuefree (incrementing both). So if what you use does not look a lot like the rxhandler then something is wrong. You might want to look at coolsat 5000's source code (I've suggested that over and over).

[DualTest]

I see what you mean on the rxhandler. I actually tried to use that subroutine at one time, but obviously it is used for other purposes. I will take a closer look at it now. I will have to hunt down the coolsat 5000 source code, I don't see it on here or any other sites I go to.

[skywalker999]

Dualtest check on the coolsat 5000 files upload done here at the fix

[jvvh5897]

Bump. Figured a month was too long not to see something here.

[skywalker999]

that goes for me to wow how time flies and poor Dualtest with wife and kids and is left all alone trying resolve what's left to finish the job

well jvvh why not give Dualtest an extra hand and post the rest of the script that he needs :noidea:

[DualTest]

Bump. Figured a month was too long not to see something here.

I haven't taken a look at it for about a week. I am trying to quit smoking and that is frustrating enough.

The last thing I was trying to do was rewrite the Rxhandler routine, to use as a replacement for the uart_read script. I will post what I have later today when I get a minute.

[jvvh5897]

I posted everything that I worked on for the project--that was all that I could do without having a box to play on (and, no, I'm not interested in having a box to play on--I don't do IKS in any form)

[skywalker999]

gees jvvh nobody is offering you a box to play with at first we were only suppose to test the scripts that you posted
and how hard can it be for someone that knows how to script to make ascript to read the incoming cws and send it to were ever it needs to go on the bin or ram address i'm still waiting to test some more

like the cable guy says let's get it done

Dualtest i know what you mean about quit smoking, me i never smoked a cigaret in my life but i smell like i smoke 3 packs a day all because i have two bros that smoke like hell

[DualTest]

This is very much a work in progress and I know it contains mistakes. But it is what I am working on.



REM put this code at 495300
ADR $253F00
OVERWRITE B0 B5 AC F5 09 FE 04 1C 0D 1C 16 48 00 68 00 28
OVERWRITE 23 D0 29 1C 20 1C 12 4A 12 68 13 48 00 68 00 28
OVERWRITE 1B D0 61 1E 04 1C 43 1C 3A D0 29 78 01 35 0C 48
OVERWRITE 10 30 00 68 42 1C 0A 4B 10 33 1A 60 0A 4A 11 54
OVERWRITE 18 1C 00 68 40 05 40 0D 19 1C 08 60 05 48 00 68
OVERWRITE 01 38 10 39 08 60 01 F6 8B FD B0 BC 08 BC 18 47
OVERWRITE CC D9 57 00 D8 D9 57 00 76 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 F




ROM:00495300 sub_495300 ; CODE XREF: sub_282A44+Cp
ROM:00495300
ROM:00495300 var_2C = -0x2C
ROM:00495300
ROM:00495300 PUSH {R4,R5,R7,LR}
ROM:00495302 BL sub_241F18 ; memcmp
ROM:00495306 MOVS R4, R0
ROM:00495308 MOVS R5, R1
ROM:0049530A LDR R0, =0x57D9D8
ROM:0049530C LDR R0, [R0]
ROM:0049530E CMP R0, #0
ROM:00495310 BEQ loc_49535A
ROM:00495312 MOVS R1, R5
ROM:00495314 MOVS R0, R4
ROM:00495316 LDR R2, =0x57D9CC
ROM:00495318 LDR R2, [R2]
ROM:0049531A LDR R0, =dword_495376
ROM:0049531C LDR R0, [R0]
ROM:0049531E CMP R0, #0
ROM:00495320 BEQ loc_49535A
ROM:00495322 SUBS R1, R4, #1
ROM:00495324 MOVS R4, R0
ROM:00495326 ADDS R3, R0, #1
ROM:00495328 BEQ loc_4953A0
ROM:0049532A LDRB R1, [R5]
ROM:0049532C ADDS R5, #1
ROM:0049532E LDR R0, =0x57D9CC
ROM:00495330 ADDS R0, #0x10
ROM:00495332 LDR R0, [R0]
ROM:00495334 ADDS R2, R0, #1
ROM:00495336 LDR R3, =0x57D9CC
ROM:00495338 ADDS R3, #0x10
ROM:0049533A STR R2, [R3]
ROM:0049533C LDR R2, =dword_495376
ROM:0049533E STRB R1, [R2,R0]
ROM:00495340 MOVS R0, R3
ROM:00495342 LDR R0, [R0]
ROM:00495344 LSLS R0, R0, #0x15
ROM:00495346 LSRS R0, R0, #0x15
ROM:00495348 MOVS R1, R3
ROM:0049534A STR R0, [R1]
ROM:0049534C LDR R0, =0x57D9D8
ROM:0049534E LDR R0, [R0]
ROM:00495350 SUBS R0, #1
ROM:00495352 SUBS R1, #0x10
ROM:00495354 STR R0, [R1]
ROM:00495356 BL sub_296E70
ROM:0049535A
ROM:0049535A loc_49535A ; CODE XREF: sub_495300+10j
ROM:0049535A ; sub_495300+20j
ROM:0049535A POP {R4,R5,R7}
ROM:0049535C POP {R3}
ROM:0049535E BX R3
ROM:0049535E ; ---------------------------------------------------------------------------
ROM:00495360 dword_495360 DCD 0x57D9CC ; DATA XREF: sub_495300+16r
ROM:00495360 ; sub_495300+2Er ...
ROM:00495364 dword_495364 DCD 0x57D9D8 ; DATA XREF: sub_495300+Ar
ROM:00495364 ; sub_495300+4Cr
ROM:00495368 off_495368 DCD dword_495376 ; DATA XREF: sub_495300+1Ar
ROM:00495368 ; sub_495300+3Cr
ROM:0049536C DCB 0xFF
ROM:0049536D DCB 0xFF
ROM:0049536E DCB 0xFF
ROM:0049536F DCB 0xFF
ROM:00495370 word_495370 DCW 0xFFFF ; DATA XREF: sub_495280+12o (CAID)
ROM:00495370 ; sub_495280+14w ...
ROM:00495372 DCB 0xFF
ROM:00495373 DCB 0xFF
ROM:00495374 DCB 0xFF
ROM:00495375 DCB 0xFF
ROM:00495376 dword_495376 DCD 0xFFFFFFFF ; DATA XREF: sub_495300+1Ao (Test CW Buffer)

[DualTest]

And the second part of that, I may not need it as all of it may be accomplished with the above script. But since I have it linked to the above subroutine at the moment, I thought I would post it also.



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 DC D9 57 00 C8 D1 57 00




ROM:004953A0 ; ---------------------------------------------------------------------------
ROM:004953A0
ROM:004953A0 loc_4953A0 ; CODE XREF: sub_495300+28j
ROM:004953A0 PUSH {R0-R2,R4-R7,LR}
ROM:004953A2 MOVS R7, R0
ROM:004953A4 MOVS R5, R2
ROM:004953A6 MOVS R6, #0
ROM:004953A8 B loc_4953EA
ROM:004953AA ; ---------------------------------------------------------------------------
ROM:004953AA
ROM:004953AA loc_4953AA ; CODE XREF: sub_495300+EEj
ROM:004953AA MOVS R4, #0
ROM:004953AC B loc_4953C6
ROM:004953AE ; ---------------------------------------------------------------------------
ROM:004953AE
ROM:004953AE loc_4953AE ; CODE XREF: sub_495300+CEj
ROM:004953AE CMP R5, #0
ROM:004953B0 BEQ loc_4953BE
ROM:004953B2 CMP R4, R5
ROM:004953B4 BCC loc_4953BE
ROM:004953B6 MOVS R0, #1
ROM:004953B8
ROM:004953B8 loc_4953B8 ; CODE XREF: sub_495300+F2j
ROM:004953B8 POP {R1-R7}
ROM:004953BA POP {R3}
ROM:004953BC BX R3
ROM:004953BE ; ---------------------------------------------------------------------------
ROM:004953BE
ROM:004953BE loc_4953BE ; CODE XREF: sub_495300+B0j
ROM:004953BE ; sub_495300+B4j
ROM:004953BE MOVS R0, #0xA
ROM:004953C0 BL sub_2CC2C0
ROM:004953C4 ADDS R4, #0xA
ROM:004953C6
ROM:004953C6 loc_4953C6 ; CODE XREF: sub_495300+ACj
ROM:004953C6 LDR R2, =0x57D9DC
ROM:004953C8 LDR R0, [R2,#0x44]
ROM:004953CA LDR R1, [R2,#0x40]
ROM:004953CC CMP R0, R1
ROM:004953CE BEQ loc_4953AE
ROM:004953D0 LDR R0, [R2,#0x40]
ROM:004953D2 LDR R3, =0x57D1C8
ROM:004953D4 ADDS R1, R0, #1
ROM:004953D6 LDRB R0, [R3,R0]
ROM:004953D8 STRB R0, [R7]
ROM:004953DA ADDS R7, #1
ROM:004953DC LSLS R0, R1, #0x15
ROM:004953DE LSRS R0, R0, #0x15
ROM:004953E0 STR R0, [R2,#0x40]
ROM:004953E2 LDR R0, [R2,#0x34]
ROM:004953E4 ADDS R0, #1
ROM:004953E6 STR R0, [R2,#0x34]
ROM:004953E8 ADDS R6, #1
ROM:004953EA
ROM:004953EA loc_4953EA ; CODE XREF: sub_495300+A8j
ROM:004953EA LDR R0, [SP,#0x30+var_2C]
ROM:004953EC CMP R6, R0
ROM:004953EE BCC loc_4953AA
ROM:004953F0 MOVS R0, #0
ROM:004953F2 B loc_4953B8
ROM:004953F2 ; End of function sub_495300
ROM:004953F2
ROM:004953F2 ; ---------------------------------------------------------------------------
ROM:004953F4 dword_4953F4 DCD 0x57D9DC ; DATA XREF: sub_495300:loc_4953C6r
ROM:004953F8 dword_4953F8 DCD 0x57D1C8 ; DATA XREF: sub_495300+D2r

[skywalker999]

well jvvh i'm sure Dualtest is still waiting for a comment about is latest work it would be greatly appreciated

[jvvh5897]

Why should I comment? It is up to you guys that own the box to try out his work at this point. Use your brains and test it!

[skywalker999]

well jvvh if dualtest wanted me or others to test his latest script he would of asked just to see if we would get the same results
from what i read on his post he wants someone with experience to point out if or what errors the scrip has but this is only my opinion
i am sure you are a very busy man with other projects :thumbsup:

[skywalker999]

so dualtest have you made any good progress

[skywalker999]

Guess not o well it's going back to the closet even jvh gave up on it i tink this must be a first for jvh :nopity:

[nunoit]

i don't think JVVH has totally given up just waiting to see if the topic is worth pursuing. what we need are more volunteers to continue the testing not looky loos like little kids waiting for the candy store to open.

i have no receiver to test with, nor do i want one, i am sure i could buy one on flee bay real cheap. also my lappy was reformatted without ida-pro installed. i have bin playing with other things.

i have read this post once and see there is progress still needed. like finding Caid address and saving returned cw's

let me add i am not a coder as JVVH will attest to that. but with help from the community the release of the following receivers was possible. pansat 2500,2700,3500, vs platinum,extreme and ultra, and also the recently released sonicview 4000, elite, premier, and the ihub emu files.
if this testing is to benefit the community then the community need to help out.

thanks to all those that really put there effort in this project. special thanks to JVVH for all your help in the community.

N.U.NO.IT

[skywalker999]

good to see you here nunoit, that's exactly what have been trying to do is get other members of the community involved specially the ones that worked on the older panys now my question is was there a big difference how the pany 2700 bin and the 3500 and the way they processed and store the cws and i don't think there is much difference how the pany 9200hd bin works also but what do i know i am not the expert here and far has testing you should leave that to dose that have the pany 9200hd and know how to use XVI32 hex program to apply any changes to the bin we have been working on
and nunoit i know that jvvh has done hall he could do but unfortunately we didn't make it yet
and nunoit i don't think you will find a pany 9200hd on flee bay dose that have one they are holding on to them now lets see if other members pinch in also

[DualTest]

i don't think JVVH has totally given up just waiting to see if the topic is worth pursuing. what we need are more volunteers to continue the testing not looky loos like little kids waiting for the candy store to open.

i have no receiver to test with, nor do i want one, i am sure i could buy one on flee bay real cheap. also my lappy was reformatted without ida-pro installed. i have bin playing with other things.

i have read this post once and see there is progress still needed. like finding Caid address and saving returned cw's

let me add i am not a coder as JVVH will attest to that. but with help from the community the release of the following receivers was possible. pansat 2500,2700,3500, vs platinum,extreme and ultra, and also the recently released sonicview 4000, elite, premier, and the ihub emu files.
if this testing is to benefit the community then the community need to help out.

thanks to all those that really put there effort in this project. special thanks to JVVH for all your help in the community.

N.U.NO.IT

Everything works, but like you said the CAID (which can be put in by the remote, either 1815 or 1816 if I remember correctly) and the return/storing of the CW's are the only problems I couldn't resolve. That is where it sits now.

I have had no time since the summer started to even get on these sites much. And now with renovations going on I have had to take down my dish. I am willing to add as much help as I can, although testing will be a problem without a dish for now.

[skywalker999]

good to see you here again Dualtest well i have lots of time to test just PM or post and will do the testing, maybe the part of the script that stores the cws could be copied from the pany 3500 just a though you never know it myth work hum :noidea:

[nunoit]

some of the ideas you have sound good from what little i seen of the code it looks very similar to the viewsat code. i would have to setup up and actually look at it. let me look in my old files to see what i have saved and see if any of that info could be used here. let me do some digging.

skywalker999, DualTest do you have any of the old 2700,3500 mod info to be able to do comparison with. you claim they should be similar. it would also help if you had a through break down of the 9200 code segments. JVVH had posted those for the other receivers

[nunoit]

this is a sample of a the routines the receiver uses, this is what i am talking about this one is for the viewsat extreme.


00283920 ; hexdump using traceout
00278F34 ; call traceout
002EE458 ; traceout
0027FB6C ; cnxt_dmx_descrambler_set_even_keys
0027FC3C ; cnxt_dmx_descrambler_set_odd_keys
0028615C ; DESCRAM_SetKeys
00285CC8 ; NAGR_ProcessEcmData
00296B80 ; HC_DEMUX_Command?

ROM:002A9104 CMP R0, #0x20
ROM:002A9106 BNE loc_2A90EC
ROM:002A9108 BL sub_292E84--do a serial read
ROM:002A910C CMP R0, #0
ROM:002A910E BLT loc_2A90EC
ROM:002A9110 CMP R0, #0xFF
ROM:002A9112 BNE loc_2A90EC
ROM:002A9114 BL sub_292E84--do a serial read

oooh and the image mod was set to use only one image. the mod was designed to use the same pic for all screens. from what i remember was not hard to do.

also there are 3 things left to do find caid,find where returned cw's are saved, and the final call to add the returned cw's to the descrambler routine to display video.

[skywalker999]

nunoit i think all the stuff for the Fortec-Pansat-2500 and 2700 is still here on the advance section

www.satfix.net/forumdisplay.php?797-Fortec-Pansat-2500-Section
dont hnow if this helps

[jvvh5897]

From what I saw, the code was quite a bit different than the older pansat boxes because of the processor and the way it works. What I was trying to get the guys to do was loosely based on what worked with the older boxes, just needed to do lots of differently. Much was very similar to the Viewsat though, though we had to mod just to get serial port to work and to get the cmd07 packets to come in--that was a pain with this box.

[nunoit]

Glad to hear from you again JvvH. i thought the snippets looked closer to viewsat code from my memory. did you ever get a break down of the routines. like you i would be playing without a testing device, (otherwise blind). so if there aren't testers out there this topic will be moot.

so i hope there are some real testers out there this time, you will need to disassemble, search, mod, edit, reassemble, and test each phase until there is a finished product. your eyes will get tired of looking at code. so get ready to learn something new.

lets get together all the tools such as ida-pro, the hex editors, anything else needed to get started. lets all get started on the same page. its time to get serious.

testing means just that trial and error. build, load, test, post results. don't rush." haste makes waste"

if you are not part of the solution then your part of the problem, please don't post unless you are contributing valid info. we all have busy lives i am sure no one wants to waste their time.

[nunoit]

some of the programs you will need terminal emulators, realterm, putty, hex editors, xvi32, hex_workshop v4.2.3, code disassembler, ida-pro and an idc to aid disassembly for it.

i have most of the code mods that was used on the vs platinum, and extreme. i could not find any old file used on the pansat 2500,2700 mods.

[jvvh5897]

Yes, I supplied labels for routines in at least two files for these boxes (might have been more--the project went on for a while). Then I showed how to call them and supplied commented disassembly for the areas of interest. I supplied winarm source code for some mods and showed how to compile them and offered modded code based on that compiled code.

[nunoit]

i will look for it thanks

[skywalker999]

nunoit if i am not mistaken there is a disassembled parts of the femu bin on page 4 on this thread

[jvvh5897]

One thing that might be causing some trouble (like in where the CAID is) was the serial dump routine--I was never sure that the number of bytes they got out was what the code called for. I was not doing the dumps so I figured that the ones doing them were the ones to be looking at stuff like that, but if the RAM addr that the dump showed was not a real addr, one can see an issue there.

[skywalker999]

With that said jvvh what would be the extra settings on realterm to make sure that we get the right size number of bytes on the ram dump

[nunoit]

if you have a receiver make or load the dump bin then while on a scrambled channel preform the dump save result. then post

[skywalker999]

but there is already ram dumps on the advance section unless you want a new one nunoit if that's the case then i will have to power up the old laptop

[nunoit]

starting to load pc to look at the files and such. going to need to play catch up so give me a little time.

[skywalker999]

no problem take all the time you need but i have a couple of questions about the settings on realterm first do we do a ram dump as in hex or ascii next and the settings on bytes size do we change anything
I am asking this because jvvh said that maybe the ram dumps were not done correctly

[nunoit]

its bin a while since i played with real term i be leave it was set to ascii and capture started before dump was started. also need to know what channel you were on at the time.

[skywalker999]

ok i am going to ad a new capture on the advance section just in case it's needed but so far i don't see nothing different

[nunoit]

i don't know how much testing you guys have done i am starting from scratch here and i don't have a testing device.

[jvvh5897]

I usually have Reaterm showing info as hex, but I don't think it matters when you capture--it should just capture whatever comes in the serial port. The point I was making with my comment about the dumps was that the routine used to send out data from the box may not be doing it right, not that your captures were wrong. If the routine does not test correctly for the serial port being ready for more info to send out then some info may get dumped in and not make it to the TX port. So, what you should look for is the size of what you get in your files--does it match what you programmed the routine to send out. If what you program and what you get does not match, then you should test for what is going on--is it random, does it depend on the size you tell the box to send out--look at the code that I lifted to see what it does do and what it doesn't.

[nunoit]

what's the starting address for ida anyone please. just playing catchup.

[skywalker999]

Nunoit i think this is what your looking for this is a c/p from page 7 of this thread posted by jvvh there is more info there

C/P 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.

[skywalker999]

jvvh with this part of the script where wee change the size of the ram dump
on realterm i am getting RXD and TXD when i am doing a ram dump
this is what i used and i' am getting just over 9 megs of ram dump should i get more or less

OVERWRITE 01 12 00 00

[jvvh5897]

You should be able to figure that out yourself--how many bytes dumped per execution of the loop, how many loops, multiply them together and you have an answer.

[DualTest]

okay I finally found a few moments to look at this again. The problem of the CW's is at 459300 address of the disassembly. By looking at the flow chart at that address it gets confusing but I believe that if some can make sense out of that we may make some progress. This where I left off. These are all the changes to the 081111 file.



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

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

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

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

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

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

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

[skywalker999]

thanks jvvh if my calculation are right then 01 12 00 00 should give 9 megs ram dump
Glade to see you back Dualtest i think wee should change the 40 18 00 00 to 16 18 00 00 do a ram dump then compare it with other ram dumps and see if there's any difference

[jvvh5897]

Why not dump the flash? Then you can do a simple compare and see if you have all the info. (I have suggested that many many times)

[skywalker999]

Well guys just posted a new ram dump this time done with the 16 18 00 00 string instead of the 40 18 00 00 and to me it looks different and maybe it appears to have more info for dose interested just take a look and maybe whats missing is there
and this string is in a different ADR 09 04 18 40 (ADR 215FD4) previous ADR with string 40 18 00 00 was always on this ADR 279879

[nunoit]

what channel were you on. and what are we supposed to looking for caid or returned cw's.

look at page 9 post 133 to see what to look for ecm packets. if i am not mistaken.

[skywalker999]

nunoit the channel was 105 and the ecm packets are the (80 30 8f 07 8d) or (81 30 8f 07 8d) the reason i posted the last ram dump it's because i changed the two spots on the bin 081111 from 10 18 00 00 to 16 18 00 00 in order to get the ecm packets 80 30 or 81 30 8f 07 8d but if we change dose two spots to 40 18 00 00 we get the ecm packets 8030 or 8130 a2 07 a0
and do ram dump and compare the ram dumps done with the 40 18 00 00 and the ram dump done with the 16 18 00 00 and it looks to me that they are differences in them but only someone with experience would know if they are help full or not

[nunoit]

well i found with xvi23 the ecm string (80 30 8f 07 8d) at 2b614, 2b714, 43593, 46266, 51a14, etc. and (81 30 8f 07 8d) at 49b91f, 526ec7, 55c00c, 5c1902, 5dd720, etc.

since there so many different spots i would assume to look not only the ecm info but maybe channel info ether inverted (05 01) or hex format (69). i may be wrong.

what you could do i suppose would be to get the suspected address and in the script change to call that address. then you could look with ida to see if the right info is displayed. then you could try in receiver to see if the request to server i has the right info.

while looking with xvi23 i noticed that at 2b614, (244014), 2b714,(244114) the info there in both locations is identical and 91 bytes which is about the size of the tx packet to send for cw packets.

the way i got address 2b614, (244014), was to take 2b614 + 241400 starting address to get ram address 244014. if this correct you will have to calculate how to get there from the address the call was made.

JVVH correct me if i am wrong please.

[nunoit]

what idc are you folks using. just to be on the same page. the script i downloaded is full of errors.

[DualTest]

http://www.satfix.net/showthread.php?144462-Pansat-9200HD-File-for-testing-how-to-mod-files

The IDC in post #2 in that thread. It does contain errors at the end but I assumed that was because it was adapted from another receivers IDC. The errors don't seem to affect the disassembly though.

[nunoit]

i have tried that must be something in the ida setup. i keep getting syntax error near static and don't run.i did force de-compile through ida.

i have bin setting up hd-9200bk_pvr_090607_api_femu.bin as arm at 241400 load and start address then i highlight the entire script and use the cod button to view all functions.

[DualTest]

i have tried that must be something in the ida setup. i keep getting syntax error near static and don't run.i did force de-compile through ida.

i have bin setting up hd-9200bk_pvr_090607_api_femu.bin as arm at 241400 load and start address then i highlight the entire script and use the cod button to view all functions.

I can't recreate that error. So it has to be something in the IDA setup.

[nunoit]

my bad i did not uncompress the file first lol

BTW: all that happened was ida locked up so i did not run the idc.

next i would like to know which file and which mods you did to what file. (please post the page and post #) i want to duplicate those and post my findings for testing.

[skywalker999]

just to let you guys know that i tested that script that dualtest posted and xvi32 gave me error and found also that it contains two times the same pat of the script first the error is in this part of the 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

always-branch as needed
ADR $0
FIND 03 23 DB 02 98 42 1C D1
FIND 1C D1
OVERWRITE 98 42

it should be like this

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

and this part of the script is doubled up

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

i fixed dose two error and tested on the receiver but of course it doesn't work
sssq gives me a caid mismatch and video and audio pids are not there they show as 4 zeros like this video pid 0000 audio pid 0000

[DualTest]

my bad i did not uncompress the file first lol

BTW: all that happened was ida locked up so i did not run the idc.

next i would like to know which file and which mods you did to what file. (please post the page and post #) i want to duplicate those and post my findings for testing.

This is the file that we have been working with, Post #1:

http://www.satfix.net/showthread.php?144462-Pansat-9200HD-File-for-testing-how-to-mod-files

It is this file, with the radio mpg replaced with a smaller one to give us room to mod.

http://www.satfix.net/showthread.php?143947-HD-9200BL_pvr_081111_9296_api

This is a list of routines from early testing, Post #80. Post #81 is the script for the ram dump.

http://www.satfix.net/showthread.php?141441-Any-interest-in-sw-modding/page6

This part of the script is the sssp output, Post #215.

http://www.satfix.net/showthread.php?141441-Any-interest-in-sw-modding/page15

This increases the buffer area needed for the sssp output. Post #159

http://www.satfix.net/showthread.php?141441-Any-interest-in-sw-modding/page11

This inputs the CAID by the remote, Post #188.

http://www.satfix.net/showthread.php?141441-Any-interest-in-sw-modding/page13

This contains some info on the C coding and WinARM stuff for the CW's. Posts #3 and #4.

http://www.satfix.net/showthread.php?144462-Pansat-9200HD-File-for-testing-how-to-mod-files

More info on the return packet and storage, Post #164 and #165

http://www.satfix.net/showthread.php?141441-Any-interest-in-sw-modding/page11

And Post #166

http://www.satfix.net/showthread.php?141441-Any-interest-in-sw-modding/page12

And basically everything from page 15 on of this thread deals with the return packet and the CW storage.

Hope that helps.

[nunoit]

hears is what i have done so far i took the bl 81111 bin and modded with what i found on first post see if you got the same results.

[DualTest]

hears is what i have done so far i took the bl 81111 bin and modded with what i found on first post see if you got the same results.

Yes I get the same results.

I made a few changes to the 459300 section of the disassembly

REM put this code at 495300
ADR $253F00
OVERWRITE F0 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 00 F0 3E F8 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 98 FD
OVERWRITE F5 E7 00 00 DC D9 57 00 60 53 49 00

I changed the beginning to take out the memory chunk, and changed 495320 to point to 4953A0 and 49533C to point to the Save CW's.

As per the routines provided in Post #80
http://www.satfix.net/showthread.php?141441-Any-interest-in-sw-modding/page6

[nunoit]

i see your setting space for returned cw's. question have you found the correct caid info yet. one thing i read yesterday might be worth looking at again i will post. might even have to look into the autorole section as well, with out that data you wont receive valid cw's.

i still have some of the vs scripts if they can be edited to use in the panny.
you know when the vs was modded the radio background was not used file was changed to only use the first image.

[DualTest]

i see your setting space for returned cw's. question have you found the correct caid info yet. one thing i read yesterday might be worth looking at again i will post. might even have to look into the autorole section as well, with out that data you wont receive valid cw's.

i still have some of the vs scripts if they can be edited to use in the panny.
you know when the vs was modded the radio background was not used file was changed to only use the first image.

The CAID location is still a mystery. But I haven't really looked at the last dump that was done.

[jvvh5897]

You might want to look at the code in the nagra decrypt section for places where the caid are tested, see what they do to get that ID and try it that way rather than just looking in RAM dumps. You might find that the CAID is passed as pointer in the stack, so a dump of stack might be a good thing to look at--find the right spot in stack to read pointer from. Just a guess though.

[jvvh5897]

Or, remember that one mod is to change an ID to allow the newer DN packets to come in--that was a mod to a place that tested the provID.You might want to mod the code so that the ID being tested is saved in a spot where you could retrieve it.

[skywalker999]

has this thread gone cold again

[nunoit]

like i said from the beginning i don't have one of these receivers so no real need for me to come up with a fix. so some of you folk's that actually have one are the ones that need to do the testing.

sorry if the post goes cold.

[iq180]

Why is this in the all other receiver section when it should be in the (Other advanced testing discussion) section.
Now this wouldn't be a problem where it is but there are too many post that don't add any info and are only posted as a bump.

[skywalker999]

Well nunoit i didn't think you would trow in the towel so fast but maybe your in luck there is a member here willing to part with one of is receivers for testing purposes that's if jvvh didn't take it already

member name = cw78836

C\p from his post

Alcon,
Have two of these boxes (minus HD mod) sitting around and collecting dust. If you have intentions of completing this project, you are welcome to use one of these boxes for testing !!!!

Please send pm or email, don't panic if no prompt response, I travel a lot.

[jvvh5897]

I don't want it.

[skywalker999]

is there a way to see the scripts in c++ instead of hex

[jvvh5897]

Well, in most cases I posted the C source that I used to generate the machine code. But for some of it, I hand coded or lifted the machine code from box code and did a little hand coding to that. For box code lifted from coolsat code, you can look at the coolsat5000 source code.

[skywalker999]

wow it has been a long time with out something new anyway well i keep reading the old threads of the pany 2500 2700 and 3500 and jvvh you commented this

CP

Hum, decided to try my hand at writing the send of the sssp packet out the serial port as source code. I'm including what I came up with and steps along the way. Disassemble of most of the old code with comments (made me look at an old RAM dump to see if what I was doing was good and there in the channel data was the provID ) --not sure when I did that dump, must have been after I wrote the old code and after a new scan of the sat I was pointed at. So, in the C code I read that location for the ID (sssp.c, bat file

now is it possible that this would be the same for the missing provider ID on the pany 9200hd
i don't think BL would change something that works well on older receivers and do something different on a newer box well i could be wrong :yes:

[skywalker999]

So nunoit could you post the VS modes or scripts please or pm

[jvvh5897]

BTW, this effort could pay off if the powervu effort does--the things you learn about the code of your HD ready box might be of use if you wanted to do PVu

[skywalker999]

Jvvh that would be a great project but, the previous project is not finished yet
And I just hate to see all that work and time spent looking at code and modes to revive the pany 9200hd to do iks and not finish it, go to waste.
You know that it wont be easy to get other community member involved you said it yourself that the community members don’t work together like the old days to fix a problem

And now I have a couple of questions I looked at this VS bin ( DBPSW-071031p-sssp ) and I see that they have exactly the same offset (h) and from adr 00000020 to 00000110 it’s the same also then it start’s to differ a bit
And it’s tempting for me to load that bin on the pany 9200, but what’s keeping me from doing that is what if I can’t recoup the receiver from a bad flash, is the boot file included in the bin

My second question if I have a ram dump that should have cws in it how do I find them and see if they are really going where they are suppose to go, and I know that there is a way to do that with realterm, but sense I have a ram dump with valid cws what hex strings should I be looking for.

To tell you the truth I don’t even need to be doing this, I have other means to watch tv ,
I have legit sub with BV3 and I have almost all the sports channels that I want ,
And now with xbmc even better.

Jvvh I just like to see things done

[jvvh5897]

I'm not sure why you want to load DBPSW-071031p-sssp but it is a bad idea to load another box's code to yours. Hardware will not match. Processor pin use will vary. It is far easier to mod a file actually for your box than mod another box's code to work with your box. You basically have to know everything about both boxes to have a chance. That being said, you might be able to modify the coolsat5000 source code to support your box--hard to say how much work it would be though--you might want to look really close at the processor ID in the pansat to see if it really is the older Conexant one in the coolsat and if it runs at the same speed (check the specifications for the pansat box).

You can find cmd07 packets by searching for the size info and the cmd byte--try 8f 07 8d or A2 07 A0--the 07 is the cmd byte and the two bytes around it tell you how many bytes to end of packet.

[skywalker999]

my second question was for the control words

and here is p9200hd is made of

Main Processor : ARM926
CPU Clock : 280MIPS
Flash Memory : 8 Mbyte
SDRAM : 128 Mbyte
EEPROM : 32 Kbit

the viewsat 9000 hd and max hd the main processors only 266MIPS

and did a google search for fta receivers that use ARM926 processor, there was one receiver that was suppose to come out with the
same hardware was the cnx carbon HD but never made it out to the stores

one other receiver that I am not sure that they still exists is called (Amico nano HD )

[jvvh5897]

Well, there are patterns that show up in CW too --the provider ID is in there, and the keys are separated by a pattern that always shows up. Um...not sure if I have anything that shows that with me....maybe if you look in the 97 degree N2 radio dump as I think I pointed out where the CWs were in that.

Oh, And I think the fact that your pansat box can do mpeg4 and the vs and coolsat 5k only do mpeg2 should tell you that use of the earlier box's sw would not be a good idea in the pansat 9200.

---------------------------------------------------------------------------------------
Ah, I did find notes on the 97 capture:

21C5E0 00 00 00 80 30 67 07 65
(78C5E0) note 0x78C5DA found in code: process ecm

decoded cmd07 (7F3EE0) but not byte flopped:
283EE0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 80 30
283EF0 67 07 65 C1 01 96 00 88-7A 4C 3E 7A 94 0E 36 6A
283F00 C1 01 1F 39 07 A8 00 80-1F 3A 07 A9 30 0B 04 EC
283F10 80 00 FF 00 1F 39 05 F5-00 10 09 00 E2 A7 40 C9
283F20 DA F8 F3 C5 11 09 00 05-25 73 9D C1 76 48 7F 82
283F30 03 F0 01 70 00 DD DE 13-DB B1 A6 51 AD C7 00 8F
283F40 A8 A1 44 05 74 2D C7 BA-06 EF C2 BB 51 CE 51 F7
283F50 1C 78 97 BA EF 72 FE C4-00 00 00 00 00 00 00 00

byte flopped:
2837D0 00 00 00 00 13 DE DD 00-70 01 F0 03 82 7F 48 76
2837E0 C1 9D 73 25 05 00 09 11-C5 F3 F8 DA C9 40 A7 E2
2837F0 00 09 10 00 F5 05 39 1F-00 FF 00 80 EC 04 0B 30
283800 A9 07 3A 1F 80 00 A8 07-39 1F 01 C1 6A 36 0E 94
283810 7A 3E 4C 7A 00 00 00 00-00 00 00 00 00 00 00 00

00 09 11 sequence is for one CW and 00 09 10 is for the other. In the decoded packet before byte flop 67 07 65 C1 01 shows the packet info still and the provider ID I think.

[skywalker999]

And jvvh in that ram dump of 97 gc n2 radio doesn't it show how the process is done
you did say on the other thread that it's to bad that we don't have have gc 97 n2 radio to see how it decrypts or processes

[jvvh5897]

Huh? Explain more or really ask a question.

[skywalker999]

Sorry this is what i was referring too.

C/p

Now it may be that the N2 radio on 97 degree Ku band is hard to get so you will not have that as an aid in seeing how the very last part is done,

[jvvh5897]

Still no question.

BTW the N2 radio channels were available on the box back when the posts were made but as far as I know the guys did not explore the code to see how it was used to save CW. Now, the N2 radio chs are gone from 97 degree sat, so it is no longer possible, though you might be able to track the code execution in part with the Ram dump.

[skywalker999]

wow i can't believe nobody here has balls big enough to finish whats left to do

Sorry Dualtest and jvvh that i could not be of more help :hide:
and another thing what hell happen to nunoit he has not been here for months :disappear:

[rick2933]

can anyone help me I need a tool to unpack and pack this pansat 9200hd boot file " Mboot_07_US"

[jvvh5897]

Well, if it is a boot file, then I would guess that it is not compressed--unless you are talking about a file that was zipped for distribution and in that case any unpack tool would likely get it done--try 7 zip.

[zelig]

it's isn't packed,you can see the ascii parts

[Gates07]

Pansat9200 pack and unpack programs
The pansat 9200 files have compressed code inside them using gzip type compression. The pack and unpack programs and the source code to generate them are attached. The source code is just modified from the cwtool source code with mods to get the header right. You use the programs by just draging and dropping the file you want to unpack or pack onto them. The zlib.dll file has to be in the folder with the programs. lcc-win32 was used to compile the code. The names assigned could be changed in the code and recompile, but I left the code doing the cwtool ones--.un for unpacked and bin for recompressed--it is easy enough to change those outside the program.

(jvvh5897)
Warning: Use at Own Risk
• tool9200.zip (56.8 KB, 0 view

[Gates07]

Pansat9200 pack and unpack programs
The pansat 9200 files have compressed code inside them using gzip type compression. The pack and unpack programs and the source code to generate them are attached. The source code is just modified from the cwtool source code with mods to get the header right. You use the programs by just draging and dropping the file you want to unpack or pack onto them. The zlib.dll file has to be in the folder with the programs. lcc-win32 was used to compile the code. The names assigned could be changed in the code and recompile, but I left the code doing the cwtool ones--.un for unpacked and bin for recompressed--it is easy enough to change those outside the program.

(jvvh5897)
Warning: Use at Own Risk
• tool9200.zip (56.8 KB, 0 view
for some reason i was not able to c/p the tool9200zipfile jvvh might be able to do it.

[cpr43]

Does DualTest still around?? Isnt time to wake up this baby discussion?? Still a lot of 9200HD user out there!! Lets go!!

Does anyone kept any old file for the Panny 9200 with the Biss Keys entry emu??

[cownuts]

Wow just happened on this. got me all excited.

[skywalker999]

Don't get your hopes to high unless you know how to finish what's left to do

[rick2933]

i don't know if anyone can help i been working on the file HD-9200BL081111Rad.bin.uc i have the video pid working also the sid: working but the CAID changes every time you change the channel can't get the CAID to stay on 1816 and if it don't stay 1816 you will get SVR **** [Fri Dec 02 12:38:21 2016] Request and server CaID mismatch (Receiver: 2509, Server: 1816). [0ms]

RECEIVER **** [Fri Dec 02 12:38:21 2016] | Processing packet...
Message Type: ECM | CaID: 2509 | Video PID: 6699 | SID: 4386

ECM Data:
81 30 8F 07 8D 01 0B 86 00 88 31 19 27 EA C4 F7
93 29 0A CA B2 C7 B5 C7 8F 67 E1 83 5B E7 96 14
A7 D9 0C 4A 5B 12 DA C2 2B 65 2A DA 1A 1B 4B CD
CC 19 38 C6 FC 86 A8 D9 CF FA E5 96 85 6D D4 6C
7E 71 AE 5D FC D1 70 6C 05 6A B7 D4 15 78 ED 3F
63 DF D0 BA C9 19 FE 1B 0A 15 C6 87 F8 B4 EB 4E
3B 76 9C EF BE 22 D2 20 C2 98 AE 43 89 01 22 DE
35 30 14 D7 F8 FF CA 70 33 3E 02 6A 0C 46 2E 5A
8B 82 0D E7 4D 16 48 B5 6A E5 82 68 15 DE 6A BD
2F 58

SVR **** [Fri Dec 02 12:38:21 2016] Request and server CaID mismatch (Receiver: 2509, Server: 1816). [0ms]

Failed to obtain valid control words from server(s).

[jvvh5897]

Well, in the box code, you can hard code the CaID, or you can do RAM dumps to see if you can find a CaID in memory that is static.
If the CaID is just changing between a few numbers, you can have the client program map from that set of # to a static one.

[rick2933]

i hate to sound dumb how do you hard code the CaID

[jvvh5897]

If you have it working as described in this thread already, then you have inserted code that was not in the file to start with. That code sets up the serial port to output the coolsat4000 type of rq-sssp comms and as part of that code it reads off places in RAM that have channel number, VPID APID and what should be the CaID---you can change the part that reads off the CaID and have it just insert the CaID that you wish to send as part of the CW/ecm request.

One method I forgot to include in the earlier post is to have a place in the original box code that tests for the CaID, and you can mod it to place the actual ID it is testing to a spot in RAM that you can then use in the outgoing CW/ecm request. That would give you better results than just hard coding one CaID if you go for both North and South prov.

[rick2933]

PANSAT 9200HD if some one could run this file i have got everything working but the caid i thank i have done every thing i know what to do i have the vedio pid and the sid works i change the the file to HD-9200BL081122Rad.bin.uc so it dont get mix up the outhers

[jvvh5897]

I don't think the earlier work included getting the CWs correctly or putting them in the register as needed to decrypt, so unless that is something you worked on too....

[skywalker999]

could it be that caid is for Globecast service if i remember correctly the modes were done using the globecast n2 and if the caid 2509 is for globecast then i would search for the caid 2509 and change it to 1618 or 1816 i could be wrong

[skywalker999]

Well rick2933 why don't you post the modes or scrips you changed and maybe someone will help

[rick2933]

if ecm packet has 80 30 8F 07 8D at
start does anyone know what the old ecm started with before nag3

[jvvh5897]

Lets see what I can find in my notes...I might have posted a few IKS messages in the coolsat format in this thread already.
Hum, notes on dss format convert, notes on PVu, disassemblies of many files.....
You know there was some info captured from N2 stream of the radio channels on 97 degree sat that would show you an example.

Well, here is an old capture of ecm requests from 110 degree sat while N3:
SSSP|ECM|00000001|00|1816|00B1|1222|81308F078DB2C2 234CF48F9FF62B37214170C13ADF45FC9E9F4AF0CAE8EB68AE DB93F32E6E70AF5B8A8A1F2DEB27DB3964079F3CEE77798431 50601D83D470AC1B4EA2395BE9A88F386D9A24FC0FA5E3925F 834B1AEF7A1B36B736FA9935B174EB88F14D9355A2EF416B29 0744FA7FCD9821DC1DD33BD3599B76A0EA8C629399375A2920 5014FCD1FDD31B866D7C5180B493
SSSP|ECM|00000001|00|1816|00B1|1222|80308F078D89A1 27A17A802DE92EB17C2E6FCB0885EA169B4045C01E6D36D4A5 A7A3D59F49CC940DA56182E5058C248317BAF69B9A487814C2 927A6FC081D31EAD0B84E64F96263EABD09FFDE2DCB86E77FD EF492D6FA19823D96E69202C5636EE49700BE716E73706B31D 02F4F4A1062A79AB2C79BFFEADC7A308527A74F7D075BE5C53 DC67753EC5BFF5BF31D58C02F01D
SSSP|ECM|00000001|00|1816|00B1|1222|81308F078DC52B 25D83014F249714774FB106C5D946C91EFB972776A525F74D1 14008FE389A1B4EE160953C9D0512D759B75BD99BA73EC1C16 41580F8E7A127105798715F3E980D916074BF51DCD7A255062 6FEC972DFAA36C398F986A6D44514E1BCCA69803615EC56F8C 4603DFE4DA33638250E2D956291C74567DB1DEE112C96F1FAA 9ABF8FBD65DE862DD2D420EEFA88

Here is something that I have from pansat 2700 notes:
SSSP|ECM|00000001|00|0072|1A22|0000|8130A207A00107 8600885B5490CEFC769B5A1EBAF120D85D37942C688BBC0AE4 E749287C78A398EA0E79D1DA4A33039A6972866EBE166BD773 539EB36B8C0FE7AE156064D8967AA3DB37FAC7614DA92B63A7 0BA4417CC282058A0642765F8C79DB467C6242DA7E76DB459B F616A51F1B1F71F04F4295526D7C69431FF47B9F962C82F28E D45EBF00C2FB6F4BBEDFFBBC8FA20A5543F1A15FCD13D88BD2 4028B181D6D254B8

Most of the info is really of after N3 started in order to look at how to do IKS. I think I will have to look at hard drive and pull a few ecm packets from old RAM dumps to have other examples. But the format used is pretty constant and set by the DVB-S standards so all that really change is the length of the ecm packets. There is some info and examples in old FAQ about N2 that you could pick up.

[jvvh5897]

Oh, I found something that might be good. I was tracking the decryption of ecm packet through a RAM dump, so I have note of the ecm, byte flipping..... From the CaID I would say I was pointed at 97 degree and looking at a radio channel.

decoded cmd07 (7F3EE0) but not byte flopped:
283EE0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 80 30
283EF0 67 07 65 C1 01 96 00 88-7A 4C 3E 7A 94 0E 36 6A
283F00 C1 01 1F 39 07 A8 00 80-1F 3A 07 A9 30 0B 04 EC
283F10 80 00 FF 00 1F 39 05 F5-00 10 09 00 E2 A7 40 C9
283F20 DA F8 F3 C5 11 09 00 05-25 73 9D C1 76 48 7F 82
283F30 03 F0 01 70 00 DD DE 13-DB B1 A6 51 AD C7 00 8F
283F40 A8 A1 44 05 74 2D C7 BA-06 EF C2 BB 51 CE 51 F7
283F50 1C 78 97 BA EF 72 FE C4-00 00 00 00 00 00 00 00

byte flopped:
2837D0 00 00 00 00 13 DE DD 00-70 01 F0 03 82 7F 48 76
2837E0 C1 9D 73 25 05 00 09 11-C5 F3 F8 DA C9 40 A7 E2
2837F0 00 09 10 00 F5 05 39 1F-00 FF 00 80 EC 04 0B 30
283800 A9 07 3A 1F 80 00 A8 07-39 1F 01 C1 6A 36 0E 94
283810 7A 3E 4C 7A 00 00 00 00-00 00 00 00 00 00 00 00

RSA:
2839F0 00 00 00 00 33 69 91 F2-DD 42 C0 EC 25 59 7B 75
283A00 DB DD F7 51 CF 06 9C F3-2D DD BC 30 84 53 F4 B6
283A10 05 06 A5 9D 65 2F AC 9B-AD FE 16 8C A7 5E DB 18
283A20 AF CA C0 E9 82 7D 7A 44-47 AA E1 FC 00 EA BD 02
283A30 13 CA AE 87 00 00 00 00-00 00 00 00 00 00 00 00

2835B0 == 7F35B0
283560 00 00 00 00 01 00 00 00-00 00 00 00 00 00 00 00
283570 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
283580 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
283590 00 00 00 00 00 00 00 00-00 96 00 00 01 00 00 00
2835A0 01 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
2835B0 01 00 00 00 01 00 00 80-30 67 07 65 C1 01 96 00
2835C0 88 98 9A ED AC 75 84 6F-CF 98 05 25 73 9D C1 76
2835D0 48 7F E2 A7 40 C9 DA F8-F3 C5 00 00 00 00 00 00
2835E0 00 00 00 00 00 00 00 00-00 00 95 8C A1 00 88 20
2835F0 66 95 95 8C A1 00 88 20-66 95 00 00 00 00 00 00
283600 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
283610 00 00 00 00 00 00 00 00-00 00 51 47 F1 E1 9F F9 --note key
283620 17 29 95 8C A1 00 88 20-66 95 51 47 F1 E1 9F F9
283630 17 29 95 8C A1 00 88 20-66 95 00 00 03 00 00 00
283640 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00

[jvvh5897]

OK found something from back around 2006:


3AC100 00 81 30 47 07 45 01 01-86 00 08 6A 94 FC C2 A4
3AC110 E3 5D 23 C7 1B 69 48 06-8A 0C 4C 81 BC E5 2F 29
3AC120 4A 3C 86 1D CB 82 9C 30-87 FA 76 A7 52 73 5E 5C
3AC130 67 16 2F 16 36 21 97 06-8C F4 4A B1 84 28 F0 B1
3AC140 DD D5 B6 57 92 AD A8 30-22 CC AA FF FF FF FF FF
3AC150 FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF


3AC1B0 FF FF FF FF FF FF FF FF-00 80 30 47 07 45 01 01
3AC1C0 86 00 88 04 C6 0C DD 12-21 5B 1A D8 DC 84 83 BA
3AC1D0 F0 D4 F0 5D 7B CA 1B B3-21 CB F3 C9 0F CE C5 73
3AC1E0 10 EB D9 9C 12 B5 CD 62-CD 87 2E 52 7C B5 36 55
3AC1F0 86 C3 6B F8 05 B0 57 EE-9B A1 FE 79 78 A8 66 59
3AC200 7B F2 70 FF FF FF FF FF-FF FF FF FF FF FF FF FF
3AC210 FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF

In the above are odd and even cmd07 packets.