Обнаружил взлом своей программы копированием файла msimg32.dll , в папку моей программы

Недавно обнаружил, что к моей программе выпущен кряк. Работает он так - просто просят скопировать в папку с моей программой специальный файл msimg32.dll, который видимо специальным образом модифицирован.

Когда моя программа устанавливается, там в папке с исполняемым файлом вообще нет никаких dll. Моя программа, видимо, обычно берет этот файл из папки Windows. Насколько я знаю, .dll файлы сначала ищутся в папке программы (где исполняемый файл) – если такового нет, то в папке Windows... – это я и не предусмотрел.


Подскажите пожалуйста, как можно защититься от подобных подложек?

Была идея проверять, есть ли в папке с программой есть какие-нибудь dll файлы, то сразу завершать работу программы с сообщением об ошибке. Но может быть есть какие-нибудь другие варианты?


p.s. Программа написана на VC MFC.

А может сделать проще, и для защиты не юзать чужих библиотек, а сделать например всё в своём коде? Хотя, верно, вы берёте через неё, привязки к машине.

Или вот ещё, просто потрясный способ от взлома! Не встречал ещё ни одного взломщика этой защиты. Выпустите прогу под свободной лицензией freeware или что-то вроде. Гарантирую, что крякеры даже и не подумают писать взломщика. *типа шутка*

Сообщение отредактировано: Eric-S - 26.01.14, 14:24

Цитата ViH @ 25.01.14, 15:23

Подскажите пожалуйста, как можно защититься от подобных подложек?

В общем случае - нельзя. Ваша программа всё равно использует KERNEL32.DLL или т.п.

Цитата Справка по MS VC пишет

Примечание по безопасности
Если код запускается под управлением операционных систем Windows NT 4, Windows 2000 или Windows XP (предшествующих пакету обновления SP1), необходимо указывать полный путь для всех библиотек DLL. В этих операционных системах при загрузке файлов в первую очередь поиск идет в текущем каталоге. Если не указать полный путь к файлу, возможно загрузка другого файла.

Т.о. запустится из вашего каталога, если что.

Добавлено 25.01.14, 17:20

Цитата Eric-S @ 25.01.14, 17:05

Или вот ещё, просто потрясный способ от взлома! Не встречал ещё ни одного взломщика этой защиты. Выпустите прогу под свободной лицензией freeware или что-то вроде. Гарантирую, что крякеры даже и не подумают писать взломщика.

И что? - вот выпустил он такую freeware-программу, а в ней - покупка "танка" идёт за деньги. Что, и к ней кряк не станут писать? Да ещё как напишут! Будьте уверены.

ViH
ВЗЛОМАТЬ МОЖНО ЛЮБУЮ ПРОГУ!!!

Цитата ViH @ 25.01.14, 15:23

то сразу завершать работу программы с сообщением об ошибке

Вообще не надо ничего показывать...

Цитата ViH @ 25.01.14, 15:23

Была идея проверять, есть ли в папке с программой есть какие-нибудь dll файлы, то сразу завершать работу программы с сообщением об ошибке.

А если удалять найденные dll?

Сообщение отредактировано: Filka - 26.01.14, 05:18

Запихай эту DLL в ресурсы или в конец EXE, при запуске программы распаковывай эту DLL из ресурсов или из конца EXE, лучше хранить в EXE.
Распаковывай куда нить в TEMP под непонятным именем, и загружай ее оттуда. Когда запихиваешь в ресурсы или EXE то кодируй ее.

Цитата

Запихай эту DLL в ресурсы или в конец EXE, при запуске программы распаковывай эту DLL из ресурсов или из конца EXE, лучше хранить в EXE.

MemoryModule?

Сообщение отредактировано: Filka - 26.01.14, 06:33

Цитата ViH @ 25.01.14, 15:23

Подскажите пожалуйста, как можно защититься от подобных подложек?

В самом начале своей программы проверяйте путь загруженных DLL через GetModuleHandle+GetModuleFileName.
Некоторые системные DLLки имеют цифровые подписи, можно их проверять дополнительно. Если очень важна безопасность а цифровых подписей нет на проверяемых DLL-ках, то можно выяснять хэши системных библиотек на системе где установлена ваша программа и проверять хеши. Здесь конечно надо мониторить обновления винды, но оно не так часто происходит для основных системных библиотек.

Цитата Eric-S @ 25.01.14, 17:05

А может сделать проще, и для защиты не юзать чужих библиотек, а сделать например всё в своём коде? Хотя, верно, вы бирёте через неё, привязки к машине.

Слинковаться статически с системными библиотеками не получится.

Сообщение отредактировано: neokoder - 26.01.14, 13:07

Цитата Славян @ 25.01.14, 17:16

вот выпустил он такую freeware-программу, а в ней - покупка "танка" идёт за деньги. Что, и к ней кряк не станут писать? Да ещё как напишут! Будьте уверены.

