Помощь - Поиск - Пользователи - Календарь
Полная версия: PlayUO -> Sallos
UoKit.com Форумы > Ultima Online : Dev > Работа с клиентом UO
Born2bake
1)

Тест
Бег с Smooth передвижением
Бег без Smooth передвижения


К сожалению, этот клиент (4.0.8b) очень старый (2010 год, если не ошибаюсь). Но примерно, точно также сейчас выглядит программа Sallos, которая уже была сделана/отредактирована от этого PlayUO клиента.

П.С. Очень часто крашит и как можно видеть на видео, передвижение игрока происходит с задержкой, по сравнению к простому клиенту.

2)

Недавно открылись - http://uorevealed.com/ ; Они собрали Саллос для своего шарда. Рискну предположить, что они пользовались вот этими ресурсами.
  • https://github.com/necr0potenc3/PlayUO
  • https://drive.google.com/file/d/0B_DDf1_iEk5nLUQ0cVZrcEFDdmc/view
  • https://github.com/ZaneDubya/UltimaXNA
Так вопрос простой: кто-нибудь в рунэте пробовал сделать Саллос играбельным на своём/другом шарде?
Aimed
Sallos это оболочка PlayUO, которая тебе не позволяет его использовать везде где попало.
Возможно там ещё какие-то элементы форка имеются, возможно нет.
Зачем тебе Sallos?
Born2bake
Цитата(Aimed @ 13.6.2016, 14:09) *

Sallos это оболочка PlayUO, которая тебе не позволяет его использовать везде где попало.
Возможно там ещё какие-то элементы форка имеются, возможно нет.
Зачем тебе Sallos?


Ну я поговорил с админами этого Uo revealed; Они сказали, у них есть версия Саллоса, который можно конфигурировать на любой сервер (Рануо, сфера, неважно). Но они сказали, они не будут его выпускать в свет так, как не все шарды в уо комьюнити хотят, чтобы у них игроки играли на саллосе.

Зачем?

1. Очень удобный для пвп (конфиг, анимация, выбор таргета, дополнительные возможности)
2. Не багнутое сглаженое передвижение. Пожалуй самое важное.
Aimed
Так в чем отличие версии PlayUO в Саллосе от старого PlayUO?
Ведь ты старый PlayUO и так запустил уже.
Born2bake
Цитата(Aimed @ 13.6.2016, 15:45) *

Так в чем отличие версии PlayUO в Саллосе от старого PlayUO?
Ведь ты старый PlayUO и так запустил уже.


<Бег с Smooth передвижением; Бег без Smooth передвижения> на видео;

Оба багнутые и работают плохо.


Постоянно крашит.
Не все макросы работают.
Грубо говоря, PlayUO не играбелен, тем более уж для пвп.
StaticZ
Если память не изменяет PlayUO это раняя версия клиента, более поздние уже стали частью оболочки Sallos, в принципе его можно выковырять из салоса, я даже это как-то делал....
Born2bake
Цитата(StaticZ @ 14.6.2016, 18:58) *

Если память не изменяет PlayUO это раняя версия клиента, более поздние уже стали частью оболочки Sallos, в принципе его можно выковырять из салоса, я даже это как-то делал....


Успешно? Было бы очень здорово старина, еслиб ты порылся и сказал, что у тебя он есть, рабочий-играй-не-хочу.
Born2bake
Токо я так понимаю, у тебя свои дела да? - https://www.reddit.com/r/ultimaonline/comme...t_with_the_new/
StaticZ
Цитата(buOA @ 15.6.2016, 3:33) *

Токо я так понимаю, у тебя свои дела да? - https://www.reddit.com/r/ultimaonline/comme...t_with_the_new/

Не понял, вы о чем и к чему?

Цитата(buOA @ 15.6.2016, 0:59) *

Успешно? Было бы очень здорово старина, еслиб ты порылся и сказал, что у тебя он есть, рабочий-играй-не-хочу.

Рабочего нет, была идея как-то декампелировать его и дописать под свои нужды, но потом махнул рукой и решил просто прокачать оригинальный клиент.
Born2bake
http://s000.tinyupload.com/index.php?file_...427668005936206

