TCSE IEEE Technical Council on Software Engineering

WCRE 2004 call for papers - see Events

Working Conference on Reverse Engineering (WCRE 2003)

“Back to the Future”

(A panel discussion on the last 10 Years of Software Reverse Engineering)

Panel organized by Nicolas Anquetil and Rainer Koschke

“We are condemned to repeat our mistakes if we don’t learn from history”.  With these words, invited speaker Elliot Chikofsky opened his presentation on a retrospective over the past 10 years of Software Reverse Engineering (SRE) and the 10^th anniversary of the WCRE.  WCRE, given birth during discussions at a 1992 CASE conference, continues to struggle with competing forums such as ICSM, IWPC, and several SIGsoft groups.  Additionally, the Reverse Engineering Forum (REF), a corollary forum to the WCRE intended to discuss industry’s usage of SRE technologies and techniques, has been discontinued due to insufficient interest.

Back in 1993, the major challenges facing the SRE community of and that WCRE was meant to resolve were artificially contrived data, characterizing the economic impact, and a lack of communications within the community.  To some extent, WCRE and the SRE community has successfully addressed these initial challenges.  Successes include generally accepted terminology, focusing discussion issues, cooperative research, tool/method comparisons, and the interesting evolution of SRE research as the graduate students of 1993 begin to teach and guide their own graduate students.

But the challenges facing SRE have also evolved along with its primary focus.  SRE’s primary focus seems to have shifted from the support of software maintenance and CASE tools to design recovery, migration to whatever (platform, language, architecture, etc.), and program comprehension, then later to Y2K correction efforts, and now to asset recovery and defensive/offensive obfuscation.  Aside from Y2K efforts and CASE tool support, most of these intended purposes for SRE still co-exist, creating a richer, more diverse set of topics for the community to address.  The challenges and pitfalls currently include an over-emphasis on language and software instead of systems, the chasm between static and dynamic reverse engineering, and coping with incompleteness. 

We must move beyond the issues of reverse engineering of code and the automatic generation of documentation.  Instead, we should begin to look at the usability of this technology within the marketplace.  For example, can the SRE community set up guidelines for recommending SRE tools?  Most of our research is tool-biased making us tool-blinded.  Tools should be chameleons, tailorable to a given task and capable of a wide range of SRE tasks.  However, this implies the need for an underlying process or guidelines for use and support such tools.  What happens after a given tool is invented?  What are the anticipated productivity gains and how do we know such gains are achieved?  In other words, the ROI as a profit motive should be expressed by comparing the cost/effort of employing SRE technology vs. the value received.  Perhaps we are missing the mark on exactly who the intended users are and their business needs.  Business users need usable levels of abstraction where they can relate their software systems in business terms and corporate goals.

The WCRE has, overall, been a successful annual conference.  This conference has built a tight community of academic researchers, thus enabling many collaborations of effort.  (In fact, some concern was expressed that perhaps the community was too tight, not allowing for new ideas from new faces.  However, considering that almost half the attendees for WCRE 2003 were first time attendees, that fear may be overstated.)  WCRE has gained international recognition for itself and the field of SRE with the publication of some landmark papers.  But in some sense, WCRE may be a victim of its own success.  The amount of time for discussion of presented papers continues to shrink due to the pressures to accept many more papers and the time now allotted for accompanying workshops.  Some maintain that the SRE field is too homogeneous, thus preventing parallel presentation tracks at the WCRE.  Alternatively, meeting twice a year may strain already tight budgets and resources.  With presentation slots at a premium, it is increasingly difficult to get non-mainstream topics accepted, allowing and recognizing growth within the SRE field needed to satisfy evolving marketplace demands.  While at the same time, the WCRE must allow discussion of topics overlooked by industry.

As for the future, the SRE community must reconsider the ways in which we are working.  Our goals should be more tightly focused, exploring in new directions, yet basing our research on real systems.  Integration is key: the integration of tools, the integration of information from multiple sources, and integrating new with old business rules.  We should seek better ways to disseminate the results of our research to industry.  We should continue to explore how SRE can support an organization’s system architecture including technology assessment procedures that yield evaluation results in terms that can assist decision-making by that organization’s leaders.  

