Tivoapp Jump Locations

[pdd]

Hi All,

Just a quick question about the dissassembly of the tivoapp. My MIPS experience is very limited... ie a few days

I am dissambling in IDA Pro on a windows XP machine.

For this small chunk of code from tivoapp there are a few jumps to addresses which appear to be outside of the tivoapp.(Marked in red)

Obviously it's a location in memory but what is there and how do I find out what is there?

I can see the jumps marked green are jumping to locations within tivoapp.

--------------------
.text:00ED70D4 sw $v0, 0x1C8+var_70($sp)
.text:00ED70D8 lw $a0, 0x1C8+var_70($sp)
.text:00ED70DC lw $a1, 0x1C8+var_6C($sp)
.text:00ED70E0 lw $a2, 0x1C8+var_60($sp)
.text:00ED70E4 addiu $fp, $sp, 0x38
.text:00ED70E8 jal 0x4A356D0
.text:00ED70EC addiu $s7, $sp, 0x1C8+var_B8
.text:00ED70F0 addiu $v0, $sp, 0x1C8+var_110
.text:00ED70F4 sw $v0, 0x1C8+var_5C($sp)
.text:00ED70F8 lw $a0, 0x1C8+var_5C($sp)
.text:00ED70FC addiu $v0, $sp, 0x1C8+var_140
.text:00ED7100 addiu $a1, $s1, 0x14
.text:00ED7104 la $a2, aSkip_0 # "Skip"
.text:00ED710C jal sub_F60970
---------------------

Also why is the hex location in the file different to the VMA by 0x400000? Is the app loaded at a higer address always?

I hope these questions are not too newbish. I am pretty quick at picking these things up just need a point in the right direction.

Thanks

[Jamie]

Yes, each file is loaded at a base address in memory. The executable has a section table at the start that lists the base address for all the files: the executable itself and the library .so's. There may sometimes be relocation at runtime loading, but that doesn't seem to be a problem with tivoapp. Perhaps it was prelinked.

I've heard of people succesfully using IDA Pro. I don't use it. I use objdump from a cross compile toolchain with the tmesis postprocessor. With a "proc" file, you can map the glibc and other external .so symbols to their symbolic names. But TiVo obfusticates the names in their libraries, so it isn't all that useful.


There is also useful information in this thread.

[pdd]

Thanks Jamie makes much more sense now. The is alot of information on these forums it's just spread out all over the place. The links you provided were an interesting read and shed a lot of information on how things are layed out.

I think I can import these other binaries into IDA Pro so that may make life easier.

Will also look at your tools to see if they are any easier too.

Thanks again

[pdd]

Two more quick questions.

Is there a way to dump the contents of the entire Tivo memory to a file?
That way when I load this memory dump into IDA I can then see where tivoapp jumps outside into other libraries.

Also is it possible to patch tivoapp while it is in memory to test patches 'live'?
That way if I stuff up a test patch it will just crash the unit and when it reloads tivoapp will remain unchanged. If it is what command do I use?

I searched ddb for a while for these answers but could not find any direct references/examples to what I need to know. The link you provided stated this

MrBlack51 stated it correctly. The offset in the file is 0x632fec. Once tivoapp is loaded, the offset is at 0xa32fec (relatively, I guess). I assume SteveT is modifying tivoapp while it's resident with kmem or something like that...

but never really mentioned how this could be done. Investigation of kmem seems to say that it deals with the kernel memory. I also saw /dev/mem exists but did not know how to directly access it. My linux knowledge is not super immense so not sure if what I want is even possible.

Answers to the two questions above should keep me occupied for a while if they are possible.

Thanks

[tivo4mevo]

I've not used IDA much, so I can't say definitively what it might be capable of, but you can see the base load address of each dynamic library on which tivoapp depends in the backtrace resulting from a crash.

Typically something like this towards the end:

bt -t /tvbin/tivoapp <<END_OF_BT	
  read 0x2aaa8000 /lib/ld.so.1	
  read 0x2ab04000 /lib/libutil.so.1	
  read 0x2ab48000 /lib/libdl.so.2	
  read 0x2ab8c000 /lib/libpthread.so.0	
  read 0x2abe8000 /lib/libm.so.6	
  read 0x2acb0000 /lib/libc.so.6	
  0x00cede04 0x00b451cc 0x00b45898 0x00b39fe4 0x00b39270 0x013aa9dc 0x013aa794	
  0x013ac51c 0x013d3a50	
END_OF_BT

In much older versions of software, tivoapp was statically linked, but from 7.x on, dynamically. Note as well that with ~7.2 on, the shared libraries appear to have been prelinked, as Jamie points out, so the jump address in tivoapp matches an address in the disassembly of the libs.

Rather that try to assemble all code into a single disassembly file, people have instead tried to determine the functions name/purpose and then add it to a .proc file so that the procedure description/name is annotated as a comment in the disassembly. It's much easier to parse the code that way, but that assumes one is using the tmesis postprocessor (I can't say if IDA offers something similar). Again, more details and discussion in the temsis thread here.

