Einen gRPC-Dienst obfuskieren, ohne den Vertrag auf der Leitung zu brechen

Eine gRPC-Assembly ist voller Namen, und die Obfuskierung muss sie in zwei Stapel sortieren, deren Regeln genau entgegengesetzt sind.

Auf dem einen Stapel liegen die Namen, die zwischen Prozessen reisen: der Dienstpfad, den ein Client wählt, der Methodenpfad darin, die Feldnummern, die jedes Feld einer serialisierten Nachricht identifizieren. Diese sind ein Vertrag. Jeder andere Peer — ein in Go geschriebener Dienst, ein Mobil-Client, die letztjährige Build deines eigenen Gateways — hängt von ihrer Stabilität ab, und einen umzubenennen ist von einer Änderung einer veröffentlichten URL nicht zu unterscheiden. Auf dem anderen Stapel liegen die Namen, die den Prozess nie verlassen: deine C#-Methodennamen, die Eigenschaften deiner Nachrichtenklassen, der Typ, den du an MapGrpcService<T> übergibst. Das sind Etiketten, die der CLR intern auflöst, und sie können ohne beobachtbare Wirkung zu a, b, c abgeflacht werden.

Die ganze Frage, gRPC sicher zu obfuskieren, ist welcher Name auf welchem Stapel liegt — und die Antwort kippt vollständig, je nachdem, ob du deinen Dienst aus einer .proto-Datei generiert oder ihn in C# mit protobuf-net.Grpc definiert hast.

Contract-First: Die Leitungsidentität ist in den generierten Code eingebrannt

Beginne mit dem häufigen Fall — eine .proto, kompiliert von Grpc.Tools. Der Vertrag wird einmal deklariert, in einer Datei, die nicht einmal C# ist:

syntax = "proto3";
package greet;

service Greeter {
  rpc SayHello (HelloRequest) returns (HelloReply);
}

message HelloRequest {
  string name = 1;
}

message HelloReply {
  string greeting = 1;
}

Der Generator macht daraus eine Greeter.g.cs, deren Aufgabe es ist, die Leitungsidentität als Literale zu tragen. Die Routing-Oberfläche sieht so aus (gekürzt auf das Wesentliche):

public static partial class Greeter
{
    static readonly string __ServiceName = "greet.Greeter";

    static readonly grpc::Method<HelloRequest, HelloReply> __Method_SayHello =
        new grpc::Method<HelloRequest, HelloReply>(
            grpc::MethodType.Unary,
            __ServiceName,                 // "greet.Greeter"
            "SayHello",                    // method name — a literal, not derived
            __Marshaller_HelloRequest,
            __Marshaller_HelloReply);
    // ...
}

Lies, was das für die Umbenennung bedeutet. Der Pfad, den ein Client wählt, ist /greet.Greeter/SayHello, und er wird aus den Zeichenfolgen-Literalen "greet.Greeter" und "SayHello" zusammengesetzt, die im Method-Deskriptor liegen. Er wird zur Laufzeit nicht aus dem Namen irgendeiner C#-Methode abgeleitet. Also deine tatsächliche Implementierung:

public override Task<HelloReply> SayHello(HelloRequest request, ServerCallContext ctx) =>
    Task.FromResult(new HelloReply { Greeting = $"Hello {request.Name}" });

kann ihren C#-Bezeichner in b umbenannt haben, und der Dispatcher bindet sie weiterhin an das Literal "SayHello" im Deskriptor, denn der Dienst-Definitions-Builder des Servers ordnet den Methodennamen des Deskriptors dem Delegaten zu — der Bezeichner der Methode ist für das Routing irrelevant. Die Namen, die du behalten musst, sind die innerhalb der generierten Datei: __ServiceName und die Method-Deskriptoren, denn diese Literale sind der Leitungsvertrag.

Feldnummern machen Nachrichtenmitglieder frei

Nachrichten sind die andere Hälfte, und hier tut dir Protobuf einen Gefallen. Die generierte HelloRequest serialisiert nach Nummer, nicht nach Namen:

public void WriteTo(pb::CodedOutputStream output)
{
    if (Name.Length != 0)
    {
        output.WriteRawTag(10);   // (field 1 << 3) | wiretype 2  ==  the tag for "name"
        output.WriteString(Name);
    }
}

Das Tag 10 kodiert die Feldnummer 1 mit Leitungstyp 2 (längenbegrenzt). Dieses Tag ist, was ein Peer liest; die C#-Eigenschaft Name ist nur ein lokaler Zugriff. Benenne Name in a um, und WriteTo gibt weiterhin das Tag 10 aus, sodass jeder Peer, der Feld 1 liest, nicht betroffen ist. Die Nachrichteneigenschaftsnamen liegen fest auf dem Frei-umbenennbar-Stapel: Die Feld-Nummer trägt die Identität, und die Nummer lebt im .proto, nicht in deinen Bezeichnern.

Zwei Vorbehalte. Erstens, wenn du gRPC-JSON-Transkodierung oder ein JSON-Gateway bereitstellst, orientiert sich diese Oberfläche am Namen des Felds im camelCase, sodass die Feldnamen auf der Leitung sichtbar werden und auf den transkodierten Nachrichten erhalten bleiben müssen. Zweitens werden Enum-Wertnamen vom JSON-Formatierer als Zeichenfolgen serialisiert und sind über die Server-Reflexion sichtbar, also fixiere, wenn du dich auf eines von beiden verlässt, die Enum-Mitgliedsnamen. Reines binäres gRPC hängt von keinem ab.

Code-First kehrt die Stapel um: Deine .NET-Namen sind der Vertrag

