Sdílet prostřednictvím

Umbenennen nach dem Überladungsinduktionsverfahren

  • Článek

Dotfuscator implementiert für die Methodenumbenennung eine patentierte Technologie mit dem Namen Überladungsinduktion™. Während die meisten Umbenennungssysteme jedem alten Namen einfach einen neuen Namen zuordnen (aus "getX()" wird z. B. "a()", aus "getY()" wird "b()"), wird die Methode mit Überladungsinduktion so weit wie möglich überladen. Diesem Vorgang liegt das Konzept zugrunde, mithilfe des Algorithmus möglichst viele Methoden mit genau demselben Namen umzubenennen. Viele Kunden bestätigen, dass 33 Prozent aller Methoden in "a()" umbenannt wurden. Dies entspricht hier der Hälfte aller umbenennbaren Methoden! Der Begriff "umbenennbar" wird verwendet, da viele Methoden nicht umbenannt werden können, wenn sie beispielsweise Konstruktoren, "Klassenkonstruktoren" oder Methoden enthalten, die zur Laufzeit aufgerufen werden sollen.

Nach solch weit reichender Verbergung ist die Logik noch intakt, aber völlig unverständlich. Im folgenden einfachen Beispiel wird die Wirksamkeit des Überladungsinduktionsverfahrens veranschaulicht:

Ursprünglicher Quellcode vor dem Verbergen 
private void CalcPayroll(SpecialList employeeGroup) {
   while (employeeGroup.HasMore()) {
        employee = employeeGroup.GetNext(true);
        employee.UpdateSalary();
        DistributeCheck(employee);
    }
}
Zurückentwickelter Quellcode
nach Dotfuscator-Überladungsinduktion		 
private void a(a b) {
    while (b.a()) {
        a = b.a(true);
        a.a();
        a(a);
    }
}

Das Beispiel zeigt, dass der verborgene Code kompakter ist. Die Reduktion des Umfangs ist ein positiver Nebeneffekt des Umbenennens. Wenn ein Name beispielsweise 20 Zeichen lang ist, wird durch Umbenennen in a() viel Platz gespart – 19 Zeichen, um genau zu sein. Die Umbenennung verringert außerdem den für die Einträge auf dem Zeichenfolgenheap benötigten Speicherplatz. Durch Umbenennen aller Bezeichner in "a" muss "a" nur einmal gespeichert werden, und jede Methode und jedes Feld, das in "a" umbenannt wurde, kann darauf verweisen. Überladungsinduktion verstärkt diesen Effekt, da die kürzesten Bezeichner fortlaufend wiederverwendet werden.

Diese Vorgehensweise hat mehrere bedeutende Vorteile:

  1. Umbenennung wird seit langem eingesetzt, um eine dekompilierte Ausgabe schwer verständlich zu machen. Das Umbenennen in nicht druckbare Zeichen (oder in Namen, die in der Zielsprache ungültig sind) ist sinnlos, da Decompiler diese Bezeichner inzwischen längst umbenennen können. In Anbetracht der Tatsache, dass durch Überladungsinduktion drei verschiedene Methodennamen in "a()" umbenannt werden können, wird das Verstehen der dekompilierten Ausgabe, zurückhaltend ausgedrückt, erheblich erschwert.
  2. Überladungsinduktion unterliegt keinen Beschränkungen, denen andere Umbenennungssysteme nicht auch unterliegen. (Diese Beschränkungen werden später erläutert.)
  3. Da die Überladungsinduktion denselben Buchstaben mehrmals verwendet, ist die Verwendung längerer Namen (z. B. aa, aaa usw.) erst später erforderlich. Dadurch wird zudem Platz gespart.

Der patentierte Algorithmus der Überladungsinduktion erkennt potenzielle Umbenennungskonflikte und setzt die Methodenüberladung nur ein, wenn dies gefahrlos möglich ist. Das Verfahren kann nachweislich nicht rückgängig gemacht werden. Das bedeutet, dass es (selbst bei erneuter Überladungsinduktion) nicht möglich ist, die Beziehungen zwischen den ursprünglichen Methodennamen wiederherzustellen.

© 2002-2007 PreEmptive Solutions. Alle Rechte vorbehalten.