FreeCalypso > hg > freecalypso-reveng

comparison objgrep/README @ 176:10a9a0ca9d07

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
objgrep/README written
author Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
date Sun, 06 Jul 2014 20:22:09 +0000
parents
children
comparison
equal deleted inserted replaced
175:928ed52930aa 176:10a9a0ca9d07
1 We have TI's reference firmware for the Calypso/Iota/Rita chipset (Leonardo) in
2 the form of linkable COFF objects and some source pieces, but when it comes to
3 practically usable "dumbphones" based on this chipset, we only have the binary
4 fw images read out of flash, without any kind of symbolic info.
5
6 The tools in this directory perform a kind of grep operation, searching an
7 unknown binary fw image for the bits of code or data contained in a linkable
8 COFF object. The objective was to determine whether or not our "reference"
9 Leonardo objects could be found verbatim in the set of proprietary firmwares
10 from Compal and Foxconn (Pirelli DP-L10) that run on our "dumbphone" targets.
11
12 The tools are as follows:
13
14 objgrep
15
16 This tool extracts one section (e.g., .text or .const, to be specified
17 on the command line) from a "needle" COFF object and searches for it in
18 the "haystack" unknown binary. The byte positions in the sought-for
19 object section where relocs are to be applied at linking time are masked
20 as appopriate for each reloc type, and the section is expected to start
21 on a 4-byte-aligned boundary in the unknown binary. If a match is
22 found, objgrep can print out the list of symbol addresses in the
23 sought-for and found section, and it can also deduce some symbols
24 external to the module or belonging to the module's other sections by
25 looking where the relocs that were masked for the match point to in the
26 unknown binary.
27
28 In order for this form of grep to be effective, the section being
29 searched for should be "meaty", i.e., mostly code or constant data with
30 some interspersed relocs. If the sought-for section is very small, fits
31 the same pattern after reloc masking as other unrelated bits of code,
32 or consists mostly of relocs, the most likely result will be a useless
33 false hit.
34
35 objgrep-fe
36
37 This program is a front-end to objgrep. It reads a line-based text file
38 listing the objects and sections to be grepped for, and invokes objgrep
39 for each listed section. The output of objgrep is captured through a
40 pipe; objgrep-fe collates together the symbol addresses found with each
41 individual objgrep hit and produces a sorted symbol listing.
42
43 Results
44 =======
45
46 The idea proved quite successful in the case of Pirelli DP-L10 firmware,
47 specifically version D910.0.3.98: this fw appears to have been built with
48 exactly the same RTS, Nucleus and GPF libraries that are featured in our
49 Leonardo semi-src as "very stable blobs", i.e., *.lib files in the source tree
50 itself, rather than blobs under g23m/__out__ for which TI's closed source
51 police excluded the corresponding source. Every object that comes from these
52 libraries in our leo2moko build was also found in Pirelli's fw.
53
54 It is worth noting that the GPF libraries in particular contain a few objects
55 with embedded second-granularity timestamps, courtesy of the C compiler's
56 __DATE__ and __TIME__ preprocessor definitions, i.e., the timestamp strings
57 with times to the second are emitted into the code image built with these
58 libraries. These timestamped objects were found in Pirelli's fw with our
59 objgrep tools along with the rest of GPF, proving beyond any doubt that this fw
60 has been built with exactly the same GPF libs as our leo2moko.
61
62 This confirmation in the case of Pirelli's fw is very reassuring because this
63 fw has received a lot of real-life testing: I've been using a Pirelli running
64 its original proprietary fw (as no free fw exists yet, for this or any other
65 dumbphone) as my personal everyday cellphone for over a year now. That is a
66 lot more real life experience than I can get with anything Openmoko-based, and
67 it is reassuring to know that the GPF libraries we have painstakingly
68 reconstructed are used not only in the largely-untested moko firmware, but also
69 in the much more real-life-tested Pirelli DP-L10 fw.
70
71 Attemping the same grep against Compal's fw yielded far fewer hits, however.
72 A lot of RTS modules were found, but very little from Nucleus or GPF libs.
73 Nucleus' tct and tmt assembly modules were found, but not much else. Manual
74 examination of Compal's INC_Initialize() function (which is easy to locate even
75 in a totally unknown fw binary, as it's only one ARM->Thumb call veneer away
76 from the boilerplate code at the boot entry point) has revealed that it's the
77 same code, but compiled slightly differently, probably a slightly newer C
78 compiler version. (The version in our reference libs saves one more call-
79 preserved register than necessary; the version that appears in Compal's fw is
80 fully optimal in this regard.) I reason that the same compiler difference must
81 be responsible for the great scarcity of hits in general, as these kinds of
82 compiler changes would produce differences in just about every module.