Windows GUI for CHDK porting - page 9 - General Discussion and Assistance - CHDK Forum supplierdeeply
« previous next »
Pages: 1 ... 4 5 6 7 8 [9] 10   Go Down

Windows GUI for CHDK porting

  • 98 Replies
  • 129939 Views
*

Offline srsa_4c

  • ******
  • 4450
Re: Windows GUI for CHDK porting
« Reply #80 on: 10 / February / 2013, 14:30:12 »
Advertisements
Quote from: waterwingz on 10 / February / 2013, 13:38:45
He sent me something with it recoded into standard C - that's part of what prompted my recent post.
That's better :)

Quote
Yea - using a false positive in the code could be a nasty thing to find during initial camera porting.  Might make more sense to leave dissassembled addresses in hex and add the name as a comment only ?
Both (replacement / comment) use seems useful.

Quote
Quote
Can you give an example? The string dump contains lots of false positives and localized strings.
Again, adding a "hit" as a comment seems safe enough.  Question is does anything in there tell you much?
Yes, you get debug strings for example. About the quote: I have corrected my original post.

Quote
Quote
Which files?
These ones :  http://www.definethis.org/temp/chdk/CanonFW_A-Series_Signatures_for_IDA.rar
Quote
Somehow that seems to be enough to turn a raw dissassembly into something much more readable
Ah, the signatures. I don't know how they are made. The "A series" sig is probably based on that early A6x0 debug firmware (does anybody have it ?), so it has lots of function names, but it's only usable on VxWorks dumps (AFAIK). The other one would need to be maintained, it's less and less usable on new cameras.