Какая же это freeware? Если там так или иначе просят деньги?

Абсолютная защита от взлома бывает. Это сделать так, чтоб никому, даже в голову, не пришло взламывать код.
Если тулза простая то freeware, без денег, вообще.
Если тулза для эксклюзивного использования, только для себя и больше никому!
Если тулза плохая или имеет привосходящие бесплатные аналоги.
Если исходный код открыт.

А вообще, некоторые программы, взламывать уж очень хочется. В основном, если они кривые, а разработчик не желает исправлять. Или же если разработчик упёр чужую идею, забыв сказать спасибо.

Но это всё психология.

Цитата Eric-S @ 26.01.14, 14:32

Какая же это freeware? Если там так или иначе просят деньги?

Откройте википедию и прочитайте:

Цитата вики

freeware - ПО, лицензионное соглашение коего не требует каких-либо выплат правообладателю.

Танки он, ViH, продаёт за деньги, но не требует, а говорит: "хотите мощный танк - платите, нет - играйте обычным". Нет никаких требований. Все чётко, агу?

Цитата

Насколько я знаю, .dll файлы сначала ищутся в папке программы (где исполняемый файл) – если такового нет, то в папке Windows... – это я и не предусмотрел.

Это называется DLL Hijacking. Атака стара как мир.
http://stackoverflow.com/questions/3623490...s-dll-hijacking
http://www.exploit-db.com/dll-hijacking-vu...e-applications/

Системные DLL вроде kernel32 описаны в секции KnownDlls (http://blogs.msdn.com/b/larryosterman/arch.../19/187752.aspx)
и потому ищутся всегда сначала в системных директориях, а потом уже где-то ещё.
Несистемная же DLL, при неуказании пути к ней - ищется, да, сначала в папке с программой, а только потом в других дирах.

Ещё один яркий пример такого - sysprep.exe на win7, заморочка для обхода UAC.

Ещё будет интересно узнать про две других атаки COM Planting и Binary Planting:
http://nobunkum.ru/analytics/en-com-hijacking

Решение в твоем случае - указать явно системную директорию, в которой лежит msimg32.dll:
1) GetSystemDirectory(sysdir)
2) SetDllDirectory(sysdir)

или LoadLibrary(PathCombine(sysdir, 'msimg32.dll'))

Цитата

Подскажите пожалуйста, как можно защититься от подобных подложек?

Понять идею, способы защиты становятся очевидны.

Цитата

В самом начале своей программы проверяйте путь загруженных DLL через GetModuleHandle+GetModuleFileName.

Сначала загрузите вредоносную DLL, а потом проверьте путь. Это что-то из серии про "- Как проверить, существует ли таблица MySQL? - Очень просто: if (DROP TABLE ... != 0) таблица существовала"

Цитата

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

Чет вас не в ту степь понесло

Сообщение отредактировано: reinterpret_alexey - 28.01.14, 04:01

А можно вместе с программой распространять файл: хакер, пожалуйста, не взламывай мою программу! Вот!!!

Эх, Бублик, Бублик.. Подвел черту, так сказать:)

Цитата reinterpret_alexey @ 28.01.14, 00:41

Цитата

В самом начале своей программы проверяйте путь загруженных DLL через GetModuleHandle+GetModuleFileName.

Сначала загрузите вредоносную DLL, а потом проверьте путь. Это что-то из серии про "- Как проверить, существует ли таблица MySQL? - Очень просто: if (DROP TABLE ... != 0) таблица существовала"

Даже в этом случае тоже можно грохнуть чужие dll.
Программа может создать .bat - файл и рестартовать
с его помощью. Этот батник и зачистит папку от плохих модулей
перед запуском.

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

1.Написать самому вирус под видом кряка.
2. Вирус пускай спамит мыло ФСБ угрозами о теракте.
3. Разложить на каждом углу.
4. Дожидаться очной ставки с любителями халявного софта.

Цитата UncleBob @ 28.01.14, 08:32

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

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

Сообщение отредактировано: ЫукпШ - 28.01.14, 09:36

Какая гонка вооружений?
Автор даже не удосужился посмотреть что dll-ка подгружаемая делает.
Она в любом случае в памяти что-то патчит, а раз не запатчили сам файл значит он протом каким-то накрыт.
Короче говоря автор топика не особо представляет что из себя представляет защита и как её поломали, так что dll можно удалять сколько влезет, только будут другие решения типа инлайн патча и всё.

Сообщение отредактировано: cppasm - 28.01.14, 10:02

Цитата reinterpret_alexey @ 28.01.14, 00:41

Решение в твоем случае - указать явно системную директорию, в которой лежит msimg32.dll:
1) GetSystemDirectory(sysdir)
2) SetDllDirectory(sysdir)

или LoadLibrary(PathCombine(sysdir, 'msimg32.dll'))

Цитата reinterpret_alexey @ 28.01.14, 00:41

