[myselfandi]

At the moment its not very efficient. to do so, you may need to implement your own api cash.

now just shift each char of the api string by 1, and define it like this #define obfuscated_apiname. now to call api, use something like this API(dll that contains the api, apiname)

Code

#include <string.h>
#include <stdlib.h>
#include <Windows.h>
#include <stdio.h>

typedef int (WINAPI *typeMessageBoxA)(
    HWND   hWnd,
    LPCSTR lpText,
    LPCSTR lpCaption,
    UINT   uType
    );
#define obfuscated_MessageBoxA "NfttbhfCpyB"


char* deob(char* str)
{
    char* mystr = (char*)malloc(strlen(str) +1);
    strcpy(mystr, str);

    for(int i = 0; mystr[i];)
        --mystr[i++];

    return mystr;
}
#define API(DLL, FUNC) ((type##FUNC)GetProcAddress(LoadLibraryA(#DLL), deob(obfuscated_##FUNC)))


int main()
{
    API(user32, MessageBoxA)(NULL, "putain d'merde", 0, 0);

}

[HFDone]

you have 3 MessageBoxA != obfuscate api calls

[myselfandi]

you have 3 MessageBoxA != obfuscate api calls

Not sure what you mean by that.

[0xDEAD10CC]

So basically an inefficient -ROT1 algorithm for a string that feeds GetProcAddress? > 🤨 Not terribly useful.

[myselfandi]

So basically an inefficient -ROT1 algorithm for a string that feeds GetProcAddress? > 🤨 Not terribly useful.

You are about right. In production code it would more convenient to hash the api strings then walk the export table of dlls comparing each api to the hash. You can even go further and create a hash table that holds a hash and pointer the previously called apis , so you don't need do an O(n) look up for each api call that has been made. nevertheless the inefficient ro1 algorithm was very suitable for my 5 api calls.

[0xDEAD10CC]

This is still not terribly useful because in order for GetProcAddress() to do anything with the string, it must be the normal string - breakpoints are a very simple thing.. If you want to hide data from a hex editor, that can be done easily without any of this weird stuff.

[myselfandi]

This is still not terribly useful because in order for GetProcAddress() to do anything with the string, it must be the normal string - breakpoints are a very simple thing.. If you want to hide data from a hex editor, that can be done easily without any of this weird stuff.

Yes, i'm trying to hide data from a hex editor, and yes there are easier ways to do it, but i wanted to try something different :).

[Friedrich Nietzsche]

LoadLibrary + GetProcAddress is hardly good obfuscation.
You literally just have to hook GetProcAddress and you get exactly what API's the program is requesting.

Static wise, its ok though.

[YouthInAsia]

This is still not terribly useful because in order for GetProcAddress() to do anything with the string, it must be the normal string - breakpoints are a very simple thing.. If you want to hide data from a hex editor, that can be done easily without any of this weird stuff.

It works for static analysis I guess if you can't read basic assembly and see that a function is subtracting/adding 1 to the dereferenced pointer value. Otherwise it's not very useful.
But a lot of times defeating static analysis is useful and a harder encryption would be better.

[myselfandi]

LoadLibrary + GetProcAddress is hardly good obfuscation.
You literally just have to hook GetProcAddress and you get exactly what API's the program is requesting.

Static wise, its ok though.

I'm aware of that. for my purposes i wanted to just obfuscate the api function from the .data section, and by calling it dynamically i avoid it being included in the import table.
And about hooking GetProcAddress, I don't think its always worth it to walk the export table to get api addresses, because function that are used to manipulate other process memory are most likely to be hooked.