I have a .exe file and i want to list all function of it. It is possible and have some tool to do it?
P/s: i tried with IDA but it is difficult to understand it. Can it resolve my problem?.
To achieve this, you must have a very good understanding of Assembly Language, and maybe learning from NASM documentation and the Intel Instruction set will get you to a good level. Before you can continue in this path.
Furthermore, for those who already know little or more Assembly Language, is possible to call the function of an exe, mostly if they are standalone or doesn't depend on any other functions using something like Asmjit. And also you can get this function addresses, and cast them into functions if you know the calling convention used here. For example, __stdcall, __cdecl and others. And if then you know the calling convention, you can use this to construct the function signature, including the return type, usually through the POP, RETURN instruction or the registry that was affected before the function exit, or return to the caller.
You have to find a good debugger, to help you find all this. As you said IDA is good but too complicated, so you can use something like x86dbg, or others like ollyDbg those can help you find the entry point of those functions and use that to construct the signature
so a core like this, assuming that 0x749593 is an address of a a function with maybe takes two argument and return sum.
typedef int (*sum)(int first, int second);
Sum mySumFunc;
Changing the address of mySumFunc to point to 0x749593, you can call this function mySumFunc(arg1, arg2 ) and it will still work.
Related
I am attempting to update a piece of fortran code that makes a calculation based on inputs from an IDL routine. When the IDL routine makes a call to fortran, it passes along the reference for each variable (IDL CALL_EXTERNAL documentation). The fortran code currently attempts to pass along each reference in the input array to a different subroutine along with the %VAL() tags.
subroutine full_calc(argc, argv)
implicit none
integer*8 :: argc
integer*8, dimension(24) :: argv
call map_gen(%VAL(argv(1)), %VAL(argv(2)), ...)
end subroutine full_calc
This worked fine with the previous code, as it was compiled in such a way as for this to be useful; however, the new compiler gives a warning that I am passing an INTEGER(8) instead of the correct type of the variables. Also, according to this, using %VAL is somewhat dubious.
If this might cause problems, what can I use to get at the values that won't throw warnings everywhere, doesn't require me to have a routine simply for passing along the references, or will at least work on any compiler?
Also, if anyone can just clarify what is really going on here or why, I would appreciate that too.
In Data.Map there are some functions like merge, glue, that I want to use but the compiler says they're not in scope. I notice at the top they are listed here:
#if defined(TESTING)
-- * Internals
, bin
, balanced
, join
, merge
#endif
I think this means I can't use them directly unless I've somehow defined TESTING but I've no clue how to do that and where. Please answer as if I'm retarded; don't assume I know you mean to type something in the command line instead of typing it in the program.
I'm on Windows XP and using GHCi if it matters.
You can't. These functions are only meant to be used by the library's internal tests. TESTING is determined at compile-time, so you couldn't change it even if you wanted to.
The internal tree structure of the map shouldn't be relevant to someone using the code, so it's difficult to say what would be a better solution without some concrete information about what you're trying to do.
I want to make a function called 'load' which imports definitions of functions from another file. I know how to import modules, but in my program I want the definitions of the functions to change depending on which module is 'loaded' with this new function. Is there a way to do this? Is there a better way to write my program so that this is not necessary?
I think it's type signature would look something like:
load :: String -> IO ()
where the string is the name of the module to be loaded (and the module is in the same directory).
Edit: Thanks for all the replies. Most people agree that this is not the best way to do what I want. Instead, is there a way to declare a global variable from within an I/O program. That is, I want it so that if I type (function "thing") into a function of type String -> IO(), I can still type 'thing' into GHCi to get the value assigned to it... Any suggestions?
There is almost certainly a better way to write your program so that this is not necessary. It's hard to say what without knowing more details about your situation, though. You could, for instance, represent the generic interface each module implements as a data-type, and have each module export a value of that type with the implementation.
Basically, the set of loaded modules is a static, compile-time property, so it makes no sense to want your program's behaviour to change based on its contents. Are you trying to write a library? Your users probably won't appreciate it doing such evil magic to their import lists :) (And it probably isn't possible without Template Haskell in that case, anyway.)
The exception is if you're trying to implement a Haskell tool (e.g. REPL, IDE, etc.) or trying to do plugins; i.e. dynamically-loaded modules of Haskell source code to integrate into your Haskell program. The first thing to try for those should be hint, but you may find you need something more advanced; in that case, the GHC API is probably your best bet. plugins used to be the de-facto standard in this area, but it doesn't seem to compile with GHC 7; you might want to check out direct-plugins, a simplified implementation of a similar interface that does.
mueval might be relevant; it's designed for executing short (one-line) snippets of Haskell code in a safe sandbox, as used by lambdabot.
Unless you're building a Haskell IDE or something like that, you most likely don't need this (^1).
But, in the case you do, there is always the hint-package, which allows you to embed a haskell interpreter into your program. This allows you to both load haskell modules and to convert strings into haskell values at runtime. There is a nice example of how to use it here
^1: If you're looking for a way to make things polymorphic, i.e. changing some, but not all definitions of in your code, you're probably looking for typeclasses.
With regards to your edit, perhaps you might be interested in IORef.
I don't have the source code but have the binary. With command "nm binary_name" I could know the functions inside the binary.
Can I know how many parameters a function has? Under solaris, is there anyway to do that?
e.g, if the function is: func1(a int,b int,c int), then there are 3 parameters.
Thanks
Daniel
No. Neil Butterworth's suggestion to examine the function signature is a good one for C++ (since the parameters are often encoded into the function so the linker can tell the difference between "int x(int)" and "int x(float)" for example) but, for C, you're going to have to get your hands dirty and disassemble the function, taking particular note of how the stack frames are built and used in your environment.
Keep in mind that SPARC has a rotating window stack rather than regular grow-down stack. You're really going to delve deep into the way the CPU works. If you're talking Solaris for Intel, the rotating stack is not there, of course.
Assuming this is C code, then no there is not - the
compiler/linker elides that information. If it is C++ code, it is just possible that the mangled name of the function is retained and includes the parameters in encoded form.
At the lowest level, if you emulate the function running on the machine, then it will read some information either from registers or the stack which it has not written. If you compare these reads to the ABI of the platform ( You don't say whether it's Sparc Solaris or Intel Solaris ) then some of them should correspond to the registers/stack locations of the parameters of the function. Of course, there's no guarantee that a function will read all its parameters.
For Solaris, elfdump might give more information than nm ( a quick google for elfdump signature indicates support was requested and added, but you'd need to check what version you've got )
IDA Pro (http://www.hex-rays.com/idapro/) is a disassembler which is pretty clever at infering parameters of a function from object code;
maybe there is also symbolic information you can use; eg. on Win32 the symbol _function#8 reveals that 8 bytes (2 parameters) are passed
one can also demangle C++ names to get the parameters and types
I recently took in a small MCF C++ application, which is obviously in a working state. To get started I'm running PC-Lint over the code, and lint is complaining that CStringT's are being passed to Format. Opinion on the internet seems to be divided. Some say that CSting is designed to handle this use case without error, but others (and an MSDN article) say that it should always be cast when passed to a variable argument function. Can Stackoverflow come to any consensus on the issue?
CString has been carefully designed to be passed as part of a variable argument list, so it is safe to use it that way. And you can be fairly sure that Microsoft will take care not to break this particular behavior. So I'd say you are safe to continue using it that way, if you want to.
That said, personally I'd prefer the cast. It is not common behavior that string classes behave that way (e.g. std::string does not) and for mental consistency it may be better to just do it the "safe" way.
P.S.: See this thread for implementation details and further notes on how to cast.