Nun der Fall, der die Leute stolpern lässt. Mit protobuf-net.Grpc gibt es kein .proto und keinen generierten Deskriptor voller Literale. Du schreibst den Vertrag in C#:

[ServiceContract]
public interface IGreeter
{
    [OperationContract]
    Task<HelloReply> SayHelloAsync(HelloRequest request, CallContext ctx = default);
}

[ProtoContract]
public class HelloRequest
{
    [ProtoMember(1)] public string Name { get; set; } = "";
}

Beim Start reflektiert die Bibliothek über IGreeter und leitet die Leitungsidentität aus den .NET-Namen ab: Der Dienstpfad kommt vom Schnittstellennamen (IGreeter → Dienst Greeter nach ihrer Standard-Benennungskonvention), und jeder Methodenpfad kommt vom Methodennamen (SayHelloAsync). Es gibt keine Literale zu erhalten, denn die Namen selbst sind die Literale. Benenne IGreeter in a um, und du hast den Dienstpfad umbenannt; benenne SayHelloAsync in b um, und du hast die Methode verschoben. Ein blinder Umbenennungslauf ändert stillschweigend den Vertrag, und jeder Client scheitert daran, den Endpunkt zu finden, den er aufzurufen pflegte.

Nachrichten bleiben sicher — [ProtoMember(1)] fixiert die Feldnummer 1, egal wie die Eigenschaft Name heißt, genau wie in Contract-First — aber die Dienstoberfläche ist auf den Zu-erhalten-Stapel gewandert. Zwei Wege, damit umzugehen, in Reihenfolge der Präferenz:

Die robuste Lösung ist, überhaupt nicht mehr von den Bezeichnern abzuhängen, indem man dem Vertrag explizite Namen gibt:

[ServiceContract(Name = "greet.Greeter")]
public interface IGreeter
{
    [OperationContract(Name = "SayHello")]
    Task<HelloReply> SayHelloAsync(HelloRequest request, CallContext ctx = default);
}

Jetzt ist die Leitungsidentität "greet.Greeter"/"SayHello" aus den Attributen, die Bezeichner IGreeter und SayHelloAsync sind wieder frei umbenennbar, und dein Vertrag hängt nicht mehr davon ab, wie dein Code heißt — was gute Hygiene ist, selbst wenn du nie obfuskierst. Die Alternative, wenn du die Verträge nicht bearbeiten kannst, ist, die Typ- und Mitgliedsnamen der Vertragsschnittstellen zu fixieren, damit die Reflexion weiterhin die Namen liest, die sie erwartet.

Nebula sagen, welcher Stapel welcher ist

Nebula rät nicht. Für Contract-First erkennt es die generierte Dienstoberfläche an der Form des Deskriptors und behält die Dienstnamenskonstante, die Method-Deskriptoren und (wenn konfiguriert) die Enum-Wertnamen, während es deine Implementierungen, die Nachrichteneigenschaftsbezeichner, die DI-Verdrahtung und die Interzeptoren umbenennt. Für Code-First zeigst du es auf die Vertragsattribute, damit es die [ServiceContract]/[OperationContract]-Typen und -Mitglieder als die zu erhaltende Menge behandelt.

<Nebula>
  <!-- Contract-first: keep the wire identity the generator baked in. -->
  <!-- Service-name constants and Method<,> descriptors in generated gRPC code. -->
  <Preserve names="true" members="true"
            attribute="System.CodeDom.Compiler.GeneratedCodeAttribute"
            where="GrpcServices" />

  <!-- Code-first: the .NET names ARE the contract surface. -->
  <Preserve names="true" members="true" attribute="System.ServiceModel.ServiceContractAttribute" />
  <Preserve names="true" members="true" attribute="System.ServiceModel.OperationContractAttribute" />

  <!-- Enums whose value names hit the wire via JSON/reflection. -->
  <Preserve memberNames="true" where="ProtoEnums" />

  <!-- Everything else — service implementations, message property names,
       interceptors, private helpers — gets full renaming. -->
</Nebula>

Die DI-Registrierung braucht keine Sonderbehandlung. builder.Services.AddGrpc() und app.MapGrpcService<GreeterService>() binden nach Type, nicht nach Namen, sodass GreeterService in d umbenannt werden kann und die Zuordnung weiterhin auflöst — das generische Argument ist ein Metadaten-Token, so wie alle Typreferenzen, und die Umbenennung aktualisiert es konsistent. Ebenso sind die Marshaller, der CallContext und deine Interzeptoren interne Verrohrung, die sauber umbenannt wird.

Die eine Regel, die beide Stile abdeckt

Nimm die Besonderheiten weg, und gRPC gehorcht derselben Regel wie jedes andere Framework, das über eine Grenze greift: Ein Name ist tragend genau dann, wenn etwas außerhalb der Token-Auflösung des CLR ihn liest. Auf der binären Leitung sind das der Dienstpfad, der Methodenpfad und die Feldnummern — und Feldnummern bedeuten, dass deine Nachrichtenmitglieder frei sind. Über JSON-Transkodierung oder Reflexion bedeutet es zusätzlich die Feldnamen und die Enum-Wertnamen. Und in Code-First zieht die Reflexion beim Start deine .NET-Typ- und -Mitgliedsnamen über diese Grenze, was der eigentliche Grund ist, warum Code-First die Antwort ändert.

Finde diese Grenze, erhalte genau die Namen, die sie überqueren, und lass Nebula alles umbenennen, was auf deiner Seite bleibt. Du behältst den Schutz über deine Dienstimplementierungen und deine Geschäftslogik — den Code, der wirklich Schutz verdient — und der Vertrag auf der Leitung bewegt sich nie.