DLL без экспортируемых функций?

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

Я не смотрел на рассматриваемые библиотеки DLL; но возможно в чем-то вроде MSOffice Microsoft сделала это, чтобы запутать DLL, чтобы усложнить отладку / обратный инжиниринг.

Однако вы спросите, как бы вы использовали такую ​​DLL? Что ж, если приложение знает макет DLL, оно может создать указатель на функцию с адресом известной функции и вызвать ее.

Если вы действительно хотите копнуть дальше, вы можете выполнить objdump DLL и поискать стандартные прологи и эпилоги функций C / C ++ ABI и, возможно, выяснить, где эти функции начинаются.

Когда вы вызываете LoadLibrary, DLL получает вызов своего DllMain. Это точка входа в DLL. Он вызывается при присоединении процесса и присоединении потока. Итак, у вас есть точка входа.

Как только у него есть хотя бы одна точка входа, он может создать экземпляр некоторого интерфейса (например, фабрики) и установить его, например Переменные TLS, откуда их подхватят другие модули.

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

Ресурсы

DLL, вероятно, имеет ресурсы, такие как строковые таблицы, изображения, значки и т. Д., Используемые остальной частью Office.

Всегда возможно, что они просто не экспортируют их как интерфейсы C. DLL - это не волшебство, это просто биты и байты, и ничто не говорит о том, что вы не можете получить код из DLL, если не попросите об этом Windows. Я считаю, что .NET использует этот подход - они сохраняют метаданные в DLL, которая сообщает CLR, что в ней содержится, вместо того, чтобы делать функции .NET доступными с помощью обычного подхода GetProcAddress. Если вы явно не попросите об этом.