Во ещё более новый саллос, с дополнительными функциями и работает через лаунчер. Но всёравно, привязан только к одному серверу.
Aimed
Цитата(StaticZ @ 15.6.2016, 2:52) *

Рабочего нет, была идея как-то декампелировать его и дописать под свои нужды, но потом махнул рукой и решил просто прокачать оригинальный клиент.


Ага, ведь это в разы проще biggrin.gif
Aimed
У кого желания и мозгов хватит добить его, присоединяйтесь:
https://github.com/AimedNuu/WarUOSallos/tree/master

Цель:
1) Выпилить хешинг и компрессию хмл логин файла, заставить клиент читать логин адрес из xml.
2) Взять код чтения мулов из старого PlayUO и прикрутить поддержку обратно, что-бы поддерживал .uop & .mul.
Wap
Цитата(Aimed @ 3.7.2016, 19:17) *

У кого желания и мозгов хватит добить его, присоединяйтесь:
https://github.com/AimedNuu/WarUOSallos/tree/master

Цель:
1) Выпилить хешинг и компрессию хмл логин файла, заставить клиент читать логин адрес из xml.
2) Взять код чтения мулов из старого PlayUO и прикрутить поддержку обратно, что-бы поддерживал .uop & .mul.
Ты решил пилить Sallos вместо клиента Тимура или собираешься заниматься обоими этими клиентами?
Aimed
Цитата(Wap @ 4.7.2016, 0:42) *

Ты решил пилить Sallos вместо клиента Тимура или собираешься заниматься обоими этими клиентами?


С какой целью интересуешься?
Wap
Цитата(Aimed @ 4.7.2016, 1:01) *

С какой целью интересуешься?
Любопытства. Т.е. никакой особой цели у вопроса нету, мне просто интересно.
Aimed
Цитата(Wap @ 4.7.2016, 3:04) *

Любопытства. Т.е. никакой особой цели у вопроса нету, мне просто интересно.


Понятно.
Нет и нет.
StaticZ
Цитата(Aimed @ 3.7.2016, 2:30) *

Ага, ведь это в разы проще biggrin.gif



Ну в каком-то смысле да. С салосом куча возни, что бы заставить его хоть как-то запускаться, потом куча возни чтобы заставить его работать как надо, доделать что не было реализовано, исправлять его проблемы, добавлять что нужно нам и тд и тп. И все это не просто в чужом коде, что к тому же не был рассчитан на подобные доработки и нововведения а еще к тому же в декомпелированном, что превращает его в кучу плохо читаемого и структурированного кода. А в случае с шеллом да работы не мало и она даже более трудоемкая и сложная, но тем не менее с самого начала уже есть рабочий клиент с которым можно работать и на котором можно играть. А сейчас когда я уже решил большую часть технических проблем и ограничений, потребность в новом клиенте уже не кажется столь актуальной.
Aimed
Цитата(StaticZ @ 6.7.2016, 17:32) *

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


От декомпиляции до запуска понадобилось ~20 часов.
Другое дело что я их почти подряд просидел и мне сильно надоело, из-за этого наделал ошибок с указателями в некоторых местах пока правил код и сломал рендерер в итоге.

Сорс код нового ПлейУО из Саллоса можно получить попросив админов uoforever.com.
uowars.com именно так и сделали. Кроме того, uoforever даже сорс код своего ланчера выложили, который через Fody Costura вивер обфусцируется и его никакой декомпилятор не берёт.
Там присутствует апдейтер файлов и много чего полезного.
Juzzver
Цитата
uoforever даже сорс код своего ланчера выложили, который через Fody Costura вивер обфусцируется и его никакой декомпилятор не берёт.

а что конкретно там обфусцируется? Ибо сам билд декомпилится на ура.
StaticZ
Цитата(Aimed @ 6.7.2016, 18:43) *

От декомпиляции до запуска понадобилось ~20 часов.
Другое дело что я их почти подряд просидел и мне сильно надоело, из-за этого наделал ошибок с указателями в некоторых местах пока правил код и сломал рендерер в итоге.

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

