Ви не увійшли. Будь ласка, увійдіть або зареєструйтесь.
Ласкаво просимо вас на україномовний форум з програмування, веб-дизайну, SEO та всього пов'язаного з інтернетом та комп'ютерами.
Будемо вдячні, якщо ви поділитись посиланням на Replace.org.ua на інших ресурсах.
Для того щоб створювати теми та надсилати повідомлення вам потрібно Зареєструватись.
Український форум програмістів → Системне програмування → Низькорівнева всячина
Сторінки Попередня 1 2 3 4 5 6 … 10 Наступна
Для відправлення відповіді ви повинні увійти або зареєструватися
Ох блін, а я про jni зовсім не подумав 
Весело..)
байткод
А якщо гугл повністю відмовиться від далвіка на користь АРТ?
Тоді Хром відмовиться від HTML на користь NaCl
Вірним шляхом крокує Томаш.
Тільки не вистачає найпримітивнішого I/O для повноцінного щастя. Раз він робить ставку на макроси у ядрі і тільки, було б дуже доречно.
Я тут подумав -- а що заважає написати зовнішній обробник типового виводу для перенаправлення виводу в потрібне русло? тобто пишеш щось штибу
display '%% WRITE ,+, 29 AB CD', що означатиме записати в кінець файлу kernel.bin 3 байти 29 AB CD. Як варіант можна додати можливість запускати зовнішні файли (себто згенерував потрібний скрипт - запустив, зчитав дані через директиву file). Макромова ФАСМ'а докорінно полегшить такий ввід/вивід.
Да хоча б і так. Сьогодні у них на форумі запитаю.
revolution пише:
Using file I/O is OS dependant. I wonder if you are confusing fasmg with some sort of HLL.
But anyway, firstly you have to define which CPU you are targeting so that the binary output code can run on the CPU (X86 or ARM etc.). Then you need to define which OS you are targeting so you can interact with the I/O APIs ("int 0x80" or "invoke function" etc.), and to format the output binary accordingly (PE or ELF etc.).
Не файно буде робити подібну підтримку задля декількох ОС та одного проца (що цілком вірно), суперечить це, бо FASM 2 у нас таки "багатонаціональний" у плані підтримки процесорів та систем.
Коротше треба качати скілл та доповнювати самому, або раз така пляска, то й створити щось своє на тому ж C, який буде легше підтримувати та доповнювати подібними плюхами, а там і до якогось "VX-фреймворка" недалеко з такими темпами.
Ну так багаторядкові коментарі і суперечать філософії, їх легко емулювати макромовою. Се те ж саме, що в геометрію додати зайву аксіому, яка насправді буде просто теоремою. Взагалі, з моддингом FASM`а треба не промахнутися, себто потрібна можливість викликати нейтив код з макромови часу компіляції і звідтіля танцювати вже - хочеш інтерпретатор Lua підключи, а хочеш - тетрис вбудуй 
Реалізація, як саме робити, це вже інше питання, відповідь від їхньої спільноти - "нам недоцільно паяти такі милиці, вам треба - робіть самі".
Те що ви пропонуєте, по логіці, легко зробити - просто стартуємо додатковий модуль з параметрами ('%% WRITE ,+, 29 AB CD'), модуль парсить аргументи cmd і працює. Звичайно хотілося б в рамках однієї "коробки" зробити, але це непросто, тим паче нутрощі fasm'у недокументовані (хоча він і гарно написаний, всеодно, приходять думки, що простіше самому написати компілятора, аніж там розібратися 
).
Поживемо подивимось, хто зна, може і зробиться щось, але так, для "вузького кола".
Прикрутив ShellExecute.
Залишилось написати парсер вашого виразу ('%% WRITE ,+, 29 AB CD') в io_module.exe та подумати над взаємодією із fasm'ом.
Я маю ще одне питаннячко по FASM`у, я б хотів побачити ще виділення регістрів в ассемблері, бо GCC має інтерхвейс взаємодії вбудованого асемблеру з аллокатором регістів, але я б хотів навпаки 
Маєте якісь думки з цього приводу?
Я маю ще одне питаннячко по FASM`у, я б хотів побачити ще виділення регістрів в ассемблері, бо GCC має інтерхвейс взаємодії вбудованого асемблеру з аллокатором регістів, але я б хотів навпаки
Я навіть не знаю що це.
Для криптування і не тільки це важлива штукенція, тож просвітіться оцим. В моєму крипторі також є воно, але зроблено через одне місце (тобто виділення регістрів напівавтоматичне)
0xDADA11C7, із LLVM бавились?
Оригінал:
Обфускація № 1:
Обфускація № 2:
Обфускація № 3:
_http://habrahabr.ru/post/213259/
Звичайно хотілося б елегантніше за допомогою одного fasm, але ККД у порівнянні із вищенаведеним.. Дехто заїкався, що від детекту деякими АВ програми у пам'яті, можна захиститися лишень морфингом сирців, або ж щось по типу McSema писати. Що ви гадаєте про детект у пам'яті?
З LLVM бавився, але без морхвингу. До речі, першопрохідці в цій справі -- яблучники з їхнім ДРМ'нутим програвачем айТюнес.
Що ви гадаєте про детект у пам'яті?
Гадаю, що спочатку вистачить і морхвингу звичайних користувачьких структур та відмова від зайвих викликів апі. Пізніше докладно розпишу мій план дій.
З приводу розподілу регістрів - ви маєте на увазі "віртуальні осередки", які формують якусь нашу мову, і цю мову ми потім розподіляємо на реальні регістри якогось проца?
я маю на увазі саме змінні, які розподіляються між регістрами. я таке робив. але без дерева залежностей, майже вручну.
var r1 = e.getFreeReg(p.LOCK_REG), r2 = e.getFreeReg(p.LOCK_REG); //виділяє 2 випадкові регістри та блокує їх, щоби уникнути повторного використання
v.add('.section_flags'); v.add('iResult'); v.add('.vprotect_ret'); // виділяє в стеці 3 слова для змінних
e.cmd('load_c32$m32', [0, 'iResult']); // обнулити змінну iResult
e.cmd('load_m32$r32', ['pSectionHeader', r1.i]); // завантажити в попередньо виділений (випадковий, не забуваймо) регістр (або іншими словами - регістрову змінну) r1 значення зовнішнього параметру pSectionHeaderГи, щось типу LLVM IR, де якось так:
%1 = add i32 2, 4
%2 = mul i32 %1, 12Тобто усе із % на початку (%1, %2) - локальні змінні, які потім розподіляє LLVM. Ви мали на увазі, зробити подібне у FASM?