As for dynamically testing patches, I'm unsure if it's possible to do. There are many confounding factors (an array of virtually indistinguishable tivoapps [the SwedishChef] and the possibility that the code caches various results [especially so with network related operations] to name two). There's definitely a balance between time spent on static disassembly analysis versus empirical testing when devising a new patch.

[pdd]

Thanks for the info.. Point taken about the dissassembly.. I am only on week 2 of learning the ins and outs of the tivo internals. I will try a few of your and Jamie's suggestions out with regards to disassembly.

I think there could possibly be a knowledge gap of a few years here as I only really used to write assembly for the c64 back in the day so I am 100% certain things are different now. Architecture has changed alot since the 8 bit days

I was under the impression that tivoapp would be loaded to a fixed location in memory and if I wanted to apply a code patch such as modifying a branch opcode to a unconditional branch or NOP then I could just perform a modification of a memory location which would then modify the code which was loaded in memory.

I definitely agree about the data which could be cached all over the place.

On investigation of all the swedishChefs they appear to all use the same code base at 0x00400000 in memory. So patching this should affect all of them.

See the output of pmap on a randomly selected swedishChef. The same results were obtained by pmap ing various other swedishChefs.

So is there a command to change a byte in memory?

I again found hints of it here
http://linux.about.com/library/cmd/blcmdl4_kmem.htm
but still no explanation of

How do I change the byte value of a point in memory?
ie the good ole basic command on the C64
poke 0x345f 0x5f
poke <address> <value>

Output of pmap on a random swedishChef below. First column is the memory address.

TiVoHD/hack $ pmap 5793
5793:   swedishChef
00400000  30080K read/exec         /tvbin/tivoapp
04000000   1272K read/exec         /lib/libc.so.6
0413e000    252K none              /lib/libc.so.6
0417d000     28K read/write        /lib/libc.so.6
04184000     16K read/write          [ anon ]
04200000    508K read/exec         /lib/libm.so.6
0427f000    252K none              /lib/libm.so.6
042be000      4K read/write        /lib/libm.so.6
04400000     80K read/exec         /lib/libpthread.so.0
04414000    256K none              /lib/libpthread.so.0
04454000     20K read/write        /lib/libpthread.so.0
04459000      8K read/write          [ anon ]
04600000     12K read/exec         /lib/libutil.so.1
04603000    252K none              /lib/libutil.so.1
04642000      4K read/write        /lib/libutil.so.1
04800000    212K read/exec         /lib/libtvutil.so
04835000    252K none              /lib/libtvutil.so
04874000     16K read/write        /lib/libtvutil.so
04a00000    644K read/exec         /lib/libtmk.so
04aa1000    252K none              /lib/libtmk.so
04ae0000     16K read/write        /lib/libtmk.so
04ae4000      4K read/write          [ anon ]
04c00000    112K read/exec         /lib/libtvstructures.so
04c1c000    252K none              /lib/libtvstructures.so
04c5b000      8K read/write        /lib/libtvstructures.so
10000000   1316K read/write        /tvbin/tivoapp
10149000    308K read/write/exec     [ anon ]
2aaa8000    100K read/exec         /lib/ld.so.1
2aac1000    156K read/write          [ anon ]
2ab00000      4K read/write        /lib/ld.so.1
2ab08000     48K read/exec         /platform/lib/libmp3dec.so
2ab14000    252K none              /platform/lib/libmp3dec.so
2ab53000      4K read/write        /platform/lib/libmp3dec.so
2ab58000     16K read/exec         /platform/lib/libcdsassetsentinelasf.so
2ab5c000    252K none              /platform/lib/libcdsassetsentinelasf.so
2ab9b000      4K read/write        /platform/lib/libcdsassetsentinelasf.so
2aba0000     32K read/exec         /platform/lib/libmomcds.so
2aba8000    252K none              /platform/lib/libmomcds.so
2abe7000      4K read/write        /platform/lib/libmomcds.so
2abe8000     36K read/exec         /platform/lib/libmomasf.so
2abf1000    252K none              /platform/lib/libmomasf.so
2ac30000      4K read/write        /platform/lib/libmomasf.so
2ac38000    612K read/exec         /platform/lib/libhpkhl.so
2acd1000    252K none              /platform/lib/libhpkhl.so
2ad10000     20K read/write        /platform/lib/libhpkhl.so
2ad15000      8K read/write          [ anon ]
2ad18000     36K read/exec         /lib/libhpkoss.so
2ad21000    252K none              /lib/libhpkoss.so
2ad60000      4K read/write        /lib/libhpkoss.so
2ad68000     16K read/exec         /platform/lib/libhpkll.so
2ad6c000    252K none              /platform/lib/libhpkll.so
2adab000      4K read/write        /platform/lib/libhpkll.so
2adb0000     36K read/exec         /lib/librt.so.1
2adb9000    256K none              /lib/librt.so.1
2adf9000      4K read/write        /lib/librt.so.1
2adfa000     40K read/write          [ anon ]
2ae08000     12K read/exec         /lib/libdl.so.2
2ae0b000    252K none              /lib/libdl.so.2
2ae4a000      4K read/write        /lib/libdl.so.2
2ae54000  98304K read/write        /dev/mem
30e5d000  12288K read/write        /dev/mem
5ee18000   1376K read/write        /SYSV00000000 (deleted)
5ef78000     64K read/write        /SYSV00000000 (deleted)
5ef90000   1536K read/write        /SYSV00000000 (deleted)
5f210000   1032K read/write        /SYSV530012ff (deleted)
5f320000    520K read/write        /SYSV530011ff (deleted)
5f3b0000    520K read/write        /SYSV530010ff (deleted)
5f978000     72K read/write        /SYSV53000bff (deleted)
5f9b0000     40K read/write        /SYSV530009ff (deleted)
5fdd8000    264K read/write        /SYSV530007ff (deleted)
5ffb0000    264K read/write        /SYSV530000ff (deleted)
7f980000     32K none                [ anon ]
7f988000    480K read/write/exec     [ anon ]
7fb00000      4K none                [ anon ]
7fb01000    508K read/write/exec     [ anon ]
7fb80000     32K none                [ anon ]
7fb88000    480K read/write/exec     [ anon ]
7fc00000     32K none                [ anon ]
7fc08000    480K read/write/exec     [ anon ]
7fc80000     32K none                [ anon ]
7fc88000    480K read/write/exec     [ anon ]
7fd00000     32K none                [ anon ]
7fd08000    480K read/write/exec     [ anon ]
7fd80000     32K none                [ anon ]
7fd88000    480K read/write/exec     [ anon ]
7ffd8000    128K read/write/exec     [ anon ]
 total   159904K