Честно говоря я бы уш лучше флюросценцию дописалбы чем с этим УГ возиться или даже свой клиент написал бы, помниться рендер карт наскору руку я написал за пару дней без всяких 3д вууду, потом за недельку добавил диффузное освещение на основе модифицированного Гуро... Создать сырой прототип клиента где можно бегать и чето тыкать не так уж и сложно а вот на его вылизывание до релизного состояния уйдет уйма времени и основные силы...
Aimed
Цитата(Juzzver @ 6.7.2016, 23:09) *

а что конкретно там обфусцируется? Ибо сам билд декомпилится на ура.




Ты выкачал билд из репы и просто его декомпилишь?
Цитата(StaticZ @ 6.7.2016, 23:38) *

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

Честно говоря я бы уш лучше флюросценцию дописалбы чем с этим УГ возиться или даже свой клиент написал бы, помниться рендер карт наскору руку я написал за пару дней без всяких 3д вууду, потом за недельку добавил диффузное освещение на основе модифицированного Гуро... Создать сырой прототип клиента где можно бегать и чето тыкать не так уж и сложно а вот на его вылизывание до релизного состояния уйдет уйма времени и основные силы...


Дык он уже вне Саллоса.
Да, там есть недоработки ещё. Создание персонажей отсутствует, но зато есть другие фичи, типа виртуальной клавиатуры для биндов и даже код для внутренней поддержки уо автомап есть.
Пилить с нуля или допиливать флорессенцию до этого состояния это дело на несколько лет, если ты один и в только в свое свободное время это делаешь.
Этот плейУО ещё в 2004 или того раньше начали делать...
Aimed
Цитата(Juzzver @ 6.7.2016, 23:09) *

а что конкретно там обфусцируется? Ибо сам билд декомпилится на ура.


Ради норм теста выкачай ланчер с форевера и попробуй декомпилируй его smile.gif

Если в репу внимательно глянешь - packages.config

Код
<?xml version="1.0" encoding="utf-8"?>
<packages>
  <package id="CommonServiceLocator" version="1.3" targetFramework="net451" />
  <package id="Costura.Fody" version="1.3.3.0" targetFramework="net451" developmentDependency="true" />
  <package id="Fody" version="1.29.3" targetFramework="net451" developmentDependency="true" />
  <package id="MvvmLight" version="5.1.1.0" targetFramework="net451" />
  <package id="MvvmLightLibs" version="5.1.1.0" targetFramework="net451" />
  <package id="Toastinet" version="2.8" targetFramework="net451" />
</packages>


Теперь погугли что такое Fody и Costura.Fody
Просто самих пакетов в репке нету, их с NuGet выкачивать надо, а так... я не знаю как это можно декомпилировать. Хотя по сути это все тот-же IL.
Juzzver
Судя по всему там просто присутствуют эти пакеты, но не используются.
лаунчер с форевера так же декомпилится и в целом ни чем не отличается.
Aimed
Цитата(Juzzver @ 7.7.2016, 14:00) *

Судя по всему там просто присутствуют эти пакеты, но не используются.
лаунчер с форевера так же декомпилится и в целом ни чем не отличается.


Чем ты декомпилилшь?
Juzzver
Цитата
Чем ты декомпилилшь?

JetBrains DotPeek.
Да я просто и в самом коде обфускации не нашел. А из того что пишут в нете, то Costura якобы для мерджа используется и еще нескольких фитч, но про обфускацию не встретил. Единственное что нашлось схожего - можно хуки всякие в коде наплодить, которые будут рандомно исключения посылать, которые сложно будет отлаживать и с помощью этой костуры распространить по всему коду).
Aimed
Да, что-то я напутал.
Это офф. Саллос нельзя декомпилировать.
По крайней мере dotPeek точно не может.

Costura.Fody помогает собирать все дллки в экзешник, в итоге на выходе только экзешник.
Ну а самим Fody можно, в принципе, обфускацию делать, хотя проще будет использовать Disguise.Fody.
Такой сетап выглядит на попытку сделать какую-то защиту от декомпиляции.
StaticZ
Цитата(Aimed @ 7.7.2016, 20:15) *

