UoKit.com Форумы > Ultima Online : Dev > RunUO Server > Документация
Страницы: 1, 2
Soteric
Листая FAQ на официальном форуме, я случайно наткнулся на раздел, описывающий компиляцию ядра и скриптов в пределах одной сборки. Объединяя ядро и скрипты, на выходе мы получаем исполняющий .exe файл сервера и .dll библиотеку, в которой содержатся все файлы папки Scripts. Такой метод сулит нам:
  • Увеличение скорости компиляции (кто просветит за счет чего? );
  • Простота развертывания (не надо закачивать на хостинг тысячу файлов, достаточно закачать одну библиотеку). Здесь однако кроется и минус - для замены одного маленького файла придется менять всю библиотеку - это около 4МБ, сомнительный плюс при сопровождении сервера;
  • Все компилируется заранее на вашей машине, на хостинге при запуске сервер мгновенно начинает работу;
  • Все файлы уложены в одну сборку и вы всегда можете быть уверены, что на хостинге размещена их полная копия (там их просто никто не сможет отредактировать);
  • Даже украв с хостинга библиотеку, злоумышленник не получит доступ к исходному коду скриптов. Впрочем их можно декомпилировать, но это создаст дополнительную головную боль;
Несмотря на обилие шагов, каждый из них по отдельности прост и реализуется одним-двумя кликами. Поэтому процедура в целом достаточно проста и, на мой взгляд, заслуживает хотя бы усилия по ее выполнению Дополнительную информацию по отдельным пунктам можно получить здесь.

Итак, для реализации задуманного нам понадобятся исходные коды RunUO (*_Full_Src.rar) и C# Exress (выбрать пункт Visual Studio 2012 Express для Windows Desktop) для сборки. Исходные коды самой последней версии могут быть также получены через SVN, описание как это сделать можно найти здесь. Когда все под рукой, то мы можем начинать.

1) В C# Express создаем новую сборку через File --> New --> Project... --> Visual C# --> Console Application. Название может быть любым, здесь я назову его RunUO;

2) В открывшемся Solution Explorer, показывающим что входит в нашу сборку, удаляем из проекта файлы AssemblyInfo.cs и Program.cs, если таковые были созданы;

3) В Windows открываем папку, содержащую исходные коды, и перетаскиваем папку Server на название проекта в Solution Explorer - RunUO. Наши файлы будут добавлены в проект;

4) Открываем меню Project (рядом с File, Edit, View) и выбираем в самом низу функцию "RunUO Properties";

5) На вкладке Application устанавливаем Startup object: Server.Core.

6) На следующей вкладке Build ставим галочку напротив Allow unsafe code;

7) Сохраняем проект (File --> Save all), указав произвольное местоположение сборки;

8) В Solution Explorer нажимаем правой кнопкой на название сборки (RunUO), выбираем Add... --> New Project... --> Class Library. Название также может быть любым, я назвал его Scripts. Это и будет нашей библиотекой скриптов;

9) Теперь в нашей сборке RunUO содержится два проекта - RunUO и Scripts. Также удаляем из проекта файлы AssemblyInfo.cs и Program.cs, если таковые были созданы;

10) Нажимаем правой кнопкой на название проекта Scripts и выбираем Add Reference... Добавляем из вкладки .NET библиотеки:
  • System.Web;
  • System.Drawing;
  • System.Windows.Forms;
  • System.Runtime.Remoting.
11) Из папки с исходными кодами перетаскиваем папку Scripts на название проекта в Solution Explorer - Scripts. Файлы будут добавлены в проект;

12) Открываем меню Project (рядом с File, Edit, View) и выбираем в самом низу функцию "Scripts Properties";

13) На вкладке Build ставим галочку напротив Allow unsafe code;

14) Теперь в проекте RunUO, в папке Server находим файл ScriptCompiler.cs и открываем его двойным щелчком;

15) Около ~541 строки находим следующий код:
Код
EnsureDirectory( "Scripts/" );
EnsureDirectory( "Scripts/Output/" );

if( m_AdditionalReferences.Count > 0 )
    m_AdditionalReferences.Clear();

List<Assembly> assemblies = new List<Assembly>();

Assembly assembly;

выделяем его и заменяем на:
Код
bool HaveCoreScriptsDll = true;
EnsureDirectory( "Scripts/" );
EnsureDirectory( "Scripts/Output/" );

if( m_AdditionalReferences.Count > 0 )
    m_AdditionalReferences.Clear();

