Reverse Engineering of Assembler Programs: A Model-Based Approach and its Logical Basis

Transcription

1 Reverse Engineering of Assembler Programs: A Model-Based Approah and its Logial Basis Tom Lake and Tim Blanhard, InterGlossa Ltd., Reading, UK Tel: {Tom.Lake,Tim.Blanhard}@glossa.o.uk Abstrat The REAP projet at InterGlossa is developing tools to support maintenane and reverse engineering of assembly language programs, onentrating on wellengineered hand-oded programs. Abstration of assembly programs takes plae in the ontext of a seleted engineering model whih inludes the definition of the instrution set semantis but also onstraints on the programs simalar to those found in ABIs. The proess of translataon takes the form of a large-sale andutive demonstration that the program meets the onstraints of the engineering model as the translated abstration is produed. An engineer s interfae makes this manifest to the engineer supervasing the translation. This approah an in pranaple handle programs whose models inlude a disiplined use of ode selfmodifiataon or dynami register bank swithing. As intermediate language for the major analyses involved we use a representation based on the XANDF X/Open standard originating from the UK Defene Researh Ageny. XANDF is a standard for arhiteture neutral program representation whih will permit support for analyses of portability. Conurreny is not yet overed but reent advanes show how XANDF an be extended to enompass onurreny and distribution[lo]. We illustrate the effetiveness of the tools with examples taken from live Intel 8051 and Zilog Z80 systems. 1. Introdution The REAP projet at InterGlossa is onstruting tools for the predominantly automati reverse engineering of assembler programs. Our main targets are miro-ontrollers, where pratie is still shifting from use of assemblers to high level languages for embedded systems. The partiular nature of these proessors and the variety of programming styles in use has prompted us to pay partiular attention to the translation from the mahine ode or binary oding to intermediate language. Having expressed the meaning in an intermedi- This work is partly supported by the UK Department of Trade and Industry under the SMART programme. ate language we have found automati transformations satisfatory for translation to C so far. The next setion gives our objetives; setion briefly disusses related work; setion 4 disus., pes our view of translation and defines terms for the rest of the paper; in setion 5 we desribe the reverse engineering proess that ensues; setion 6 gives a brief introdution to the XANDF intermediate language used; setion 7 gives a pratial example; setion 8 disusses the urrent state and prospets of the REAP projet; setion 9 is a summary. 2. Objetives The REAP tools are for translation and also for prodution of maintenane doumentation (inluding interative representations) of assembler ode and binary systems, espeially for miro-ontrollers, with engineer interation supplementing automati transformations and translations. We have seen many examples of long-lived odes, e.g. in aerospae and defene appliations whih are urrently maintained from assembler soure and where translation an ease the maintenane task or provide a more familiar representation of the system for study. Reverse engineering for software maintenane is our primary objetive in the REAP projet. Another objetive in reverse engineering is that we hope to support safety arguments via reverse translation. We expet to provide sound, though not formal, arguments that the behaviour of the system has been aptured. This is the reason for paying partiular attention to the first steps of the translation. At present, safety arguments for miro-ontroller based systems have to be based on the ompilation tool hain. Our REAP tools offer an alternative approah to ertifiers wishing to satisfy themselves of ertain simple properties of a ode from its final installed form. While we would not propose suh methods as the sole safety argument, we do believe that their use offers useful additional safeguards, espeially with respet to tlhe reliability of the tool hain. Consider the safety argument for e.g. the onfinement of a robot arm to a ertain spatial region by, say, a system of sensors and power ontrol. Suh an argument ould be made independent of large parts of the /96 $ IEEE Proeedings of WCRE 96 67