Да, что-то я напутал.
Это офф. Саллос нельзя декомпилировать.
По крайней мере dotPeek точно не может.

Да все можно, я его и декомпелировал кстати, вытаскивал дллку потом ее уже декомпелил..
Aimed
Цитата(StaticZ @ 8.7.2016, 2:29) *

Да все можно, я его и декомпелировал кстати, вытаскивал дллку потом ее уже декомпелил..


Чем именно? dotPeek последних версий его не берет.
StaticZ
Цитата(Aimed @ 8.7.2016, 10:14) *

Чем именно? dotPeek последних версий его не берет.

Да не помню я уже давно возился, скорее всего рефлектором или спайсом, тогда дотпика вообще как класса не существовало. Там вначале надо было извлечь сами бинарники и ресурсы из архивов салоса (честно говоря уже в упор не помню что они из себя представляют и как извлек). А если dotPeek не берет, то смотреть надо возможно там не управляемый код или CLI код, последнее самое жоп - там вообще адекватных решений декомпиляции не существует.
Aimed
Цитата(StaticZ @ 8.7.2016, 14:05) *

Да не помню я уже давно возился, скорее всего рефлектором или спайсом, тогда дотпика вообще как класса не существовало. Там вначале надо было извлечь сами бинарники и ресурсы из архивов салоса (честно говоря уже в упор не помню что они из себя представляют и как извлек). А если dotPeek не берет, то смотреть надо возможно там не управляемый код или CLI код, последнее самое жоп - там вообще адекватных решений декомпиляции не существует.


CLI? Ты наверное имел в виду IL(CIL). Там, кстати, просто кишит неупраавляемым кодом))) Когда я его в порядок приводил после декомпиляции, скорее всего где-то накосячил с указателями и сломал рендерер. Проект на тот момент запускался и можно было смотреть в черное окно biggrin.gif

Но ведь сам PlayUO декомпилировался через dotPeek, а именно в нем дофига неуправляемого кода...


Получается можно сделать свой экзешник не декомпилируемым если добавить в него IL код?
Aimed
Цитата(Juzzver @ 7.7.2016, 18:02) *

Да я просто и в самом коде обфускации не нашел.


А зачем обфусцировать свой собственный сорс код? По-моему обфусцируют обычно при компиляции уже или перед релизом...
StaticZ
Цитата(Aimed @ 8.7.2016, 16:29) *

CLI? Ты наверное имел в виду IL(CIL).
Нет я имел ввиду Common Language Infrastructure, так же известный как С++/CLI - смесь неуправляемого и управляемого кода. Все известные мне декомпиляторы управляемого кода даже не могут его отрыть, а дизассемблеры не выдают ничего существенного, лишь какие-то огрызки функций, преимущественно пришествующих точке входа - WinMain (она является точкой входа с точки зрения исходников, но по факту компиляторы вставляют кучу своего кода до нее, к примеру для получения того же списка аргументов командной строки, что уже передается в WinMain).


Цитата(Aimed @ 8.7.2016, 16:29) *
Но ведь сам PlayUO декомпилировался через dotPeek, а именно в нем дофига неуправляемого кода...
Неуправляемый и небезопасный код немного разные вещи. Первое не является managment кодом и является чисто машинным кодом, второй хоть по стилю и возможностям близок к неуправляемому коду, все таки является управляемым кодом и транслируется не в машинный код а в тот же IL код, просто в более низкоуровневый с прямым доступом к памяти и без лишних проверок, за счет чего и получил название не безопасного кода.


Цитата(Aimed @ 8.7.2016, 16:29) *
Получается можно сделать свой экзешник не декомпилируемым если добавить в него IL код?
Все можно сломать и декомпелировать, можно лишь сделать этот процесс сложнее и тут много способов, но обратная сторона медали что это вынуждает совершать больше телодвижений, к примеру повсеместно использовать динамическую линковку вместо статической для крупного проекта это потребует писания еще какого-то своего менеджера, чтобы не делать ее по 100 раз в разных местах кода.
Aimed
Цитата(StaticZ @ 8.7.2016, 16:49) *