List<Assembly> assemblies = new List<Assembly>();

Assembly assembly = null;

try
{
    assembly = Assembly.LoadFrom("Scripts.dll");
}
catch (Exception e)
{
    Console.WriteLine(String.Format("Scripts.DLL: {0}", e.Message));
    Console.WriteLine("Can't load script library, Scripts.DLL!  Proceeding without it.");
    HaveCoreScriptsDll = false;
}

if (HaveCoreScriptsDll)
{
    if ( !m_AdditionalReferences.Contains( assembly.Location ) )
        m_AdditionalReferences.Add( assembly.Location );

    assemblies.Add(assembly);

    Version CSversion = assembly.GetName().Version;
    Console.WriteLine("Using: [{0}] Version {1}.{2}.{3}.{4}", assembly.GetName().Name, CSversion.Major, CSversion.Minor, CSversion.Build, CSversion.Revision);
}

16) Сохраняем проект (File --> Save all);

17) Нажимаем правой кнопкой на название проекта RunUO, выбираем Build. Если все было сделано верно, то в папке сборки \bin\Release появится RunUO.exe - собранное ядро. Если ошибки, то еще раз внимательнее собираем проект и анализируем что было сделано не так;

18) Когда ядро собрано, то нажимаем правой кнопкой на названии проекта Scripts и добавляем ссылку через Add Reference... найдя через вкладку Browse файл ядра - RunUO.exe;

19) Нажимаем правой кнопкой на название сборки RunUO и выбираем Project Dependencies... где для проекта Scripts добавляем галочкой зависимость от RunUO;

20) Сборка почти закончена. В файле Scripts\Misc\ServerList.cs прописываем название нашего шарда и его адрес; в Scripts\Misc\DataPath.cs расположение .mul файлов;

21) Сохраняем проект (File --> Save all);

22) Собираем целиком сборку Build --> Build Solution;

23) В папке сборки Scripts\bin\Release получаем окончательный вариант - ядро RunUO.exe и библиотеку скриптов Scripts.dll;

24) В итоге ваш сервер будет иметь следующую структуру
  • Data (папка взята из исходных кодов)
  • RunUO.exe (ядро)
  • Scripts.dll (библиотека скриптов)
  • zlib32.dll (для x32 битной ОС)
  • zlib64.dll (для x64 битной ОС)
Запускаем, радуемся

Оригинальная статья написана Jareish, ее можно прочитать здесь.
Вверх
Warstone
Цитата(Soteric @ 20.2.2009, 22:46)
Увеличение скорости компиляции (кто просветит за счет чего? );
За счет того, что не пользуется Compiler скрипт в самой Ранке. ИМХО не видно.
Цитата(Soteric @ 20.2.2009, 22:46)
Простота развертывания (не надо закачивать на хостинг тысячу файлов, достаточно закачать одну библиотеку). Здесь однако кроется и минус - для замены одного маленького файла придется менять всю библиотеку - это около 4МБ, сомнительный плюс при сопровождении сервера;
Все компилируется заранее на вашей машине, на хостинге при запуске сервер мгновенно начинает работу;
Все файлы уложены в одну сборку и вы всегда можете быть уверены, что на хостинге размещена их полная копия (там их просто никто не сможет отредактировать);
Даже украв с хостинга библиотеку, злоумышленник не получит доступ к исходному коду скриптов.
Сразу на все. Откройте для себя Reflector. С# 99% восстанавливаемый язык. Из ехе восстанавливается все с точностью до названия локальных переменных. Модификация кода в этом случае не представляется чем-то сложным и не создает никакой боли. Именно из-за этого в свое время Раян и Вят сильно поругались и Ранка стала ОпенСорс.

Результат этого геморроя примерно 1: Легче манипулировать dll чем кучей скриптов. Все остальное - от лукавого.
Вверх
Dark_Falcon
Цитата
Сразу на все. Откройте для себя Reflector. С# 99% восстанавливаемый язык. Из ехе восстанавливается все с точностью до названия локальных переменных. Модификация кода в этом случае не представляется чем-то сложным и не создает никакой боли. Именно из-за этого в свое время Раян и Вят сильно поругались и Ранка стала ОпенСорс.

Угу. А если еще поставить Reflector.FileDisassembler.dll, то жизнь станет еще приятнее...
Вверх
Soteric
Обфускаторы тоже не спасают?
Вверх
Dark_Falcon
Цитата
Обфускаторы тоже не спасают?

