Any interest in sw modding?

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