Your first thought might be to simply write a piece of code which loads the image and calls every address in a for loop with the desired arguments, then checks the result. It might also be thought of as a kind of reverse fuzzing, where we deliberately pass invalid arguments to every function in an application except for one – where the arguments have been pre-chosen to be valid – to distinguish it from the rest. This can be considered a kind of brute-force attack where the key space is the possible address range of code in the image. What if… we just call every address in the image until one of them spits out the expected result? You know the function arguments and return type, but the assembly code is extremely obfuscated and difficult to disassemble, trace or decompile. You want to find a function in an executable image. The technique I’m about to describe can be applied to any application which you know contains a specific function with particular arguments and return type, but don’t know where it is located in the binary file. At the very least, to perform this attack your life will definitely be easier if you have some kind of scripting language on hand. Well, sort of… far be it from me to troll my dear readers with a clickbait title, but there is an element of truth in this. Today, I thought we’d have a bit of fun and show you a novel and unorthodox alternative way to find any function with known discrete inputs and an assumption about the possible outputs in a compiled application – specifically for this example, a decryption function in a game.
0 kommentar(er)