Сначала загрузите вредоносную DLL, а потом проверьте путь. Это что-то из серии про "- Как проверить, существует ли таблица MySQL? - Очень просто: if (DROP TABLE ... != 0) таблица существовала"

Сам написал и потом своё же зачеркнул
Ты то видимо до загрузки системных библиотек собрался пути их поиска указывать? Гений!

Цитата reinterpret_alexey @ 28.01.14, 00:41

Чет вас не в ту степь понесло

Именно в ту. Ты никакими стандартными способами не сможешь контролировать загрузку системных DLL. Только сделать то что я сказал. Всё же лучше чем ничего, проверил - если что-то не так завершил программу. А если предполагать, что в подмененной DLL каким то образом во время загрузки можно "отключить", предотвратить пост-проверку откуда чего загружено. Ну так от этого защита только - контроль за тем чтобы все системные библиотеки были в порядке. Другого в принципе ничего не придумаешь. И это уже не задача программера.

А что касается своих библитек тут ещё всё проще - делать статику и все дела. Но если очень надо DLL, то подписывать их и подписывать свою программу и далее по тому же принципу что я говорил для системных библиотек.

Добавлено 28.01.14, 11:12
А где цитаты? Что за глюк?

Сообщение отредактировано: neokoder - 28.01.14, 11:20

У тебя один [/quote] лишний

Цитата UncleBob @ 28.01.14, 11:19

У тебя один quote лишний

Точно. Исправил

Добавлено 28.01.14, 11:37

Цитата reinterpret_alexey @ 28.01.14, 00:41

Несистемная же DLL, при неуказании пути к ней - ищется, да, сначала в папке с программой, а только потом в других дирах.

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

Сообщение отредактировано: neokoder - 28.01.14, 11:37

Цитата

Ты то видимо до загрузки системных библиотек собрался пути их поиска указывать? Гений!

Цитата

Именно в ту. Ты никакими стандартными способами не сможешь контролировать загрузку системных DLL.

О господи. Какие ещё системные DLL, какие ещё цифровые подписи и хеш-суммы? msimg32.dll есть в любой винде,
но она не перечислена в KnownDlls, поэтому системной её не назовешь. Контролировать её загрузку как раз
можно, если положить DLL с таким именем в папку рядом с приложением, которое её загружает без указания пути. Это и есть
DLL hijacking, это и есть то, о чем спрашивает ViH. Нужно пути к DLL правильно указывать:
C:\windows\system32\msimg32.dll
А хеш-суммы считать от системных DLL - это вообще бред: если у атакующего есть возможность перезаписать
системную DLL, он может сделать и всё остальное.

Цитата

Даже в этом случае тоже можно грохнуть чужие dll.
Программа может создать .bat - файл и рестартовать
с его помощью. Этот батник и зачистит папку от плохих модулей
перед запуском.

Гонка вооружений! DLL, заинжектившись на первом этапе в программу перехватит функции
записи в файл и при записи bat-файла добавит туда само-восстановление.
Кстати, .bat-файл для перезаписи вовсе не нужен. Для этого нужно выполнить
ping -n 1 -w 2000 1.2.3.4&&del /q /f program.exe
(ping организует задержку 2000 мсек, за это время программа успевает сделать ExitProcess)

Добавлено 28.01.14, 13:17

Цитата

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

Защит от чего? От порядка директорий, в которых ищется DLL? Если DLL твоя, то она должна лежать в папке с программой.
Если DLL чужая - ты должен знать к ней путь. Если ты грузишь DLL по пути, по которому её нет и кто-то может положить -
то это уязвимость, надо перестать так делать, а не "защиты" писать.

ViH

Т.к. msimg32.dll системная библиотека но её нет в списке KnownDLLs (почему то!) и поэтому она будет грузиться из папки где запущено ваше приложение, вам чисто для решения вашей проблемы:

Ипользуйте Run-Time Dynamic Linking, там видимо используете одну из 3-х функций из этой библиотеки - AlphaBlend, TransparenrtBlt или GradientFill, так что мароки не особо много.
Но если и в системном каталоге могут подменить DLL, то тут уже конечно могут всё что угодно и защититься сложно. Но один из вариантов я обозначил - забить хеш msimg32.dll в свою программу и проверять его. Если у вас программа будет с цифровой подписью, то для аттакера это уже очень сложная проблема будет, при условии сохранности подписи конечно.

И чтобы не было потенциальных проблем уже с вашими DLL - линкуйтесь статически, без DLL.

Надо же, когда писал своё сообщение ещё твоего не видел Одновременно мы почти...

Цитата reinterpret_alexey @ 28.01.14, 13:15

А хеш-суммы считать от системных DLL - это вообще бред: если у атакующего есть возможность перезаписать
системную DLL, он может сделать и всё остальное.

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

Цитата reinterpret_alexey @ 28.01.14, 13:15