2 system. We believe that a similar approah is within reah by reverse engineering although a great deal of work is neessary before suh arguments an arry real weight. At present they an be simply useful additional evidene of the safety of the implementation and the ompilation tool hain in a given ase. We also expet to be able to provide portable translations of suh ode or to indiate where portability breaks down. The arhiteture neutral representation of store offered by the XANDF intermediate format is essential to ahieving this objetive.. Related Work Other authors have disussed translation and understanding of assembler programs. Deompilation is a form of translation where a restrited and known set of idioms an appear in the soure system. Deompilation for Intel x86 proessors to C is disussed in [] and a more general framework is given by Bowen [2]. For translation of possibly hand-written assembler systems the best-known work is that of Ward and Bennett [5] who desribe their translation of assembler programs briefly. In some ases the authors are most onerned with the indution of design level information from the ode rather than the dedution of its behaviour. Breuer and Lano [6] disuss the indution of objets from CO- BOL and Fortran in this sense. The maintenane system desribed in [8] is more relevant to our urrent onerns. Ward and Bennett disuss assembler translation (in the ontext of the IBM 70 instrution set) in the following terms, with whih we heartily onur: It is theoretially possible to have a perfet model of the language whih orretly aptures the behaviour of all assembler programs. Certain features of Assembler, suh as branhing to register addresses, self-modifying ode and so on, would imply that suh a model would have to reord the entire state of the mahine, inluding all registers, memory, disk spae, and external devies and interpret this state as eah instrution is exeuted. Unfortunately, suh a model is useless for inverse engineering purposes sine suh trivial hanges as deleting a NOP instrution, or hanging the load address of a module, an in theory hange the behaviour of a program. Ward and Bennett then disuss three types of modelling of assembler programs whih are apparently applied to different onstruts during translation and whih they judge suitable for all pratial purposes: 1. Complete modelling: they appear to emphasise the expliit treatment of flag registers and the treatment of the memory as an array here. 2. Partial modelling: The treatment of dynami branhes is disussed under this head, with a set of labels (the set of possible targets) being assoiated, possibly by heuristi means, with dynami branhes. With this approah the dynami aspet an be transferred from the jump target to a onventional ase or hoie struture.. Exluded or minimally modelled: e.g. selfmodifying ode, only speial ases are reognised by the translator. This very general framework oinides with our approah, although we will show that fully automati methods an superede heuristis in many ases, by iteration through the analysis. Very little has been written about the auray of inferene of data strutures. In a private ommuniation Ward indiates that the identifiation of distint data items falls down where the assembler program fiddles with base registers in suh a way as to reate aliasing between otherwise distint symboli names. 4. Translating Mahine Code As mentioned above, we expet eah translation to be assoiated with an idealised model of the proessor, simpler than the full behaviour. Aspets of behaviour whih are not exerised in the partiular system in question an be desribed in the notation of CSP[4] as haos - in a given ase we need not be onerned with the preise desription of subsequent events one the bounds of our model are over-stepped. In general, a range of models will be deployed for a given proessor depending on the features of the proessor whih have been used in the system. For example, for the Intel 8051 family register banks an be swithed dynamially, but may not be in a partiular ase, or again the registers an be addressed by indiretion, but may not be in a partiular ase. Suppose that system S does not exerise a partiular feature F, for example ode modifiation. The absene of F will be an invariant property, say inv-f of the system. A full desription of the proessor may be replaed by a desription whih leaves out the feature or desribes the behaviour on its invoation as haos. This may onsiderably simplify the desription. For example in the absene of ode modifiation the desription need no longer inlude the binary deoding of instrutions, whih may be applied statially to the ode at the outset. The true proessor desription is 68

