💻 computer science

Project-wise Comparison of Software Birthmarks Using Weighted Partial Similarity

Dieses Paper schlägt ein projektweises Software-Birthmark-Vergleichsframework vor, das gewichtete Aggregation und Mechanismen zur partiellen Ähnlichkeit verwendet, um die partielle Code-Wiederverwendung robust zu detektieren und durch kleine Module verursachte falsch-positive Ergebnisse zu minimieren, wobei es eine überlegene Leistung gegenüber bestehenden Methoden über diverse Open-Source-Java-Projekte hinweg demonstriert.

Ursprüngliche Autoren: Nikolay Fedorov, Akito Monden, Hiroki Inayoshi, Haruaki Tamada, Masateru Tsunoda

Veröffentlicht 2026-06-30

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Nikolay Fedorov, Akito Monden, Hiroki Inayoshi, Haruaki Tamada, Masateru Tsunoda

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie sind ein Detektiv, der versucht, einen Fall von Software-Plagiaten zu lösen. Jemand hat ein Stück Code aus einem Open-Source-Projekt genommen, ihn leicht verändert und behauptet, er sei sein eigener. Ihre Aufgabe ist es, zu beweisen, dass diese Person gestohlen hat.

In der Vergangenheit untersuchten Detektive (Forscher) dieses Problem eine Datei nach der anderen. Sie verglichen Datei A von Projekt X mit Datei B von Projekt Y. Wenn sie sich ähnlich sahen, schlugen sie Alarm.

Aber echte Software ist eher wie eine riesige Bibliothek als wie ein einzelnes Buch. Ein Projekt kann Tausende von Dateien haben. Oft stiehlt ein Dieb nur ein oder zwei Kapitel (Module) aus einem Buch und fügt sie in seine eigene massive Enzyklopädie ein. Wenn man die gesamte Enzyklopädie mit dem Original vergleicht, gehen die gestohlenen Kapitel im Rauschen verloren. Außerdem können zwei völlig unterschiedliche Bibliotheken manchmal ein paar generische Wörter gemeinsam haben (wie „der“, „die“ oder „das“), was den Detektiv dazu verleiten kann, zu glauben, es handele sich um dasselbe Buch.

Dieses Paper stellt eine neue, intelligentere Art vor, ganze Softwareprojekte zu vergleichen, um solche Diebe zu überführen. Hier ist die Erklärung, wie sie es gemacht haben, vereinfacht dargestellt:

1. Das Problem: Die „Nadel im Heuhaufen“ und der „Fehlalarm“

Die Autoren identifizierten zwei Hauptprobleme der alten Methoden:

Die Nadel im Heuhaufen (Teilweise Wiederverwendung): Wenn ein Projekt 1.000 Dateien hat und nur 10 gestohlen wurden, verwässert der Blick auf die durchschnittliche Ähnlichkeit aller 1.000 Dateien das Beweismaterial. Das „gestohlene“ Signal wird durch die „sauberen“ Dateien überdeckt.
Der Fehlalarm (Zufällige Ähnlichkeit): Kleine, generische Dateien (wie ein einfaches „Hello World“ oder eine einfache Hilfsfunktion) können rein zufällig ähnlich aussehen. Wenn man eine winzige 5-Zeilen-Datei genauso behandelt wie eine massive 5.000-Zeilen-Datei, kann die winzige Datei einen Fehlalarm auslösen und zwei unschuldige Projekte wie Zwillinge aussehen lassen.

2. Die Lösung: Eine zweistufige Detektivstrategie

Die Autoren schlugen ein neues Framework vor, das wie ein intelligenter Filter fungiert. Sie schauten nicht nur auf die Dateien; sie schauten auf das Gewicht der Dateien und ignorierten das Rauschen.

Schritt A: Die „Gewichtsskala“ (Gewichtung)

Stellen Sie sich vor, Sie vergleichen zwei Obstkörbe. In einem Korb liegt eine riesige Wassermelone, im anderen eine winzige Weintraube.

Alte Methode: Zählt die Weintraube und die Wassermelone jeweils als „1 Stück Obst“.
Neue Methode: Erkennt, dass die Wassermelone viel bedeutender ist. Sie gibt der Wassermelone ein hohes „Gewicht“ und der Weintraube ein geringes „Gewicht“.

