Спасибо всем ребятам, которые пытались помочь. Я только что сделал это (или, лучше сказать, взломал это :-)
Короче говоря, действительно есть ключ в реестре. Я не смог найти его, потому что он не был указан под именем программного обеспечения. После того, как я скопировал этот ключ (и с некоторыми знаниями в области программирования), он работает как по волшебству.
Вот мои шаги.
Я провел несколько исследований и много поисков в Google. Я начал с этого сайта, обучая как получить серийный номер программы с OllyDbg.
Тем не менее, я обнаружил, что это Microsoft Visual C # / Basic .NET в PEiD.
Я не смог отладить мой .exe от OllyDbg. Сказал на этом сайте:
Олли здесь не ответ, потому что это программа .Net. Так что используйте Google, чтобы найти программу, которая поможет вам.
Сначала я наткнулся на декомпилятор .NET. Это хороший инструмент. После моей первой проверки исходного кода я обнаружил критический метод btnOK_Click() который является точкой для проверки UserKey. К сожалению, содержимое метода маскируется // trial версией в .NET-декомпиляторе (wtf), поскольку это не бесплатная программа, и она стоит 399 долларов США (не меньше для меня). И еще, я не уверен, что он гарантированно получит UserKey после покупки декомпилятора .NET. (в любом случае, это мой первый раз)
Затем я перешел к другим бесплатным альтернативам, таким как ILSpy (бесплатно) и .NET Reflector (14-дневная пробная версия ).
Наконец-то я смог проверить метод btnOK_Click :
private void btnOK_Click(object sender, EventArgs e)
{
this.pbcUserKey = Strings.Trim(this.txtUserKey1.Text + this.txtUserKey2.Text + this.txtUserKey3.Text + this.txtUserKey4.Text);
this.pbcUserKey = Strings.LSet(Strings.Trim(this.pbcUserKey), 16);
try
{
this.createUserKey = modCommon.XxGetUserID(ref this.pbcUserKey);
if (this.createUserKey)
{
MyProject.Forms.FrmLauncher.strUserID = this.pbcUserKey;
}
}
catch (Exception expr_86)
{
ProjectData.SetProjectError(expr_86);
Application.Exit();
ProjectData.ClearProjectError();
}
this.Close();
}
Проще говоря , pbcUserKey - это пользовательский ключ, который мы вводим, и с чем он будет сравниваться? Он передается в метаданные modCommon.XxGetUserID():
[DllImport("XXGetUserkey.dll", CharSet = CharSet.Ansi, ExactSpelling = true, SetLastError = true)]
public static extern bool XxGetUserID([MarshalAs(UnmanagedType.VBByRefStr)] ref string userID);
Еще одно препятствие подошло. Это внешний метод, и мы не смогли просмотреть его источник. Мы только знаем, что путь для дальнейшего продвижения вперед должен быть XXGetUserkey.dll . Поверьте мне, я проверял эту DLL миллион раз, и мне не повезло. (Я не смог найти IL Disassembler из M $ btw) Если у вас есть какие-либо инструменты для просмотра / дизассемблирования / декомпиляции DLL, ваш вклад будет высоко оценен!
Я снова начал думать обо всем потоке. Первоначально я хотел использовать OllyDbg для дублирования программы, а не для декомпиляции. Я надеюсь, что, если бы я смог найти инструмент, который фактически отлаживает программы .NET, я бы мог проверить регистры и места в памяти, чтобы увидеть, с чем сравнивается мой ввод (например, как сказано в самой первой веб-ссылке). Вот почему я начал искать «.NET-отладчик», и я не удосужился попробовать другой декомпилятор, такой как dotPeek или другие, упомянутые здесь. Однако, кроме официального средства отладки M $, я не смог найти других.
Здесь я полагаю, что официальным инструментам не хватает взломанных способностей. Это правда? Есть ли там какой-нибудь злой отладчик .NET? (Мне нужны NAMES - режим #gangsters)
Столкнувшись с тупиком, я начал искать другой маршрут. Теперь мы не могли получить UserKey путем отладки или декомпиляции. Что если пропустить процесс проверки?
В декомпилированном исходном коде я обнаружил, что XxGetUserID() используется prfBeforeLoad() в дополнение к btnOK_Click() . Тогда мне наконец-то повезло в prfBeforeLoad():
private bool prfBeforeLoad()
{
RegistryKey registryKey = Registry.CurrentUser.OpenSubKey("SOFTWARE\\XX-1234-12345678", false);
bool flag = false;
string left;
if (registryKey == null)
{
left = "";
}
else
{
left = Conversions.ToString(registryKey.GetValue("YY-11112222"));
}
// ...
bool flag2 = modCommon.XxGetUserID(ref left);
// ...
}
Я посмотрел в HKEY_CURRENT_USER\Software\XX-1234-12345678 и нашел ключ XX-1234-12345678 и значение 123456789ABCDEF0 . После простого добавления этой пары ключа и значения в соответствующее место в реестре на компьютере B, она работает как по волшебству - без повторного запроса слова о ключе пользователя - конечно, это то, как она кодируется. B-)
Бонус трек:
123456789ABCDEF0 на самом деле UserKey. Ввод того же ключа в графическом интерфейсе активирует программное обеспечение, действуя так же, как и изменение реестра.
В общем:
На этот раз мне повезло, что ключ пользователя хранится в реестре, и я нашел его путь в исходном коде (как я полагаю, это просто программное обеспечение). И все же есть много высоких препятствий, которые я не мог бы перепрыгнуть
Если ключ объединен / зашифрован с ключом компьютера (например, MAC-адрес), мой простой подход потерпит неудачу.
Если ключ не хранится в реестре и не отображается в кодах, например, он извлекается онлайн, сейчас я все еще не могу отладить исполняемый файл .NET , получить ключ пользователя будет невозможно.
Хотя я могу декомпилировать и просматривать исходный код программ .NET, DLL-библиотека Microsoft Visual C++ 6.0 все еще остается загадкой.
Вот еще несколько (может быть полезных) веб-ссылок:
Взлом простого приложения (ByPass Login) - получение ключа непосредственно из исходного кода (кода сборки). Он просто предоставил скриншот, но не упомянул название инструмента.
Взломанная программа сделана на VB.NET / C # / Delphi / MC++ / Oxygene / F # - создание кейгенов путем проверки исходного кода в .NET Reflector. Скопируйте строку аутентификации для генерации ключа.
Взлом .NET DLL для любителей [1] и [2] - довольно краткое, но хорошее простое руководство. .NET Reflector не может открыть мой XXGetUserkey.dll . В PEiD сказано, что это Microsoft Visual C++ 6.0 DLL, которая может быть причиной.