Защит от чего? От порядка директорий, в которых ищется DLL?

От подмены DLL приложения.

Цитата reinterpret_alexey @ 28.01.14, 13:15

Если DLL твоя, то она должна лежать в папке с программой.

Ну так кто спорит то. Вот от подмены своих DLL с помощью цифровых подписей или хешей и цифр. подп. и шла речь.

Цитата reinterpret_alexey @ 28.01.14, 13:15

Если DLL чужая - ты должен знать к ней путь. Если ты грузишь DLL по пути, по которому её нет и кто-то может положить -
то это уязвимость, надо перестать так делать, а не "защиты" писать.

Ну то что ты предложил 100% не будет работать для системных билиотек Сам же пишешь если их подменить, то без раницы по какому пути они загружаются.

Сообщение отредактировано: neokoder - 28.01.14, 13:42

neokoder

И опять мимо

В конкретно этом случае нужно просто заменить AlphaBlend на GdiAlphaBlend, а msimg32.lib заменится на gdi32.lib,
соответственно, msimg32.dll заменится на gdi32.dll. А gdi32.dll уже есть в KnownDlls)

Поэтому я и говорю: решением проблемы должно стать понимание DLL hijacking)

Ох, neokoder, помню я был таким же. Влезал в дискуссию только для того, чтобы показать какие-то знания. Даже если
по теме сказать было нечего. Да я и до сих пор такой же остался, че тут) Поэтому я ну ооочень хорошо это в
других замечаю Не будем же этого стыдицо)

Сообщение отредактировано: reinterpret_alexey - 28.01.14, 13:40

Цитата reinterpret_alexey @ 28.01.14, 13:38

В конкретно этом случае нужно просто заменить AlphaBlend на GdiAlphaBlend, а msimg32.lib заменится на gdi32.lib,
соответственно, msimg32.dll заменится на gdi32.dll. А gdi32.dll уже есть в KnownDlls)

И чё дальше то?

Ты вообще хоть одно мало мальское практическое решение автору топика подсказал? Кроме теоретической болтовни от тебя ничего не слышно

Тут дело ширше обстоит, а не "понимание DLL hijacking)"
Чисто практически, вот есть программа у клиента. Если у аттакера есть доступ к компьютеру локально и он более мене квалифицированный - НИЧЁ не спасёт! Если не очень квалифициованный, то о чём я говорил поможет решить проблему.
Вопрос в необходимости таких мер. Поскольку ни одно известное коммерческое приложение так не озадачивается точно, проблемы локальной безопасности целиком лежат на клиенте. Это невозможно универсально предусмотреть.

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

Ещё разок напомню:
1) Run-Time Dynamic Linking c msimg32.dll
2) Проверка хеша msimg32.dll забитого в подписанное цифровой подписью главное приложение.
3) Никаких своих DLL-ок, только статическая линковка

Сообщение отредактировано: neokoder - 28.01.14, 14:01

Ну чего то автор топика пропал совсем. Молчит... А мы тут разболтались
ViH, ау ты где? Ну нашёл что-нибудь здесь для решения или хотя бы снижения градуса своей проблемы?

Сообщение отредактировано: neokoder - 28.01.14, 14:06

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

shm

А если юзать Obfuscator-LLVM ? http://crypto.junod.info/2013/12/24/about-...cademic-ethics/

Цитата

Попытаться удалять DLL? Сразу найдет неугодный вызов DeleteFile или что-нить аналогичного.

Можно написать лаунчер для своей программы...

Launcher

На Delphi , но смысл, думаю, понятен:

program Launcher;
 
uses
  Windows, SysUtils;
 
  procedure DetectAndRemoveDLL;
  var
    SR: TSearchRec;
  begin
    if FindFirst('*.dll', faAnyFile - faDirectory, SR) = 0 then
    begin
      repeat
        if (SR.Attr and faReadOnly) <> 0 then
          FileSetAttr(SR.Name, SR.Attr and not faReadOnly);
        DeleteFile(SR.Name);
      until FindNext(SR) <> 0;
      FindClose(SR);
    end;
  end;
 
  procedure Exec(const S: string);
  const
    Flag = CREATE_DEFAULT_ERROR_MODE;
  var
    SI: TStartupInfo;
    PI: TProcessInformation;
  begin
    FillChar(SI, SizeOf(TStartupInfo), 0);
    SI.cb := SizeOf(TStartupInfo);
    CreateProcess(nil, PChar(S), nil, nil, False, Flag, nil, nil, SI, PI);
    CloseHandle(PI.hProcess);
    CloseHandle(PI.hThread);
  end;
 
begin
  DetectAndRemoveDLL;
  Exec('MainProg.exe');
end.

Или что-то типа того...

А потом понадобится Enigma Virtual Box

Скрытый текст

Что усложнит взлом...

Цитата reinterpret_alexey @ 28.01.14, 14:48

А если юзать Obfuscator-LLVM ?

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