3 learly a refinement of the partiular desription sine haos is replaed by a partiular behaviour. However, the notion of the inverse of refinement does not preisely apture the nature of our desription. Given the ode for S and its starting and environmental onditions or a partial desription of them we hope to prove the invariane of inv-f. Usually the proessor semantis will allow the effet of a given instrution to be dedued from the state at the start and will speify the state at the end of the instrution. The truth of inv-f on the initial state will allow the simpler semantis to be used. If we an then prove that inv-f is maintained we have the indution step for proving the invariane of inv-f from its initial truth and properties of the rest of the system. Suppose we are trying to prove that there are no register bank swithes in a program. Initially we an assume that there were none up to the nth exeution step and translate the instrutions aordingly. (0therwise we would have had to represent the proessor register banks more expliitly in translation.) Sine the desired invariant is learly true at the start we have to prove that it is preserved by the instrutions of the nth step of the program from the premise that it is valid for the instrutions up to the n - lth. It is this hidden indutive proof that onstitutes the logial basis of reverse engineering. We desribe as an engineering model the simplified proessor desription and the invariants that guarantee its orretness. The availability of a tratable engineering model is usually the result of the disipline applied during the systems design and implementation. When we have verified that the engineering model applies throughout the operation of the system we have already made a big step towards reovering the design of the system, albeit that part whih related to its mapping to the proessor. We an thus see reovery of design information as the reovery of properties whih guarantee the system s onfinement to a state spae in whih its dynamis and properties are more simply desribed. In most ases we annot expet to demonstrate the indution step from a diret translation of the proessor semantis, without a good deal of transformation and preparation. For this reason, we expet to arry the invariants whih haraterise an engineering model forwards through the analysis proess as proof obligations to be disharged either automatially by analysis or by the expliit intervention of human ageny. Our methods are not formal. In order to produe a formal argument for the orretness of a desription of behaviour derived by transformations it is neessary to demonstrate both that the transformations are in a- ordane with the semantis and that the transformation engine applies the transformations orretly. While authors have reported the former property [5] we do not know of systems for whih both properties are formalised Analyses and Proof Obligations The analyses whih lead to disharge of proof obligations are arried out subjet to these onditions. We need to be sure that we are not merely basing an argument on ontradition. In fat onventional data and ontrol flow analyses used to support these demonstrations are satisfatory. Logial problems would arise if we tried to run the semantis bakwards, that is, argue from operation results to operation inputs. As long as we avoid this both bakwards and forwards analyses an ontribute soundly to the overall indutive argument. We hope to formalise this argument in the future. 5. The REAP Reverse Engineering Proess We assume that the program to be reverse engineered has been produed in an engineering environment. By this we generally mean that ertain invariants are preserved during exeution with the result that the interpretation of instrution semantis in the ontext of the program is onsiderably simplified. In this setion we identify the engineering model for the program. As we proess the program, we an hek that the program onforms to the proposed engineering model (and iterate if not). We then present the REAP engineer s interfae (see setion 5.1). Our hoies of engineering model must be strong enough to allow the program to be translated into our hosen intermediate format. The essential harateristis involved are disussed in setion 6.2. When the program is known to onform to a given engineering model (either through assertions about the program by the engineer or by analysis of the soure ode) the program an be translated into one or more intermediate forms. Atually, the program need only partially be shown to onform to the model, while outstanding properties an be arried forward as proof obligations to be disharged later. Alternatively, a partial translation may be possible with partial knowledge, and further knowledge, derived from analysis of the translated form of the program, an be fed bak to improve the partial translation, in an iterative sheme. The XANDF-based intermediate format is referred to in the following as IF. In IF translation we provide 69

