reverse engineering – recent advances and applications - OpenLibra

More documents

Recommendations

Info

18 Reverse Engineering – Recent Advances and Applications 16 Will-be-set-by-IN-TECH embedded systems. An important concern is soundness (i.e., whether the obtained timing results are guaranteed to generalize to all system executions). Timing analysis via executing the actual system or a model thereof cannot give guarantees (i.e., the approach is unsound), but heuristics to effectively guide the runs can be used to improve the confidence into the obtained results. 14 A sound approach operates under the assumptions that the underlying model is valid. For WCET the tool is trusted to provide a valid hardware model; for model checking the timing automata are (semi-automatically) synthesized from the system and thus model validation is highly desirable. 15 Since both model synthesis and validation involve manual effort, scalability to large systems is a major concern for both model checking and simulation. However, at this time simulation offers better tool support and less manual effort. Another scalability concern for model checking is the state-space explosion problem. One can argue that improvements in model checking techniques and faster hardware alleviate this concern, but this is at least partially countered by the increasing complexity of embedded systems. Simulation, in contrast, avoids the state-space explosion problem by sacrificing the guaranteed safety of the result. In a simulation, the state space of the model is sampled rather than searched exhaustively. With respect to applicability, execution time analysis (both static and hybrid) are not suitable for complex embedded systems and it appears this will be the case for the foreseeable future. The static approach is restricted to smaller systems with simple hardware; the hybrid approach does overcome the problem to model the hardware, but is still prohibitive for systems with nontrivial scheduling regimes and data/control dependencies between tasks. Model checking is increasingly viable for model-driven approaches, but mature tool support is lacking to synthesize models from source code. Thus, model checking may be applicable in principle, but costs are significant and as a result a more favorable cost-to-benefit ratio likely can be obtained by redirection effort elsewhere. Simulation arguably is the most attractive approach for industry, but because it is unsound a key concern is quality assurance. Since industry is very familiar with another unsound technique, testing, expertise from testing can be relatively easily transferred to simulation. Also, synthesis of models seems feasible with reasonable effort even though mature tool support is still lacking. 5. Discussion Based on the review of reverse engineering literature (cf. Section 3) and our own expertise in the domain of complex embedded system we try to establish the current state-of-the-art/practice and identify research challenges. It appears that industry is starting to realize that approaches are needed that enable them to maintain and evolve their complex embedded “legacy” systems in a more effective and predictable manner. There is also the realization that reverse engineering techniques are one important enabling factor to reach this goal. An indication of this trend is the Darwin 14 This is similar to the problems of general software testing; the method can only be used to show the presence of errors, not to prove the absence of errors. Nonetheless, a simulation-based analysis can identify extreme scenarios, e.g., very high response-times which may violate the system requirements, even though worst case scenarios are not identified. 15 The simulation community has long recognized the need for model validation, while the model checking community has mostly neglected this issue.
Software Reverse Engineering in the Domain of Complex Embedded Systems Software Reverse Engineering in the Domain of Complex Embedded Systems 17 project (van de Laar et al., 2011), which was supported by Philips and has developed reverse engineering tools and techniques for complex embedded systems using a Philips MRI scanner (8 million lines of code) as a real-world case study. Another example is the E-CARES project, which was conducted in cooperation with Ericsson Eurolab and looked at the AXE10 telecommunications system (approximately 10 millions of lines of PLEX code developed over about 40 years) (Marburger & Herzberg, 2001; Marburger & Westfechtel, 2010). In the following we structure the discussion into static/dynamic fact extraction, followed by static and dynamic analyses. 5.1 Fact extraction Obtaining facts from the source code or the running system is the first step for each reverse engineering effort. Extracting static facts from complex embedded systems is challenging because they often use C/C++, which is difficult to parse and analyze. While C is already challenging to parse (e.g., due to the C preprocessor) , C++ poses additional hurdles (e.g., due to templates and namespaces). Edison Design Group (EDG) offers a full front-end for C/C++, which is very mature and able to handle a number of different standards and dialects. Maintaining such a front end is complex; according to EDG it has more than half a million lines of C code of which one-third are comments. EDG’s front end is used by many compiler vendors and static analysis tools (e.g., Coverity, CodeSurfer, Axivion’s Bauhaus Suite, and the ROSE compiler infrastructure). Coverity’s developers believe that the EDG front-end “probably resides near the limit of what a profitable company can do in terms of front-end gyrations,” but also that it “still regularly meets defeat when trying to parse real-world large code bases” (Bessey et al., 2010). Other languages that one can encounter in the embedded systems domain—ranging from assembly to PLEX and Erlang—all have their own idiosyncratic challenges. For instance, the Erlang language has many dynamic features that make it difficult to obtain precise and meaningful static information. Extractors have to be robust and scalable. For C there are now a number of tools available with fact extractors that are suitable for complex embedded system. Examples of tools with fine-grained fact bases are Coverity, CodeSurfer, Columbus (www.frontendart.com), Bauhaus (www.axivion.com/), and the Clang Static Analyzer (clang-analyzer.llvm. org/); an example of a commercial tool with a course-grained fact base is Understand (www.scitools.com). For fine-grained extractors, scalability is still a concern for larger systems of more than half a million of lines of code; coarse-grained extractors can be quite fast while handling very large systems. For example, in a case study the Understand tool extracted facts from a system with more than one million of lines of C code in less than 2 minutes (Kraft, 2010, page 144). In another case study, it took CodeSurfer about 132 seconds to process about 100,000 lines of C code (Yazdanshenas & Moonen, 2011). Fact extractors typically focus on a certain programming language per se, neglecting the (heterogeneous) environment that the code interacts with. Especially, fact extractors do not accommodate the underlying hardware (e.g., ports and interrupts), which is mapped to programming constructs or idioms in some form. Consequently, it is difficult or impossible for down-stream analyses to realize domain-specific analyses. In C code for embedded systems one can often find embedded assembly. Depending on the C dialect, different constructs are 19
Page 1 and 2: REVERSE ENGINEERING - RECENT ADVANC
Page 5 and 6: Contents Preface IX Part 1 Software
Page 9 and 10: Preface Introduction In the recent
Page 11 and 12: Preface XI and con’s related to t
Page 13 and 14: Preface XIII the step-by-step appli
Page 17: Part 1 Software Reverse Engineering
Page 20 and 21: 4 Reverse Engineering - Recent Adva
Page 26 and 27: 10 Reverse Engineering - Recent Adv
Page 74 and 75: 58 2. Model driven architecture: An
Page 78 and 79: 62 Fig. 1. Model, metamodels and tr
Page 84 and 85:
68 Reverse Engineering - Recent Adv
Page 86 and 87:
Page 88 and 89:
Page 90 and 91:
Page 92 and 93:
Page 94 and 95:
Page 96 and 97:
Page 98 and 99:
Page 100 and 101:
Page 102 and 103:
Page 104 and 105:
Page 106 and 107:
Page 108 and 109:
Page 110 and 111:
Page 112 and 113:
Page 114 and 115:
Page 116 and 117:
100 Reverse Engineering - Recent Ad
Page 118 and 119:
Page 120 and 121:
Page 122 and 123:
Page 124 and 125:
108 Table 1. Number of smoothers an
Page 126 and 127:
Page 128 and 129:
Page 130 and 131:
Page 133 and 134:
1. Introduction 60 Surface Reconstr
Page 135 and 136:
Surface Reconstruction from Unorgan
Page 137 and 138:
Page 139 and 140:
Page 141 and 142:
Page 143 and 144:
Page 145 and 146:
Page 147 and 148:
Page 149 and 150:
1. Introduction A Systematic Approa
Page 151 and 152:
A Systematic Approach for Geometric
Page 153 and 154:
Page 155 and 156:
Page 157 and 158:
Page 159 and 160:
Page 161 and 162:
Page 163 and 164:
Page 165 and 166:
Page 167 and 168:
Page 169 and 170:
Page 171 and 172:
Page 173 and 174:
Page 175 and 176:
Page 177 and 178:
A Review on Shape Engineering and D
Page 179 and 180:
Page 181 and 182:
Page 183 and 184:
Page 185 and 186:
Page 187 and 188:
Page 189 and 190:
Page 191 and 192:
Page 193 and 194:
Page 195 and 196:
Page 197 and 198:
Page 199 and 200:
Page 201 and 202:
Page 203 and 204:
Integrating Reverse Engineering and
Page 205 and 206:
Page 207 and 208:
Page 209 and 210:
Page 211 and 212:
Page 213 and 214:
Page 215 and 216:
Page 217 and 218:
Page 219 and 220:
Page 221 and 222:
Page 223 and 224:
Page 225 and 226:
Page 227 and 228:
Page 229 and 230:
Page 231:
Part 3 Reverse Engineering in Medic
Page 234 and 235:
Page 236 and 237:
Page 238 and 239:
Page 240 and 241:
Page 242 and 243:
Page 244 and 245:
Page 246 and 247:
Page 248 and 249:
Page 250 and 251:
Page 252 and 253:
Page 254 and 255:
238 5. Summary and discussions Reve
Page 256 and 257:
Page 258 and 259:
Page 260 and 261:
Page 262 and 263:
Page 264 and 265:
Page 266 and 267:
Page 268 and 269:
Page 270 and 271:
Page 272 and 273:
Page 274 and 275:
Page 276 and 277:
Page 278 and 279:
Page 280 and 281:
Page 282 and 283:
Page 284 and 285:
268 Fig. 6. A closed polygon mesh r
Page 286 and 287:
Page 288 and 289:
272 3. Results Reverse Engineering
Page 290 and 291:
Page 292:
show all

reverse engineering – recent advances and applications - OpenLibra

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?