In ihrer Software wiesen sie größeren Codemodulen eine höhere Bedeutung zu. Wenn eine kleine Datei einer anderen kleinen Datei ähnlich sieht, sagt das System: „Das ist wahrscheinlich nur ein Zufall; ignorieren Sie es.“ Aber wenn eine riesige, komplexe Datei einer ähn sieht, zahlt das System genau darauf acht. Dies verhindert die „Fehlalarme“, die durch winzige, generische Dateien entstehen.

Schritt B: Die „Top 1 %“-Regel (Teilweise Ähnlichkeit)

Stellen Sie sich vor, Sie suchen nach einem bestimmten Lied in einer Playlist mit 1.000 Liedern. Sie wollen nicht die ganze Playlist anhören, um den Treffer zu finden; Sie wollen nur die top paar Lieder hören, die Ihrem Ziel am ähnlichsten sind.

Alte Methode: Berechnet den Durchschnitt der Ähnlichkeit jeder Dateipaar zwischen zwei Projekten.
Neue Methode: Sagt: „Lass uns nur die Top 1 % bis 5 % der ähnlichsten Dateipaare betrachten.“

Indem sie sich nur auf die „besten Übereinstimmungen“ konzentrieren und den Rest ignorieren, ignoriert das System die tausenden irrelevanten Dateien, die nicht wichtig sind. Dies macht es viel einfacher, die „Nadel“ (den gestohlenen Code) zu finden, selbst wenn er nur ein kleiner Teil eines riesigen Projekts ist.

3. Das Experiment: Den neuen Detektiv testen

Um zu beweisen, dass dies funktioniert, bauten die Forscher ein Testlabor:

Die Testobjekte: Sie sammelten 35 reale Java-Projekte (wie Mediaplayer, Texteditoren und Testwerkzeuge) von GitHub.
Der Aufbau: Sie behandelten verschiedene Versionen desselben Projekts als „gestohlene“ Fälle (da neue Versionen einfach alte Versionen mit Änderungen sind). Sie behandelten verschiedene Projekte derselben Kategorie (z. B. zwei verschiedene Mediaplayer) als „unschuldige“ Fälle.
Die Metrik: Sie maßen zwei Dinge:
1. Resilienz: Kann es den „gestohlenen“ Code immer noch finden, selbst wenn der Dieb ihn verändert hat?
2. Glaubwürdigkeit: Kann es korrekt sagen: „Nein, diese beiden sind unterschiedlich“, wenn sie es tatsächlich sind?

4. Die Ergebnisse: Die neue Methode gewinnt

Die Ergebnisse waren eindeutig:

Die neue Methode (Gewichtung + Top-1%-Fokus) war signifikant besser als alle bestehenden Methoden.
Sie war sehr stabil (konsistente Ergebnisse) und machte selten Fehler.
Interessanterweise stellten sie fest, dass Symmetrie eine Rolle spielt. Wenn man Projekt A mit Projekt B vergleicht, sollte der Score derselbe sein wie beim Vergleich von B mit A. Ihre neue Methode stellte diese Balance sicher, was ältere Methoden nicht taten.
Sie fanden auch heraus, dass die Edit Distance (eine Methode, um zu messen, wie viele Änderungen nötig sind, um einen String in einen anderen zu verwandeln) das beste Werkzeug für den Vergleich der eigentlichen Code-Snippets war.

Das Fazit

Dieses Paper sagt nicht nur: „Wir haben einen besseren Weg gefunden, Code zu zählen.“ Es sagt: „Um einen Dieb zu fangen, der nur ein paar Seiten aus einer Bibliothek gestohlen hat, müssen Sie die winzigen, generischen Seiten ignorieren und sich auf die schweren, komplexen Kapitel konzentrieren, die übereinstimmen.“

Indem sie großen Dateien mehr Gewicht verleihen und sich nur auf die allerbesten Übereinstimmungen konzentrieren, macht dieses neue Framework es für Plagiatoren viel schwieriger, ihren Diebstahl in einer Flut von Code zu verstecken, und für unschuldige Projekte viel schwieriger, fälschlicherweise beschuldigt zu werden.