4 an IF equivalent for eah assembler instrution, subjet to the validity of the engineering model for the given program. The registers must be modelled as globals but stak loations an be treated as loals provided that stak modelling has shown that their lifetimes are properly nested within those of routines. Manipulation of IF allows us to further verify the onformane of the program to the engineer s model. We also redue program size, and simplify the ode, through transformations suh as eliminating dead expressions and tests, idiom reognition and in-lining. Given onformane to the model we an produe a high level language translation or output the IF representation of the program for later ode generation or further analysis. We desribe this proess in setion 7. In setion 8 we present an example of the REAP tool used on a live Intel 8051 system, illustrated by fragments drawn from the original soure text. Some of the properties that make up an engineering model are almost always inter-proedural in nature, e.g. the orret nesting of all/return pairs. It annot be expeted that translation an be performed effetively on a proedure by proedure basis alone. A useful example of translation is given by the return instrution in a typial assembly language. The return instrution neessarily speifies a data-dependent transfer of ontrol. To substitute the most general semantis of the return instrution into a program is to invite haos. Instead the return instrution should only be translated in ontexts where its use is onstrained. In the most ommon ases the program onforms to the onstraint that the program returns to the instrution following the mathing all, with orretly nested all/return pairs. This an be established by areful modelling of the all/return stak over the ontrol flow of the program. An assembler program annot be translated into the IF format unless its all struture has been analysed and an be modelled using the onventional alls and returns. Suh modelling itself depends on the absene of overwriting or stak overflow of the return stak from the program s exeution. Verifiation of this an be deferred until after translation to IF, when a target independent analysis an be used, sine an IF representation infers that the original stak struture was fairly regular In summary, we arry out the translation in the ontext of a set of oupled global properties of the program whih are verified at various stages of the translation Engineer s Interfae Figure 1 shows the entry interfae of the REAP translator at the start of the translation proess from REAP HYPOTHESIS BROWSER (hypos) SVOL AS PASSED Stak/stak pointer not volatile 2 RTI AS PASSED Instrution after subroutine all SPOVW AS PASSED Stak pointer not overwritten 4 REGB AS PASSED Register bank onstant 5 DTOK AS PASSED Data/return addresses trusty 6 MVPC AS PASSED MOVC from PC unambiguous 7 DPOW AS PASSED DPTR manipulates data labels 8 SOVF IF UNRESOLVED Stak doesn t underflow or overflow 9 SOVW IF UNRESOLVED Stak not overwritten or read 10 INTR IF UNRESOLVED Sope and side effet of interrupts 11 ROVW IF UNRESOLVED No register overwriting by indiretion 12 DIND IF UNRESOLVED Data is reloatable Figure 1. REAP hypothesis browser (8051) Intel 8051 assembler to C. The model seleted is expressed by a number of hypotheses embodying global properties of the system. There is a status assoiated with eah hypothesis (PASSED, FAILED or UNRE- SOLVED). Hypotheses are grouped by phases where AS indiates hypotheses that must be substantiated for the assembler representation of the program; and IF those for substantiation in the intermediate format. A number of analyses are available to the engineer who an aiso browse the ode and any annotation to the ode made by the translator. As the engineer proeeds iteratively with the analyses and examinations of the points at whih they show inonsisteny with the hypotheses of the seleted model, onfidene in the orderly behaviour of the system an be established. A ertain number of analyses are performed diretly on the assembly ode. When a ertain degree of struture has been established, partiularly order in the all/return nesting, it is possible to translate the assembly ode to the intermediate format, IF, whih is based on XANDF, for an easier and more portable approah to program translation. Some aspets of translation, suh as translation of dynami jumps or of pure binary, require, under Ward and Bennett s partial modelling approah, that range information be input to the translations. In fat suh information an be olleted, albeit laboriously, by a grand iteration of the whole translation proess, feeding new ranges disovered in the IF analyses bak to the start of translation. 6. Introdution to XANDF XANDF is an intermediate language developed by DRA at Malvern and adopted as its hoie of ANDF (Arhiteture Neutral Distribution Format) by the Open Software Foundation[7]. XANDF is being standardised by The Open Group (X/Open) [l]. 70