It would make more sense to include additional functions in the sigfinder (I don't know how to do this unfortunately). And it would be good to have an IDA replacement (like Pelican's ARMu). Unfortunately ARMu is pretty buggy and I doubt that the author will ever continue with its development, or that he would be willing to open source it :(
« Last Edit: 11 / February / 2013, 09:18:44 by srsa_4c »
Logged
*

Offline fe50

  • ******
  • 3139
  • IXUS50 & 860, SX10 Star WARs-Star RAWs
    • fe50
Re: Windows GUI for CHDK porting
« Reply #81 on: 17 / February / 2013, 05:04:26 »
Quote from: waterwingz on 10 / February / 2013, 10:23:54
  • The strings.txt file included with each f/w dump in the repository seems to have a lot of usefull information ?
This are simple text files generated with the BinText utility (by Foundstone Inc / McAfee, free) with the default settings.
You can easily extract the strings from a fw dump & save them as text file...

(BinText v3.01 is included in whim's Cardtricks package)
Logged
*

Offline waterwingz

  • ******
  • 12125
    • Waterwingz
Re: Windows GUI for CHDK porting
« Reply #82 on: 17 / February / 2013, 09:56:34 »
Quote from: fe50 on 17 / February / 2013, 05:04:26
This are simple text files generated with the BinText utility (by Foundstone Inc / McAfee, free) with the default settings.
You can easily extract the strings from a fw dump & save them as text file...
Good point.  I don't need to depend on having the "official" f/w file from the repository with an  included strings.txt file as I can generate the same information from the primary.bin file selected by the user.   I've only looked at it a little but figuring out how to make that information useful is going to be tricky.  I was hoping for nice names to use as labels for subroutines called from the CHDK C assembly tasks ( boot.c, video.c, capt_seq.c ).
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline srsa_4c

  • ******
  • 4450
Re: Windows GUI for CHDK porting
« Reply #83 on: 17 / February / 2013, 11:05:15 »
Quote from: waterwingz on 17 / February / 2013, 09:56:34
I was hoping for nice names to use as labels for subroutines called from the CHDK C assembly tasks ( boot.c, video.c, capt_seq.c ).
Do you mean the kind of naming which the DryOS IDA IDC's produce? That's a bit tricky. You would need to follow every subroutine call (1 level deep), determine where that subroutine ends, and look for DebugAssert calls inside (if any), from which you could get the name of the source file.
On the contrary, looking up (potential) strings in the "currently displayed" disassembly would be easier (but obviously less useful).
Logged
*

Offline nafraf

  • *****
  • 1308
Re: Windows GUI for CHDK porting
« Reply #84 on: 18 / February / 2013, 05:18:52 »
Quote from: srsa_4c on 17 / February / 2013, 11:05:15
On the contrary, looking up (potential) strings in the "currently displayed" disassembly would be easier (but obviously less useful).
It seems that disassemble.pl is looking for the potential strings, looking for pointer to string and pointer to pointer strings.

My impression is that disassemble.pl method will return similar results to looking for DebugAssert call Method.
I used disassemble.pl output to get strings, and added them as comments in capt_seq.c.  Calls to DebugAssert were identified using hex2task.

Using grep, I got:
grep -B1 DebugAssert platform/a810/sub/100b/capt_seq.c
Code: [Select]
      "LDR     R0, =0xFF86E814 \n" // **"SsShootTask.c"
      "BL      _DebugAssert \n"
--
      "LDR     R0, =0xFF86E814 \n" // *"SsShootTask.c"
      "BL      _DebugAssert \n"
--
      "LDREQ   R0, =0xFF86E814 \n" // *"SsShootTask.c"
      "BLEQ    _DebugAssert \n"
--
      "LDRNE   R0, =0xFF960D2C \n" //SsCaptureSeq.c
      "BLNE    _DebugAssert \n" //RAM
--
      "LDR     R0, =0xFF8AA76C \n" // **"ExpDrv.c"
      "BL      _DebugAssert \n"
--
      "LDRNE   R0, =0xFF899E7C \n" //  ; "Shutter.c"
      "BLNE    _DebugAssert \n"
--
      "STRH    R4, [R5, #2] \n"
      "BLEQ    _DebugAssert \n" //RAM
--
      "LDR     R0, =0xFF899E7C \n" //  ; "Shutter.c"
      "B       _DebugAssert \n" //RAM
Logged
*

Offline waterwingz

  • ******
  • 12125
    • Waterwingz
Re: Windows GUI for CHDK porting
« Reply #85 on: 06 / May / 2013, 22:37:24 »
Small milestone tonight - the 500th download.   8)
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline srsa_4c

  • ******
  • 4450
Re: Windows GUI for CHDK porting
« Reply #86 on: 19 / June / 2013, 12:38:48 »
The attached patch adds support for jumptables used in vxworks firmwares. They look like this:
        LDRLS   PC, [PC, R3, LSL #2]
        B       loc_FF8899EC
        .long   loc_FF88992C
        .long   loc_FF88994C
Since all vxworks firmwares start at 0xffc00000 or 0xff810000, all ROM addresses appear to be 'undefined instructions' or SWIs. The patched chdk_dasm will treat every undefined instruction as data instead. An additional check will turn these data words to addresses, if they happen to point to a destination closer than 0x1000 bytes. These hacks are enough to get a nicely formatted jumptable on vxworks dumps.
The patch could be nicer: the addition of 'condition codes' are avoided by a nasty hack instead of introducing a new variable. And of course this hack will not work for other address ranges.
Added v2 of the patch: Instructions with oddities or errors are also treated as data - the firmware dumps we work with contain sane code or data (or meaningless bytes), no need for warnings about odd instructions.
« Last Edit: 21 / June / 2013, 14:24:34 by srsa_4c »
Logged
*

Offline waterwingz

  • ******
  • 12125
    • Waterwingz
Re: Windows GUI for CHDK porting
« Reply #87 on: 19 / June / 2013, 22:53:13 »
Quote from: srsa_4c on 19 / June / 2013, 12:38:48
The attached patch adds support for jumptables used in vxworks firmwares.
Thanks - I'll add it this weekend.
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline waterwingz

  • ******
  • 12125
    • Waterwingz
Re: Windows GUI for CHDK porting
« Reply #88 on: 21 / June / 2013, 19:29:54 »
Quote from: srsa_4c on 19 / June / 2013, 12:38:48
Added v2 of the patch: Instructions with oddities or errors are also treated as data - the firmware dumps we work with contain sane code or data (or meaningless bytes),
Updated the svn and released as 2.09 at the usual download link.  Thanks.

Quote
no need for warnings about odd instructions.
No need for warnings anymore ... in part thanks to your help.  Believe me,  as I was first getting this to work, there was major need for the warnings as valid instructions were incorrectly disassembled.
 :o
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline srsa_4c

  • ******
  • 4450
Re: Windows GUI for CHDK porting
« Reply #89 on: 22 / June / 2013, 09:59:01 »
The following change should deal with the remaining junk in some of the 'data' words.
Code: [Select]
Index: chdk_dasm.c
===================================================================
--- chdk_dasm.c (revision 51)
+++ chdk_dasm.c (working copy)
@@ -735,6 +735,7 @@
       format = "=";
       instr = 14 << 28; // no condition code please, see below
       result.oddbits = result.badbits = 0;
+      result.text[0] = flagchars[0] = 0;
   }
 
   if (result.oddbits || result.badbits) { // treat erroneous instructions as data
@@ -743,6 +744,7 @@
     format = "=";
     instr = 14 << 28; // no condition code please, see below
     result.oddbits = result.badbits = 0; // no need for error display
+    result.text[0] = flagchars[0] = 0;
   }
 
   *flagp=0;
Logged
Pages: 1 ... 4 5 6 7 8 [9] 10   Go Up
« previous next »
 

Related Topics