Добавлено 28.01.14, 15:30

Цитата Filka @ 28.01.14, 15:22

потом понадобится Enigma Virtual Box

Это вроде обычный упаковщик.

Цитата shm @ 28.01.14, 15:23

Это вроде обычный упаковщик.

Распакуй

Сообщение отредактировано: Filka - 28.01.14, 15:32

Цитата Filka @ 28.01.14, 15:31

Распакуй

все уже давно распаковано (не подойдет - в сети куча других)

Сообщение отредактировано: shm - 28.01.14, 15:44

Цитата neokoder @ 28.01.14, 13:37

Если хеш будет в основной программе и она будет с цифровой подписью

а как это вяжется с разными версиями DLL для разных систем?

Сообщение отредактировано: UncleBob - 28.01.14, 15:46

Цитата

Современные компиляторы с включенной оптимизацией и так являются хорошими обфускаторами.

Не, тут о настоящих обфускаторах идет речь. Он замусоривает и запутывает код. И поток управления и поток данных.
Необратимо. Obfuscator-LLVM это, так сказать, последняя академическая разработка.
У них есть демка - kryptonite: http://0vercl0k.tuxfamily.org/bl0g/?p=260

Цитата

а как это вяжется с разными версиями DLL для разных систем?

Ты читаешь клинический бред) Какой ты хочешь получить ответ?)

Сообщение отредактировано: reinterpret_alexey - 28.01.14, 15:47

Цитата reinterpret_alexey @ 28.01.14, 15:46

Он замусоривает и запутывает код

Иии? Ты думаешь это сильно усложнит отладку?

Сообщение отредактировано: shm - 28.01.14, 15:51

Цитата

Иии?

Ну посмотри демку. Ты можешь покрыть весь код приложения таким обфускатором и сделать так, чтобы он работал только при правильном вводе серийника.
Пока серийник не уплывет к отакуюсчим - не думаю, что кто-либо поломает такое. А к случае с уплыванием - надо раздавать именные лицензии как делает
IDA&HexRays)

Цитата

Иии? Ты думаешь это сильно усложнит отладку?

Это сделает её практически невозможной. Даже автоматизированными средствами, т.к. не понятно, что именно искать. Символьные формулы
тоже не составишь - ни один smt сольвер их не решит: слишком много кода, не понятно, какой код выполняется, а какой нет.
Какой мусорный, а какой нет. В то и идеяя запутывания control-flow.

Сообщение отредактировано: reinterpret_alexey - 28.01.14, 15:58

Цитата reinterpret_alexey @ 28.01.14, 15:56

Ну посмотри демку

Домой приду - посмотрю.

Цитата UncleBob @ 28.01.14, 15:45

а как это вяжется с разными версиями DLL для разных систем?

Я об этом говорил выше почитай.

Цитата reinterpret_alexey @ 28.01.14, 15:46

Ты читаешь клинический бред) Какой ты хочешь получить ответ?)

Слышь, придурок, больше не пиши на мой счет ничего ладно. Не зли, не хочу злиться Ты глупый бестолковый рассуждатель, теоретик!

Сообщение отредактировано: neokoder - 28.01.14, 16:06

shm

Попробуй. У меня не получилось Прямой линк
http://download.tuxfamily.org/overclokblog...kme.Win7.x64.7z

Там же висит статья о том, как, из чего и чем они её скомпилировали
http://0vercl0k.tuxfamily.org/bl0g/?p=260

Какие, мля, обсуфукации хренофукации когда речь идёт о подмене DLL! Вот чудак!

Просто оффтопят, neokoder, не паникуй.

Цитата reinterpret_alexey @ 28.01.14, 00:41

Решение в твоем случае - указать явно системную директорию, в которой лежит msimg32.dll:
1) GetSystemDirectory(sysdir)
2) SetDllDirectory(sysdir)

или LoadLibrary(PathCombine(sysdir, 'msimg32.dll'))

Похоже, это то, что нужно. Но у меня msimg32.dll не загружается явно через LoadLibrary.

Т.о. нужно через SetDllDirectory, но где этот код вставлять в MFC приложении (Dialog Based)? Получается, что dll подхватывается раньше. Вставляю в начало метода CMyApp:InitInstance() { ... }, но это уже поздно.

Стандартная DLL хранится тут c:\Windows\System32\msimg32.dll и при попытке ее подменить Windows сразу заблокирует это действие.

Подгружай эту DLL из системной папки динамически и вызывай динамически необходимые тебе функции их в этой DLL всего 5, в чем проблема то ??? В лени ???

Цитата ViH @ 29.01.14, 11:20

Но у меня msimg32.dll не загружается явно через LoadLibrary.