5 6.1. Purpose and Use of XANDF XANDF is an intermediate language independent of soure language and target arhiteture developed by the Open Systems Software Group at DRA Malvern. XANDF supports modular ompiler development, permitting detailed heking of the target independene of programs and the orretness of their use of standard APIs. XANDF has been onsidered as a strategi tehnology for the OM1 projet luster in the ESPRIT program. More generally, XANDF provides a standard semanti medium for programs at the implementation level. XANDF is a tree-strutured language with speial features for portability. It preserves more program struture than low level IRs suh as the RTL of g, but has no syntati sugar and a weaker type system than typial high level languages (HLLs). Expliitly written XANDF appears verbose, but is implemented with powerful ompression. In quantitative studies XANDF ompares well in measures of performane and size with standard ompilation. A produer onverts an HLL into a ompat binary representation of XANDF. The fundamental unit of XANDF is the apsule whih ontains definitions and delarations of proedures, variables and tokens (see below). A apsule an export these delarations and definitions by binding them to external names. A XANDF linker allows apsules to be bound together using these names. Even portable programs possess mahine and operating system dependenies suh as the implementations of C types int and FILE. XANDF possesses a mehanism to defer the representation of target dependent program omponents using parameterised plaeholders alled tokens. XANDF provides a linker that an be used to inlude parameterised definitions for tokens. These expand plae-holders to satisfy target dependenies. An installer onverts a fully linked XANDF file to target speifi objet ode whih is then linked with required system objet libraries using the target system linker to produe an exeutable. Produers have been or are being developed for C, Fortran 77, Ada95, Dylan and C++ along with installers for 80x86, MIPS, Alpha, PowerPC, HP/PA and ARM proessors Expressiveness of XANDF XANDF s desription of store shapes, alignments and aesses allows it to give an arhiteture neutral desription of store without losing the apability of representing C ompletely. XANDF views store as segmented into independently reated hunks known as orzginll spaes. It is not permitted to take the differene of pointers in different original spaes or, by XANDF pointer operations, to derive a pointer in one original spae from a pointer in another. XANDF desribes all proedures as having single entry and returning to their aller. This means that additional onventions have to be adopted to represent the multi-entry and alternate return proeduires used in some programs. 6.. Translation to XANDF When we translate from assembly language to XANDF, in the ontext of the engineering model whih has been assumed, we do so for the partiular data representation appropriate for the proessor and system in question. To ahieve an effiient arhiteture neutral translation we an proeed to demonstrate the representation independene of the program in XANDF. Alternatively, we an transform the program so that the required data representation is bound in, diretly modelling data for the proessor in question. This latter approah is likely to produe slower ode beause oerions to the proessor s register formats has to be introdued in some plaes. Demonstrating representation independene depends on establishing types for the program variables. Our IF ontains onstruts orresponding to most of those in XANDF apart from onstruts onerned with apsule level representation and install time omputation. One all AS phase hypotheses have been validated we may translate the assembler program into IF. The registers and various speial memory loations are translated into variables wherever appropriate. We generally represent separately the smallest units in whih registers an be addressed, e.g. bytes for the bit registers in order to allow liveness analysis the most freedom and re-unite the piees in a later analysis. The status registers are generally translated to separate boolean global variables. The literals in the ode stream beome stati onstants. The ode translation is a semanti equivalent of the assembler instrutions subjet to the onstraints of the engineering model seleted. So, for example, the Intel 8051 instrution MOV A. 84 would be translated to: 2The environment pointers used to provide aess to outer sopes are exeptional but there use is strongly onstrained to avoid violating the independene of original spaes. 71

