Может есть в толстом и старом x86/x86-64 асм инструкция, которая симулирует запись по адресу без самой записи и генерит исключение если адрес не записываемый
Вобщем нужен быстрый и потокобезопасный аналог такого вот
Проблема описанного кода в том что он не потокобезопасный. Использование атомарных инструкций с lock-ом возможно решит эту проблему, но ударит по перфомансу..
Как много веселых ребят, и все делают велосипед...
Re: быстро и безопасно проверить что указатель writable
O>Использование атомарных инструкций с lock-ом возможно решит эту проблему, но ударит по перфомансу..
не решит
потому что xchg умеет только r/rm, r или наоборот r, r/rm
соотв-но инструкция lock xchg [eax], [eax] не компилируется:
error: invalid combination of opcode and operands
паранойя не болезнь, а критерий профпригодности
Re[2]: быстро и безопасно проверить что указатель writable
R>потому что xchg умеет только r/rm, r или наоборот r, r/rm R>соотв-но инструкция lock xchg [eax], [eax] не компилируется: R>error: invalid combination of opcode and operands
не ну емое.. это как раз таки фигня вопрос:
for (;;)
{
long l = *p;
if (_InterlockedCompareExchange(p, l, l)==l) break;
}
Как много веселых ребят, и все делают велосипед...
Re[3]: быстро и безопасно проверить что указатель writable
Здравствуйте, ononim, Вы писали:
R>>потому что xchg умеет только r/rm, r или наоборот r, r/rm R>>соотв-но инструкция lock xchg [eax], [eax] не компилируется: R>>error: invalid combination of opcode and operands O>не ну емое.. это как раз таки фигня вопрос: O>
R>>>потому что xchg умеет только r/rm, r или наоборот r, r/rm R>>>соотв-но инструкция lock xchg [eax], [eax] не компилируется: R>>>error: invalid combination of opcode and operands O>>не ну емое.. это как раз таки фигня вопрос: O>>
R>ну да, ну да R>а после присвоения l поток вытеснили и в *p другое значение кто-нть записал R>InterlockedOr(p, 0) тогда уж лучше
Ну если ктото другое значение записал _InterlockedCompareExchange нифига не запишет и вернет это самое другое значение, которое будет отличаться от l и цикл пойдет на следующую итерацию-попытку.
InterlockedOr тоже интересно, но вопрос — можно ли обойтись протестировать записывабельность адреса без сисколла, lock'а и ваще самой записи?
Как много веселых ребят, и все делают велосипед...
Re[5]: быстро и безопасно проверить что указатель writable
R>>ну да, ну да R>>а после присвоения l поток вытеснили и в *p другое значение кто-нть записал R>>InterlockedOr(p, 0) тогда уж лучше O>Ну если ктото другое значение записал _InterlockedCompareExchange нифига не запишет и вернет это самое другое значение, которое будет отличаться от l и цикл пойдет на следующую итерацию-попытку.
и поток снова вытеснили после присваивания l и так далее. весьма маловероятно но тем не менее данный цикл может теоретически крутиться вечно
O>вопрос — можно ли обойтись протестировать записывабельность адреса без сисколла, lock'а и ваще самой записи?
думаю что нет
паранойя не болезнь, а критерий профпригодности
Re[6]: быстро и безопасно проверить что указатель writable
R>>>InterlockedOr(p, 0) тогда уж лучше O>>Ну если ктото другое значение записал _InterlockedCompareExchange нифига не запишет и вернет это самое другое значение, которое будет отличаться от l и цикл пойдет на следующую итерацию-попытку. R>и поток снова вытеснили после присваивания l и так далее. весьма маловероятно но тем не менее данный цикл может теоретически крутиться вечно
весьма маловероятно но теоретически возможно что ваша клава в следующую секунду вся целиком распадется на ядра более легких элементов с выделением гамма квантов, электронов, позитронов, и как знать — может даже бозонов Хиггса, но тем не менее....
O>>вопрос — можно ли обойтись протестировать записывабельность адреса без сисколла, lock'а и ваще самой записи? R>думаю что нет
думать все могут, а вдруг x86 ведь такой толстый..
Как много веселых ребят, и все делают велосипед...
Re: быстро и безопасно проверить что указатель writable
От:
Аноним
Дата:
30.08.12 17:52
Оценка:
Здравствуйте, ononim, Вы писали:
O>Может есть в толстом и старом x86/x86-64 асм инструкция, которая симулирует запись по адресу без самой записи и генерит исключение если адрес не записываемый O>Вобщем нужен быстрый и потокобезопасный аналог такого вот O>
O>Проблема описанного кода в том что он не потокобезопасный. Использование атомарных инструкций с lock-ом возможно решит эту проблему, но ударит по перфомансу..
bool IsWritablePtr(PVOID p)
__declspec (naked) void __fastcall PtrWriteTest(PVOID p)
{
__asm
{
xor [ecx], 0
ret
}
}
void __cdecl checker(void *p)
{
::SetThreadAffinityMask(::GetCurrentThread(), 1);
for (;;)
{
__try
{
PtrWriteTest(p);
}
__except(1)
{
printf("checker AV!\n");
}
}
}
int _tmain(int argc, _TCHAR* argv[])
{
::SetThreadAffinityMask(::GetCurrentThread(), 2);
volatile int v = 0;
_beginthread(checker, 0, (void *)&v);
for (;;)
{
volatile int v_prev = v;
++v;
++v_prev;
volatile int v_now = v;
if (v_prev!=v_now)
{
printf("%u!=%u\n", v_prev, v_now);
}
}
return 0;
}
==> все плохо. Добавление lock перед xor делает все хорошо, но...
Как много веселых ребят, и все делают велосипед...
Re: быстро и безопасно проверить что указатель writable
От:
Аноним
Дата:
07.09.12 03:08
Оценка:
Без проверки итак фолт будет если память не для записи. Можно обратиться к памяти без её изменения, к примеру сделать or/xor с нулём. При этом Lock не нужен, так как память не изменяется.
Re[2]: быстро и безопасно проверить что указатель writable
А>Без проверки итак фолт будет если память не для записи. Можно обратиться к памяти без её изменения, к примеру сделать or/xor с нулём. При этом Lock не нужен, так как память не изменяется.
дык изменяется
см http://rsdn.ru/forum/asm/4875241.1.aspx
Как много веселых ребят, и все делают велосипед...
Re[3]: быстро и безопасно проверить что указатель writable
От:
Аноним
Дата:
07.09.12 14:04
Оценка:
Здравствуйте, ononim, Вы писали:
А>>Без проверки итак фолт будет если память не для записи. Можно обратиться к памяти без её изменения, к примеру сделать or/xor с нулём. При этом Lock не нужен, так как память не изменяется. O>дык изменяется O>см http://rsdn.ru/forum/asm/4875241.1.aspx
А>>>Без проверки итак фолт будет если память не для записи. Можно обратиться к памяти без её изменения, к примеру сделать or/xor с нулём. При этом Lock не нужен, так как память не изменяется. O>>дык изменяется O>>см http://rsdn.ru/forum/asm/4875241.1.aspx
А>Ну и накой тогда проверка раз что то в памяти меняется не пойму ?
Ок, если оч хочется знать: имеется виртуальная файловая система сделанная на юзермодных хуках. То есть обхучено все начиная с ntdll!NtCreateFile
Файлмэпинги на виртуальные файлы реализованы через vectored exception handler. То есть делаем недоступную страничку, когда происходит к ней обращение — приходит исключение, срабатывает VEH prehandler, подчитывает из файла нужные данные, а если исключение на запись — еще и помечает нужный кусок размером N килобайт в своем кэше как 'dirty'. Все работает круто, но как обычно есть одно но: если поинтер на такой view передавать в системный сервис ядра, никакой VEH prehandler само по себе не вызовется, а тупо сервис вернет ошибку наружу. Потому сделано следующее — обхукана туева хуча системных сервисов, и все подозрительные буфера которые передаются им в параметрах предварительно "облапываются" в нужных местах, что приводит к срабатыванию VEH и все работает правильно.
Так вот я озадачился вопросом оптимизации облапывания.
А>RTFM !
сам такой
Как много веселых ребят, и все делают велосипед...
Re[5]: быстро и безопасно проверить что указатель writable
Обожемой! Сори за оффтоп, но зачем такое садомазо? Почему не драйвер ФС?
O>Ок, если оч хочется знать: имеется виртуальная файловая система сделанная на юзермодных хуках. То есть обхучено все начиная с ntdll!NtCreateFile
Re[6]: быстро и безопасно проверить что указатель writable
потому что
1) есть usecase'ы когда требуется работа без админских прав и инсталляции ваще (есть вариант работы как веб приложение и с флэшки)
2) секурнее против общих (non-targeted) атак. Секурнее в плане что создаваемая FS представляет собой криптографический контейнер. Чем "ближе" контейнер к приложениям которые его юзают — тем меньше риск что залетный шпиен сдампит пароли.
3) Кроме фс там обхучено много чего. По сути создается виртуальная сессия со своим шеллом, некоторыми сервисами etc. То есть обхучен реестр, создание объектов ядра, чутарь gdi/user32 etc. Кода относящегося к FS там меньше половины. Остальное проще обхучить в юзермоде. Смысл делать драйвер FS если от остальных хуков он не избави?
AA>Обожемой! Сори за оффтоп, но зачем такое садомазо? Почему не драйвер ФС? O>>Ок, если оч хочется знать: имеется виртуальная файловая система сделанная на юзермодных хуках. То есть обхучено все начиная с ntdll!NtCreateFile
ЗЫ а давайте не флеймить, если нечего сказать по теме — как "потрогать" память на запись, не записывая в нее ничего?
Как много веселых ребят, и все делают велосипед...
Re[7]: быстро и безопасно проверить что указатель writable
Никакого флейма, чисто научный интерес. Спасибо за пояснения.
O>ЗЫ а давайте не флеймить, если нечего сказать по теме — как "потрогать" память на запись, не записывая в нее ничего?
Re[6]: быстро и безопасно проверить что указатель writable
А>С вашими извратами я знаком, как бэ на аверлабе сабж перетёрли уже. Но накой атомарность я так и не понял. Вы видимо тоже.
Про атомарность это вы сами чего то придумали. Мне нужна _проверка_ записываемости виртуального адреса без сисколлов и lock'a и которая не производит записи в ячейку во избежания проблем с другими потоками которые могут писать в эту же память. Вариант с or'ом это 1) чтение 2) or 3) запись того что прочитано в 1) ==> некатит. Приведенный пример просто это доказывает.
А>А патч же не годен, ваша поделка будет выпилена одной кнопкой как вредоносная ня портящая целостность модулей.
"поделка" продается уже пол десятилетия.
В случае проблем с каким либо AV ему пишется официальное письмо, на тему того что их эвристика не дает пользоваться документированным API винды, и они вносят наше приложение в whitelist. Ну если они его не вносят — мы вносим их в свой blacklist. Такая уж вот в сегменте секурити приложений чехарда происходит, бизнес такой
Как много веселых ребят, и все делают велосипед...
Re[7]: быстро и безопасно проверить что указатель writable
От:
Аноним
Дата:
08.09.12 11:26
Оценка:
Здравствуйте, ononim, Вы писали:
А>>С вашими извратами я знаком, как бэ на аверлабе сабж перетёрли уже. Но накой атомарность я так и не понял. Вы видимо тоже. O>Про атомарность это вы сами чего то придумали. Мне нужна _проверка_ записываемости виртуального адреса без сисколлов и lock'a и которая не производит записи в ячейку во избежания проблем с другими потоками которые могут писать в эту же память. Вариант с or'ом это 1) чтение 2) or 3) запись того что прочитано в 1) ==> некатит. Приведенный пример просто это доказывает.
Так чем не устраивает ксор я нулём я не понял.
А>>А патч же не годен, ваша поделка будет выпилена одной кнопкой как вредоносная ня портящая целостность модулей. O>"поделка" продается уже пол десятилетия. O>В случае проблем с каким либо AV ему пишется официальное письмо, на тему того что их эвристика не дает пользоваться документированным API винды, и они вносят наше приложение в whitelist. Ну если они его не вносят — мы вносим их в свой blacklist. Такая уж вот в сегменте секурити приложений чехарда происходит, бизнес такой
Я запускаю рку и он восстанавливает кодосекции выпиливая все патчи, и малварщиков и аверов.
А софт я никогда не покупал. Я даже платный под нт не знаю.
Re[8]: быстро и безопасно проверить что указатель writable
А>Так чем не устраивает ксор я нулём я не понял.
Сравните поведение вышеупомянутого кода с ксором с префиксом lock перед ксором и без. Потом подумайте.
Как много веселых ребят, и все делают велосипед...
Re[9]: быстро и безопасно проверить что указатель writable
От:
Аноним
Дата:
08.09.12 16:36
Оценка:
Здравствуйте, ononim, Вы писали:
А>>Так чем не устраивает ксор я нулём я не понял. O>Сравните поведение вышеупомянутого кода с ксором с префиксом lock перед ксором и без. Потом подумайте.
Во первых если адрес выравнен на 4, то лок вообще пропускается камнем. Во вторых проверяющий поток не собирается использовать синхронизации на переменной, накой тогда нужно проверять её на запись. Да и никакой разницы в поведении для ксора нет, что с локом, что без. Атомарность не нужна, ибо переменная не изменяется и не читается.
Re[10]: быстро и безопасно проверить что указатель writable
А>>>Так чем не устраивает ксор я нулём я не понял. O>>Сравните поведение вышеупомянутого кода с ксором с префиксом lock перед ксором и без. Потом подумайте. А>Во первых если адрес выравнен на 4, то лок вообще пропускается камнем. В
Выравнен. Более того — он выравнен на 0x10000 ибо таков granularity файлмапингов.
А>о вторых проверяющий поток не собирается использовать синхронизации на переменной, накой тогда нужно проверять её на запись. Да и никакой разницы в поведении для ксора нет, что с локом, что без. Атомарность не нужна, ибо переменная не изменяется и не читается.
Плохо думали.
xor [ptr], 0 читает переменную, затем записывает ее прочитанное значение в память. В момент исполнения этой инструкции другой процессор может ее изменить, потому мой код показывает проблему на многопроцессорных/ядерных системах
Разница: lock лочит шину доступа к памяти на время исполнения инструкции и другие ядра не могут во время исполнения инструкции доступиться к памяти. Что решает проблему, но бьет по перфомансу.
Как много веселых ребят, и все делают велосипед...
Re[7]: быстро и безопасно проверить что указатель writable
От:
Аноним
Дата:
08.09.12 18:49
Оценка:
O>ЗЫ а давайте не флеймить, если нечего сказать по теме — как "потрогать" память на запись, не записывая в нее ничего?
Для проверки сегмента есть инструкция VERW. Для проверки региона нужно запросить инфу у ядра, NtQueryVM etc, в зависимости от мода и прочих условий. Можно напрямую дт потыкать.
Re[8]: быстро и безопасно проверить что указатель writable
O>>ЗЫ а давайте не флеймить, если нечего сказать по теме — как "потрогать" память на запись, не записывая в нее ничего? А>Для проверки сегмента есть инструкция VERW.
VERW видел, как юзать его в защищенном режиме в flat model для проверки доступности страница не понял. Похоже никак. Если скажете как — буду премного благодарен.
А>Для проверки региона нужно запросить инфу у ядра, NtQueryVM etc, в зависимости от мода и прочих условий. Можно напрямую дт потыкать.
Сисколл позвать — много ума не надо. Но это же ваще ппц как медленно, даже хуже чем с lock'ом.
Как много веселых ребят, и все делают велосипед...
Re[9]: быстро и безопасно проверить что указатель writable
От:
Аноним
Дата:
08.09.12 19:23
Оценка:
Здравствуйте, ononim, Вы писали:
O>>>ЗЫ а давайте не флеймить, если нечего сказать по теме — как "потрогать" память на запись, не записывая в нее ничего? А>>Для проверки сегмента есть инструкция VERW. O>VERW видел, как юзать его в защищенном режиме в flat model для проверки доступности страница не понял. Похоже никак. Если скажете как — буду премного благодарен.
Страница к сегменту в данном случае никакого отношенья не имеет.
А>>Для проверки региона нужно запросить инфу у ядра, NtQueryVM etc, в зависимости от мода и прочих условий. Можно напрямую дт потыкать. O>Сисколл позвать — много ума не надо. Но это же ваще ппц как медленно, даже хуже чем с lock'ом.
Медленно это если миллионы раз сисколы дёргать в секунду. Реально же такая проверка может быть однократной, иначе придётся миллионы раз ремапить какие то секции, чего никто не делает и сделать не может. Задача и проблемы в сферическом вакууме.
Re[10]: быстро и безопасно проверить что указатель writable
O>>>>ЗЫ а давайте не флеймить, если нечего сказать по теме — как "потрогать" память на запись, не записывая в нее ничего? А>>>Для проверки сегмента есть инструкция VERW. O>>VERW видел, как юзать его в защищенном режиме в flat model для проверки доступности страница не понял. Похоже никак. Если скажете как — буду премного благодарен. А>Страница к сегменту в данном случае никакого отношенья не имеет.
O> как бы мне проверить адрес
A> зырь, есть VERW
O> VERW не катит наверное
A> какой нафиг VERW, он ваще тут не пойдет
кэп, вы ведете себя как марковский тролль
А>>>Для проверки региона нужно запросить инфу у ядра, NtQueryVM etc, в зависимости от мода и прочих условий. Можно напрямую дт потыкать. O>>Сисколл позвать — много ума не надо. Но это же ваще ппц как медленно, даже хуже чем с lock'ом. А>Медленно это если миллионы раз сисколы дёргать в секунду. Реально же такая проверка может быть однократной, иначе придётся миллионы раз ремапить какие то секции, чего никто не делает и сделать не может. Задача и проблемы в сферическом вакууме.
Проверка неоднократно вызывается при вызове практически любого сисколла и добавление 3..10 NtQueryVirtualMemory на каждую Nt*** и многие NtGdi*** весьма плачевно скажется на перфомансе, что бы вы сами поняли если бы немного подумали над тем зачем она нужна. Но вместо того вы лишь троллите в попыках доказать, что анонимы тоже бывают круты... Но увы, пока у вас получается совершенно наоборот
Как много веселых ребят, и все делают велосипед...
Re[11]: быстро и безопасно проверить что указатель writable
От:
Аноним
Дата:
08.09.12 20:55
Оценка:
O>Проверка неоднократно вызывается при вызове практически любого сисколла и добавление 3..10 NtQueryVirtualMemory на каждую Nt*** и многие NtGdi*** весьма плачевно скажется на перфомансе, что бы вы сами поняли если бы немного подумали над тем зачем она нужна. Но вместо того вы лишь троллите в попыках доказать, что анонимы тоже бывают круты... Но увы, пока у вас получается совершенно наоборот
ProbeForWrite() etc обычно юзается. Либо вообще память не чекается, а возможный фолт откатывается в сех. Фолт в любом случае будет, атомарно или нет. А в таком случае зачем проверка нужна ?
Могу предположить что это аверский фильтр будет, но зачем в нём выполнять синхронизации на пользовательском буфере опять же не понятно. Ядро к примеру так не делает, если нужно память лочится(MmLockUserBuffer() etc, ремап через мдл). Я не припомню ни одного сервиса(в шадове тоже), где такие синхронизации имеются. В любом случае такие механизмы внесут нестабильность и дров ваш(клиф наверно ?) будет есчо дырявее.
Re[12]: быстро и безопасно проверить что указатель writable
O>>Проверка неоднократно вызывается при вызове практически любого сисколла и добавление 3..10 NtQueryVirtualMemory на каждую Nt*** и многие NtGdi*** весьма плачевно скажется на перфомансе, что бы вы сами поняли если бы немного подумали над тем зачем она нужна. Но вместо того вы лишь троллите в попыках доказать, что анонимы тоже бывают круты... Но увы, пока у вас получается совершенно наоборот А>ProbeForWrite() etc обычно юзается. Либо вообще память не чекается, а возможный фолт откатывается в сех. Фолт в любом случае будет, атомарно или нет. А в таком случае зачем проверка нужна ? А>Могу предположить что это аверский фильтр будет, но зачем в нём выполнять синхронизации на пользовательском буфере опять же не понятно. Ядро к примеру так не делает, если нужно память лочится(MmLockUserBuffer() etc, ремап через мдл). Я не припомню ни одного сервиса(в шадове тоже), где такие синхронизации имеются. В любом случае такие механизмы внесут нестабильность и дров ваш(клиф наверно ?) будет есчо дырявее.
Нет не клиф, и не дров вообще.. Хуки все в юзермоде. При обращении в ядре к невалидному юзерскому буферу SEH в юзермоде не придет.
Блин ну точно марковский тролль
Как много веселых ребят, и все делают велосипед...
Re[5]: быстро и безопасно проверить что указатель writable
Здравствуйте, ononim, Вы писали:
O>Потому сделано следующее — обхукана туева хуча системных сервисов, и все подозрительные буфера которые передаются им в параметрах предварительно "облапываются" в нужных местах, что приводит к срабатыванию VEH и все работает правильно. O>Так вот я озадачился вопросом оптимизации облапывания.
Любопытно, а не может ли в этой реализации случиться так, что уже облапанный буфер снова станет невалидным внутри системной фнукции?
Re[6]: быстро и безопасно проверить что указатель writable
O>>Потому сделано следующее — обхукана туева хуча системных сервисов, и все подозрительные буфера которые передаются им в параметрах предварительно "облапываются" в нужных местах, что приводит к срабатыванию VEH и все работает правильно. O>>Так вот я озадачился вопросом оптимизации облапывания. A>Любопытно, а не может ли в этой реализации случиться так, что уже облапанный буфер снова станет невалидным внутри системной фнукции?
нет
Как много веселых ребят, и все делают велосипед...