До чого це я? А до того, що даний продукт також захищений цим протектором (як і, наприклад, VIP). Визначити протектор не складає проблеми, так як давно вже існує безліч різноманітних програм, які допомагають в цій справі: PeID, DotNet Id, ProtectionID і т.п. Відповідно, якщо проаналізувати виконуваний файл за допомогою ProtectionID, то він відразу ж видасть наступне:
Відразу відкрити такий файл в рефлекторе не вийде, бо:
.NET Reactor builds a native code wall between potential hackers and your .NET assemblies by producing a file which can not be understood directly as CIL. Because the CIL in your assembly is emitted intact only at run time or design time (in a form in which the source is completely inaccessible), no tool is capable of decompiling .NET Reactor protected assemblies.
Проблема вирішується досить просто:
1. Запускаємо програму.
2. Качаємо який-небудь .NET-дампер (якщо немає бажання за допомогою відладчика копатися в пам'яті процесу).
3. дампи частина пам'яті процесу.
4. ...
5. PROFIT!
Але після відкриття отриманого файлу в рефлекторе ми побачимо "порожні" методи в найцікавіших місцях:
Щоб не вникати в особливості (я жахливий ледар), звернемося до ще одного корисного інструменту CodeRipper'a - Reactor Decryptor. Відповідно відкриваємо програму в ньому, деобфусціруем додаток, а вже потім обробляємо його фіксери заголовків. Отриманий файл можна спокійно відкрити в рефлекторе і подивитися код цікавить нас методу.
Єдина неприємність - рядки в нечитабельному вигляді. Але і це не становить проблеми, просто відкриваємо файл в програмі Simple Assembly Explorer, переходимо до цікавого методу і використовуємо вбудований деобфускатор. Перед нами
шукані рядки:
