On 10/02/2010 12:56 AM, Lars Viklund wrote:
On Wed, Sep 29, 2010 at 06:48:55PM -0800, Robert Ramey wrote:
Chris Yuen wrote:
Hey guys,
I am using boost::serialization from 1.44.0. One thing that I noticed is that linking statically to the serialization libs will add several hundred exports in the final exe file that I get. Using `dumpbin /exports my_program.exe`
These functions are not explicity called from the library. But they ARE called as part of the serialization process. Its just that MSVC doesn't see them. So when you compile for release, The MSVC Linker strips them out and the program won't work anymore. In order to work around this, these functions are explicitly exported. This prevents MSVC from stripping them out. For more information see force_include.hpp
The problem with exporting is that it adds a semantic meaning which is unwanted. I think the /include linker option is supposed to do what you want: http://msdn.microsoft.com/en-US/library/2s3hwbhs%28v=VS.80%29.aspx "Specifying a symbol with this option overrides the removal of that symbol by /OPT:REF." You can even specify it in the source: #pragma comment(linker, "/include:__mySymbol") http://msdn.microsoft.com/en-us/library/7f0aews7%28VS.80%29.aspx
These exported symbols are excellent for provoking bugs in software that makes assumptions about the maximum reasonable length a symbol should be able to have.
I had a quite fun hair-tearing experience with a task manager replacement that overran some buffer due to Boost.S11n, resulting in instability, bogus output and program crashes.
Sounds like that app may have an exploitable security hole. There are a variety of techniques to load modules remotely into Windows, especially if the attack doesn't need be executed directly. - Marsh