blogs.conus.info

As to method of extracting all *that* information in Oracle RDBMS, about what function called what, and what arguments can be, and what golbal variables can be used, all that is really simple.
I use IDA for all disassembling work, and it can generate .asm file automatically.
Then, these .asm files can be parsed using regular expressions or anything similar.
Then, we just notice functions start, end, "push" and "call" instructions and so on.
We also need to parse all data statements.
We also need to know function arguments number. Well, we can notice "add esp, X" after each function call, but it is not robust method: often, C/C++ compilers can generate such code, where you'll see two or even three cdecl function calls and only one stack correcting "add esp, X". So wee need to find all possible calls to this functions and notice all stack correcting "add esp, X"-s, and notice where X was minimal: thus we can deduce real arguments number.
Of course, it is not working for printf-s, sprintf-s, and so on, so here we can deduce arguments number from printf string.
Oracle RDBMS is written completely in C (not even C++) and compiled by Intel C++ (greatest C compiler). Of course, I did not mean PL/SQL stuff, etc.
On contrary, latest versions of IBM DB2 is written in C++, with classes, yes.
So, this utility can be written using any scriptable language like Perl or Python.
I think, IDA can be not used, probably, simple objdump may be used instead.

I also used MediaWiki to store all that generated stuff. In it, we can use wiki feature "what links here" to see, which functions may raise some specific errors, and so on. This is really strange irony when we can understand that information about some really rare errors may help to find some useful.

While we parse .asm listings generated by IDA, one quick idea comes to mind: we can notice stack frame layout. Of course, we can sometimes deduce all local variable types: by looking on where these variables used and how. We can see sizes of all string buffers. And we can see all that sprintf-s where these buffers used. Then we can easily find them all, and see, which sprintf call can overwrite string buffer. Just a quick idea: it was not used by me, but I think, this approach can be used anywhere.
See also: Stack buffer overflow.

Here is also some kind of irony I stumbled on: Oracle functions which raise errors use setjmp/longjmp to return directly to OPI calls dispatcher. And sometimes we can overwrite some buffer, some stack frame, yes, but then error raising and that overwritten stack is just dropped.