Is there any way for SymInitialize and SymFromAddr methods to automatically load symbols from a custom symbol store. I'm trying to resolve an address to a readable function name using SymFromAddr(). It seems to work fine if I have symbols for the given module stored locally, however I'd like it to automatically download them from the path given to SymInitialize, just like WinDbg does it.
I call SymInitialize like that:
SymInitialize(procHandle, "SRV*c:\\symbols*http://msdl.microsoft.com/download/symbols;http://mycustomstore.com/symbols", TRUE);
SymFromAddr returns error 487 "Attempt to access invalid address." as it can't find the symbol since it has never even attempted to download it.
Is there any way to force download them?
As it turned out dbghelp.dll needs symsrv.dll in order to load symbols. It was struggling to find it, so needed a bit of help.
I've used dbghelp logging to help track down the issue https://msdn.microsoft.com/en-us/library/ms680687.aspx
If you want to use a HTTP symbol store, you define it with
.sympath SRV*c:\mysymbols*http://example.com/symbols
To add the Microsoft symbol path, use
.symfix+ c:\microsoftsymbols
Looking at the WinDbg symbol path now gives you:
0:000> .sympath
srv*c:\mysymbols*http://example.com/symbols;SRV*c:\microsoftsymbols*http://msdl.microsoft.com/download/symbols
which tells us that your symbol path was not correct, since it didn't have the second SRV*...* part but just http://.... If you copy/paste the symbol path from your code to WinDbg, it probably wouldn't work as well.
Related
I was trying to insert an unknown module.
which in turn throws error saying, module can not be inserted
seems it found an unknown symbol.
I have a better access to whole source tree.
need clues, how can I start debugging over it.
In fact, I have never done with any module debugging.
Thanks.
Your module's dependencies are probably not being met. It seems it needs a symbol which isn't available in your currently running kernel.
Check that the symbol it needs is in your System.map file for starters.
Instead of insmod, you should use modprobe, which automatically loads module dependencies.
I'm using DLL injection in a video game for the purpose of modding (I'm building a game API).
I want to directly access structures and variables in the EXE from my new DLL. The absolute addresses of variables are known (the EXE has a fixed image base) .
According the GNU ld documentation, I can use --defsym=symbol=expression to create a global symbol in the output file, containing the absolute address given by expression.
I can't get it to work.
If I declare the symbols as extern in my code, and use ld --defsym, I get undefined reference errors. But if I define the symbols in my code, it just uses the local (DLL) versions, not the EXE ones.
It seems the --defsym options are having no effect. Any insights would be greatly appreciated.
Update: --defsym works perfectly under Linux. When I try compiling on Windows using mingw, I get undefined reference errors.
I've figured out the problem.
After inspecting the assembly produced by mingw, I found the C symbol names are being prefixed by an underscore. This happens on Windows, but not on Linux.
There is a gcc option -fno-leading-underscore, but this results in an undefined reference to WinMain.
Simply adding leading underscores to the symbol names works.
Example: if my my symbol is named alien in C, using gcc --defsym=_alien=0x500000 works fine.
i am having an error as duplicate symbol _winsocks in /users/..../xxx.o and /users/..../yyy.o
can any one tell me how to avoid this error in XCODE.
I don't know about XCODE specifically, but this sort of error means that both object files define the the __winsocks symbol (which means they were compiled with something (maybe a header file) that defines this. If you can provide the compile/link instructions for each of them, then maybe we can give you more help.
My application loads a DLL using LoadLibrary() suppressing the standard critical-error-handler message box. When LoadLibrary() fails and GetLastError() returns ERROR_MOD_NOT_FOUND (0x7E) I'd like to retrieve the missing DLL name. This error code is set not only when the requested DLL is missing, but also when any DLL it depends on is missing.
It's worth noting that the standard message box (which is suppressed) displays the correct missing DLL name, and the question is how can I get it within the code.
Thanks
I'm not sure there's an easy way of getting the missing DLL's name. But you can probably find it by stepping through LoadLibrary() in the debugger and seeing which function fails with what filename in the parameters. depends.exe can also show the dependencies.
Also, it might worth a try firing up the process monitor and using appropriate filters see what I/O errors there are in your process and for what files.
If you're calling LoadLibrary with a DLL name, shouldn't you already know the name?
You could always try hooking LoadLibrary if this isn't the case.
When I attempt to use SecPKCS12Import() from the Security framework as provided by Mac OS X 10.6, the result code is always errSecUnimplemented, regardless of the arguments provided.
Furthermore, the linker is unable to find symbols for the constants relevant to this function declared in SecImportExport.h (i.e. kSecImportExportPassphrase, kSecImportItemIdentity, et al.).
What on Earth is going on with this library -- is the function implemented or is it not? Why can the linker resolve all other symbols in the framework, but not these? How should I convert a PKCS12-formatted binary blob to a SecIdentityRef or SecCertificateRef and SecKeyRef pair?
What am I doing wrong? I'm sure this is a PEBKAC issue. :-)
EDIT: I see that I was very unclear in my question. I'm aware that Security.framework is implemented, given that I am able to use the other functionality it provides without an issue. Given this, I'm fairly certain that I'm linking against the framework correctly, since if I remove the link, none of the symbols can be found -- as expected. When I relink the framework, all the symbols are found, with the exception of the constants relevant to SecPKCS12Import(), e.g. kSecImportExportPassphrase, kSecImportItemIdentity, etc.
Given that I cannot use these symbols, I passed in what could have been incorrect strings (#"kSecImportItemIdentity", etc.), but the error code returned was errSecUnimplemented. This led me to believe that perhaps this specific functionality has not been implemented.
I tried using the 10.5 SDK, but that didn't work, of course. :-)
EDIT: My import is just a regular #import <Security/Security.h>. For kicks, I tried #import <Security/SecImportExport.h> as well, but this effected no change. That said, the error is issued by the linker, not the compiler.
I ran dyldinfo -export Security.framework/Security to list the symbols exported by the library and found many of the new symbols, but kSecImportExportPassphrase and friends were conspicuously missing. This might explain why the linker cannot find the symbols. The symbol for SecPKCS12Import appears in the symbol table and I can call that with no issues, it's just the functionality does not seem to be there.
Security.framework is most certainly implemented — see the Security Reference Update which documents what has changed in the framework in 10.6 and prior. Since you know the headers to use, I assume you've already consulted the Security Framework Reference.
Are you sure you're properly importing and linking against the framework? (It's in /System/Library/Security.framework, so you shouldn't have to specify the path.)
Does the compiler issue warnings or errors stating that the symbols in SecImportExport.h are undefined? (If not, how do you know they're "declared but undefined"?)
When you say that this fails on 10.6, have you tried it on an earlier version of the OS successfully?
EDIT: Okay, since you're using other parts of Security.framework successfully, and the APIs and constants you're trying to use are 10.6 only, it doesn't seem like a linking issue. What do your import look like? Are you sure you're importing SecImportExport.h properly? The constants are declared just above the SecPKCS12Import() function, so if you get warnings for the constants, you should get one for the function being undefined as well.
EDIT: I have confirmed with a member of the team at Apple that works on Security.framework that this functionality is not currently implemented. Please file a bug to gripe about this at http://bugreport.apple.com against component Security (New Bugs), version X. Include the URL to this question in your report. Sorry there's not a better answer at the moment.
To my knowledge, Apple is great at partially implementing things or leaving no documentation. If you really can't find the real implementation you need, you can use OpenSSL to extract the blobs and then Security services to import them to a keychain or further process with Security/CDSA methods. That would get you going and you can ping the Apple dev connection with further questions, if you have the possibility.
Further, looking at /System/Library/Frameworks/Security.framework/Headers/SecImportExport.h on my 10.6.2 machine, I see references to PKCS#12 in the documentation of SecKeychainItemImport()
Search that file for "PKCS12" for further information.