Хочу реализовать передачу данных между потоками через CreateThread

Вопрос состоит в том, как именно обернуть параметры функции.

Пример функции



Посоветуете что-то?

| Сообщение посчитали полезным:

galenkane пишет:
передачу данных между потоками через CreateThread
... ну допустим. В lpParameter указатель на данные и как бы все. Зачем нужна непонятная "чудо-функция"?
Или вопрос должен звучать "как закриптовать данные", тогда контекст с потоками можно было не озвучивать.
Непонятно, б****!©

| Сообщение посчитали полезным:

криптовать ничего не надо

Добавлено спустя 1 минуту
надо данные передавать на стек

| Сообщение посчитали полезным:

galenkane пишет:
надо данные передавать на стек
Данные заносишь в структуру, адрес которой передаешь на стек. Больше никак.

| Сообщение посчитали полезным:

Как из структуры потом достать данные?

Добавлено спустя 23 минуты
Сделал вот так
https://gist.github.com/lurumdare/d3a8558f544fe1cabf9f1fc2d6bdf179

| Сообщение посчитали полезным:

galenkane, еще было бы неплохо освободить память из-под MessageBoxParameters

| Сообщение посчитали полезным:

Более ООП подход - файловые проекции. CreateFileMapping/OpenFileMapping. Для синхронизации можно использовать критические секции (один процесс) или события (разные процессы, можно и в одном, но будет медленнее). А вообще более детальное описание задачи, вероятно, помогло бы в поиске более качественного решения.

-----
Stuck to the plan, always think that we would stand up, never ran.

| Сообщение посчитали полезным:

ARCHANGEL требуется работать с ООП и виртуальными функциями в потоках. Чтобы данные передавались между ними.

| Сообщение посчитали полезным:

galenkane
Это всё ещё очень туманно

-----
Stuck to the plan, always think that we would stand up, never ran.

| Сообщение посчитали полезным:

ARCHANGEL

Крит секции могут быть глобальными, те для межпроцессной синхронизации. Вот только эти синхронизации использовались на младших версиях, затем их заменили на RWL, в частности SRWL. Так как в критсект нет разделения по типу доступа к ресурсам, а это не профайл.

rmn

Прямой записью в чужой стек, ну да, начинать нужно с эксплойтов, а лучший способ это обкатать на своих косяках

galenkane

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

-----
vx

| Сообщение посчитали полезным:

https://gist.github.com/lurumdare/8b6275107daf7283c0bb8a409045266a PoC на данный момент

хочется простоты на самом деле

| Сообщение посчитали полезным:

galenkane

Жуткая жуть, конечно, а не PoC. Потому я вам и предлагаю не костыли тут городить, а описать задачу. Практическую, которую вам нужно решить. Вряд ли на практике нужно так через жопу вызвать MessageBox.

-----
Stuck to the plan, always think that we would stand up, never ran.

| Сообщение посчитали полезным: difexacaw

ARCHANGEL задача хранить данные на стеке

| Сообщение посчитали полезным:

galenkane

Это чушь какая-то, а не задача. Вы уж меня простите за прямоту.

-----
Stuck to the plan, always think that we would stand up, never ran.

| Сообщение посчитали полезным:

ARCHANGEL задача как бы есть

мб вы не поняли ее

главное чтобы они были на стеке

| Сообщение посчитали полезным:

galenkane пишет:
PoC на данный момент
вспомнилось

| Сообщение посчитали полезным:

Хз проблема в чем. Создай структуру, объяви локальную переменную этого типа, заполни, передай указатель на нее в lpParameter. Не забывай, что как только в текущем потоке завершится функция, в локальных переменных которой лежит это структура, папе сделают укол. Тебе советы по синтаксису твоего ЯП чтоли нужны?

-----
2 оттенка серого

| Сообщение посчитали полезным:

galenkane
Твой "stackprotect" это один большой лулз с use-after-free как бонус. Нужно больше С++ кастов и прочей абсолютно ненужной здесь ООП мишуры. Без этого ты эти ссаные вин апи не дернешь однозначно.

| Сообщение посчитали полезным: morgot

В качестве альтернативы можешь рассмотреть WM_COPYDATA(PostThreadMessage). Ходят слухи, что даже между процессами можно данные ею передавать. Это будет всяко грамотней.

-----
2 оттенка серого

| Сообщение посчитали полезным:

Alchemistry так-то на это не обращайте внимание.

f13nd спасибо гляну

| Сообщение посчитали полезным:

f13nd

> WM_COPYDATA

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

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

Тема походу про написание дырявого кода.

-----
vx

| Сообщение посчитали полезным:

WM_COPYDATA для двух процессов?

Как быть с потоками?

| Сообщение посчитали полезным:

difexacaw пишет:
В этом смысл - посылка нотифи в ожидающий обьект, поток выйдет из сна и получит данные; при этом событии стек сместится вниз, так как всякое сообщение доставляется как обратный вызов ядра с параметрами.
Про что это вообще? Насколько я могу судить, с WM_COPYDATA весь геморрой с синхронизацией и доставкой n байт другому потоку винда берет на себя. Почему ты решил, что я предлагал указатель на локальную переменную этим передавать? Если пишешь что-то с прицелом на публикование, никакого подобного колхоза вообще быть не должно, а если какую-то утилитарную шляпу собственного покроя для личного поноса - абсолютно наплевать какие ужасные уязвимости оно содержит.

-----
2 оттенка серого

| Сообщение посчитали полезным:

f13nd

Потому что:

> задача хранить данные на стеке

А для этого нужно передать в функцию обмена данными указатель на эту область. Если бы было нужно простое копирование, то тс вопрос такой не задал. Было бы проще, если знать зачем это нужно.

-----
vx

| Сообщение посчитали полезным:

difexacaw пишет:
А для этого нужно передать в функцию обмена данными указатель на эту область...
... и размер данных. И винда скопирует эти данные в другой контекст. Так же, как ты можешь использовать WM_SETTEXT с другим окном, при этом если окно в другом процессе, туда улетает LPARAM не из твоего адресного пространства.

| Сообщение посчитали полезным:

rmn

И при выходе из функции обмена локальные данные будут уничтожены, так как стек сместится вверх. Можно зарезервировать место на стеке и туда копировать данные, но зачем. Где хранить указатель на этот буфер, в тлс.. тогда зачем нужен буфер на стеке.

-----
vx

| Сообщение посчитали полезным:

difexacaw
Причем здесь вообще какой-то стек?

| Сообщение посчитали полезным:

rmn

Откуда же мне знать, так нужно

-----
vx

| Сообщение посчитали полезным:

difexacaw
Кому нужно? ТС просто идиот и не может внятно сформулировать задачу. В примере, что он выше привел, никакого "хранения на стеке" нет; выделяется структура с параметрами на куче и ее адрес передается в функции потоков. Единственная проблема там в том, что он неправильно управляет временем жизни структуры и все это упадет с эксепшеном, если луна в ненужной фазе будет.

| Сообщение посчитали полезным:

rmn

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

-----
vx

| Сообщение посчитали полезным: