CC BY
8стратегий игроков в реальном времени и получить возможность управления динамическими объектами с обратной связью, учитывающей действие различных возмущений. Погрешности, возникающие из-за ограниченного количества учтенных дискрет дифференциальных спектров и размерности векторов произвольных параметров программных управлений, могут быть снижены до необходимого уровня при уточнении решения градиентным методом в области дифференциальных спектров [13].
Выводы
Предложен дифференциально-игровой подход к решению задачи синтеза программных алгоритмов многоэтапного управления терминальным выведением БАЛА при действии неопределенных возмущений. Подход базируется на применении теории дифференциальных игр и модифицированного метода дифференциальных преобразований, позволяет осуществлять аналитические преобразования, что дает возможность значительно сократить объем вычислений для получения решения в численном виде без применения численных методов интегрирования дифференциальных уравнений.
Литература
1. Айзекс Р. Дифференциальные игры. - М.: Мир, 1967. - 480 с.
2. Толпегин О.А. Дифференциально-игровые методы управления движением беспилотных летательных аппаратов. - СПб: БГТУ, 2009. - 244 с.
3. Васильев В.В., Баранов В.Л. Моделирование задач оптимизации и дифференциальных игр. -К.: Наукова думка, 1987. - 296 с.
4. Кунцевич В.М., Лычак М.М. Синтез оптимальных и адаптивных систем управления. Игровой подход. - К.: Наукова думка, 1985. - 248 с.
5. Красовский Н.Н. Управление динамической системой. Задача о минимуме гарантированного результата. - М.: Наука, 1985. - 520 с.
6. Пухов Г. Е. Дифференциальное преобразование функций и уравнений. - К.: Наукова думка, 1980. - 419 с.
7. Гусынин А. В. Модифицированный многоэтапный метод дифференциальных преобразований для решения нелинейных обыкновенных дифференциальных уравнений // Проблеми шформацш-них технологш, №02(020), 2016. - С.26-34.
8. Gusynin A., Gusynin V., Tachinina H. Estimate of accuracy of approximate solutions of non-linear boundary value problems by the multi-step differential transform method // Proceedings of NAU, № 1(70), 2017. - С.48-54.
9. Adomian G. Solving frontier problems of physics: the decomposition method. - Kluwer Academic Publishers, Boston, MA, 1994. - 352 pp.
10. Elsaid A. Adomian polynomials: a powerful tool for iterative methods of series solution of nonlinear equation/Journal of Applied Analysis and Computation, Vol.2, No.4, 2012. - P.381-394.
11. Ebaid A. On a general formula for computing the one-dimensional differential transform of nonlinear functions and its applications // Proceedings of the American Conference on Applied Mathematics, Harvard, Cambridge, USA, 2012. - P. 92-97.
12. Гусинш А. В. Диференщально-провий шдхвд до синтеза алгоршшв керування багаторе-жимних лггальних апаралв // Авиационно-космическая техника и технология, №1(88), 2012. - С. 4045.
13. Баранов В.Л., Уруский О.С., Баранов Г.Л., Комаренко Е.Ю. Моделирование игровых алгоритмов терминального управления динамическими объектами // Электронное моделирование, Т. 18, №2, 1996. - С. 75-81.
14. Брайсон А., Хо Ю-Ши. Прикладная теория оптимального управления. - М.: Мир, 1972. - 544 с.
15. Ziatdinov Ju., Gusynin V., Gusynin A. Guaranteed adaptive terminal control of an aerostatic aircraft based on differential game approach // Proceedings of NAU. - 2020. - № 1(82). - С.12-22.
МЕТОДИ ЗАХИСТУ ПРОГРАМНОГО КОДУ В1Д РЕ1НЖИНИР1НГУ З ВИКОРИСТАННЯМ
ВГРТУАЛЬНИХ МАШИН
Корнага Я.1.
Нацюнальний технгчний утверситет Украши «Кигвський полтехнгчний гнститут гменг 1горя Сгкорського»
кандидат технгчних наук доцент кафедри технгчног кгбернетики
Базака Ю.А.
Нацюнальний технгчний утверситет Украши «Кшвський полтехнгчний гнститут гменг 1горя Сгкорського» асистент кафедри технгчног кгбернетики
Базалш М.Ю.
Нацюнальний технгчний утверситет Украши «Кшвський полтехнгчний гнститут гменг 1горя Сгкорського» РИБ-студент кафедри технгчног кгбернетики
Мухш О.В.
Нацюнальний технгчний утверситет Украши «Кигвський полтехнгчний гнститут гменг 1горя Сгкорського» бакалавр кафедри математичних методгв системного аналгзу
METHODS OF PROTECTING SOFTWARE CODE FROM REENGINEERING USING VIRTUAL
MACHINES
Kornaga Ya.
National Technical University of Ukraine "Igor Sikorsky Kyiv Polytechnic Institute"
Associate Professor of Technical Cybernetics Candidate of technical sciences Bazaka Yu.
National Technical University of Ukraine "Igor Sikorsky Kyiv Polytechnic Institute"
Assistant of the department of technical cybernetics
Basaliy M.
National Technical University of Ukraine "Igor Sikorsky Kyiv Polytechnic Institute" PHD-student of the Department of Technical Cybernetics
Mukhyn O.
National Technical University of Ukraine "Igor Sikorsky Kyiv Polytechnic Institute" Bachelor of the Department of Mathematical Methods of Systems Analysis
АНОТАЦ1Я
В статп розкриваеться сутшсть застосування вiртуальних машин для захисту виконуваного коду вщ аналiзу i зворотного проектування з використанням ПВОК 3i сво!м набором команд (шструкцш), набором репсов i областю пам'ятг Даш вiртуальнi машини працюють як звичайна прикладна програма в основнш ОС i пiдтримуe единий процес. Вони створюеться, коли цей процес починае виконуватися, i знищуеться, коли процес закiнчуе виконання. Метою вiртуальних процесiв е забезпечення незалежного вщ платформи середовища програмування, яке абстрагуеться ввд деталей основного устаткування або операцiйних систем i дозволяе програмам виконуватися так само, як на шших платформах.
ABSTRACT
The article reveals the essence of the use of virtual machines to protect executable code from analysis and reverse engineering using PVOK with its own set of commands (instructions), a set of registers and memory area. These virtual machines run like a normal application in the main OS and support a single process. They are created when this process begins to run, and destroyed when the process ends. The purpose of virtual processes is to provide a platform-independent programming environment that is abstracted from the details of the main hardware or operating systems and allows programs to run in the same way as on other platforms.
Ключовi слова: програмне забезпечення, обфускащя, заплутуючi перетворення, вiртуальнi машини.
Keywords: software, obfuscation, confusing transformations, virtual machines.
Постановка проблеми.
Шд час захисту виконуваного файлу протектор, що розробляеться, перетворить код програми у байт-код свое! вiртуальноi машини i записуе його заметь звичайного, не захищеного коду. Байт-код -машинно-незалежний код низького рiвня, генеро-ваний транслятором i виконуваний штерпретато-ром. Трансляцiя у байт-код займае промiжне поло-ження мiж комшлящею в машинний код та штерп-ретащею. Розглянемо роботу вiртуального процесора детальнiше. Для цього введемо поняття алгоритму.
Алгоритм - набiр шструкцш, що описують порядок дш виконавця для досягнення результату розв'язку задачi за скiнченний час. Кожна шструк-цiя мае символiчне iм'я, код (унiкальне число, що однозначно характеризуе дiю) i набiр аргуменпв-операндiв, якi параметризують дiю. Кожна шструк-цiя представляе собою вiртуальну команду. Вiртуа-льна програма - це послщовшсть вiртуальних команд. На рiвнi користувача вiртуальна програма -це текст, а на рiвнi вiртуального процесора - це по-слiдовнiсть кодiв, що вщповщають тексту. Вiртуа-льна програма може бути трансльована в послвдов-шсть фiксованих кодiв, так само як звичайна програма транслюеться в послщовшсть машинних команд.
1снують два рiзнi пiдходи до трансляцii' почат-кового коду програм : компiляцiя та штерпретащя. Компiлятор спочатку кiлька разiв уважно перегля-дае початковий код, попм звертаеться до необхщ-них бiблiотек, i, нарештi, видае готову програму -виконуваний код. Виконуваний код завжди ма-шинно-залежний. Його можна запускати тiльки на комп'ютерах тих систем, на яш був розрахований компiлятор. Щоб програма могла працювати на комп'ютерах iнших систем, Г! потрiбно перекомш-лювати з початкового коду шшими компiляторами, розрахованими на щ системи. 1нтерпретатор - це програма, яка по рядках читае початковий текст, попм переводить його в машинний код процесора i тут же подае на виконання. Виконавши один рядок початкового коду, штерпретатор переходить до ш-шого, i так далi. Таким чином, програма, створена програмютом, працюе на комп'ютерi клiента пiд уп-равлшням iнтерпретатора. Програми, що штерпре-туються, можна зробити машинно-незалежними i працюючими на комп'ютерах будь-яких систем. Для цього треба, щоб кожен комп'ютер мав свою версш iнтерпретатора. Хоча рiзнi iнтерпретатори оброблятимуть одну i ту ж програму по^зному, працювати вона зможе на будь-якому комп'ютерi, на якому е вщповвдний iнтерпретатор[1,2].
Анат останшх досл1джень i публшацш. У
сучасних умовах машино-незалежнiсть - дуже цш-ний фактор, адже програмiст заздалепдь не знае, на якому комп'ютерi йому доведеться працювати. Але програми, що штерпретуються, зазвичай працюють набагато повiльнiше компiльованих i, до того ж, ма-ють значно бiльшi розмiри. Тому зручно викорис-товувати пром1жний пiдхiд, що поеднуе переваги як того, так i iншого методу. Цей тдхвд називаеться компiляцiею в пром1жний код[3].
При цьому пiдходi початкова програма комш-люеться не в машинний код конкретного проце-сора, а в деякий пром1жний код вiртуального процесора ^ртуально! машини). Тодi на комп'ютерi будь-яко! системи можна поставити програму--ште-рпретатор, яка здатна розумгги цей промiжний код i переводити його в код реального процесора того комп'ютера, на якому цей штерпретатор працюе[4]. Швидшсть i шстюстъ програми забезпечуються за рахунок комшляцп в код вiртуальноi машини, а ма-шино-незалежнiсть досягаеться завдяки тому, що цей код розумггамуть ус комп'ютери, на яких заздалепдь встановлений iнтерпретатор. В цьому ви-падку виходить зручне поеднання, яке забезпечуе багатоплатформшсть протектора[5].
Цiль статть Розробка мехашзму захисту про-грамного коду вщ реiнжинирингу.
Low Level Virtual Machine i особливосп TT за-стосування. В якостi iнструментарiю для реалiзацii методiв захисту ПЗ вщ реiнжинiрингу був вибраний LLVM (Low Level Virtual Machine) - ушверсальна система аналiзу, трансформацii i оптимiзацii про-грам, що реалiзуе вiртуальну машину з RISC-подiбними шструкщями. Може використовуватися як оптимiзуючий комтлятор цього байткоду в машинний код для рiзноi архiтектури. Система мае модульну структуру i може розширюватися додат-ковими алгоритмами трансформаци (compiler passes) i кодогенераторами для нових апаратних платформ.
LLVM IR можна охарактеризувати як тишзо-ваний трьохадресний код в SSA формг У констру-юваннi компiляторiв SSA- представлення (Static single assignment form) - це промiжне представлення, в якому кожнш змшнш значення присвою-еться лише один раз. Змiннi початково! програми розбиваються на версii, зазвичай за допомогою до-давання суфшса, таким чином, що кожне присво-ення здiйснюеться унiкальнiй версii змшно!.
Код в SSA- формi зручно розглядати не як ль ншну послiдовнiсть iнструкцiй, а як граф потоку управлшня (control flow graph, CFG). Вершини цього графа - так зваш базовi блоки (basic blocks), що мютять послiдовнiсть шструкцш i позначаються мiтками, що закшчуеться шструкщею-термшато-ром, яка явно передае управлшня в шший блок. Те-рмiнаторами е наступнi iнструкцii:
— ret тип значення - повернення значення iз функцii;
— br i1 умова, label мiтка_1, label мика_2 -умовний переход;
— br label мита - безумовний переход;
— switch - узагальнення br, дозволяе оргашзу-вати таблицю переходiв;
— invoke i unwind - використовуються для ор-гашзацп виключень;
— unreachable - спещальна iнструкцiя, яка по-казуе комшлятору, що виконання нiколи не досягне ще1 точки.
Щоб зробити змшш змiнюваними, в SSA- фо-рмi до iнших iнструкцiй додаеться спещальна фун-кцiя ф, яка повертае одне з перерахованих значень залежно ввд того, який блок передав управлшня поточному.
В LLVM цш функци вiдповiдае iнструкцiя phi, яка мае наступну форму:
phi тип, [значення_1, label мiтка_1], ..., [зна-чення_ N, label мита_ N]
У якостi прикладу розглянемо функцш обчис-лення факторiалу, яку на Ci можна було б записати так:
int factorial(int n)
{
int result = n; int i;
for (i = n - 1; i > 1; --i) result *= i;
return result; }
Приметка: блок, який розпочинаеться з входу у функцш, позначаеться %0.
define i32 @factorial(i32 %n) {
%i.start = sub i32 %n, 1 br label %LoopEntry LoopEntry:
%result = phi i32 [%n, %0], [%result.next, %LoopBody]
%i = phi i32 [%i.start, %0], [%i.next, %LoopBody]
%cond = icmp sle i32 %i, 1
br i1 %cond, label %Exit, label %LoopBody
LoopBody:
%result.next = mul i32 %result, %i %i.next = sub i32 %i, 1 br label %LoopEntry Exit:
ret i32 %result
}
LLVM також вимагае, щоб усi phi- шструкцп йшли на початку блоку i до них не було шяких iн-ших iнструкцiй. Хоча SSA- форма дозволяе робити багато корисних трансформацш, безпосередньо ге-нерувати ii з коду на iмперативнiй мовi складно, хоча е добре вiдомi алгоритми перетворення в SSA. При написанш компiлятора на основi LLVM немае нiякоi необхiдностi займатися цим, тому що система умiе генерувати SSA самостiйно.
SSA представлення, в основi якого лежить ро-збиття коду на BasicBlock, дуже зручне для реалiза-цп обфускацii на базi мереж Петрг Так як усерединi BasicBlock немае переходiв, то виконання мережi Петрi можна контролювати. Тобто усi шструкцп, що виконують пiдсумовування мережi, гаранто-
вано будуть виконаш, i крiм того завжди буде до-триманий порядок !х виконання. За наявносл тер-мiнаторiв ця важлива умова могла бути порушена, що привело б до некоректно! роботи мережт щ-льовi значения не були б отримаш у фжсованих мi-тках.
Метод побудови кодогенератора вiртуаль-но'1 машини. Кодогенератор перетворить код у формата промiжиого представления LLVM у байткод вiртуальноi машини. Для кожно! вiртуальноi машини кодогенератор створюеться автоматично. Ав-томатичне створення кодогенератора проводиться у три етапи (Рисунок 1).
На першому етат вiдбуваеться перетворення оиису вipтyaльнoi машини з внутрпднього формату
додатка у формат LLVM. Результатом цього етапу е файли типу LLVM Target Description (Td файли) i файли з початковим кодом на mobî C++ (С++ файли). На другому етат здшснюеться генеращя файлiв з початковим кодом на мовi C++ (Inc файлiв) з Td файлiв за допомогою утилгги llvm - tblgen, що входить до складу бiблiотек LLVM. На третьому етапi вiдбуваеться збiрка кодогенератора за допомогою компшятора GCC 4.6.2. При збiрцi викорис-товуються C++ файли, отримаш на першому етат, Inc файли, отримаш на другому етат, i каркас кодогенератора, написаний на мовi C++ i однаковий для уах вiртуальних машин.
Рисунок 1. Автоматичне створення кодогенератора
Висновок. В поточнш версп прототипу автоматичне створення кодогенератора займае б™ од-нiеï хвилини, причому 95% цього часу приходиться на збирання кодогенератора за допомогою комшлятора GCC. Далi показано, яким чином зменшити час автоматичного створення генератора до декшь-кох секунд.
По-перше, необхiдно збирати кодогенератор як динамiчно пiдключену бiблiотеку (.dll) пiд ОС Windows або як об'ект (shared object .so), що роздь
ляеться, тд ОС Linux. Зараз кодогенератор е окре-мою програмою i переважну частину часу зборки виконуваного файлу цiеï програми за допомогою компiлятора GCC складае компонування з бiблiоте-ками LLVM. У разi використання динамiчно тдк-лючено1 бiблiотеки (роздiленого об'екту) код бiблi-отек LLVM не вимагаеться включати у збираний .dll (.so) файл, осшльки вони вже присутнi в адресному просторi додатка (бiблiотеки LLVM потрiбнi
на бшьш раншх етапах захисту, наприклад, для пе-ретворення машинного коду в пром1жне представления LLVM).
По-друге, слад зменшити кiлькiсть фамв, як1 мiстять С++-код кодогенератора. Кожен С++-файл е одиницею траисляцii, а зменшення одиниць тран-сляцп значно прискорюе зборку. Число файлiв мае бути рiвне один плюс число фамв, згенерованих утилiтою llvm, - tbgen.
По-трете, тимчасовi файли треба тримати в па-м'ятi, а не збертати на диск. У поточнш версii прототипу ус тимчасовi файли зберiгаються на диск. Осшльки доступ до шформацп на диску на три порядки повшьшше, шж доступ до даних в пам'ятi, уникнення такого збереження дозволить значно прискорити автоматичне створення кодогенератора.
По-четверте, утилiта llvm - tbgen мае бути ште-грована в додаток. У поточнш версп прототипу ути-лiта llvm - tbgen е окремою програмою. 1нтегращя утилiти (можлива, завдяки вщкритому початко-вому коду LLVM) llvm - tbgen дозволить уникнути зайвоi витрати часу на створення нового системного процесу.
По-п'яте, слщ замiнити компiлятор GCC на комшлятор LLVM Clang. Для зборки кодогенератора прийиятнiше застосовувати комшлятор LLVM Clang, оскшьки вш вже використовуеться додатком для зборки штерпретатора. У поточнiй версii прототипу застосовуеться компiлятор GCC, так як у C++-кодi кодогенератора використовуеться стандартна бiблiотека C++, яка присутня в пакетi програм GCC i вiдсутня в Clang. Таким чином, для викорис-тання Clang необхвдно виключити виклики функцiй стандартно1 бiблiотеки C++ з початкового коду кодогенератора.
Шсля здiйснення приведених в статп пiдходiв по прискоренню автоматичного створення кодогенератора з процесу створення будуть виключенi ко-шювання коду бiблiотек LLVM, вщкриття/за-криття/читання /запис велико1 кiлькостi файлiв i ви-клик нових системних процеав. Час створення кодогенератора визначатиметься часом комшляцп дек1лькох файлiв компiлятором Clang, часом гене-рацii C++-коду утилггою llvm - tbgen i часом гене-рацii описання вiртуальноi машини у форматi LLVM. Практика показуе, що уа цi етапи в сумi займають менше 3 секунд.
Лггература
1. Stepanenko I., Kinzeryavyy V., Nagi A., Lo-zinskyi I. Modern obfuscation methods for secure coding. Ukrainian Scientific Journal of Information Security, 2016, vol. 22, issue 1. P. 32-37.
2. Kurmangaleev Shamil, Dolgorukova K.Y., Savchenko Valeriy, Nurmukhametov Alexey, Matev-osyan H.A., Korchagin V.P. Software deobfuscation methods: analysis and implementation. Proceedings of the Institute for System Programming of RAS. Vol. 24. P. 145-160.
3. Никольская К. Ю., Хлестов А. Д. Обфуска-ция и методы защиты программных продуктов. Вестник УрФО. Безопасность в информационной сфере. 2015. № 2(16). С. 7-10
4. Wang P., Wang S., Ming J. et al. Translingual Obfuscation. In Proceedings of the 1st IEEE European Symposium on Security and Privacy. Saarbrucken, Germany. 2016. — March 21-24.
5. Варновский Н.П., Захаров В.А., Кузюрин Н.Н., Шокуров А.В. Современное состояние исследований в области обфускации программ: определения стойкости обфускации. Труды Института системного программирования РАН. 2013. Vol. 26. С. 167-198.
МЕРЕЖ1 SMART GRID У ГРОМАДАХ: ЗАГАЛЬН1 П1ДХОДИ ТА МЕТОДИ РОЗРАХУНКУ ДЛЯ
МОДЕЛЮВАННЯ
Мельничук Г.В.
магктр електронгки, державний експерт Директорату просторового планування територт та архгтектури Мгтстерства розвитку громад та територш Украши
м. Кшв, Украша
SMART GRID NETWORKS IN COMMUNITIES: GENERAL APPROACHES AND CALCULATION
METHODS FOR SIMULATION
Melnichuk G.
master of electronics, state expert Directorate of Spatial Planning and Architecture Ministry of Development of Communities and Territories of Ukraine
Kyiv, Ukraine
АНОТАЦ1Я
У статп розглянуто аспекти розвитку електромереж населених пункпв та !х об'еднань в умовах впро-вадження технолопчних шновацш у сферi електроенергетики, електротехшки та транспорту, а також ме-тоди розрахунку таких систем для застосування моделювання електроенергетичних процеав. ABSTRACT
The article considers aspects of development of electric networks of settlements and their associations in the conditions of introduction of technological innovations in the field of electric power, electric engineering and transport, and also methods of calculation of such systems for application of modeling of electric power processes.