Technisches Resümee: Projektweiser Vergleich von Software-Birthmarks mittels gewichteter partieller Ähnlichkeit

Problemstellung
Software-Birthmarks sind intrinsische Programmekennzeichen, die zur Erkennung von Plagiaten und unbefugter Code-Wiederverwendung verwendet werden. Während bestehende Ähnlichkeitsmaße auf Modulebene effektiv sind (z. B. beim Vergleich einzelner Quell- oder Klassendateien), reichen sie für groß angelegte, reale Software-Ökosysteme, die aus zahlreichen Modulen bestehen, nicht aus. Es ergeben sich zwei primäre Herausforderungen bei der Aggregation von Modulebene-Vergleichen auf Projektebene:

Partielle Wiederverwendung: In vielen Fällen wird nur eine Teilmenge der Module innerhalb eines Projekts wiederverwendet, während der Großteil unzusammenhängend bleibt. Eine einheitliche Aggregation aller Modulpaare verwässert das Signal der tatsächlichen Wiederverwendung.
Zufällige Ähnlichkeit: Kleine oder generische Module weisen oft durch Zufall eine hohe Ähnlichkeit zwischen unzusammenhängenden Projekten auf. Wenn diese „verrauschten“ Übereinstimmungen gleich behandelt werden wie größere Module, können sie zu falsch-positiven Ergebnissen führen und die Glaubwürdigkeit der Erkennung untergraben.

Aktuelle projektweise Methoden versäumen es oft, diese Probleme systematisch anzugehen, da es ihnen an robusten Mechanismen mangelt, um zwischen bedeutsamer partieller Wiederverwendung und zufälligem Rauschen zu unterscheiden.

Methodik
Die Autoren schlagen ein Framework für den projektweisen Vergleich von Birthmarks vor, das Ähnlichkeiten auf Modulebene unter Verwendung zweier komplementärer Mechanismen aggregiert: Gewichtete Aggregation und Partielle Ähnlichkeit.

Symmetrische Aggregation (SA): Das Framework etabliert eine Basis-Methode zur symmetrischen Aggregation. Im Gegensatz zu bisherigen asymmetrischen Ansätzen berechnet SA den Durchschnitt der höchsten Ähnlichkeitswerte, die für jedes Modul in Projekt A gegenüber Projekt B und umgekehrt gefunden wurden. Dies stellt sicher, dass der Ähnlichkeitswert unabhängig von der Eingabereihenfolge ist.
Gewichtzuweisung: Um die zufällige Ähnlichkeit durch kleine Module zu mildern, weisen die Autoren den Modulen Gewichte basierend auf ihrer Größe (speziell der Anzahl der $k$ -Gramme) zu. Eine logarithmische Transformation ( $W = \ln(K)$ ) wird angewendet, um den Gewichtsbereich zu komprimieren, wodurch verhindert wird, dass extrem große Module den Score dominieren, während gleichzeitig der Einfluss kleiner, verrauschter Module reduziert wird. Die endgültige gewichtete Ähnlichkeit zwischen zwei Modulen ist das Produkt ihrer Rohähnlichkeit und des Minimums ihrer normalisierten Gewichte.
Partielle Ähnlichkeit: Um die partielle Wiederverwendung zu adressieren, konzentriert sich das Framework nur auf den obersten Bruchteil ( $\alpha\%$ ) der höchsten gewichteten Ähnlichkeitswerte zwischen Modulpaaren. Durch das Ignorieren der Masse unzusammenhängender Modulpaare betont diese Methode die relevantesten wiederverwendeten Komponenten.
Evaluationsmetriken: Die Leistung wird mittels Resilienz (die Fähigkeit, wiederverwendeten Code trotz Modifikationen zu erkennen) und Glaubwürdigkeit (die Fähigkeit, unabhängig entwickelte Projekte zu unterscheiden) bewertet. Diese werden über ihr harmonisches Mittel ( $H_{mean}$ ) kombert, um ein Gleichgewicht zwischen der Erkennung wahrer Positiver und der Vermeidung falscher Positiver zu gewährleisten.

