JsonConvert.DeserializeObject() возвращает неизвестный объект, когда сборка запутана

у меня есть решение C#, которое содержит два проекта, один из которых является основным приложением, а другой - лицензионным проектом. Проект работает стабильно. я использовал json для сериализации деталей лицензии. теперь мне нужно сделать обфускацию моего лицензионного проекта, чтобы обезопасить его от мошенничества или хакеров. Я использовал Dotfuscator для запутывания. я использовал строку ниже для десериализации сведений о лицензии, полученных приложением. xmlDocument.LoadXml(xml); details = xmlDocument.SelectSingleNode("/license/details"); licenseDetails = JsonConvert.DeserializeObject<LicenseDetails>(details.InnerText);

эта строка возвращает неизвестный объект I после запутывания, но до запутывания она работала хорошо.

возвращаемое значение до обфускации

licenseDetails == Shared.Licensing.Client.LicenseDetails

возвращаемое значение после обфускации

licenseDetails = I

Мой XML-файл

<?xml version="1.0" encoding="utf-8"?> <license> <details>{"Product":"Outlook Templates","ProductVersion":"1.0.0.0","Username":"Demo","Serial":"1fKxUCJylsm+qVUccjUn8gYNVgDc4pE5OuqYs48vkaQ=","RegistrationDate":"\/Date(1326202832909+0200)\/","ExpirationDate":"\/Date(1330387200000)\/","PayloadEntries":[{"ValueType":2,"EntryName":"MaxNumProviders","Operation":1,"EntryValue":"3"},{"ValueType":2,"EntryName":"MaxNumQuick","Operation":1,"EntryValue":"5"},{"ValueType":2,"EntryName":"ExpirationDaysOffset","Operation":1,"EntryValue":"30"}]}</details> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" /> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /> <Reference URI=""> <Transforms> <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" /> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> <DigestValue>c/BK0YOhnW8cXUGxTJx3mpWQj1U=</DigestValue> </Reference> </SignedInfo> <SignatureValue>gWYcpr3OBhUoiPEFyWskgoRcDw5rO2RWNbMulXSXg2tsKWebEFqgptCUfr7JRvvSjm4kALyvU7mZviJI/peJWmJC69gs7QDMEOWLvrOa0TL1qyO5K5onCBZopJUdrPE0PJCVYRacasI3DvTOSo+IDEOSFVpEWZNcERhB6ZkOFrU=</SignatureValue> </Signature> </license>

Я не знаю, что происходит во время обфускации.


json c# dotfuscator
person Ramesh Karna    schedule 28.04.2013    source источник
comment
попробуйте это решение stackoverflow.com/questions/33062867/json-net-and -obfuscation, надеюсь, это поможет!   -  person SteBert    schedule 11.10.2015

Ответы (2)


arrow_upward
0
arrow_downward

Вам придется исключить свойства LicenseDetails, открытые JSON, из переименования.

В качестве альтернативы, если вы не хотите раскрывать эти имена, вы можете вручную преобразовать Json в свой текст LicenseDetails таким образом, чтобы это не включало отражение. Я думаю, вы могли бы использовать что-то вроде этого:

var json=new JObject(details.InnerText);
var license=new LicenseDetails();
license.Product=json["Product"];
license.ProductVersion=json["ProductVersion"];
....

Обратите внимание, что это требует гораздо больше работы, хотя это делается вручную.

person Earlz    schedule 29.04.2013
comment
спасибо за ваше предложение, оно работает, хотя после явного преобразования типа данных, например licenseDetails.Product = json["Product"].ToString(); без явного преобразования, выдает ошибку типа cannot convert source type "Newtonsoft.Json.Linq.JToken' To target type string Теперь у меня проблема с RegistrationDate & PayloadEntries, поскольку они относятся к типу DateTime и List‹›, как я могу явно преобразовать их в связанный тип данных? - person Ramesh Karna; 29.04.2013
comment
@RameshKarn вам, вероятно, придется вручную выполнить DateTime.Parse по датам, и вам, возможно, придется вручную перебрать список и создать новый список. Я бы проверил документацию Json.Net, я довольно ржавый с ней - person Earlz; 29.04.2013

arrow_upward
0
arrow_downward

Обфускация подразумевает, что все существующие имена изменены, чтобы скрыть смысл и назначение кода (умные и целеустремленные люди все равно могут понять, что делает код, просто для этого требуется больше усилий).

Сериализация обычно зависит от соглашений об именах, чтобы сопоставить входные данные со свойствами целевого объекта. Поскольку последние были переименованы, вам необходимо предоставить явную карту имен для вашего механизма сериализации. Обычно это работает путем аннотирования всех сериализованных свойств атрибутами, где каждый атрибут указывает сериализованное имя свойства. Эта информация позволяет сериализатору, например. сопоставьте ввод «RegistrationDate» со свойством «I1i» (в качестве примера запутанное имя для того, что, вероятно, также называлось «RegistrationDate» до запутывания). Обратитесь к документации вашего механизма сериализации, чтобы узнать, как вы его настраиваете.

Однако вы должны отметить, что эти атрибуты и их значения легко доступны людям, проверяющим вашу сборку, и поэтому вы на самом деле очень мало выигрываете от запутывания кода. На самом деле, я бы сказал, что это пустая трата вашего времени, поскольку даже запутанный код обычно можно декомпилировать до довольно разумного C#.

person Morten Mertner    schedule 28.04.2013
comment
since even obfuscated code can usually be decompiled to fairly sensible C#. Нет, если вы используете приличное запутывание потока управления. Я работаю над Dotfuscator, поэтому я предвзят, но я считаю, что большинство декомпиляторов захлебнутся запутанным кодом и либо не смогут полностью декомпилировать, либо внесут логические ошибки в C#. Обфускация никогда не является 100% решением, но она служит для того, чтобы люди с декомпиляторами не могли быстро обойти ваше лицензирование (или что-то еще) с 5 минутами свободного времени. - person Earlz; 29.04.2013
comment
@Earlz Хотя я согласен с тем, что декомпиляторы иногда задыхаются, очень трудно скрыть, что происходит в коде IL, поскольку методы вызываются по имени (поэтому, по крайней мере, все обращения к BCL будет легко обнаружить). Обфускация может помочь защитить интеллектуальную собственность (код), но, конечно же, не удерживает тех, кто заинтересован в обходе лицензионной защиты. Кроме того, агрессивное переписывание кода может привести к появлению незаметных ошибок, которые проявятся только в коде релиза. Немного дополнительной защиты лицензии не оправдывает этот риск, по крайней мере, с моей точки зрения. - person Morten Mertner; 29.04.2013