Обфускаторы конечно могут сильно запутать код... А то и вовсе, сделать так, что их в reflector не откроешь. Но хороших, бесплатных обфускаторов, я еще не видел! А за те деньги, что продают хорошие, ну их нах, эти скрипты. Хотя знаю один обфускатор, не очень дорогой. http://netobf.com/obfuscator При этом очень хороший! Наш. Русский! Все возможности там расписаны. Даже с картиночками. Как раз показывают, как их программа, с Reflector после обфускации расправляется
Вверх
Soteric
Как бы то ни было, на мой взгляд, это тема отдельной статьи Описанный метод дает возможность защитить свой труд от посягательств со стороны и на этом пока можно поставить точку
Вверх
Warstone
Вот тут в корне не согласен, этот метод не дает
Цитата
возможность защитить свой труд от посягательств со стороны
собственно почему и заговорил об этом.
Вверх
Juzzver
Опоздал я с прочтением этой темы, но всё же скажу =)
Взяв процентное соотношение злоумышлеников:
Взяв процент работающих злоумышлеников на провайдере;
Взяв процент злоумышлеников каторые знают хоть чтото об уо или просто злоумышлиник каторый хочет поживиться рессурсом на будущия что либо поиметь с этого.
Далее он сам поймет или ему разъеснят, что он нехрена не может сделать с рессурсом кроме того как запустить и держать как он есть, что мало кого устроит - он рынется искать другой еще мельче процент зла - каторое поможет ему спустить наводу этот ресурс. При этом за спасибо он не вазмется.
Глядя на другой процент - если этот злоумышленик находящийся на месте расположения будет Warstone, тогда будем бояться. Но к этому проценту "Камень войны" охотиться за просто сервером не будет. И не устроется на работу ради того, чтобы дёрнуть проэкт xD
Остальные разрушители библиотек будут иметь такой же процент =)
Делая выводы о уязвимости данного примера:
Простой смертный: 1%
Бывший геймер UO: 1%
Ранее или ныне АдминUO: 3-4%
Soteric; Warstone; Falcon: 5-6%
Уязвимость вашего сервера на провайдере равна 7% в критическом состоянии и в случае, что у вас большой проэкт.
Шифр 7%: Где простой смертный общаясь с геймером уо на радостях рассказывает, что у него на проводе есть сервер с 1000+онлайном(откуда эти 2% опасности бегут к какому либо знакомому в процентном соотношении 4% успешному стаффу) =6% вместе трудясь понимают, что у них мало шансов и они взрывают двери:
Soteric; Warstone; Dark Falcon; выбивая у кого либо из них 1% уязвимости. После только бьют по библиотеке.
Почему 1%? Потому, что успешным стаффом и должен являться подобием перечисленных прозвищь.
Вот в таком виде мы можем расмотреть семи-процентную уязвимость сервера "Критическую" как для проэкта!!! В других случаях процентное соотношение колибается не выше 1% из 100%!
[*]Т.к. людям работающим на проводе - это не нужно.
[*]Нет друзей по уо.
[*]Не имеют понятия о C# исходние, а темболее о *.dll
[*]Нету связей подобных.
[*]Нету в близи Сотерика, ВарХамера,Тёмного Фалкона.
Вверх
Warstone
Цитата
ВарХамера
Я не варХамер =))))
Юзверь... Ты опять не понял самого главного. Самое главное в этом методе то, что все идет 1-м файлом, занимает меньше места и грузится чуть быстрее.
Если уважаемый Сотерик еще, к тому-же, допишет сюда генерацию native кода для Mono под любую ОСь, которая действительно дает небольшое ускорение (по словам самих разработчиков - выигрывает пока что только менеджер памяти + по мелочам). Тогда статья будет еще более полезней. И тут я не спорю.
Взъелся я на слова Сотерика, что такой подход даст защиту. Просто немного (запуск 1 приложения и работа с ним) усложнит процесс доставания исходников. А вот если использовать нативную генерацию моно, да в FreeBSD, то, по моим данным, Reflector такое пока не кушает.
Вверх
Juzzver
Цитата
Я не варХамер =))))

Извеняюсь, записался малёх =)
Да суть всю я понял. Очень даже хорошая вещь в плане защиты как по мне. Но есть в ней немного гемороя =).
Вверх
Invision Power Board © 2001-2024 Invision Power Services, Inc.
Version for Pocket PC © 2006-2024, IPBest Studio.