Нет я имел ввиду Common Language Infrastructure, так же известный как С++/CLI - смесь неуправляемого и управляемого кода. Все известные мне декомпиляторы управляемого кода даже не могут его отрыть, а дизассемблеры не выдают ничего существенного, лишь какие-то огрызки функций, преимущественно пришествующих точке входа - WinMain (она является точкой входа с точки зрения исходников, но по факту компиляторы вставляют кучу своего кода до нее, к примеру для получения того же списка аргументов командной строки, что уже передается в WinMain).




Про С++/CLI впервые слышу, загуглил - интересная чтука, спасибо за инфу.
Только, по-моему, не верно говорить просто CLI, тут речь идёт об С++ заточеным под CLI. Сама CLI это ведь инфраструктура и кодом не является, поэтому я тебя и поправил.


Цитата(StaticZ @ 8.7.2016, 16:49) *

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



Насчет неуправляемого кода... если ты имеешь в виду extern и DllImport, так это ж по сути вызовы внешних(возможно нативных) библиотек обычно. Либо я чего-то ещё не знаю? Но я не нашёл как на шарпе писать неуправляемый код. Если можешь, обьясни, пожалуйста или пример какой-нибудь покажи.
Вот, кстати, кусок из репы где нормально декомпилировались длл импорты и их вызов с неуправляемым кодом.

Цитата(StaticZ @ 8.7.2016, 16:49) *

Все можно сломать и декомпелировать, можно лишь сделать этот процесс сложнее и тут много способов, но обратная сторона медали что это вынуждает совершать больше телодвижений, к примеру повсеместно использовать динамическую линковку вместо статической для крупного проекта это потребует писания еще какого-то своего менеджера, чтобы не делать ее по 100 раз в разных местах кода.