Сделай чтобы загружалось Run-Time Dynamic Linking
Просто укажи путь к этой библитеке в LoadLibrary и не нужны никакие SetDllDirectory.
Если очень важна безопаснсоть или для твоего случая - когда кто-то там играется с подменой, то в принципе для всех системных DLL которые не перечислены здесь: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs и используется твоей программой надо бы использовать Run-Time Dynamic Linking c явным указанием пути в LoadLibrary.

И ещё не забудь, что библиотека msimg32.dll может находиться в 2-х папках:
c:\Windows\SysWOW64\msimg32.dll
c:\Windows\System32\msimg32.dll

в зависимости от разрядности твоего приложения.

Сообщение отредактировано: neokoder - 29.01.14, 12:19

ViH почитай, чтобы разобраться:
Dynamic-Link Library Search Order
Dynamic-Link Library Security

Можно ещё использовать манифест и side-by-side components, я честно говоря не знаю можно ли таким образом жестко задать путь к msimg32.dll, не пробовал.

ViH

Цитата

Похоже, это то, что нужно. Но у меня msimg32.dll не загружается явно через LoadLibrary.

Какая у тебя Visual Studio? 6.0?
msimg32.dll вообще не должна использоваться. Она у тебя используется потому что где-то есть код, вызывающий
одну из устаревших функций (нужны для 9x) - AlphaBlend, GradientFill, TransparentBlt, vSetDdrawflag.
Их нужно заменить на GdiAlphaBlend, GdiGradientFill, GdiTransparentBlt, GdivSetDdrawflag,
т.е. в название добавить Gdi. Если msimg32.lib есть в настройках проекта (linker options), то нахрен выкинуть и заменить на gdi32.lib.

Сообщение отредактировано: reinterpret_alexey - 29.01.14, 12:50

Ну что вы привязались к этой несчастной msimg32.dll? Наверняка, злоумышленники выбрали ее для кряка только благодаря малому размеру. Решите проблему с ее загрузкой - просто выберут другую из десятка прочей "всякой всячины". Прикажите штудировать весь импорт и пресаживать все не KnownDll на LoadLibrary?

Сообщение отредактировано: leo - 29.01.14, 17:36

Цитата leo @ 29.01.14, 17:35

Ну что вы привязались к этой несчастной msimg32.dll? Наверняка, злоумышленники выбрали ее для кряка только благодаря малому размеру. Решите проблему с ее загрузкой - просто выберут другую из десятка прочей "всякой всячины". Прикажите штудировать весь импорт и пресаживать все не KnownDll на LoadLibrary?

leo, ну неужели ваши приложения используют очень много системных DLL не из списка KnownDlls? Не думаю что их так много что сложно будет их пересадить на run-time linking. И достаточно будет только для первого уровеня из dependencies приложения, а то что они там уже вызывают это уже не дело приложения. Ну реально думаю это сделать, почему нет.

А что ещё можно сделать?

Цитата neokoder @ 29.01.14, 18:18

leo, ну неужели ваши приложения используют очень много системных DLL не из списка KnownDlls? Не думаю что их так много что сложно будет их пересадить на run-time linking.

Дело не в мало или много, а в том, что эти dll могут юзаться "без твоего ведома" либами типа MFC и т.п., в которые со своим LoadLibrary просто так не влезешь.
Хотя VC, вроде как, позволяет задавать delay load dll и свой хук на их загрузку. Но все равно это морока - перед каждым билдом проверять, не появилось ли "что-то но-овенькое", чтобы добавить его в delaylod

Цитата leo @ 29.01.14, 22:33

Дело не в мало или много, а в том, что эти dll могут юзаться "без твоего ведома" либами типа MFC и т.п., в которые со своим LoadLibrary просто так не влезешь.
Хотя VC, вроде как, позволяет задавать delay load dll и свой хук на их загрузку. Но все равно это морока - перед каждым билдом проверять, не появилось ли "что-то но-овенькое", чтобы добавить его в delaylod

Я это понимаю, поэтому и говорил выше если ты читал, что все подмены системных DLL из knownDLLs это в принципе не забота создателей программы, и тем более то что загружают системные либы типа MFC. Но те, которые грузит само приложение непосредственно и они почему то странным образом отсутствуют в knownDLLs и поэтому могут грузиться из папки приложения при Load-Time Dynamic Linking надо бы или подгружать вручную или хотя бы контролировать путь их загрузки, пусть и уже после загрузки, всегда можно завершить приложение если она загрузилась не оттуда откуда надо.

Ну вот у чела конкретная проблема и её вполне можно решить одним из путей.

Кстати, leo, знаешь или нет можно использовать манифест и side-by-side components чтобы жестко задать путь к таким DLL?

Сообщение отредактировано: neokoder - 30.01.14, 09:51

Цитата reinterpret_alexey @ 29.01.14, 12:47