6 sequene ( assign(obtain-tag(a), make_int(*unsigned_byte(),make_signed_nat(false,4))), assign(obtain_tag(parity),make-parity(ontents(a) )) ) A and parity are alloations of data spaes in the representation of the Intel 8051 memory model. obtain-tag returns the pointer to suh a data spae; ontents retrieves the ontents at that pointer. make-parity is a token standing for determination of parity. Miro-ontrollers often provide optimised funtions that annot be reognised by their ompilers from a soure oding of their semantis. Our translation for funtions like make-parity is an identifier whih an be treated as a C maro but for whih the analyses have respeted the semantis in arrying out transformations. 7. Analysing IF This form of translation leads to a far more ompat intermediate representation than the use of a full proessor desription but one whih is still verbose ompared to the original. We therefore introdue a number of analyses to redue the size of the ode. These eliminate dead global variables, dead expressions and dead jumps using inter-proedural analyses. We also remove unneessary movement of data. We identify multi-word arithmeti operations and shifts and group smaller variables whih are used in ommon multi-word operations. This analysis is inevitably to some extent heuristi and is similar in some respets to the more general lass abstration proesses used in identifying objets in ode. The ode is also simplified by a novel intraproedural ontrol flow normalisation algorithm for IF, the priniples of whih are desribed in [9]. The obligation to verify the remaining parts of the engineering model should be disharged in this representation. We are not yet far enough advaned in the analysis of data representations to support this effetively by automati tools. Analysis of data representations would also allow information on portability and the non-portable onstruts to be reported. At this point an effetive translation to C an be produed. The method involves transformations of the IF to a normal form easily mapped to C ontrol onstruts and then diret translation. 8. Example In this setion, we present an extended example of the use of the REAP reverse engineering tool on an Intel 8051 Teletext Control System, provided by GEC Plessey Semi-Condutors. The system has 7000 lines of assembler soure, whih assembles to 14K of Intel 8051 ode. We also show translations for Z80 as drawn from a live aerospae system Assembly Language Representation The soure ode onforms to our model for Intel 8051 after engineer s assertions: the stak is not misused (the stak pointer is not reset, subroutines return to the point of all, et); the register bank is identifiable; the data pointer (DPTR) is used only for referring to stati data; and the stati data aessed offset from the PC is unambiguously identifiable. There are a few plaes in the ode at whih the engineer must plae an assertion to add information. We illustrate with the treatment of a avalier use of returns in a routine, whih we term unonventional returns. This ase affords a simplifiation of the struture in translation to IF. The subroutine hkint manipulates the all stak by popping off the return address and issuing a return, effetively performing a return from its aller. Our ontrol flow analysis an support suh unonventional exits from subroutines. A problem arises when the return from the routine, via the instrution labelled with nohk, is shared between both the normal exit path from the routine and the double return path. The analysis is flexible enough about the order of instrutions to allow it to deal with pathed ode and hene has no real way of knowing whether the instrution after popping the return address from the stak belongs to the same routine or to its aller. Our default assumption is that it belongs to the aller. But the use of a ommon instrution with the normal return path auses the assembler routine to be onsidered as part of the IF proedure inluding its aller on translation to IF. A human engineer an easily determine what is intended in simple ases, but this judgement is based on heuristi knowledge and ommon sense - whih our analysers as yet do not possess. An assertion of the form AssertReturnOK by the engineer prevents the merging of the routine hkint with its allers into a single IF proedure. AssertReturnOK ats like an artifiial return instrution, ensuring that there is no fall through between the hkint and nohk ode bloks. Consequentially, the alled routines and alling routines are not merged by the ontrol flow analysis Intermediate Code Representation One all hypotheses for the AS phase requirements have been satisfied we are free to translate to IF. The 72