Разумеется.
А ты не в курсе что будет, если в коде будут IL иньекции? Он будет нормально декомпилироваться?
StaticZ
Цитата(Aimed @ 8.7.2016, 18:50) *
Насчет неуправляемого кода... если ты имеешь в виду extern и DllImport, так это ж по сути вызовы внешних(возможно нативных) библиотек обычно. Либо я чего-то ещё не знаю? Но я не нашёл как на шарпе писать неуправляемый код. Если можешь, обьясни, пожалуйста или пример какой-нибудь покажи.
Никак, .Net это управляемый код на нем невозможно писать не управляемый код, даже если Вы будите писать не на шарпе а на голом MSIL это все равно будет управляемый код. По сути когда идет запуск управляемого кода там идет загрузка mscoree.dll которая уже и отвечает за трансляцию управляемого кода в машинный код. Единственный способ совместить вместе управляемый и неуправляемый код это как раз и есть С++/CLI, в частности именно он и используется для врапинга COM объектов в ManagedDirectX (но вообщем-то тут конечно это вопрос больше компилятора, так то впринципе можно сделать спокойно к примеру на C# дллку и сделать там экспорт управляемых методов, что можно будет спокойно вызывать из неуправляемого кода, но компиляторы такой возможности не предоставляют, как и много других - стандарт C++ не соблюдает полностью не один компилятор да и многие возможности MSIL компиляторы еще не научились использовать)... Ну в принципе конечно есть и другие способы из разряда левой ногой через правое ухо, к примеру можно через тот же C# путем WinAPI выделить область памяти для исполнения, скопировать туда машинный код и потом путем некоторых махинаций с делегатами и маршалингом вызвать этот код (посути это примерно тоже самое что происходит при DllImport, только там оно более универсально), но все это очень не удобное извращение, т.к. надо писать код на голом ассемблере потом конвертировать его в машинный код и хранить в виде массива байтов, что делает читабельность кода и его отладку очень неудобной. Ну и еще надо понимать что тут все не так однозначно маршалинг на самом деле достаточно медленная штука и потери быстродействия на нее может спокойно превысить выигрыш даже от ассемблерного кода, к примеру когда я писал рендер я испробовал множество способов оптимизации memcpy для шарпа и весь выигрывш с лихвой нивилировался задержками маршалинга, поэтому в конце концов я само изображение т.е. блитинг тайлов делал управляемым кодом, а вот уже финальный блиттинг изображения с экранного буфера на экран через маршалинг на свой вариант написанный на асме ( ну там на самом деле т.к. изображение 15 битное а нынче как правило у всех мониторы в 32 битном формате нужно еще паралельно с копированием осуществлять конвертацию 15 битного цвета в 32 битный и за счет расширенных регистров MMX\SSE\AVX я там сразу по 16 пикселей за раз обрабатывал, что дало очень существенный прирост производительности несмотря даже на маршалинг)




Цитата(Aimed @ 8.7.2016, 18:50) *
А ты не в курсе что будет, если в коде будут IL иньекции? Он будет нормально декомпилироваться?
Какого рода инъекции и в какой код?
Aimed
Оооо, сколько инфы smile.gif

Цитата(StaticZ @ 8.7.2016, 19:04) *

Какого рода инъекции и в какой код?

Например как делается в FastMember

Вот у него есть TypeAccessor который IL кодом генерирует можно сказать "getter" что-бы без рефлексии ( взяв только PropertyInfo ( хотя я уже форкнул что б и FieldInfo и приватные в том числе брал )), в рантайме, имея стрингу с названием мембера обьекта можно было достать значение из указанного мембера обьекта, имея сам обьект и стрингу с названием его мембера и получить на выходе object со значением.

А вот по первой ссылке performance:
Цитата
So let’s roll some numbers; I’m bundling read and write together here for brevity, but - based on 1M reads and 1M writes of a class with an auto-implemented string property:

Static C#: 14ms
Dynamic C#: 268ms
PropertyInfo: 8879ms
PropertyDescriptor: 12847ms
TypeAccessor.Create: 73ms
ObjectAccessor.Create: 92ms


Вот такого рода IL иньекции, если это иньекциями можно назвать.
StaticZ
Цитата(Aimed @ 8.7.2016, 21:52) *
Вот у него есть TypeAccessor[/url] который IL кодом генерирует можно сказать "getter" что-бы без рефлексии
посмотрел мелком, слишком много всего там навалено, но на первый взгляд это просто какие-то хелперы реализуемые при помощи рефлексии и динамической генерации кода. Для чего и какой в этом смысл пока не уловил, хотя особо и не искал. Но бывает всякое я что-то подобное использовал для динамического приведения к интерфейсу (к примеру объявляем интерфейс IStream и дальше каст обычного MemmoryStream в данный интерфейс, если там есть прототипы методов объявленных в интерфейсе, то генерируется врапер для объекта данного интерфейса, и получаем что требуется, хотя формально MemmoryStream и не реализует интерфейс IStream )... В целом вообще это все на самом деле круто интересно но на деле большое извращение и без реальной надобности лучше этим не злоупотр<вырезано анти-матом>ть.


Цитата(Aimed @ 8.7.2016, 21:52) *
Вот такого рода IL иньекции, если это иньекциями можно назвать.
Ну это скорее динамическая генерация а не инъекции. На декомпиляцию оно никак не повлияет, разве что сделает код менее читаемым, с другой стороны подобные места сложнее обфусцировать, поэтому стоит иметь ввиду что подобные пляски с кодом могут быть пропущены обфускаторами.

Инъекции это впихивание своего кода в чужой или в свой собственный или изменение оригинального кода во время исполнения, это усложняет декомпиляцию т.к. в декомпилированом коде сложно понять что куда и для чего пихается (ну при условии отсутствия нормальных оригинальных названий и комментариев)
Juzzver
Цитата
А зачем обфусцировать свой собственный сорс код? По-моему обфусцируют обычно при компиляции уже или перед релизом...

Ну это были твои слова, мне и самому стало интересно, мол зачем в опен сорсе обфускация, вот я и пошел смотреть smile.gif
Цитата
uoforever даже сорс код своего ланчера выложили, который через Fody Costura вивер обфусцируется и его никакой декомпилятор не берёт.
Aimed
Да уж, это была кривая формулировка smile.gif
Это текстовая версия — только основной контент. Для просмотра полной версии этой страницы, пожалуйста, нажмите сюда.
Русская версия Invision Power Board © 2001-2024 Invision Power Services, Inc.