带有混淆的 Proto-buf 序列化 [英] Proto-buf serialization with Obfuscation

问题描述

我正在寻找有关使用带有混淆的 proto-buf 网络 (Dotfuscator) 时发生了什么的一些指导.项目的一半是 DLL，另一半是其他地方的 EXE，他们使用 proto-buf NET 完美地交换数据.直到我混淆了 DLL.

I am looking for some guidance as to what is going on when using proto-buf net with obfuscation (Dotfuscator). One half of the project is a DLL and the other is an EXE elsewhere and using proto-buf NET they exchange data flawlessly. Until I obfuscate the DLL.

那时 P-BN 失败而没有引发异常，返回不同的长度为 0 的字节数组或缩短的数组，具体取决于我摆弄过的内容.该类相当简单(VB):

At that point P-BN fails without raising an exception, returning variously a 0 length byte array or a foreshortened one depending on what I have fiddled with. The class is fairly simple (VB):

<ProtoContract(Name:="DMailer")> _
Friend Class DMailer

    Private _Lic As Cert
    Private _Sys As Sys
    Private _LList As List(Of LItem)

    ..
    ..
End Class

有 3 个 props 都用 ProtoMember 装饰来获取/设置组成类对象.为简洁起见剪掉了.

There are 3 props all decorated with ProtoMember to get/set the constituent class objects. Snipped for brevity.

再说一次，它运行良好，直到我混淆了 DLL.然后，Dotfuscator 将这些重命名为 null，显然因为它们都是 Friend，这似乎扼杀了 proto-buff.如果我免于重命名类(只是类名，而不是道具/成员)，它似乎又可以工作了.P-BN 只能作用于具有适当名称的对象是有道理的，尽管当被要求序列化一个空命名对象时，似乎可能会有一个例外.

Again, it works GREAT until I obfuscate the DLL. Then, Dotfuscator renames each of these to null, apparently since they are all Friend, and that seems to choke proto-buff. If I exempt the class from renaming (just the class name, not props/members), it seems to work again. It makes sense that P-BN would only be able to act on objects with a proper name, though when asked to serialize a null named object, it seems like an exception might be in order.

另一方面，PB-N 的大部分魅力应该是序列化独立 .NET 名称从属性工作 - 至少在我的理解中是这样.然而，在这种情况下，它似乎只适用于带有名称的类.我尝试使用如上所示的 Name 限定符或参数，但无济于事 - 它显然没有按照我的想法行事.

On the other hand, much of the charm of PB-N is supposed to be serialization independent of .NET names working from attributes - at least as I understand it. Yet in this case it only seems to work with classes with names. I tried using the Name qualifier or argument as shown above, to no avail - it apparently doesnt do what I thought it might.

所以，我很好奇:

a) ...我基本上正确地推测了问题

a) ...I have basically surmised the problem correctly

b) ...还有一些其他属性或标志可能有助于序列化一个空的命名对象

b) ...There is some other attribute or flag that might facilitate serializing a null named object

c) ...如果还有其他有用的见解.

c) ...if there are any other insights that would help.

如果我从 Dotfuscator 重命名中免除所有 3 或 4 个类(LList 尚未实际实现，留下 DMailer、Cert 和 Sys)，DLL 似乎又可以工作了 - 至少输出是正确的大小.我可以接受，虽然模糊名称会更好:Dotfuscator (CE) 要么免除它们，要么将名称设置为 Null - 我似乎无法找到强制重命名它们的方法.

If I exempt all 3 or 4 classes from Dotfuscator renaming (LList is not actually implemented yet, leaving DMailer, Cert and Sys), the DLL seems to work again - at least the output is the correct size. I can live with that, though obscured names would be better: Dotfuscator (CE) either exempts them or sets the names to Null - I cant seem to find a way to force them to be renamed.

