Does anyone know where I can find documentation about the output of windbg command !ddls? I'm mostly interested in the meaning of the Flags and LoadCount parameters, and what does it mean when the value of LoadCount is 0xffffffff.
I spent a day searching for this information on the NET, but didn't find anything useful.
Thanks in advance,
Andre
This link should help - Is 0x0000ffff the default load count of a dll in windows?
Snip from the same The load count for a DLL is a 16-bit value. If that value, treated as a signed short, is -1 (0xfffff) it indicates the DLL is statically linked, otherwise it's dynamically loaded.
Related
I am working on making a pretty trivial change to an old existing pascal source file. I have the source code, but need to generate a new hex file with my changes.
First, I tried compiling with "Embedded Pascal", which is the program used by my predecessor. Unfortunately, it is an unregistered copy and gives the message that the file is too large for the unregistered version. Support for and even the homepage for the project has disappeared (old), so I have no idea how I would register.
I tried a couple other compilers, "Free Pascal" and "Turbo51", and they are both giving similar errors:
Filename.pas (79): Error 36: BEGIN expected.
Linkcode $2E
^
The source code begins with
Linkcode $2E
LinkData $0A // normally 8 - make room for capacitance data
Program Main; Vector LongJmp Startup_Vector; //This inserts the start to the main routine.
uses IntLib;
I'm not well-versed in Pascal or embedded programming, but as I understand it, the Linkcode and LinkData lines are required to set up the RAM as needed. Following the "Const" and "var" declarations are subroutines that indeed start with procedure... begin... end.
I realize that Pascal is a bit out of date, but we are stuck with it and our old micro. Any ideas why previously working source code with trivial changes cannot be compiled? I am willing to consider other compilers, including paid options, if any are available with decent support. I am using Windows 10 x64 processor to compile, and flashing to an Atmel 89C51RC2.
If more source code is needed for diagnosis, please let me know what in particular, as I'll need to change some proprietary information before posting. Thanks!
Statements like linkcode and linkdata are not general, but target and compiler specific. Unless you have the know-how to reengineer to a different compiler, getting the original one is best.
Thanks to all for the information. While I didn't find an exact solution here, your comments were helpful for me to understand just how compiler-specific the Pascal code was.
In the end, I was able to get into my predecessors files and transfer registration, solving the issue for now. As suggested, I think I will port to C in the future to avoid fighting all the unsupported compiler nonsense.
In c2 architecture specific file i see the above variable. Please share
1. what it is?
2. Whether does it has any relation to the run time constant pool.
Thank you.
An IR graph node that represents a base address of the compiled method's constants table in a machine-specific manner. This node actually does nothing on x86, since the architecture allows to reference the whole range of 32-bit or 64-bit addresses inline.
Generally, no. Though some constants from the constant pool (particularly, floating point) may appear in that table.
P.S. I guess HotSpot Compiler guys are too busy to browse StackOverflow :) The better place for asking C2 implementation-specific questions is hotspot-compiler-dev list.
I have got a PE executable file *.exe (32-bit), which is an small application (2.6Mb) to update firmware software of TV device. However, the update mechanism was only available up to 2013-03-12. I want to hack this executable just for pleasure. I'm trying to find this expiration date in file hexdump using PE Explorer, and replace it by some date in future to make this program work.
I found this article about binary date format:
binary date format
I am trying to find something like this value:
2013-03-xx: 0x713xxxxx
Is this a good approach to solve my task? Any suggestions? Do you know any others tools for hexdump that may be useful?
Best regard,
WP
There are likely a lot of values of the form 0x713xxxxx -- 2.6 MB might be larger than you've thought when you start looking through it more or less at random (you don't actually know that the application uses this date format internally).
The conventional approach to deal with this sort of problem is to use a tool to step through the program, examining the code that is executing, until you find the point where the check occurs. Then simply disable the check so that it always fails -- by altering the date, or simply by altering the code.
A popular tool for stepping through code that you do not control is the Interactive Dissassembler, IDA. You can download a freeware version of it here: https://www.hex-rays.com/products/ida/support/download_freeware.shtml
It might be harder than you think to do what you want, but you'll almost certainly learn a lot by trying.
Be aware of the legal issues you may be getting yourself into by making modifications to someone else's binaries, particularly if you distribute them afterwards.
dumpbin is a good PE parser (but if I were you, I won't do such kind of time stamp hacks :))
I searched the internet but did not find a concrete answer that why decompilers are unable to produce original source code. I dint get a satisfactory answer. Somewhere it was written that it is similar to halting problem but dint tell how. So what is the theoretical and technical limitation of creating a decompiler which is perfect.
It is, quite simply, a many-to-one problem. For example, in C:
b++;
and
b+=1;
and
b = b + 1;
may all get compiled to the same set of operations once the compiler and optimizer are done. It reorders things, drops in-effective operations, and rewrites entire sections of code. By the time it is done, it has no idea what you wrote, just a pretty good idea what you intended to happen, at a raw-CPU (or vCPU) level.
It is even smart enough to remove variables that aren't needed:
{
a=5;
b=func();
c=a+b;
d=func2(c);
}
## gets rewritten as:
REGISTERA=func()
REGISTERA+=5
return(func2(REGISTERA))
For starters, the variable names are never preserved when your program is compiled. ...so the best it could possibly do would be to use meaningless variable names throughout your re-constituted program. Compiling is generally a one-way transformation - like a one-way hashing function. Like the hash, it may be possible to generate something else that could hash to the same value, but it's highly unlikely the decompiled program will be the exact same as your original.
Compilers throw out information; not all the information that is in the source code is in the compiled code. For example in compiled Java, you can't tell the difference between a parameterized and unparameterized generic type because the information is only used by the compiler; some annotations are only used at compile time and are not included in the compiled output. That doesn't mean you couldn't get some sort of source code by decompiling; it just wouldn't match nor would be as informative as the actual source code.
There is usually not a 1-to-1 correspondence between source code and compiled code. If an essentially infinite number of possible sources could result in the same object code (given unbounded variable name lengths, etc.), how is a decompiler to guess which one to spit out?
So I'm dealing with a fat binary, and I'm trying to find the method offset for frame [FOOClass abcdMethod].
Using otool I get the __text segment addr and offset. The only problem is that offset in decimal given in the output equals the starting address of the __text segment.
My question is. How can someone deduct the offset of the method in a 64bit environment?
otool or any Apple compiler tools accepts the argument -arch which specifies which part of the fat binary it'll look. See otool's man page, for example. nm might be useful, too.
But, why do you want to get the offset??? I guess you can ask what you want to do, which lead to this current question how you get the offset. Then people might come up with an easier way to achieve you originally wanted to do.