reverse engineering – recent advances and applications - OpenLibra

More documents

Recommendations

Info

6 Reverse Engineering – Recent Advances and Applications 4 Will-be-set-by-IN-TECH computer engineering skills for construction. These characteristics already make it apparent that complex embedded systems differ from desktop and business applications. Typical non-functional requirements in this domain are safety, maintainability, testability, reliability and robustness, safety, portability, and reusability (Ebert & Salecker, 2009; Hänninen et al., 2006). From a business perspective, driving factors are cost and time-to-market (Ebert & Jones, 2009; Graaf et al., 2003). While users of desktop and web-based software are accustomed to software bugs, users of complex embedded systems are by far less tolerant of malfunction. Consequently, embedded systems often have to meet high quality standards. For embedded systems that are safety-critical, society expects software that is free of faults that can lead to (physical) harm (e.g., consumer reaction to cases of unintended acceleration of Toyota cars (Cusumano, 2011)). In fact, manufacturers of safety-critical devices have to deal with safety standards and consumer protection laws (Åkerholm et al., 2009). In case of (physical) injuries caused by omissions or negligence, the manufacturer may be found liable to monetarily compensate for an injury (Kaner, 1997). The Economist claims that “product-liability settlements have cost the motor industry billions” (The Economist, 2008), and Ackermann et al. (2010) say that for automotive companies and their suppliers such as Bosch “safety, warranty, recall and liability concerns . . . require that software be of high quality and dependability.” A major challenge is the fact that complex embedded systems are becoming more complex and feature-rich, and that the growth rate of embedded software in general has accelerated as well (Ebert & Jones, 2009; Graaf et al., 2003; Hänninen et al., 2006). For the automotive industry, the increase in software has been exponential, starting from zero in 1976 to more than 10 million lines of code that can be found in a premium car 30 years later (Broy, 2006). Similar challenges in terms of increasing software are faced by the avionics domain (both commercial and military) as well; a fighter plane can have over 7 million lines of code (Parkinson, n.d.) and alone the flight management system of a commercial aircraft’s cockpit is around 1 million lines of code (Avery, 2011). Software maintainers have to accommodate this trend without sacrificing key quality attributes. In order to increase confidence in complex embedded systems, verification techniques such as reviews, analyses, and testing can be applied. According to one study “testing is the main technique to verify functional requirements” (Hänninen et al., 2006). Ebert and Jones say that “embedded-software engineers must know and use a richer combination of defect prevention and removal activities than other software domains” Ebert & Jones (2009). Complex embedded systems are real-time systems, which are often designed and implemented as a set of tasks 1 that can communicate with each other via mechanisms such as message queues or shared memory. While there are off-line scheduling techniques that can guarantee the timeliness of a system if certain constraints are met, these constraints are too restrictive for many complex embedded systems. In practice, these systems are implemented on top of a real-time operating system that does online scheduling of tasks, typically using preemptive fixed priority scheduling (FPS). 2 In FPS scheduling, each task has a scheduling priority, which typically is determined at design time, but priorities may also change dynamically during 1 A task is “the basic unit of work from the standpoint of a control program” RTCA (1992). It may be realized as an operating system process or thread. 2 An FPS scheduler always executes the task of highest priority being ready to execute (i.e., which is not, e.g., blocked or waiting), and when preemptive scheduling is used, the executing task is immediately preempted when a higher priority task is in a ready state.
Software Reverse Engineering in the Domain of Complex Embedded Systems Software Reverse Engineering in the Domain of Complex Embedded Systems 5 run-time. In the latter case, the details of the temporal behavior (i.e., the exact execution order) becomes an emerging property of the system at run-time. Worse, many complex embedded systems are hard real-time systems, meaning that a single missed deadline of a task is considered a failure. For instance, for Electronic Control Units (ECUs) in vehicles as much as 95% of the functionality is realized as hard real-time tasks (Hänninen et al., 2006). The deadline of tasks in an ECU has a broad spectrum: from milliseconds to several seconds. The real-time nature of complex embedded systems means that maintainers and developers have to deal with the fact that the system’s correctness also depends on timeliness in the sense that the latency between input and output should not exceed a specific limit (the deadline). This is a matter of timing predictability, not average performance, and therefore poses an additional burden on verification via code analyses and testing. For example, instrumenting the code may alter its temporal behavior (i.e., probing effect (McDowell & Helmbold, 1989)). Since timing analysis arguably is the foremost challenge in this domain, we address it in detail in Section 4. The following example illustrates why it can be difficult or infeasible to automatically derive timing properties for complex embedded systems (Bohlin et al., 2009). Imagine a system that has a task that processes messages that arrive in a queue: do { msg = receive_msg(my_msg_queue); process_msg(msg); } while (msg != NO_MESSAGE); The loop’s execution time obviously depends on the messages in the queue. Thus, a timing analysis needs to know the maximum queue length. It also may have to consider that other tasks may preempt the execution of the loop and add messages to the queue. Besides timing constraints there are other resource constraints such as limited memory (RAM and ROM), power consumption, communication bandwidth, and hardware costs (Graaf et al., 2003). The in-depth analysis of resource limitations if often dispensed with by over-dimensioning hardware (Hänninen et al., 2006). Possibly, this is the case because general software development technologies do not offer features to effectively deal with these constraints (Graaf et al., 2003). Even though many complex embedded systems are safety-critical, or at least business-critical, they are often developed in traditional, relatively primitive and unsafe programming languages such as C/C++ or assembly. 3 As a general rule, the development practice for complex embedded systems in industry is not radically different from less critical software systems; formal verification techniques are rarely used. Such methods are typically only applied to truly safety-critical systems or components. (Even then, it is no panacea as formally proven software might still be unsafe (Liggesmeyer & Trapp, 2009).) Complex embedded systems are often legacy systems because they contain millions of lines of code and are developed and maintained by dozens or hundreds of engineers over many years. 3 According to Ebert & Jones (2009), C/C++ and assembly is used by more than 80 percent and 40 percent of companies, respectively. Another survey of 30 companies found 57% use of C/C++, 20% use of assembly, and 17% use of Java (Tihinen & Kuvaja, 2004). 7
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 24 and 25: 8 Reverse Engineering - Recent Adva
Page 26 and 27: 10 Reverse Engineering - Recent Adv
Page 72 and 73:
56 Reverse Engineering - Recent Adv
Page 74 and 75:
58 2. Model driven architecture: An
Page 76 and 77:
Page 78 and 79:
62 Fig. 1. Model, metamodels and tr
Page 80 and 81:
Page 82 and 83:
Page 84 and 85:
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

Create successful ePaper yourself

Delete template?

Save as template?