executable files on windows have a .reloc section which stores information to rebase the image. But EXE built by lazarus doesn't have that. How I enable dynamic base on a lazarus project if I really need ASLR?
Use Editbin tool with /DYNAMICBASE or /HIGHENTROPYVA parameter to edit your executable .
Related
I am looking for a way to program for MIPS assembly using VS2013 - but there is no assembly type project.
Is there a way to do this and get the .s output files of MIPS so I can later run them on other machines, and if I can't do this on VS2013 than how do I program MIPS on Windows 7?
Thanks
The assembler used in visual studio is Microsoft assembler (MASM), and yes you can program assembly language on it.
select an "Empty Project" then configure the "Build Customizations" of the project to use MASM, after that add a new c++ source file and rename it to any name .asm
Here are the detailed steps:
http://kipirvine.com/asm/gettingStartedVS2013/index.htm
And as for assembling your code to run on MIPS, I guess you can't do that with MASM, because it's a x86 assembler,
here is a list of the supported processor types directives on masm
.386
.386P
.387
.486
.486P
.586
.586P
.686
.686P
.K3D
.MMX
.XMM
Refer to
https://msdn.microsoft.com/en-us/library/vstudio/8t163bt0%28v=vs.100%29.aspx
the processor section.
Nevertheless, there is an option in the project "Properties" > "Linker" > "advanced" that let you chose between different machines, including Mips, but I guess this will merely set the Machine Flag in the PE header to MIPS and when the assembler try to build your module it will find a conflict between the machine type flag and the code in the module. But I'm not sure If you can build codes for MIPS.
To run MIPS programs on Windows 7, you need some type of emulator and a corresponding tool set. In the case of ARM processors, there are emulators that include a source level debugger and tool sets, including compilers, assemblers, linkers, and binary image output utilities for embedded systems. There's also a debugger for embedded systems that is run from Windows and some type of connection to the embedded system. The tool set runs on Windows, but targets the emulator or an actual embedded system. I don't know if there's a equivalent tool set and emulator like this for the MIPS processor.
My application is using openssl (libeay32).
I've built the openssl myself and it is located somewhere.
This location is placed as the first location of 'PATH' value.
However I see the NSVC (2010) load the DLL from C:\Windows\SysWOW64 and not from the location I want. Why it is so? How can I fix it?
Thanks,
Rafi
Why it is so?
See Dynamic-Link Library Search Order.
How can I fix it?
Richter covers this in his book Programming Applications for Microsoft Windows. In general, use a .local file for DLL Redirection.
For the particular case of "Under the Debugger", see the Working Directory setting of the Visual Studio project at Project Settings for a C++ Debug Configuration.
I compiled the mupdf command line utilities on Windows8 with Visual Studio 2010 Professional with the included VS projects. They work. If I want to move them to another system (any Windows) is it enough to move the exe's?
You can move them as long as they are compiled in Release mode. If they are in Debug mode the target machine will need Debug VC libraries installed. Release libraries are usually present on all machines.
My guess is: yes. Provided that you don't move a 64bit-exe to a 32bit Windows. And provided you move any *.dll files which were compiled alongside the *.exe with them. -- Why don't you just try it?
I have a DLL file. How can I view the functions in that DLL?
For native code it's probably best to use Dependency Walker. It also possible to use dumpbin command line utility that comes with Visual Studio.
Use the free DLL Export Viewer, it is very easy to use.
You may try the Object Browser in Visual Studio.
Select Edit Custom Component Set. From there, you can choose from a variety of .NET, COM or project libraries or just import external DLLs via Browse.
Use dumpbin command-line.
dumpbin /IMPORTS <path-to-file> should provide the function imported into that DLL.
dumpbin /EXPORTS <path-to-file> should provide the functions it exports.
For .NET DLLs you can use ildasm
Use dotPeek by JetBrains.
https://www.jetbrains.com/decompiler/
dotPeek is a free tool based on ReSharper. It can reliably decompile
any .NET assembly into C# or IL code.
Without telling us what language this DLL/assembly is from, we can only guess.
So how about .NET Reflector.
If a DLL is written in one of the .NET languages and if you only want to view what functions, there is a reference to this DLL in the project.
Then doubleclick the DLL in the references folder and then you will see what functions it has in the OBJECT EXPLORER window.
If you would like to view the source code of that DLL file you can use a decompiler application such as .NET reflector.
For non .NET dlls, installing binutils on a Linux system presents the objdump command that can be used to display information of a dll.
objdump --private-headers <file.dll>
Look for the Export Address Table section in the output.
.NET ildasm
ildasm helped and even dumped methods body, but to edit .DLL you also need any hex editor.
ildasm example to fix Help Viewer v2.x issue:
error: "An error occurred while updating content: File '???.cab' was not signed by Microsoft"
here could be image
more example files
I need to create a basic app to check the availability of components and if necessary download them to any computer running Windows XP or above. Which language (preferably free or VS 2010) should I use to create such an application which can run without requiring any frameworks installed beforehand?
could you please elaborate? By static library, do you mean a dll that should reside alongside the exe? or do you refer to available dlls in windows/system32? Also, will programs compiled using this method require the 'Visual C++ Redistributable'?
When C++ executable links to a static library, then the linker includes the library's object code in the same file as the EXE. The result is a single *.exe file, and the library does not need to be shipped as a separate *.dll.
The DLLs in windows/system32 are typically O/S files. They're O/S-specific. You may/must/do not ship/redistribute these files (Microsoft does). Your EXE (or e.g. the C run-time library to which you have statically linked) depends on (requires) some of the functions which are exported from these DLLs. These O/S DLLs tend to be backward-comptible, so that if you target the O/S API which exists on XP, your code will also run on Vista.
I'm guessing that by 'Visual C++ Redistributable' you mean "the Visual C run-time library", whose DLL filename is something like msvcrt80.dll. This is what I talked about in my first paragraph: if you choose the build option (available under project/properties) to statically link to the C run-time library, then the code you require is statically linked into your EXE and you don't require (don't run-time link to) this DLL.
Visual C++ 6 with MFC. If you use a later version of Visual C++ then your Windows XP targets will need libraries for them.
Edit: Comments pointed out that the CRT and MFC library can be linked staticly even in later versions. That is right and I forgot.
While not specifically designed for this, I recommend InnoSetup for setup bootstrappers. It doesn't require any libraries, provides functionality for common setup requirements and has PascalScript to extend it. There are a lot of plugins available, and you can do anything left with a custom script (basically like Delphi). PascalScript can import API functions, so you can really do anything. With InnoCallback, you can even get callbacks from the API - I used this to bootstrap a lot of MSI setups into a single package using the MSI API.
If you download it, get the QuickStart Pack, which includes a good editor and the InnoSetup preprocessor.