TiVoHD/hack $

I could still be missing something here and if I am way off track just let me know and I will stop this line of questioning

[Jamie]

You could try something like this: http://ukai.jp/Software/livepatch/. It uses the ptrace system call to live patch a running process.

You can also build gdb for mips, which also uses ptrace and I believe has commands for changing code in memory.

I will second what tivo4mevo said though: the fact that the same executable is running in many different instances causes extra difficulties for live patching.

[djl]

Sorry for an off-topic post, but anyone else that coded for the c64 deserves a tip of the cap!

I think there could possibly be a knowledge gap of a few years here as I only really used to write assembly for the c64 back in the day so I am 100% certain things are different now. Architecture has changed alot since the 8 bit days

[pdd]

Upon further reading memory handling is much more complex now than it used to be.
http://www.linuxhq.com/guides/TLK/mm/memory.html

It appears that each process has it's own virtual address space and 'poke'ing one's tivoapp probably will not affect the all programs using tivoapp. That is a MAJOR shame because it would have made life so much easier for finding patches

'Back in my day' we had only 64k to work with(pun intended) and there was no memory management and we had full access to the memory and could alter programs by changing physical memory directly.

In a virtual memory system all of these addresses are virtual addresses and not physical addresses. These virtual addresses are converted into physical addresses by the processor based on information held in a set of tables maintained by the operating system.

It seems nowadays each process is given it's own virtual address space to work in. Each virtual address space behaves like a virtual single C64 (but with much more memory) and is self contained. However this does not actually correlate to the physical memory as the CPU and OS handles the translation from virtual to physical. Heaps safer to work with and stops people injecting code from one process into another.. which is what I want to do in this instance. It also explains why peek and poke are no longer relevent in todays computing as apps/processes just don't sit in physical memory together but sit in their own virtual memory. They could be anywhere in physical memory.

It is still possible that the tools that Jamie mentioned might help but the more I read about memory management the harder I think this will be.

Shared Virtual Memory
Although virtual memory allows processes to have separate (virtual) address spaces, there are times when you need processes to share memory. For example there could be several processes in the system running the bash command shell. Rather than have several copies of bash, one in each processes virtual address space, it is better to have only one copy in physical memory and all of the processes running bash share it. Dynamic libraries are another common example of executing code shared between several processes.

Based on my skimming through the above link it is likely that the tivoapp is stored in one place somewhere and the OS is linking all these swedishapps to the same tivoapp code. If I could find out where and how to modify this code then we could achieve live patching. However that is way beyond my capabilities at present. At least I learnt a bit more about memory management in linux and moved a bit closer to the 64bit world.

Thanks for the info though guys. Looks like I will have to trace the assembly with a bit more care then as opposed to just firing hacks directly into memory and seeing what happens. That would have been way more fun.

If anyone knows of a linux guru that may assist in finding out where the OS is hiding this one copy of tivoapp and if it is possible to change it then please let me know. It may even require a kernel mod???

Thanks again.

Another good link found here. This guy has a series he wrote weeks ago on memory management and goes into great detail about how it all works.
http://duartes.org/gustavo/blog/post...gram-in-memory