API Resolution Algorithm 2

I discussed in my last post how a variant of Bredolab typically resolves the API functions it needs. Basically, most malware embed an array of hash values, each corresponding to an API function, rather than storing plain API names. Then, a function is used to “resolve” hash values into the relevant API function addresses. A call to such a function looks like this (taken from actual malware):

Concretely, an array of API hashes table may look something like below (we added an “Equivalent API” column for comprehension, but of course it’s not present in the malware):

Commonly, at “encoding” time, the hash values are obtained by passing the API function names through a hash function. Then in Bredolab, resolving a hash value at run time is done by comparing it with the hashes of all the API function names in the target DLL file (which are computed on the fly by the same hash function), until a match is found.

During recent analysis, I encountered a slightly different algorithm.

The observed malware, an Oficla variant, had a list of ‘api codes’ that were obviously not plain API name hashes. Indeed, to resolve an api code into an api name, the malware did not just compare the api code to hashes of all possible “candidate” api names in the dll until it finds a match. Instead, for each candidate api, it hashed the name, combined it with the api code to resolve (following an algorithm involving several XOR operations) and then compared the result with a “magic number”, or “key”. This key is always 14c353e0.

If the combination result equals the key, then the api code is considered resolved into the candidate api (otherwise, the operation is repeated with the next api candidate).

The flowchart below sums up the whole process

Regarding the key, it may be a relevant number combination for the malware author. Perhaps a hash of his own name. Or somebody special to him. Or probably yet another random value.