I have two executables, both manually created by me, I shall call them 1.exe and 2.exe respectively. First of all, both the executables are compiled by MSVS 2010, using the Microsoft compiler. I want to type a message into 1.exe, and I want 1.exe to inject that message into 2.exe (possibly as some sort of parameter), so when I run 2.exe after 1.exe has injected the message, 2.exe will display that message.
NOTE - this is not for illicit use, both these executables were created by me.
The big thing for me is:
Where to place the message/instructions in 2.exe so they can be easily accessed by 2.exe
How will 2.exe actually FIND use these parameters (message).
I fully understand that I can't simply use C++ code as injection, it must be naked assembly which can be generated/translated by the compiler at runtime (correct me if I am wrong)
Some solutions I have been thinking of:
Create a standard function in 2.exe requiring parameters (eg displaying the messagebox), and simply inject these parameters (the message) into the function?
Make some sort of structure in 2.exe to hold the values that 1.exe will inject, if so how? Will I need to hardcode the offset at which to put these parameters into?
Note- I don't expect a spoonfeed, I want to understand this aspect of programming proficiently, I have read up the PE file format and have solid understanding of assembly (MASM assembler syntax), and am keen to learn alot more. Thank you for your time.
Very few programmers ever need to do this sort of thing. You could go your entire career without it. I last did it in about 1983.
If I remember correctly, I had 2.exe include an assembler module with something like this (I've forgotten the syntax):
.GLOBAL TARGET
TARGET DB 200h ; Reserve 512 bytes
1.exe would then open 2.exe, search the symbol table for the global symbol "TARGET", figure out where that was within the file, write the 512 bytes it wanted to, and save the file. This was for a licensing scheme.
The comment from https://stackoverflow.com/users/422797/igor-skochinsky reminded me that I did not use the symbol table on that occasion. That was a different OS. In this case, I did scan for a string.
From your description it sounds like passing a value on the command line is all you need.
The Win32 GetCommandLine() function will give you ther passed value that you can pass to MessageBox().
If it needs to be another running instance then another form of IPC like windows messages (WM_COPYDATA) will work.
Related
I have written a Fortran code for being compiled as a '*.DLL' file.
The program which reads that file is a Finite Elements Method software named Plaxis, I already achieved to generate the '*.DLL' file in Visual Studio and Plaxis recognizes my model but the model does not work fine.
I would like to evaluate all the variables involved in my code and the procedure that Plaxis is using to read them, but when I use commands like "write(*,*) 'variable'" Plaxis does not show me what I asked in the source code.
Probably you want to open a file and write to that for debug logging, because presumably Plaxis doesn't run with standard output connected to anything useful. Or maybe it would if you just ran Plaxis from a command line window?
It's not going to create a dialog box for you.
But anyway, another option would might be attach to Plaxis with a debugger, and set a breakpoint in a function in your DLL. Then you can single-step your code as called by Plaxis.
Or you can write your own test callers and write unit tests for your functions, making them easy to debug. This could work well if your function just gets an array + size as args.
If instead it passes some wrapped object that you need to call special functions to deal with, then maybe make another version of your function that does just take an array so you can call it from a simple test caller.
I have dumped a Windows SDK .lib file (kernel32.lib) with DUMPBIN, the output show me that there are two "versions" for every API name, for example:
_imp_ExitProcess#4
and
_ExitProcess#4
So, why there are two of the same with different name mangling? .
Let say i want to call ExitProcess from NASM, wich of them should i use when declare EXTERN?, mi practice shows me that i can call any of them but i don't know which one is the "correct" or the "prefered" to stick with it.
I think the _imp_ version is meant to be used with __declspec(dllimport) on Visual C++ compilers to prevent potential conflicts with code in the same module.
You're not supposed to use that fact explicitly in your code -- just use the original function, i.e. _ExitProcess#4.
I'm building a static binary out of several source files and libraries, and I want to control the order in which the functions are put into the resulting binary.
The background is, I have external code which is linked against offsets in this binary. Now if I change the source, all the offsets change because gcc may decide to order the functions differently, so I want to put the referenced functions at the beginning in a fixed order so their offsets stay unchanged...
I looked through ld's documentation but couldn't find anything about order of functions.
The only thing i found was -fno-toplevel-reorder which doesn't really help me.
There is really no clean and reliable way of forcing a function to a particular address (except for the entry function) or even forcing functions having a particular order (and if you could enforce the order that would still not mean that the addresses stay the same when the source is changed!).
The biggest problem that I see is that even if it may be possible to fix a function to some address, it will be sheer impossible to fix all of them to exactly the addresses that the already existing external program expects (assuming you cannot modify this program). If that actually worked, it would be total coincidence and sheer luck.
It might be almost easiest to provide trampolines at the addresses that the other program expects, and having the real functions (whereever they may be) pointed to by these. That would require your code to use a different base address, so the actual program code doesn't collide with the trampolines.
There are three things that almost work for giving functions fixed addresses:
You can place each function that isn't allowed to move in its proper section using __attribute__ ((section ("some name"))). Unluckily, .text always appears as the first section, so if anything in .text changes so the size is bumped over the 512 byte boundary, your offsets will change. By default (but see below) you can't get a section to start before .text.
The -falign-functions=n commandline option lets you align functions to a boundary. Normally this is something around 16 bytes. Now, you could choose a large value like for example 1024. That will waste an immense amount of space, but it will also make sure that as long as functions only change moderately, the addresses of the following functions will remain the same. Obviously it still does not prevent the compiler/linker from reordering entire blocks when it feels like it (though -fno-toplevel-reorder will prevent this at least partially).
If you are willing to write a custom linker script, you can assign a start address for each section. These are virtual memory addresses, not positions in the executable, but I assume the hard linking works with VMAs (based on the default image base) too. So that could kind of work, although with much trouble and not in a pretty way.
When writing your own linker script, you could also consider putting the functions that must not move into their own sections and moving these sections at the beginning of the executable (in front of .text), so changes in .text won't move your functions around.
Update:
The "gcc" tag suggests that you probably target *NIX, so again this is probably not going to help you, but... if you have the option to use COFF, dollar-sign sections might work (the info might be interesting for others, in any case).
I just stumbled across this today (emphasis mine):
The "$" character (dollar sign) has a special interpretation in section names in object files. When determining the image section that will contain the contents of an object section, the linker discards the "$" and all characters that follow it. Thus, an object section named .text$X actually contributes to the .text section in the image. However, the characters following the "$" determine the ordering of the contributions to the image section. All contributions with the same object-section name are allocated contiguously in the image, and the blocks of contributions are sorted in lexical order by object-section name. Therefore, everything in object files with section name .text$X ends up together, after the .text$W contributions and before the .text$Y contributions.
If the documentation does not lie (and if I'm not reading wrong), this means you should be able to pack all the functions that you want located in the front into one section .text$A, and everything else into .text$B, and it should do just that.
Build your code with -ffunction-sections -- this will place each function into its own section.
If you are using GNU-ld, the linker script gives you absolute control, but is a very platform-specific and somewhat painful solution.
A better solution might be to use the recent work on gold, which allows exactly the function ordering you are seeking.
A lot of it comes from the order the functions are in the file and the order the files are on the command line when you link.
Embed something in the code that your external code can find, a const structure with some ascii code and the address to functions perhaps, then no matter where the compiler puts the functions you can find them.
that or use the normal .dll or .so mechanisms, and not have to mess with it.
In my experience, gcc -O0 will fix the binary order of functions to match the order in the source code.
However as others have mentioned, even if the order is fixed, the offsets can change as you modify the source code or upgrade your toolchain.
Maybe asking the question betrays my lack of knowledge about the process, but then again, there's no better reason to ask!
Tracking these down can be frustrating because stack traces can help me know where to start looking but not which object was null.
What is going on under the hood here? Is it because the variable names aren't bundled in the executable?
.NET code built with full optimizations and no debug info: your local variable names are gone, some local variables may have been eliminated entirely.
.NET code built with full optimizations + PDB (or full debug): most local variable names preserved, some local variables may have been eliminated
No optimizations + no debug info: local variable names are gone.
And then we have to consider that whatever you're dealing with may not be in a local variable at all - it might have been the result of a previous function call, on which you're chaining a new function call.
Basically you answered your own question. When you're code is compiled it's transformed in intermediate language (IL). IL does not have variable names the way your code does, arguments to a method being called are pushed on to a stack before the method is called and the currents methods arguments and local variables are referred to by there position. I believe this is because this structure aids the JIT compiler generate code.
The pdb symbols file stores a mapping between the IL generated and your code. It is used to tell you which line in your code each method call in the call stack refers to. Possibly the information stored here isn't detailed enough to say which variable is null, or possibly it was just considered too expensive in terms when of perf to be able to do this. In any case, if you have allowed the compiler to optimize the IL generated there may no longer be a one to one mapping between the variables in the IL and the variables in your code.
Hope that helps,
Rob
There is no "object identifier". There's no way that .NET could say "the object with identifier xxxx is null".
You'll learn how to not make these mistakes, don't worry. Just break down your expressions into smaller pieces, and you'll find which objects you forgot to initialize. You'll learn to iniitialize them in that scenario, and after a while, that case won't happen again.
I have a dll that I need to make use of. I also have a program that makes calls to this dll to use it. I need to be able to use this dll in another program, however previous programmer did not leave any documentation or source code. Is there a way I can monitor what calls are made to this dll and what is passed?
You can't, in general. This is from the Dependency Walker FAQ:
Q: How do I view the parameter and
return types of a function?
A: For most functions, this
information is simply not present in
the module. The Windows' module file
format only provides a single text
string to identify each function.
There is no structured way to list the
number of parameters, the parameter
types, or the return type. However,
some languages do something called
function "decoration" or "mangling",
which is the process of encoding
information into the text string. For
example, a function like int Foo(int,
int) encoded with simple decoration
might be exported as _Foo#8. The 8
refers to the number of bytes used by
the parameters. If C++ decoration is
used, the function would be exported
as ?Foo##YGHHH#Z, which can be
directly decoded back to the
function's original prototype: int
Foo(int, int). Dependency Walker
supports C++ undecoration by using the
Undecorate C++ Functions Command.
Edit: One thing you could do, I think, is to get a disassembler and disassemble the DLL and/or the calling code, and work out from that the number and types of the arguments, and the return types. You wouldn't be able to find out the names of the arguments though.
You can hook the functions in the DLL you wish to monitor (if you know how many arguments they take)
You can use dumpbin (Which is part of the Visual Studio Professional or VC++ Express, or download the platform kit, or even use OpenWatcom C++) on the DLL to look for the 'exports' section, as an example:
dumpbin /all SimpleLib.dll | more
Output would be:
Section contains the following exports for SimpleLib.dll
00000000 characteristics
4A15B11F time date stamp Thu May 21 20:53:03 2009
0.00 version
1 ordinal base
2 number of functions
2 number of names
ordinal hint RVA name
1 0 00001010 fnSimpleLib
2 1 00001030 fnSimpleLib2
Look at the ordinals, there are the two functions exported...the only thing is to work out what parameters are used...
You can also use the PE Explorer to find this out for you. Working out the parameters is a bit tricky, you would need to disassemble the binary, and look for the function call at the offset in the file, then work out the parameters by looking at the 'SP', 'BP' registers.
Hope this helps,
Best regards,
Tom.