Page 4 of 9 FirstFirst ... 23456 ... LastLast
Results 46 to 60 of 126

Thread: Mips disassembler v0.1

  1. #46
    Join Date
    Oct 2003
    Location
    Houston, TX
    Posts
    26
    The reason I have not released the source code is because I wrote this on my work laptop, which uses IBM VisualAge C++ 3.5. The code won't compile with anything else because I use its class library. I doubt anybody else uses this compiler. However, I do still maintain it, and continue to add features and bug fixes (v1.1 is now available).

    I have no problems with adding useful features, if requested. Bug reports are also welcome. I just didn't want to get flooded with requests.

    It turns out there aren't as many TiVo reversers as I thought. ...in this forum, anyway
    Last edited by Xybyre; 08-16-2004 at 02:05 PM.
    ---Xybyre

  2. #47
    Join Date
    Jun 2003
    Posts
    23
    I'm trying to run mips.dasm.pl against tivoapp from 4.0.1, but it keeps dying while in load_sections, saying 'Out of Memory!' I've got 512m physical ram and upped my disk swap to 5g, and upped shmmax, but it still keeps dying.
    Any thoughts on how to get this to work? I'm using drnull's 0.4.2 version.

  3. #48
    Join Date
    Jun 2003
    Posts
    23
    Quote Originally Posted by bma
    I'm trying to run mips.dasm.pl against tivoapp from 4.0.1, but it keeps dying while in load_sections, saying 'Out of Memory!' I've got 512m physical ram and upped my disk swap to 5g, and upped shmmax, but it still keeps dying.
    Any thoughts on how to get this to work? I'm using drnull's 0.4.2 version.
    I must be blind, just saw the suggestion to s/SYMBOL/Disassembly/. It's working now

  4. #49
    Join Date
    May 2003
    Location
    Chicago Burbs
    Posts
    160
    used this a few times on tivoapp from 3.1.1c and 4.0.1b no problems.
    Trying it now on tivoapp from 6.2 and it fails while writting the annotated dump. yet still works fine on the 4.0.1b tivoapp.

    I've done some debugging and it looks like its calculating an offset beyond the end of the tivoapp file which causes the file read to fail. Not a perl programer so haven't been able to figure out why. The .S output looks fine up to the failure point.
    Attached is the output file. I can put the tivoapp file up on ftp if it would help.

    Below is the console output:

    Dev101:/home/jowens/tivo/dasm # ./4.2mips.dasm.pl 6tivoapp
    tmesis MIPS linux disassembler 2004-05-30 v0.4.2

    Disassembling ...
    Reading constants ... 767664 bytes
    Reading sections ... Loaded 24 data sections
    Reading GOT ... 54163 entries
    Reading Resources ... 0 entries
    Processing symbol table ... 304 entries
    Loading syscall numbers ... 1163 entries
    Loading procedure definitions ... 0 entries
    Finding jump targets ...

    Writting annotated dump ...
    ......Reading file 6tivoapp failed

    Vegas

  5. #50
    Join Date
    Aug 2003
    Posts
    2,149
    I've built a .proc file for 7.1. My question for now regards my tivoapp71a.S disassembly.

    Code:
    Dynamic Section:
      NEEDED      libhpkoss.so
      NEEDED      libtvstructures.so
      NEEDED      libhpkhl.so
      NEEDED      libtmk.so
      NEEDED      libtvutil.so
      NEEDED      libhpkll.so
      NEEDED      libutil.so.1
      NEEDED      libdl.so.2
      NEEDED      libpthread.so.0
      NEEDED      libm.so.6
      NEEDED      libc.so.6
      INIT        0x410abc
      FINI        0x174b174
    
    <small snip>
    
    Version definitions:
    1 0x01 0x0b0d5800 tivoapp
    2 0x00 0x0d696910 GLIBC_2.0
    
    Version References:
      required from libutil.so.1:
        0x0d696910 0x00 14 GLIBC_2.0
      required from libhpkhl.so:
        0x0b0e3b73 0x00 15 HPK_1.0_WITH_EXTRA_SYMS
        0x0d512450 0x00 13 HPK_1.0
      required from libdl.so.2:
        0x0d696910 0x00 10 GLIBC_2.0
        0x0d696912 0x00 09 GLIBC_2.2
    This is what I've gotten dumped at the beginning and I'm not sure if it's telling me that I 'still' need these files in my .proc files list or if 'these files needed' something during disassembly?

    Hope that makes sense.


    NutKase
    "God, and DealDataBase, help those that help themselves." --Shamelessly stolen from psxboy
    ------------------------------------------------
    2 each, SA S2 287hr 7.2.1a's with Lifetime.
    Hacks: 1 Manually Monte'd -140, Bash,Telnet,FTP,TivoWebPlus,
    Superpatch-67all Unscrambled/HMO,MFS_FTP Ver. N,TyTools, tivoserver
    Fully hacked SA S1

  6. #51
    Join Date
    Jan 2005
    Posts
    127
    Quote Originally Posted by Vegas
    used this a few times on tivoapp from 3.1.1c and 4.0.1b no problems.
    Trying it now on tivoapp from 6.2 and it fails while writting the annotated dump. yet still works fine on the 4.0.1b tivoapp.

    I've done some debugging and it looks like its calculating an offset beyond the end of the tivoapp file which causes the file read to fail. Not a perl programer so haven't been able to figure out why. The .S output looks fine up to the failure point.
    The issue, as you observed, is that the perl script is trying to read beyond the end of the tivoapp file. I've seen this with 7.1 and some 5.X tivoapps too. I believe this is in code DrNull added. Possible solutions:
    1. Turn the die into a warn and return zero but continue.
    2. Check the file offset against the file size and don't try to read beyond the end of the file.
    3. Observe that not every VMA maps to a file offset. For example, the uninitialized data section (bss) is not stored in the elf file since it is "uninitialized" (really, initialized to zero during the startup code). Check the vma address against the section map, and check the flags for the corresponding section to see whether there is data stored in the file for that section.
    The attached patch (against 0.4.2) implements approach 3.

  7. #52
    Join Date
    May 2003
    Location
    Chicago Burbs
    Posts
    160
    Quote Originally Posted by 7.1
    The issue, as you observed, is that the perl script is trying to read beyond the end of the tivoapp file. I've seen this with 7.1 and some 5.X tivoapps too. I believe this is in code DrNull added.
    Thanks 7.1, I tracked it down to the added code and I think the subs handle_laj_mode and handle_lalj_mode. This is my first venture into disassembly so it would have taken me forever to figure out how to fix it.

    To get around it I had done #1, replace die with printf and a warning along with $addr and $offset. This let the disassembly finish, but I received 6121 warning messages, so didn't think this was a very good approach.

    I will try your patch tonight. Looking forward to digging into tivoapp. This should be fun.

    Thanks

    Vegas

  8. #53
    Join Date
    Jan 2004
    Posts
    459
    Quote Originally Posted by 7.1
    The attached patch (against 0.4.2) implements approach 3.
    That's pretty cool. I especially like the jump target indicators.
    There's no place like ~/

  9. #54
    Join Date
    May 2003
    Location
    Chicago Burbs
    Posts
    160
    Quote Originally Posted by 7.1
    The attached patch (against 0.4.2) implements approach 3.
    The patch fixed up the disassembly for 6.2 tivoapp. I now have dumps of 3.1.1c, 4.0.1b and 6.2 and am off to begin my learning curve for patching binaries... diving into the deep end.
    If anyone else would like to dive in, there is some great info in this thread. Learned more last night in 3 hours than I did from the $40 assembly book I bought.

    Just a heads up to 7.1. When I ran your patched version against 3.1.1c-tivoapp it went into the infinet loop during reading sections. Didn't look into it, just went back and used the unpatched ver.

    Vegas

  10. #55
    Join Date
    Jan 2005
    Posts
    127
    Quote Originally Posted by Vegas
    Just a heads up to 7.1. When I ran your patched version against 3.1.1c-tivoapp it went into the infinet loop during reading sections. Didn't look into it, just went back and used the unpatched ver.
    Hum. I suspect it is this change:
    Code:
    -       while (!/^SYMBOL/o) {
    +       while (!/^(Disassembly|DYNAMIC SYMBOL TABLE|SYMBOL TABLE)/o) {
    that is at fault. This is supposed to correct the "seems to run forever and consume large amounts of memory" problem with 4.x and above tivoapps discussed earlier in the thread. I guess it's not properly finding the end of the section table. It might be that "SYMBOL TABLE" should be changed to just "SYMBOL". Or it could do more intelligent parsing of the section table lines and bail from the loop when it hits something it can't parse.

    If you could send me the first few hundred lines of the .dump file, I could probably figure out what it should be looking for to terminate the section table scan.

  11. #56
    Join Date
    Jan 2002
    Posts
    1,777
    Quote Originally Posted by 7.1
    Hum. I suspect it is this change:
    Code:
    -       while (!/^SYMBOL/o) {
    +       while (!/^(Disassembly|DYNAMIC SYMBOL TABLE|SYMBOL TABLE)/o) {
    Might want to change that to something like:

    Code:
    while(defined($_) && !/(Disassembly|DYNAMIC SYMBOL TABLE|SYMBOL TABLE)/o) {
    so that if objdump aborts for some reason or those markers are not present, it craps out (somewhat) gracefully instead of getting stuck in an infinite loop.

  12. #57
    Join Date
    May 2003
    Location
    Chicago Burbs
    Posts
    160
    Quote Originally Posted by 7.1
    If you could send me the first few hundred lines of the .dump file, I could probably figure out what it should be looking for to terminate the section table scan.
    Here is the dump of 3.1.1c sniped after the start of disassembly.

    Edit I tried the suggestion from ADH. It did jump out of reading sections after about 15 seconds, but writing annotated dump looks like it's going to take hours to complete.

    Vegas
    Last edited by Vegas; 03-09-2005 at 09:14 PM.

  13. #58
    Join Date
    Jan 2004
    Posts
    459
    The one thing that I always would have liked for mips.dasm.pl is the ability to see the raw machine code hex value alongside the address in the anotated dumpfile. The attached patch for mips.dasm.pl against against 0.4.2a accomplishes this. 0.4.2b also has alldeadhomiez' suggested fix for eliminating possible infinite loops.

    Usage is now "mips.dasm.pl <executable> [raw]". Without the raw option, the <executable>.dump and <executable>.S files are produced as before. With the raw option these two files are created instead: <executable>.dump_w_raw and <executable>_w_raw.S. Unfortunately, the annotated file in this case may not be loaded into Xbyre's MIPS viewer tool. But both types of .S file may be around simultaneously - just run mips.dasm once with the raw option and once without.

    I've also included a patch for xrefs.pl which allows it to work with a <executable>_w_raw.S file. It picks up whether the annotated *.S file is a "raw" file automatically (by searching for "raw" in the filename). I called it version 0.1a, but it's actually created off of drnull's patch of xrefs.pl

    (If anyone has problems with the patches, I'll post the entire perl files.)
    There's no place like ~/

  14. #59
    Join Date
    Feb 2005
    Posts
    41
    Just wanted to add a quick note that when I used the precompiled gnu toolchain from sourceforge that objdump ends the last section with:
    "Disassembly of section .fini:"

    So it would be useful to update the dasm script to include both:

    For this routine:
    sub find_jump_targets()
    {
    open(IN, "<$dump") || die "Cannot open file $dump\n";
    while (<IN>) {
    if (/Disassembly of section/o) { last; }
    }

    Change "last" to "fini" or maybe to (last|fini)?

    BTW, Great tool!
    -S8C

  15. #60
    Join Date
    Mar 2005
    Posts
    235
    I am trying to run this on tivoapp (7.1b) and receive this error in the load_got routine:
    "Reading GOT ...Reading file tivoapp failed"

    Here's a little more info:
    OS = RH9 and RH8
    Perl = v5.8.0 and ???
    Script Version = 0.4 and 0.4.2a
    objdump = self compiled and sourceforge
    tivoapp file size = 22051388
    tivoapp.dump .got line = "21 .got 0003ef24 10088620 10088620 014c8620 2**4"

    Variable values at failure:
    $i=57303
    $got_size=64457
    $offset=21792288

    Can anyone offer any suggestions as to what I am doing wrong. Let me know if you need any more info. Any help would be appreciated.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •