Где записать байт что бы считать его из другой проги! Не используя HD!

Почти то чё надо, но реестр - всё таки HD.Про другой процесс-передатчик - это по сути то же, что и не выключать свой процесс передатчик, а драйвер, который устанавливает процесс-передатчик это про то, что в драйвере хранится та самая временная инфа. В этом случае тоже что и в первом. Да и драйвер - то не для всех аккаунтов.



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

???

 

PavPS

Может быть, я скажу не в тему, но может Вам подойдет обычный буфер обмена?

 

Насколько я понял задачу, нужно в существующую прогу вставить минимальный код, который анализировал бы некий признак, установленный другим вспомогательным процессом. В идеале это mov\cmp\je. Условие неиспользования HD в данном случае это, наверное, не прихоть, а требование минимизации кода. Поэтому реестр, MMF, Winsock, буфер обмена, GetExitCode и т.п. относятся к этой же категории и прежде чем их обсуждать нужно рассмотреть более простые варианты. А простые варианты получаются когда вспомогательная прога вызывает ломаемую, а не наоборот. В этом случае можно использовать:

1) WriteProcessMemory - достаточно определить нулевой байтик в .data и записать туда не ноль. Здесь вопрос только в том как найти безопасный байтик, чтоб ничего не подвесить до вызова проверки. Наверное самое простое использовать завершающий ноль какой-нить строковой константы. Хотя для надежности лучше не 0, а наоборот занулять какой-то символ строки - так безопаснее.

2) Сообщение MainWindow - послать невероятное сообщение основному окну и отловить его в message loop. В качестве невероятного можно например использовать какой-нить WM_MOUSEMOVE с полным набором флагов fwKeys. Скорее всего это самый простой и надежный способ.

3) Регистры FPU\MMX - вещь на первый взгляд менее надежная, но может работать, если параллельно не рулит процесс интенсивно их использующий. Конечно, проверочку надо делать не на 0, а на какое-нить "магическое" сочетание млаших dword пары регистров mm6-mm7.



PS: Рассматривая "сложные" варианты можно незаметно сделать глупость - вызов вспомогательной проги и чтение байтика может оказаться сложнее, чем непосредственный вызов GetVolumeInformation или GetInformationByHandle в ломаемой проге.

 

если бы обе проги можно было произвольно изменять, то вот вариант:

1. Первая прога внедряет DLL в Explorer и завершается.

2. DLL как-то проявляет себя в системе, например, создает mutex.

3. Вторая прога вызывает OpenMutex.

 

Идея с ММХ оказалась бредовой. Проверил в 9x - после CreateProcess во всех mm круглые нули. Все таки ось их инициализирует или использует для инициализации памяти процесса.



vinnie_pooh

Ты это всерьез или издеваешся ?

 

Подумал что можно читать серийник CPU. Вродеб просто, cpuid и минимум кода. Пополучил 0000 0F29 030B 7040 0000 0000!!!!!!!! Язык не поворачивается его серийником называть! Что это вообще такое?По мне так больше смахивает на серию партии.??? Кто проверял есть возможность нарваться на такойже?

 

DimaS

"читать серийник CPU"

Если почитаешь мануал IA-32 Intel Architecture, то поймешь что "серийник" дело бесполезное, т.к. PSN (processor serial number) поддерживается только в Pentium 3. В более ранних моделях его не было, а в P4 его убрали "по просьбе трудящихся". По CPUID можно только определить модель процессора и связанные с ней характеристики, а это вещь отнюдь не уникальная.

 

Спасибо понЯл, уже забыли...

 

Все, что я писАл в своем посте про внедрение - отстой.

Осмелюсь предложить еще более отстойный и ламерский способ, но неожиданный:



1. Даем ломаемой проге расширение .dll и помещаем ее в какую-нибудь вложенную директорию.

2. В первой проге делаем необходимые проверки и если все в порядке, запускаем вторую (которая .dll) на выполнение способом

Код (Text):

1.     push    SW_SHOWNORMAL
2.     push    offset our_exe_with_dll_ext_name
3.     call    WinExec

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



PS. Это, конечно, не отвечает на вопрос Где записать байт, но решает проблему (если я ее правильно понял).

 

2vinnie_pooh

Да в принципе решает. Я обдумываю вариант.. Тока вот новые файлы найти простым поиском можно, а это неприятно!

Или замаскировать овцу в стаде, exe->dll->dll->dll и аще всяких там..

А может можно его какнить подпортить? Чтоб перед использованием востанавливать. Тока вот как обратно баги вешать?????

 

vinnie_pooh & DimaS

Чего-то вас друзья не в ту степь понесло. Может со своими наивными фантазиями в Helheim переместитесь, там как раз на повестке аналогичная тема Защита от копирования откомпилированной проги.

 

Да нет, я имел ввиду заранее поменять расширение на .dll и в таком виде дистрибутив распространять.

Развивая мысль: можно основную прогу зашифровать, вспомогательная после проверок считывает ее в память, расшифровывает, копирует где-то на HD и запускает. Вот тогда появится новый файл, но если эта идея подходит, есть несколько вариантов предотвратить его копирование.

 

leo

>Идея с ММХ оказалась бредовой.

неудивительно, ведь вычисления с плавающей запятой сплошь и рядом.

 

ozzman

"неудивительно, ведь вычисления с плавающей запятой сплошь и рядом"

Может быть и не удивительно, но дело видимо не в вычислениях, а в "заботливости" мелкософтов. При нормальном стиле программирования не делается никаких предположений относительно начального состояния регистров и содержимого стека, поэтому и занулять их незачем. По крайней мере инструкции FINIT и EMMS не зануляют регистры, а только помечают их как пустые. Так что мелкософты зануляют их принудительно - или мувами или FXRSTOR-ом из заранее подготовленного шаблона.

 

Даже если бы мы нашли сейчас какой-нибудь регистр, который не трогает система, нет гарантии, что его не будут трогать будущие версии Windows. А они появляются слишком часто.

 

vinnie_pooh

Регистры уже никто и не предлагает. А вот WriteProcessMemory или PostMessage - это реально и более надежно, чем просто "игра в прятки". Зачем расшифровывать или подправлять прогу и писать ее в файл, когда можно ее запустить CreateProcess и "подправить" WriteProcessMemory. Потому, что это сложнее - разбираться надо ?

 

Можно еще всякие извращенческие объекты вроде глобальных атомов создавать - видел я такую реализацию ограничения числа запусков за сессию. Надо будет заметку на полях сделать, чтобы в самую финальную версию "Теоретических основ..." это дело внести. Чего-то забыл про эту экзотику, когда писал - а то вдруг кто из начинающих споткнется. Нехорошо получится...