ViH
Какая у тебя Visual Studio? 6.0?
msimg32.dll вообще не должна использоваться. Она у тебя используется потому что где-то есть код, вызывающий
одну из устаревших функций (нужны для 9x) - AlphaBlend, GradientFill, TransparentBlt, vSetDdrawflag.
Их нужно заменить на GdiAlphaBlend, GdiGradientFill, GdiTransparentBlt, GdivSetDdrawflag,
т.е. в название добавить Gdi. Если msimg32.lib есть в настройках проекта (linker options), то нахрен выкинуть и заменить на gdi32.lib.

VS 2013 Ultimate, ни одна из этих функций в программе не используется.

Проблема в том, что я не знаю, откуда подгружается эта msimg32.dll

В коде через LoadLibrary у меня подгружаются только:
UxTheme.dll
wtsapi32.dll
psapi.dll
kernel32.dll

В AdditionalDependencies только Psapi.lib
(там нет msimg32.lib и gdi32.lib)

Сообщение отредактировано: ViH - 30.01.14, 13:24

ViH
http://www.dependencywalker.com/

У-у, как все запущено - msimg32 сидит в delay load импорте многих сис.dll, в частности IE-библиотек, и даже (о, боже!) в user32 (используется ф-я AlphaBlend).

Поэтому, если msimg32 действительно загружается с задержкой через delay import, то решение проблемы может оказаться простым "до безобразия" - просто на старте проверяем загрузку msimg32 по GetModuleHandle, и если получаем NULL, то просто грузим ее сами (!) через LoadLibrary из сис.директории. Ну а если она уже подцепилась (что мало вероятно при delay load), то проверяем ее путь и если он не соответствует system32, то (тихо-мирно без лишнего шума) отказываемся работать или еще лучше впадаем в обморок\конвульсии и начинаем глючить

Так в итоге получается "У-у, как все запущено" если и можно сказать то только про микрософтов ну по данному конкретному вопросу точно
Если дело обстоит так как говорит топик стартер и он непосредственно эту DLL не юзает, то user32.dll или какая-то другая системная либа не может правильно загрузить свою msimg32 по правильному пути а грузит из папки приложения!
Неважно как они реализуют Deload Load, в любом случае такие либы как msimg32, которые являются системными но почему-то странным образом их нет в KnownDLLS должны грузится по правильному пути всеми системными DLL, а не из папки приложения.

Добавлено 31.01.14, 16:06
Кстати через манифест и side-by-side component нельзя жестко задать путь к таким либам. В элементе манифеста file hash параметр не обязательный и видимо система его вообще игнорит, а полный путь к DLL задать нельзя. Так что либа всё равно будет грузиться из папки приложения, если она там есть.

Сообщение отредактировано: neokoder - 31.01.14, 16:06

Программа должна устанавливаться в Program Files. В Program Files писать может только админ. Тот, у кого есть права админа может сделать все, что угодно. В чем вопрос?

Цитата reinterpret_alexey @ 31.01.14, 16:13

Программа должна устанавливаться в Program Files.

Так - вы навязываете автору, куда ему устанавливать программу. Не следует.

Цитата Славян @ 31.01.14, 18:20

Цитата reinterpret_alexey @ 31.01.14, 16:13

Программа должна устанавливаться в Program Files.

Так - вы навязываете автору, куда ему устанавливать программу. Не следует.

Ничего не навязываю. Просто это никаким боком не задевает вопрос безопасности. Если пользователь имеет доступ к директории, в которую установлена программа, какой смысл думать о каких-то DLL? Он может просто изменить саму программу. Это не вопрос секурити и это НЕ БАГ. Ни программы, ни системы. Вся эта тема с именами DLL, с поиском DLL и KnownDlls называется DLL HIJACKING. Иногда это действительно баг, я давал ссылку (СOM hijacking). В данном случае нет никакой проблемы. Решать же нечего. Рассуждать можно, я всегда за:)

На самом деле всё ещё хуже... у микрософтов
Сам kernel32.dll грузит системные либы из папки приложения. Это вообще кто у них придумал вот интересно?
Сделать delay-loading на kernel32.dll нельзя, отсюда любое приложение не защищено.
Можно только пост-приорно проверить своё приложение уже после загрузки на наличие подключенных вредоносных DLL-ок, выгрузить их и поудалять, загрузить правильные или хотя бы не давать работать приложению. Но это полумеры, поскольку если DLL-ка грузанулась она уже и дел может натворить!

Опираться только на то, что доступ к папке приложения будет закрыт правами админа, это слишком недальновидно со стороны микрософтов.
Штука в том, что можно загрузить комп с диска или флешки(ну мало кто ставит пароль в BIOS) линуксовского LIVE CD и спокойненько и быстренько скопировать DLL в нужную папку. Не надо иметь доступ в систему чтобы поставить хуки или как-то там ещё заморачиваться другими способами. Просто файлик скопировал и всё. А вот далее лежит себе какая-то DLL-ка в папке приложения и кто на неё обращать внимание будет? Правильно никто. А она может всё что угодно, к примеру мониторить всю память любого процесса и передавать данные по сети куда угодно. Все фаэрволы будут молчать! К примеру в папку к любому браузеру или почтовой программе закинул и все разрешения на исходящие на 80,443,53 или почтовые порты уже есть! А если приложение при запуске попросит права администратора так вообще пи....!

