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

[neokoder]

Цитата 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

[neokoder]

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

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

[reinterpret_alexey]

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

[leo]

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

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

[neokoder]

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

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

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

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

[leo]

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

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

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

[neokoder]

Цитата 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

[ViH]

Цитата 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

[Filka]

ViH
http://www.dependencywalker.com/

[leo]

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

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

[neokoder]

Так в итоге получается "У-у, как все запущено" если и можно сказать то только про микрософтов ну по данному конкретному вопросу точно
Если дело обстоит так как говорит топик стартер и он непосредственно эту 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

[reinterpret_alexey]

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

[Славян]

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

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

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

[reinterpret_alexey]

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

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

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

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

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

[neokoder]

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

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

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

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

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