> The real hackers will know that as soon as I found evidence of sqlite3_key_v2 in the Zyzzyva dylib file that getting the key was inevitable. I don’t actually

> The real hackers will know that as soon as I found evidence of sqlite3_key_v2 in the Zyzzyva dylib file that getting the key was inevitable. I don’t actually know the steps for removing debug symbols from compiled code off the top of my head, but I bet if this had been done, this would have made my job much, much harder. I'm not entirely sure about OS X, but at least on Linux, system-assisted dynamic linking (i.e. not mmap(PROT_EXEC)) requires that all required symbols are exposed so that relocation can be done in the original executable; in other words, the OS needs to know where the functions in the library are so that it can tell the program how to call them. Of course, you could obfuscate the function names, but then tracebacks wouldn't work properly and at that point you'd be better off just statically linking the whole program. Debug symbols are completely different; if you have those, you can simply do "frame variables" which shows the args with names. > Yesss. Time to get out the x86 assembly hats. You don't even really need to do that. Since you know the function signature, you can assume (since it is in a separate library) that the function uses the standard System V AMD64 ABI where "the first six integer or pointer arguments are passed in registers RDI, RSI, RDX, RCX, R8, and R9" [0], meaning that the pKey pointer is probably in RDX. I know that the author said that it was in RAX, but since that is caller-saved, there must have been some copying or processing done to it inside the function. [0] https://en.wikipedia.org/wiki/X86_calling_conventions#System_V_AMD64_ABI https://en.wikipedia.org/wiki/X86_calling_conventions#System...