Ведь просто же исправить: разрешить загрузку системных либ только из системных папок, собственно там где они только и могут находиться.

Вот вам реальный пример как просто можно хакнуть любую программу:
Прикреплённый файлversion.7z (47.33 Кбайт, скачиваний: 142)

И все эти бла-бла-бла о том что дескать нет админских прав записать что-то в папку приложения это вообще херня. Всё можно, и это не сложно.
Вон скайп вообще обновляется скачивая обновления в темповую директорию юзера, если там будет лежать соответсвующая DLL, пи.... юзеру. Скайп запросит админские права, ну а далее с админскими правами...

Цитата Qraizer @ 21.02.15, 07:10

Как тебя понимать?

Не ну самом деле опираться только на то что требуются права админа чтобы записать в каталог с приложением это ж очень недальновидно со стороны микрософтов и это мягко говоря )).

А по поводу админских прав читаем очередной пассаж от микрософт

Цитата Microsoft

This security update resolves a vulnerability in Microsoft Windows that could allow an attacker to take advantage of the lack of impersonation-level security checks to elevate privileges during process creation. An authenticated attacker who successfully exploited this vulnerability could obtain administrator credentials and use them to elevate privileges. An attacker could then do the following:

Install programs
View, change, or delete data
Create new accounts that have full administrative rights

И после этого они же и надеются что отсутствие адиниских прав это очень надежно!

Сообщение отредактировано: neokoder - 21.02.15, 08:42

Надёжным является получение необходимых прав по запросу, не надёжным – незаметно.

Цитата ViH @ 25.01.14, 15:23

Недавно обнаружил, что к моей программе выпущен кряк. Работает он так - просто просят скопировать в папку с моей программой специальный файл msimg32.dll, который видимо специальным образом модифицирован.

Когда моя программа устанавливается, там в папке с исполняемым файлом вообще нет никаких dll. Моя программа, видимо, обычно берет этот файл из папки Windows. Насколько я знаю, .dll файлы сначала ищутся в папке программы (где исполняемый файл) – если такового нет, то в папке Windows... – это я и не предусмотрел.


Подскажите пожалуйста, как можно защититься от подобных подложек?

Была идея проверять, есть ли в папке с программой есть какие-нибудь dll файлы, то сразу завершать работу программы с сообщением об ошибке. Но может быть есть какие-нибудь другие варианты?


p.s. Программа написана на VC MFC.

VMProt купить и упаковать-пошифровать свое творение этим протектором.
Он же от длл инъекций защитит.

Слом вмпрота стоит от 15 килобаксов.

Цитата progman @ 22.02.15, 08:16

VMProt купить и упаковать-пошифровать свое творение этим протектором.
Он же от длл инъекций защитит.

Защитить то программу сможет, а вот предотвратить инъекцию никаким образом не сможет. Если надо сломать прогу то для этого не DLL-инъекции вообще используются. В общем это уже другая тема.
И кстати данные в памяти всё равно в какой-то момент будут расшифрованы, так что вопрос цены и времени.

Сообщение отредактировано: neokoder - 22.02.15, 13:35

Цитата neokoder @ 22.02.15, 13:30

Защитить то программу сможет, а вот предотвратить инъекцию никаким образом не сможет. Если надо сломать прогу то для этого не DLL-инъекции вообще используются. В общем это уже другая тема.
И кстати данные в памяти всё равно в какой-то момент будут расшифрованы, так что вопрос цены и времени.
Сообщение отредактировано: neokoder - 22 февраля, 13:35

вмпрот позволяет интегрировать все длл внутри програмного пакета - даже если длл изначально с динамической линковкой.
и контролирует как то целостность памяти процесса.

там дохране чего напихано всякого.
потому и цена взлома от 15 килобаксов

Цитата progman @ 26.02.15, 00:40

вмпрот позволяет интегрировать все длл внутри програмного пакета - даже если длл изначально с динамической линковкой.

Включая системные?

Антивирусы как к такой защите относятся?

Цитата Kray74 @ 26.02.15, 10:23

Антивирусы как к такой защите относятся?

по разному. Иногда приходится ручками в исключения добавлять.

Цитата Kray74 @ 26.02.15, 10:23

Включая системные?

вот за них не уверен. Надо маны читать.

Я лично вмпрот уже 5 лет использую для защиты своих проектов.
Лично знаю топовых ребят с краклаба - в общем в СНГ всего 4 человека есть которые могут снять правильно навешенную защиту вмпрот с мутацией, обфускацией, виртуализацией, защитой памяти и прочими плюшками
и цена снятия от 15 тысяч

Сообщение отредактировано: progman - 26.02.15, 15:44