Im trying to get a hold of the symbol tables for object files. Does anyone know an application which provides this functionality?
Thank you!
Does anyone know an application which provides this functionality?
The usual UNIX application for looking at the symbol table is nm. If you are on an ELF platform, readelf -Ws foo.o.
If you are on Windows, use dumpbin /symbols.
Related
How can I read the icons from a DLL or an EXE file, using C++ (and Qt) ?
I can't find anything relevant on google, I only get how to change application icon using qt, which is not what I need.
If I understand what you're trying to do, this should be possible through the general LoadResource function or the specific LoadIcon function. An example of the former can be found here.
You would create a handle to the exe or DLL using LoadLibrary, which you subsequently use as an argument in the LoadResource or LoadIcon function.
I don't know of any Qt functions providing similar options, but perhaps others do.
Is it possible to decompile a Mac kernel extension?
In theory it is possible to decompile any binary code.
Kernel extensions are a little bit tricky because
a) they're C++, so virtual methods make the code harder to follow.
b) linking happens differently in kernel extensions, so any decompiler would need be specially designed to handle kernel extensions in order to find dependencies and symbol names.
you can use gdb (as nate c suggested) to inspect the assembly code of a kernel extension. i'm not aware of any decompilers for kernel extensions specifically.
you can use the kextload tool to create a symbols file that you can load into gdb. this will let you see decoded symbol names for functions, &c. there's a crash (haha get it?) tutorial here: http://praveenmatanam.wordpress.com/2008/05/22/kext-debugging-on-mac/
why do you want to do this?
It is no problem to decompile 32bit kext's using the hexrays decompiler.
Decompiling c++ code, means you have to define your structs in the right way: when an object has virtual methods, the first item in the object will be a pointer to the object's vtable.
if you declare the vtable in IDA or hexrays as well, and make sure all the types of the function pointers are correct, hexrays will produce quite readable code.
But chances are that the parts of the kext you are interested in were written in C-like C++, and you don't need to worry about that at all.
For reversing 64-bit kexts, acquire ida pro and x64 Decompiler (any of mac/lin/win).
Also, you can usually debug a kext (without symbols) using lldb remote setup. (gdb is gone.)
If you happen to work for a large security shop, do the song-and-dance: sign an NDA, give rights to first born and just get the OSX source.
Also, here's a large list of decompilers:
https://en.wikibooks.org/wiki/X86_Disassembly/Disassemblers_and_Decompilers
I have a third party static library that was built on AIX with gcc. When I try to link to that library using the xlC AIX compiler I get all sorts of unresolved symbols. I believe it is due to the differences in name mangling. If I get the manged names out of the library with the nm command is there anything fundamentally wrong with building the binary with the xlC compiler provided it can find the symbols it is looking for? What troubles am I asking for?
This will very likely not work; see the C++ Faq Lite question about this.
C++ is a lot more complicated than C, and there's a lot of additional things that might not be compatible.
For a few examples, is the exception handling compatible? Are data objects laid out in the same way (in C, the order is as listed, but in C++ it can vary with access specifiers)? Do the vtables work the same? How is dynamic_cast handled?
The difference in name mangling is stopping you from linking, but there are many other differences that can bite you.
You're probably better off using the version of gcc they did. That's what I had to do in a similar project once.
I was just wondering if it is possible to replace Loader (executable program loader not the boot loader) of an Operating System (Windows is my choice). Are there any third party loaders available that would patch the default one.
Is there any way through which I can obtain the control over the OS Loader? I mean, I want things it is doing to be visible to me(each and every step).
If you ask me why I want to do this, For learning purposes.
No, process creation and the user-mode loader in ntdll are tied together (PsCreateProcess will directly map in ntdll and jump to it so that it can finish resolving modules and setting up the process), you cannot replace it.
If you want to play with this sort of thing then Linux is the way to go.
The loader is part of the kernel, but as you have access to all the kernel source you can play with it to your hearts content.
Linux has pluggable executable file formats, so it is possible to add an extra program loader which will do its own custom stuff with executable files, rather than the standard ones (ELF, shell scripts, binfmt_misc).
The binfmt_misc module allows you to write custom loaders for executable programs entirely in userspace; this is commonly used to execute non-native binaries or interpreted binaries such as Java, CLR executables etc.
On the other hand if you wanted to replace the ELF loader with something else you can make a binfmt module directly in the kernel. Look at fs/binfmt_* for examples. The ELF loader itself is in there.
Since each of the answers & comments is giving useful information. I just compiled, all the answers & comments into a single post.
I was just wondering if it is possible
to replace Loader (executable program
loader not the boot loader) of an
Operating System (Windows is my
choice).
No, in windows process creation and the user-mode loader in ntdll are tied together (PsCreateProcess will directly map in ntdll and jump to it so that it can finish resolving modules and setting up the process), you cannot replace it.
but there are resources availbable describing the format and loading of processes.
Here is a quite old but still uptodate MSDN article regarding PE files ( exe + dll )
Part I. An In-Depth Look into the Win32 Portable Executable File
Format by Matt Pietrek (MSDN
Magazine, February 2002)
Part II. An In-Depth Look into the Win32 Portable Executable File
Format by Matt Pietrek (MSDN
Magazine, March 2002)
You can use this information to write an app that starts a given executable.
If you are more interested in linux and the elf format you will find all you need in google.
Is there any way through which I can
obtain the control over the OS Loader?
I mean, I want things it is doing to
be visible to me(each and every step).
On Windows, you can get some visibility into the loader at work by enabling Loader Snaps. You do this with gflags.exe (part of Debugging Tools for Windows). There's a nice gflags.exe reference http://www.osronline.com/DDKx/ddtools/gflags_4n77.htm . With Show Loader Snaps enabled, you can see loader trace messages by starting the application under a debugger (WinDBG).
If you want to play with this sort of thing then Linux is the best way to go.
The loader is part of the kernal -- but as you have access to all the kernal source you can play with it to your hearts content.
The loaders for various binary formats are in fs/binfmt_*.c in the Linux source (fs/binfmt_elf.c is the loader used for executables in ELF format - ie. the vast majority).
The dynamic loader /lib{,64}/ld-linux.so.2 is also used for dynamically linked binaries - it's an example of an "interpreter" as referenced by the code in binfmt_elf.c.
Linux has pluggable executable file formats, so it is possible to add an extra program loader which will do its own custom stuff with executable files, rather than the standard ones (ELF, shell scripts, binfmt_misc).
The binfmt_misc module allows you to write custom loaders for executable programs entirely in userspace; this is commonly used to execute non-native binaries or interpreted binaries such as Java, CLR executables etc.
On the other hand if you wanted to replace the ELF loader with something else you can make a binfmt module directly in the kernel. Look at fs/binfmt_* for examples. The ELF loader itself is in there.
No, you cannot replace the OS loader, but there are resources availbable describing the format and loading of processes.
Here is a quite old but still uptodate MSDN article regarding PE files ( exe + dll ) http://msdn.microsoft.com/en-us/magazine/cc301805.aspx
You can use this information to write an app that starts a given executable.
If you are more interested in linux and the elf format you will find all you need in google.
Is there any way through which I can obtain the control over the OS Loader? I mean, I want things it is doing to be visible to me(each and every step).
On Windows, you can get some visibility into the loader at work by enabling Loader Snaps. You do this with gflags.exe (part of Debugging Tools for Windows). There's a nice gflags.exe reference here. With Show Loader Snaps enabled, you can see loader trace messages by starting the application under a debugger (WinDBG).
I've scoured Google and found to large a variety of tools and answers. I want to disassemble a DLL into something at least readable, e.g. recognise Win32 API calls by their names etc. How do I go about this?
Check out THIS. Any of them can work for you but IDA rocks...
I think what you're looking for are the Windows Symbol Packages. When you install these, you're basically getting symbol information (debugging info) for the majority of the Windows API, including Kernel32 and advapi (which I find to be the two biggies in my programming).
You might need to tell your debugger and/or compiler where the symbols live though - just make sure you remember where they install to, then you can use a debugger option (sometimes called "sympath") to tell the debugger where to find them.