The forceful implementation of features

• Download source - 97 KB
• Download demo - 61.2 KB

Background

As a long time user of Firefox, I decided to switch to Apple’s Safari; unfortunately, the browser is missing some functionality that I require to surf the web, with the plug-in API being currently unavailable. I decided to implement it on my own by the usage of DLL-Injection and Hooking.

How it works

After our Dynamic Link Library is injected, we first have to import Apple’s Core Foundations in order to interface with the browser. Unfortunately, Apple unlinks their modules from the PEB, so that we have to do this in DllMain, or else we would have to jump through further hoops to get the Module Handles.

#define InitCFImport( x ) \
( *( FARPROC* )&##x ) = GetProcAddress( hmCoreFoundations, #x ); \
if( x == NULL ){ \
    ( *( FARPROC* )&##x ) = GetProcAddress( hmCFNetwork, #x );\
}\
if( x == NULL ){\
    MessageBoxA( 0, #x, "Unable to import", 0 );\
    return false;\
}

InitCFImport( CFStringGetSystemEncoding );
InitCFImport( CFStringGetCStringPtr );
InitCFImport( CFStringGetCharactersPtr );
InitCFImport( CFURLCopyAbsoluteURL );
InitCFImport( CFURLGetString );
InitCFImport( CFURLGetBaseURL );
InitCFImport( CFURLCreateWithString );
InitCFImport( CFStringGetCharacters );
InitCFImport( CFStringDelete );
InitCFImport( CFStringGetLength );
InitCFImport( CFURLRequestGetURL );

Now, with those imports, we can read which URL Safari is trying to access, and we also need a way to integrate ourselves into the Safari UI. I decided to use the “Page Button” because it seemed like the right place to me. But before we can place our entries there, we need to obtain the menu handle, which is why I hooked InsertMenuItemW. Basically, all I do there is to wait for Apple to add their entries so that I can insert mine. Please refer to “hkInsertMenuItemW” if you want to know more.

Now that we have inserted ourselves into Apple’s menu, we need to subclass their main-window. The problem with that is that Apple creates a multitude of windows of all kinds. In fact, they even create the MainWindow new for each “instance” of Safari. To handle that, I hooked “CreateWindowExW” to subclass the “Message-Handler” (please refer to “hkCreateWindowExW” if you want to know more ).

Last but not least, we need a way to figure out which URLs are being loaded and a way to prevent that from happening for undesired ones.

This is my solution:

Core::CFURLRef __cdecl hkCFURLRequestGetURL( Core::CFRequestRef refRequest )
{
    Core::CFURLRef pResult = Core::CFURLRequestGetURL( refRequest );

    DWORD dwReturnAddress = ( DWORD ) _ReturnAddress();
    DWORD dwModuleBase = ( DWORD ) Core::g_hmCFNetwork;

    if ( pResult && dwReturnAddress > dwModuleBase
    && dwReturnAddress < dwModuleBase + 0x57000 )
    {
        Core::CStringRef refUrlText = Core::CFURLGetString( pResult );
    
        if ( refUrlText )
        {
            wchar_t wszBuffer[2024];

            if ( Core::ConvertString( refUrlText, wszBuffer, 1024 ) )
            {
                // returns true if the content is to be blocked
                if ( ContentIndexer::Add( wszBuffer ) )
                {
                    return NULL;
                }
            }
        }
    }
    return pResult;
}

I check for the return address (location where the call to our hook originated from) to be within the boundaries of CFNetwork.dll because some callers of this function expect it to always return a valid value, although Apple’s SDK states that this function might fail. The only thing that’s left to do within the function is to check for URLs of interest and either index them or block them. The algorithms I use are very basic because speed matters here.

Thanks for reading.

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)