我正在考虑的一种替代方法不是免除 3 或 4 个类的重命名，而是简单地将 Cert 和 Sys 的序列化程序输出存储为 DMailer 中的字节数组或 Base64 字符串，而不是类.然后让接收者分别反序列化每个对象.能够像魔术一样打开一件事并把玩具放在那里真是太好了.

Rather than exempt 3 or 4 classes from renaming, one alternative I am considering is to simply store the Serializer output for Cert and Sys as byte arrays or Base64 strings in DMailer instead of classes. Then have the receiver Deserialize each object individually. It is kind of nice to be able to unpack just one thing and have your toys right there as if by magic though.

(许多)TIA

推荐答案

由于有一些兴趣增加，以下是可行的:

Since there were a few upticks of interest, here is what looks like will work:

a) 任何形式的反射都无法获得混淆类型的属性列表.我尝试遍历所有类型以找到带有 ProtoContract 的类型，我可以找到它们但是属性名都改成了a,m,b,j,g.

a) No form of reflection will be able to get the list of properties for an obfuscated type. I tried walking thru all the types to find the ones with ProtoContract on it, I could find them but the property names are all changed to a,m, b, j, g.

我也尝试了 Me.GetType.GetProperties，结果相同.

I also tried Me.GetType.GetProperties with the same result.

您可以从输出中实现一个映射来指示 Employee.FirstName 现在是 a0.j，但是分发它会违背混淆的目的.

You could implement a map from the output to indicate that Employee.FirstName is now a0.j, but distributing this defeats the purpose of obfuscation.

b) 在一定程度上起作用的是免除类 NAME 的混淆.由于 PB-N 寻找 ProtoMember 属性来获取数据，您可以混淆属性/成员名称，而不是类/类型名称.如果名称类似于 FederalReserveLogIn，则您的类/类型有一个靶心.

b) What does work to a degree is to exempt the class NAME from obfuscation. Since PB-N looks for the ProtoMember attributes to get the data, you CAN obfuscate the Property/Member names, just not the CLASS/type name. If the name is something like FederalReserveLogIn, your class/type has a bullseye on it.

我在以下方面取得了初步成功:

I have had initial success doing the following:

1) 构建一个简单的类来存储属性令牌和值.使用 ConvertFromInvariantString 将所有内容存储为字符串.从 PBN 那里得到一个提示，我使用了一个整数作为令牌:

1) Build a simple class to store a Property Token and value. Store everything as string using ConvertFromInvariantString. Taking a tip from PBN, I used an integer for the token:

<ProtoMember(propIndex.Foo)>
Property Foo As String

枚举有助于稍后将所有内容联系在一起.将这些存储在 Dictionary(Of T, NameValuePair)

An enum helps tie everything together later. Store these in a Dictionary(Of T, NameValuePair)

2) 添加一些访问器.这些可以为您执行类型转换:

2) add some accessors. these can perform the type conversions for you:

  Public Sub Add(ByVal Key As T, ByVal value As Object)
        If _col.ContainsKey(Key) Then
            _col.Remove(Key)
        End If

        _col.Add(Key, New TValue(value))

    End Sub

    Public Function GetTItem(Of TT)(key As T) As TT
        If _col.ContainsKey(key) Then
            Return CType(_col(key).TValue, TT)
        Else
            Return Nothing
        End If
    End Function

T 是您希望使用的任何键类型.Integer 导致最小的输出，并且仍然允许订阅代码使用 Enum.但它可能是字符串.

T is whatever key type you wish to use. Integer results in the smallest output and still allows the subscribing code to use an Enum. But it could be String.

TT 是原始类型:

myFoo = props.GetTItem(Of Long)(propsEnum.Foo)

3) 将内部列表(字典)暴露给 PBN 和宾果游戏，全部完成.

3) Expose the innerlist (dictionary) to PBN and bingo, all done.

添加点、矩形、字体、大小、颜色甚至位图转换器也很容易.

Its also very easy to add converters for Point, Rectangle, Font, Size, Color and even bitmap.

HTH

这篇关于带有混淆的 Proto-buf 序列化的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！