Following Elliot’s presentation, the following was discussed by WCRE attendees:

 ·        Relevance of WCRE to industry

Although tool-building is necessary for research, are the tools presented at WCRE irrelevant to industry?  There seems to be little if any commercial usage of the tools presented at WCRE.  Could it be that the information presented at WCRE is not connected to real-world problems?  This may give impetus to resurrecting the REF as a bridge to the commercial world.  REF would serve as a forum on commercial tools and real-world SRE projects/issues (such as WINE, Lexmark vs. Static Controls, MS Samba, Hacking the X-Box, anti-virus, and IBM autonomic computing).  Although difficult to report due to an understandable unwillingness to discuss failures, papers should also present the failures of SRE within industry.

Resurrecting the REF would allow the WCRE to remain an academic conference.  One option may be to co-locate the REF with WCRE, allotting the first 1.5 or 2 days for REF and the last 2.5 or 3 days for WCRE.  But what would be the impact on the workshops and number of WCRE papers permitted?  Another option would be for the WCRE to add a track on visionary papers and another track for industry.  But could the conference support 3 parallel tracks?  Perhaps one or more tracks could be considered a fast track with minimal discussion.  The full SRE community should be allowed to decide which strategy is best.

·        Software reverse engineer (SRE) is not reengineering

As such, WCRE papers tend to ignore the forward engineering part of software reengineering.  This tendency illustrates the removal of SRE papers from the real-world application of SRE tools and techniques.  After all, the vast majority of software reengineering projects in the real-world must then consider how to use the resulting information gathered by SRE.

·        Sharing SRE tools

Many SRE researchers begin their research by inventing another SRE toolset.  Yet, oftentimes the functionality of these toolsets overlap or duplicate existing toolsets developed by other SRE research groups.  Is it feasible to develop a standard set of basic SRE tools for research?  Such tools could be downloaded from a central website and customized as needed.  At the very least, would SRE research groups be willing to contribute their existing SRE research tools to such a website so that these tools could be downloaded by other SRE research groups?

·        Additional topics for consideration at WCRE

There are numerous articles on the web concerning the hacking of software code and systems.  Hacking usually involves initial SRE for the hacker to understand how the system works and how to defeat protection schemes.  Industry is increasingly interested in system security.  SRE topics should be able to discuss how to support security efforts by protecting system information such as architecture and code design.

WCRE should consider a Birds-of-a-Feather luncheon for like-minded SRE research groups to informally discuss problems and ideas.

·        The SRE newsletter (www.tcse.org/revengr) needs to be revived and expanded

Based on prior discussions with Elliot Chikofsky and Rainer Koschke, Mike Olsem presented several ideas for expanding the usefulness of the Reverse Engineering and Reengineering (RER) website.  An email distribution list should be developed or updated to inform the SRE community of new online newsletters, other RER modifications, the application of SRE research within industry, or anything else that might be of interest to the full SRE community.

Current website information includes:

Ø      Newsletters (letters from the Chair, conf. summaries, industry papers, etc.)

Ø      Related events (conferences, seminars, etc.)

Ø      Terminology project

Ø      Resource repository project

Ø      Pointers to relevant websites

Future website information may include:

Ø      Research genealogy page – a survey sheet was handed out to all WCRE attendees to include contact information, research areas of interest, mentor/student information, and web links.

Ø      Critical SRE literature page with pointers to existing literature lists

Ø      Future SRE research topics

Ø      SRE vendor tools (and consulting services?) with web links.  Should we charge advertising fees for commercial tools advertised on the RER website?

Ø      Real time chat and/or bulletin board

Ø      Ongoing SRE projects within industry

Ø      Any additional ideas?

Send mail to olsemm@tacom.army.mil with questions or comments about this web site.
Last modified: May 25, 2004