Автор: Soteric 20.2.2009, 22:46
Листая FAQ на официальном форуме, я случайно наткнулся на раздел, описывающий компиляцию ядра и скриптов в пределах одной сборки. Объединяя ядро и скрипты, на выходе мы получаем исполняющий .exe файл сервера и .dll библиотеку, в которой содержатся все файлы папки Scripts. Такой метод сулит нам:
- Увеличение скорости компиляции (кто просветит за счет чего? );
- Простота развертывания (не надо закачивать на хостинг тысячу файлов, достаточно закачать одну библиотеку). Здесь однако кроется и минус - для замены одного маленького файла придется менять всю библиотеку - это около 4МБ, сомнительный плюс при сопровождении сервера;
- Все компилируется заранее на вашей машине, на хостинге при запуске сервер мгновенно начинает работу;
- Все файлы уложены в одну сборку и вы всегда можете быть уверены, что на хостинге размещена их полная копия (там их просто никто не сможет отредактировать);
- Даже украв с хостинга библиотеку, злоумышленник не получит доступ к исходному коду скриптов. Впрочем их можно декомпилировать, но это создаст дополнительную головную боль;
Несмотря на обилие шагов, каждый из них по отдельности прост и реализуется одним-двумя кликами. Поэтому процедура в целом достаточно проста и, на мой взгляд, заслуживает хотя бы усилия по ее выполнению
Дополнительную информацию по отдельным пунктам можно получить https://forum.uokit.com/index.php?showtopic=13936
Итак, для реализации задуманного нам понадобятся
https://code.google.com/p/runuo/downloads/list и
http://www.microsoft.com/visualstudio/rus/downloads#d-2012-express (выбрать пункт Visual Studio 2012 Express для Windows Desktop) для сборки. Исходные коды самой последней версии могут быть также получены через
SVN, описание как это сделать можно найти https://forum.uokit.com/index.php?showtopic=13936 Когда все под рукой, то мы можем начинать.
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 (библиотека скриптов)
- http://www.runuo.com/mark/zlib32.dll (для x32 битной ОС)
- http://www.runuo.com/mark/zlib64.dll (для x64 битной ОС)
Запускаем, радуемся
Оригинальная статья написана
Jareish, ее можно прочитать http://www.runuo.com/forums/faq-forum/87363-setting-up-runuo-visual-c-express-2005-creating-exe-library.html
Автор: Warstone 21.2.2009, 0:10
Цитата(Soteric @ 20.2.2009, 22:46)
Увеличение скорости компиляции (кто просветит за счет чего?
);
За счет того, что не пользуется Compiler скрипт в самой Ранке. ИМХО не видно.
Цитата(Soteric @ 20.2.2009, 22:46)
Простота развертывания (не надо закачивать на хостинг тысячу файлов, достаточно закачать одну библиотеку). Здесь однако кроется и минус - для замены одного маленького файла придется менять всю библиотеку - это около 4МБ, сомнительный плюс при сопровождении сервера;
Все компилируется заранее на вашей машине, на хостинге при запуске сервер мгновенно начинает работу;
Все файлы уложены в одну сборку и вы всегда можете быть уверены, что на хостинге размещена их полная копия (там их просто никто не сможет отредактировать);
Даже украв с хостинга библиотеку, злоумышленник не получит доступ к исходному коду скриптов.
Сразу на все. Откройте для себя Reflector. С# 99% восстанавливаемый язык. Из ехе восстанавливается все с точностью до названия
локальных переменных. Модификация кода в этом случае не представляется чем-то сложным и не создает никакой боли. Именно из-за этого в свое время Раян и Вят сильно поругались и Ранка стала ОпенСорс.
Результат этого геморроя примерно 1: Легче манипулировать dll чем кучей скриптов. Все остальное - от лукавого.
Автор: Dark_Falcon 21.2.2009, 1:26
Цитата
Сразу на все. Откройте для себя Reflector. С# 99% восстанавливаемый язык. Из ехе восстанавливается все с точностью до названия локальных переменных. Модификация кода в этом случае не представляется чем-то сложным и не создает никакой боли. Именно из-за этого в свое время Раян и Вят сильно поругались и Ранка стала ОпенСорс.
Угу. А если еще поставить Reflector.FileDisassembler.dll, то жизнь станет еще приятнее...
Автор: Dark_Falcon 21.2.2009, 15:16
Цитата
Обфускаторы тоже не спасают?
Обфускаторы конечно могут сильно запутать код... А то и вовсе, сделать так, что их в reflector не откроешь. Но хороших, бесплатных обфускаторов, я еще не видел!
А за те деньги, что продают хорошие, ну их нах, эти скрипты.
Хотя знаю один обфускатор, не очень дорогой. http://netobf.com/obfuscator При этом очень хороший! Наш. Русский!
Все возможности там расписаны. Даже с картиночками. Как раз показывают, как их программа, с Reflector после обфускации расправляется
Автор: Soteric 21.2.2009, 16:48
Как бы то ни было, на мой взгляд, это тема отдельной статьи Описанный метод дает возможность защитить свой труд от посягательств со стороны и на этом пока можно поставить точку
Автор: Warstone 22.2.2009, 5:50
Вот тут в корне не согласен, этот метод не дает
Цитата
возможность защитить свой труд от посягательств со стороны
собственно почему и заговорил об этом.
Автор: Juzzver 7.11.2009, 4:51
Опоздал я с прочтением этой темы, но всё же скажу =)
Взяв процентное соотношение злоумышлеников:
Взяв процент работающих злоумышлеников на провайдере;
Взяв процент злоумышлеников каторые знают хоть чтото об уо или просто злоумышлиник каторый хочет поживиться рессурсом на будущия что либо поиметь с этого.
Далее он сам поймет или ему разъеснят, что он нехрена не может сделать с рессурсом кроме того как запустить и держать как он есть, что мало кого устроит - он рынется искать другой еще мельче процент зла - каторое поможет ему спустить наводу этот ресурс. При этом за спасибо он не вазмется.
Глядя на другой процент - если этот злоумышленик находящийся на месте расположения будет 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 7.11.2009, 11:09
Цитата
ВарХамера
Я не варХамер =))))
Юзверь... Ты опять не понял самого главного. Самое главное в этом методе то, что все идет 1-м файлом, занимает меньше места и грузится чуть быстрее.
Если уважаемый Сотерик еще, к тому-же, допишет сюда генерацию native кода для Mono под любую ОСь, которая действительно дает небольшое ускорение (по словам самих разработчиков - выигрывает пока что только менеджер памяти + по мелочам). Тогда статья будет еще более полезней. И тут я не спорю.
Взъелся я на слова Сотерика, что такой подход даст защиту. Просто немного (запуск 1 приложения и работа с ним) усложнит процесс доставания исходников. А вот если использовать нативную генерацию моно, да в FreeBSD, то, по моим данным, Reflector такое пока не кушает.
Автор: Juzzver 8.11.2009, 5:03
Цитата
Я не варХамер =))))
Извеняюсь, записался малёх =)
Да суть всю я понял. Очень даже хорошая вещь в плане защиты как по мне. Но есть в ней немного гемороя =).
Автор: Sfairat 11.8.2011, 9:36
Можно тупой вопрос, то что собрать все в один файл это ясно, а есть возможность скрипты из ядра вытащить наружу, а в ядре оставить только то что нужно для его работы и компиляции и.т.д?
Т.е чтобы оперативно править ядро )
Автор: Juzzver 11.8.2011, 10:33
это и подразумевается.
Ты можешь одновременно обрабатывать как и ядро, так и скрипты, при этом после компиляции - будешь получать свежий .exe файл и Scripts.dll
Автор: Soteric 11.8.2011, 10:41
Цитата
есть возможность скрипты из ядра вытащить наружу, а в ядре оставить только то что нужно для его работы и компиляции и.т.д?
Не думаю. Проще написать .bat файл, который будет компилировать сервер без визуал студии.
Автор: StaticZ 12.9.2011, 12:11
Цитата(Soteric @ 11.8.2011, 11:41)
Не думаю. Проще написать .bat файл, который будет компилировать сервер без визуал студии.
Имхо проще поставить студию, для начала хотя-бы просто ради быстрого перехода к ошибке и к объявлением чего либо, да и править и искать что-то в коде куда проще.. так что потраченная пара дней на студию очень быстро окупится ) Да и тотже бат куда менее дружелюбен, одно дело настройки проекта менять через гуи, другое все через аргументы ручками прописывать...
Автор: Realteque 10.12.2016, 16:08
Такой вопрос, всё скомпилировал, всё запустил, выставил все пути, выставил поддержку клиента, но во-первых не знаю как привязать папку Data в ранке, во-вторых не открывается paperdoll в игре) скорее всего именно из-за первой проблемы) есть люди кто толково объяснит?
Автор: Juzzver 11.12.2016, 1:22
папку Data просто в корень кидать надо, где сам RunUO.exe файл.
Папердол открывается на стороне клиента, если не ошибаюсь, возможно серверные настройки тут не причем.