7 hkint: mov a,tflag an1 a,#ofh jz nohk ;TOP aquisition?... jb ie.0,nohk ;EVENT?... 8 setb t imf lag. 7 ;Abandon flag pop a ;Yes, balane stak pop a ;..and return from previous ; interrupt AssertReturnOK 1 nohk: ret Figure Assembler Example TdfExp-Label(: hkintt8,tdfmake-pro( TdfInteger(TdfVar-WidthCTdfFalse,2),2849), C1,N/A, TdfLabelled(TdfCoto(TdfMake-Label(! hkint18),2851), C TdfExp-Label(: hkint'8,tdfsequene( C Tdf Sequene ( C TdfAssign(TdfObtain-Tag(-A.mov A tflag,2856), TdfContents(TdfInteger(-,-,-), TdfObtain-Tag(-,-,-,_),mov A tflag,2857), mov A tflag,2855), TdfAssign(Tdf0btain-Tag(-PAFLITY,mov A tflag,2861), TdfParity(TdfContents(-,-,-,-,-),mov A tflag,2862), mov A tflag,2860)l,mov A tflag,2854), TdfSequene(C TdfAssign(TdfObtain-Tag(-A,anl A #15,2868), TdfAnd(TdfContents(-,-,-,-,-), TdfMake-Int (-,-,-,-,-),an1 A #15,2869), an1 A # ), TdfAssimiTdfObtain-Tap(_PARITY.anl A t ). t " - - ".- TdfParity(TdfContents( -,-,-,-,-),an1 A #15,2876), an1 A #l5,2874)l,anl A #15,2866), TdfInteger-Test(TdfNot-Equal,TdfMake-Label(: nohk!8), tdf-browse> TdfContents (Tdf Integer (TdfVar-Width(Tdf False,a),2882), Figure. IF tree browser REAP tool suite inludes an interative IF tree walker, so that the engineer an determine the orrespondene between the IF and the original assembler. Figure given a typial output from the tool. Note that the tool maintains links to the original assembler by inluding the original assembler instrutions in the IF primitives derived from them. We an now validate the IF hypotheses; and redue the omplexity of the program through various analyses. The program fragment given in figure ould be redued to the ode shown in figure 4: At this point, we an translate the program to C. The resulting C for the subroutine hkint is given in figure 5. At the two return points from the subroutine, there is a differing ret0 field value: one signifies an unonventional return; the aller will test this value and perform a subsequent return as a result, thereby modelling the TdfMake-Pro(TdfStruture( C Tdf Integer(TdfVar_Width(TdfFalse,2),4), TdfInteger(TdfVar_Width(TdfFalse,8),5)1,), C,N/A, TdfVariable (N/A.TdfMake-Tag(JO), TdfMake-Value (Tdf Integer( TdfVar_Width(TdfFalse,8),8),: hkinti0,l). TdfSequene(C TdfMake-Top(iO), TdfAssign(Tdf0btain-Tag(0,anl A #15,12), TdfAnd(TdfC0ntents ( TdfInteger(TdfVar-Width(TdfFalse,8),15), TdfObtain-Tag(tflag,mov A tflag,l6),mov A tflag,14), TdfMake-Int (TdfVar-Width(TdfFa1se.8), 15,an1 A #15,17), an1 A #15,1),anl A #15,11), TdfConditional(TdfSequene( TdfInteger-Test(TdfNot-Equal,: nohk!o(: nohk'0). TdfContents(TdfInteger(TdfVar_Width(TdfFalse,8),22), TdfObtaln-Tag(0,Jz nohk'0,2),jz nohkt0,21), TdfMake-Int(TdfVar-Width(TdfFalse,8),O,Jz nohk!0,24), jz nohkt0,20), TdfConditional (TdfSequene ( TdfInteger-Test(TdfEqua1,LABEL 56, TdfChange-Bitfield-To-Int( Figure 4. IF program fragment, post analysis strut-hkint, hkint-() BYTE -A-0; /* TOP aquisition?... EVENT?... Abandon flag Yes, balane stak */ - A-0 = (*tflag- & 15); if (-A-0!= 0) if (BIT-VALUEO(*ie-) == 0) BIT-SET7 (*t imf lag-) = I ; /*..and return from previous interrupt */ hkint--return (I,-A-0); nohk- : ; hkint--return (O,-A-0); /* hkint- */ Figure 5. C program fragment, post analysis 7

