I have PE file that was made with 16bit delphi. I spent all day trying to use WriteProcessMemory() on this file. It doesn't work. I can't find adresses in cheat engine nor tsearch. Peid says that file is not valid PE, I guess thats because of 16 bits?
Do you have any ideas how to read these adresses ?
I can post exe if needed.
Delphi 16bit didn't make PE files. It made NE files... IOW, NE = "New Executable" and PE = "Portable Executable" NE files were introduced in Windows 32bit with the release of Windows NT 3.1 around '92 or '93.
It is not likely that you'll be able to read the memory of a running 16bit process from a 32bit process. This is because a 16bit application will run within a special subsystem that emulates the 16bit environment.
Related
Is it possible to open a 16-bit Windows executable, just to browse its resources? I want to use LoadLibraryEx with LOAD_LIBRARY_AS_IMAGE_RESOURCE | LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE, so there is no worry about incompatibility with 64-bit processor, but it is still rejected, saying that it must be a valid Win32 executable. What was the function used to load 16-bit executables then?
16-bit NE images cannot be loaded nor (directly) executed by 32-bit or 64-bit PE threads. You have to load such a file using ReadFile() or similar and dissect yourself. Despite that RC files are mostly compatible, 16-bit resources are completely differently organized than 32-bit resources. Most notably, there is no language subdirectory level.
Problem
I have a Windows application that we developed for in house use. Thanks to Windows Error Handling, the window stays open and I can easily generate a crash dump from the task manager.
I have used crash-dumps on linux through eclipse once before, but this is the first time on Windows.
Hardware
The server is Windows 2012, and my development machine is Windows 7.
Windbg
When I load the crash dump in Windbg, load my symbols, then choose to look at the call stack, the only listings are:
How can I see my application call stack specifically?
Looks like your applications is a 32Bit application and you used the 64Bit Taskmgr to generate a dump.
You should use ProcessExplorer instead, it cares about the bitness:
Process Explorer v15.3: It also creates dump files that match the
bitness of the target process
Or run the 32Bit Taskmgr from C:\Windows\SysWOW64 to generate the dump.
As already answered, you have taken a 64 bit dump of a 32 bit application. There are multiple options to take a 32 bit dump of a 32 bit application on 64 bit OS, just choose the one which is most comfortable to you.
If this is the only dump you have and there's hardly a chance to get a better dump, you can try !sw to switch to 32 bit mode:
0:014> !sw
Switched to 32bit mode
0:014:x86>
Note how the command prompt changed. IMHO the exact same effect can be achieved by .effmach
0:014> .effmach x86
Effective machine: x86 compatible (x86)
0:014:x86>
except that you specify the mode explicitly where the !sw command toggles between the two.
In case of a .NET application, none of these ever helped me, since SOS cannot work with dumps of incorrect bitness.
I am making a retro text adventure game in Turbo Pascal that will be played in MS-DOS, and I want it to be in the COM file format. I've looked it up and have found nothing on this subject. If you can help me that would be greatly appreciated.
Something other than that, whenever I try to run my program (compiled into EXE) from DosBox it can't run due to "This program cannot be run in DOS mode". Is this because I'm using Turbo Pascal 7 and need to downgrade? Thanks a lot of you can figure this out.
Set your TP7 to target dos, not windows. Note that you might have an Windows only TP product (also known as TPW)
COM files will still be out of your reach, but at least DOS exe files should run in dosbox. Keep in mind that COM files have a 64k limitation, and therefore are of limited interest.
Free Pascal is working on a DOS16-bit Dos compiler that can generate com files directly from (64-bit) Windows, and while it is working, it is not released yet.
Is it possible to convert a DOS Application to a Win32 Console Application? I have an old program I wrote a long time ago, lost the source to it and asked myself now if it's possible to convert the DOS Binary to an actual Windows Binary, which runs in Command Line Prompt?
This is not possible. The DOS program will attempt to use DOS system calls that do not exist under Windows. The program will need to be updated and rebuilt for Windows. You might have some success running the original program in a DOS emulator.
See other answers about running a DOS program under Windows.
To convert a DOS program to a Win32 console application, one would have to convert the 16-bit (8086) code within the DOS program to 32-bit (i386) code. This is a very hard task to do right, and probably that's why there is no converter readily available. (Alternatively, an emulator can run 16-bit code without conversion, see the other answers and comments.)
However, not all DOS programs contain 16-bit code, for example programs using DOS extenders built with the Watcom C/C++ compiler (or, equivalently, with OpenWatcom: owcc -bdos4g prog.c) contain only 32-bit code. Windows can run 32-bit code directly, but API calls (e.g. opening and reading a file, allocating memory, getting the current time, writing colorful text to the console) have to be converted from the DOS+DPMI API to the Win32 API. Such a conversion is technically possible and feasible (even on the final .exe file, without access to the source code), and it is much easier to do correctly than the conversion of 16-bit code to 32-bit code. However, I still don't know of a converter readily available.
Please also note that conversion graphics and audio code to the Win32 API is very hard, but that's out of scope in this question.
I am a newbie to Windows device drivers. My immediate task is to take an existing 32 bit minifilter driver and port it to 64 bit Windows. My development environment is Windows 7/64 bit, Visual Studio 2012 Ultimate, DDK 7600.16385.1, and SDK 7.1A. The install package is a setup.exe created with InstallShield 2013.
I've found some doc on porting drivers to 64 bit, but it's all about code issues. I haven't been able to find an idiot's guide covering step-by-step instructions for everything else you might have to change, so I decided to take the naive try-it-and-see-what-happens approach and just recompile for 64 bit, with the one exception to that being code signing since I did read somewhere that Win64 requires signed drivers.
The pre-existing build for the driver project used DDKBuild.cmd, and I have modified the properties for the Win64 platform to specify ../scripts/build.cmd -WNETAMD64 free $(OutDir) on the build command line. The compile and link are successful. I've modified the InstallShield project to pull in the signed 64 bit code file instead of the 32 bit code.
The installation appears to run successfully on a 64 bit system (Win2008 R2). There's a two line script that runs during the install:
rundll32.exe setupapi,InstallHinfSection DefaultInstall 132 .\xxxxxflt.inf
fltmc load xxxxxflt
The rest of our application is actually Java, which makes some JNI calls to a couple of DLLs, one of which calls FilterLoad(). (BTW, the JVM and the DLLs remain 32 bit, but my understanding is that 32 bit code should be able to load a 64 bit driver via FilterLoad(). Please correct me if I'm wrong.) The return from FilterLoad() was ERROR_FILE_NOT_FOUND, and that caused me to notice that, as stated above in the question, the xxxxxxflt.sys file had been copied into SysWOW64\drivers instead of System32\drivers.
I know this is wrong, because Win64 is oppositeland, so System32 is where 64 bit stuff should go and SysWOW64 is where 32 bit stuff should go. What I don't know is why it ended up there. Are there changes necessary in the .inf file in order to identify this as a 64 bit driver? Is there anything I might have to do in the InstallShield project to tell it to build a 64 bit installer or run scripts in a 64 bit engine? Does the script have to do something to force use of the 64 bit version of rundll32? Something else, perhaps?
I haven't seen this specific problem, but I've had issues with this type of "WOW64" thing before. It usually means there is something within your software that is 32-bit and is being run in that mode, so anything you do will end up in the a "Program Files (x86)" or "WOW64" type location. Here is what I think might be happening:
This could have something to do with the way you are calling rundll32.exe. See the following post:
rundll32.exe equivalent for 64-bit DLLs
It's possible that if your InstallSheild installation is creating a 32-bit executable then it is running in WOW mode already which means that it's probably choosing the rundll32.exe that is in the WOW directory, thus the reason your installation ends up there too.
You might look at modifying your script to call the specific one based on the platform, or see if you can change your InstallShield to run as a 64-bit application in non WOW64 mode.