Experimenteller Aufbau
Die Studie nutzt einen Datensatz von 35 Open-Source-Java-Projekten aus 10 Kategorien. Wiederverwendungsfälle werden simuliert, indem verschiedene Versionen desselben Projekts verglichen werden, während Nicht-Wiederverwendungsfälle durch den Vergleich verschiedener Projekte innerhalb derselben Kategorie gebildet werden. Die Experimente verwenden statische $k$ -Gramm-Birthmarks und evaluieren verschiedene Modul-Ähnlichkeitsfunktionen (z. B. Cosine, Jaccard, Edit Distance) sowie verschiedene Parameterkonfigurationen.

Wichtigste Ergebnisse

Überlegenheit der vorgeschlagenen Methode: Die vorgeschlagene Methode (die Gewichtung und partielle Ähnlichkeit mit einem Umfang von 1 % kombiniert) übertrifft konsistent bestehende Ansätze, einschließlich der Baseline-Methode von Lee et al. und früherer aggregierter Ähnlichkeitsvarianten. Sie erreicht das höchste mediane $H_{mean}$ (0,9728) bei geringer Varianz.
Notwendigkeit der Gewichtung: Gewichtung ist entscheidend. Wenn partielle Ähnlichkeit ohne Gewichtung angewendet wird, verschlechtert sich die Leistung erheblich (in einigen Konfigurationen sogar unter die Zufallsähnlichkeit), da kleine Module die obersten Paare dominieren. Die Gewichtung unterdrückt dieses Rauschen und stabilisiert die Ergebnisse.
Effektivität der partiellen Ähnlichkeit: Die Konzentration auf eine kleine Teilmenge hochgradig ähnlicher Modulpaare (z. B. die Top 1 % oder 5 %) liefert bessere Ergebnisse als die Berücksichtigung aller Paare. Dies bestätigt, dass das Ignorieren unzusammenhängender Module essenziell für die Erkennung partieller Wiederverwendung ist.
Optimale Konfigurationen: Die beste Leistung wird mit kleinen Vergleichsumfängen (1–5 %), größeren $k$ -Gramm-Größen (3–4) und der Edit Distance Ähnlichkeitsfunktion erreicht, welche die höchste Genauigkeit und Stabilität unter den getesteten Funktionen demonstrierte.
Symmetrische Aggregation als Baseline: Selbst ohne Gewichtung oder partielle Ähnlichkeit übertrifft die Formulierung der symmetrischen Aggregation selbst bereits bestehende asymmetrische Methoden und bietet somit eine starke Grundlage für den projektweisen Vergleich.

Bedeutung und Behauptungen
Das Paper beansprucht, ein robustes Framework für den projektweisen Vergleich von Birthmarks zu etablieren, das die spezifischen Einschränkungen der Analyse auf Modulebene in groß angelegten Systemen adressiert. Die Autoren behaupten:

Projektweise Ähnlichkeit ist eine notwendige Komponente für die erste Stufe der groß angelegten Plagiatserkennung (Retrieval), die der detaillierten Überprüfung auf Modulebene vorausgeht.
Die Kombination aus größenbasierter Gewichtung und partieller Ähnlichkeit ist ein komplementärer Mechanismus, der sowohl die Resilienz gegenüber Code-Modifikationen als auch die Glaubwürdigkeit bei der Unterscheidung unzusammenhängender Projekte gemeinsam verbessert.
Effektive projektweise Ähnlichkeit erfordert keine komplexen Matching-Strategien; vielmehr bietet eine einfache Kombination aus symmetrischer Aggregation, größenbewussten Gewichten und dem selektiven Fokus auf hochgradig ähnliche Paare eine praktische und robuste Lösung.
Das vorgeschlagene Framework ist allgemein und für verschiedene Arten von Birthmarks anwendbar, obwohl die Studie es spezifisch unter Verwendung statischer $k$ -Gramm-Birthmarks auf Java-Projekten validiert.

Die Autoren räumen Einschränkungen ein und merken an, dass der Datensatz aus Open-Source-Java-Projekten besteht und keine bestätigten Fälle von realer Plagiatsabsicht oder adversariell obfuskierten Code enthält. Sie positionieren ihre Arbeit als systematische Evaluierung von Ähnlichkeitsaggregationsstrategien, wobei zukünftige Arbeiten geplant sind, um das Verfahren auf andere Sprachen zu erweitieren und die Robustheit gegenüber Obfuskation zu untersuchen.