FreeCalypso > hg > freecalypso-reveng
comparison objgrep/README @ 176:10a9a0ca9d07
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. |