8 A-TO-HL: LD H,A LD L,O SRL H RR L SRL H RR L SET 7,H BOUND : BNG : PNV : BGS : BIT 7,D JR 2,PNV BIT 6,D JR 2,BNG BIT 5,D JR 2,BNG LD A, 80H BIT 6,D JR N2,BGS BIT 5,D JR NZ,BGS LD A, 7FH re original double return ontrol flow onstrut. Two small utility routines from a 280 aerospae appliation are shown - first in assembler and then in their C translation. We see how the inter-proedural analysis gives a lear indiation of the dataflow at alls and returns.. Conlusions and pros The suitability and orthogonality of the onstruts of XANDF and the availability of mahine readable syntax for it has allowed us to proeed rapidly in onstruting transformations and analyses based on XANDF. This is a key advantage in using XANDF as an intermediate form for reverse engineering. We make use of the publily available definition for XANDF and have produed our own toolsets for its manipulation. A long term advantage in using XANDF is it gives us the ability to interoperate with other tool hains, potentially le SHORT A-TO-HL-(BYTE -A-) SHORT -H-L-69; - H-L-69 = ((((SHORT) -A-) << 8) >> 2); BIT7((BYTE-I(-H-L-69, 1))) = 1; return (-H-L-69) ; /* A-TO-HL- */ BYTE BOUND-(BYTE -A-, BYTE -D-) if (BIT7(-D-) == I) if (BITG(-D-) == I) if (BIT5(-D-) == I) return (-A-) ; BNG-: ; return (128); PNV-: ; if (BIT6(-D-) == 0) if (BIT5(-D-) == 0) return (-A-) ; return (127) ; /* BOUND- */ Figure 7. C program fragment, post analysis 74

9 allowing reverse engineering tools to beome a standard faility in a developer's toolset. We now have automated translations to C from 280 and 8051 ode, as our examples demonstrate, and the means to introdue new proessor arhitetures with limited effort. The C ode produed is good quality and learly exhibits the intent of the original programmers. We an deal with theoretially any size of well engineered ode onforming to the urrently fairly simple engineering models that we support (i.e. no dynami jumps, a single stak et). Pratially, we have been automatially translating medium sized embedded appliations of about lines. Development of the REAP tools is on-going. We have a tool hain whih supports translation from 8051 and Z80 to C via XANDF. We have a number of IF analyses, related to ode restruturing and ode elimination. We are adding analyses onneted to data independene and original spaes. Of partiular interest will be analysis whih supports the reation of portable ode by typing onstruts derived from assembler ode. We also expet to be using our indutive framework to give evidene of the behaviour of ritial odes. [8] S.Chen, K.G.Heisler, W.T.Tsai, X.Chen, and E.Leung. A Model for Assembly Program Maintenane. J. Software Maint.: Researh and Pratie, 2:-2, [9] B. Sloman, T. Lake, and S. Williams. Identifying loops in flowgraphs. report SEG/GN/94/1, Dept. of Computer Siene, Reading University, Dept. of Computer Siene, University of Reading, PO Box 225, Whiteknights, Reading, RG6 2AY, UK, Marh [lo] Ben Sloman and Tom Lake. Featherweight threads and ANDF ompilation of onurreny. In Proeedings of EUROPAR '95. Springer-Verlag, Referenes [l] The XANDF guide. Tehnial Report G508, X/OPEN, [2] J.P. Bowen. From Programs to Objet Code and Bak Again. J. Software Maint.: Researh and Pratie, 5(4), 199. [] C.Cifuentes and K.Gough. Deompilation of Binary Programs. Software - Pratie and Experiene, 25(7): , [4] C. A. R. Hoare. Communiating Sequential Proesses. Communiations of the ACM, 21(8): , August [5] M.P.Ward and K.H.Bennett. Formal Methods for Legay Systems. J. Software Maint.: Researh and Pratie, 7():20-220, [6] P.T.Breuer and K. Lano. Creating Speifiations from Code. J. Software Maint.: Researh and Pratze, ( ): , [7] OSF researh institute. ANDF Tehnology Soure Book. Tehnial report, OSF, Cambridge, MA,