recently I stumbled upon a strange phenomenon.
I am building a dumper for PE-files, reading along the section header and "optional" section header quite well. Now, when I reach the fields "OS major" and "OS minor", I notice a strange value.
[WORD] OS VERSION major :0x00000006
[WORD] OS VERSION minor :0x00000000
Apparently this would mean Windows Vista....
Here: https://learn.microsoft.com/de-de/windows/win32/sysinfo/operating-system-version?redirectedfrom=MSDN
I wrote a simple hello-world 32bit executable, and also tested with 7zip.exe (where it, for some reason, was 4.0 [==Win98]).
Now I am confused.... How can my freshly written PE-file (Visual Studio 2019) NOT be of OS version 10???
Did Microsoft maybe, because of lazyness, not update their Linker correctly???
On that page it says something about a manifest file, but only that it would tell you Windows 8.0 if you'd not manifest your executable (however I am supposed to do that, doesn't really matter for the question tho).
Question: Is there a way to read the correct OS-version from a binary?
As it turned out, it seems like this number is more of a
"Required Minimum Opreating system",
that would explain why it is windows Vista.
Related
This question already has answers here:
How to detect true Windows version?
(9 answers)
Closed 7 years ago.
It appears that the version info functions in the Win32 API that I know and love have changed their behavior. GetVersionEx now return what the program's manifest is set for, not the actual version.
The new function IsWindows10OrGreater seems pointless since it is only available on windows 10 or greater, so if the program includes it and successfully links it will always return TRUE.
But, in an installer or similar program, how does it determine whether the current environment really is Windows 10 or greater? It needs this to know what to download or which options to set up for other programs.
Your premise is false. The IsWindows10OrGreater function is a macro, so provided you are using a suitably recent version of the SDK the compiled program will work on all currently supported versions of Windows. (As well as Windows XP and I think even Windows 2000.)
(Of course, this mistake is understandable, since the documentation is wrong.)
Note that the program's manifest must still indicate that it supports Windows 10 in order for the macro to work.
Questions like this one involve issues caused by not setting the proper subsystem version in the PE header. I can do that with /SUBSYSTEM on Visual C++ and -Wl,--(major/minor)-subsystem-version on gcc.
But I noticed there is also an OS version field in the PE header. This is set by -Wl,--(major/minor)-os-version on gcc; I don't see an equivalent option in Microsoft's linker. What's confusing me is that gcc sets both the OS field and the subsystem field to 4.00 by default. So what's the difference between the two?
(Is the "image version" header field related to either of these?)
In addition, I see it is also possible to specify supported Windows versions in a manifest file. This question shows several being used at once.
What's the difference between all these settings and is there any advantage to using one over the other? Or all at the same time?
What if I have a DLL? Do any of these not apply with a DLL if the EXE that links to it isn't set up identically?
Thanks.
I am studying "Hacking: The Art of Exploitation". I am trying to follow the code examples, but for some reason the assembly codes simply does not match the one on my actual Linux (running on Virtual Box as Guest). I have made sure that I have installed 32 bit Linux OS. Is there any args that I can pass to gcc that lets me compile the code into an assembly that matches closely with the ones given in the book?
I would be fine reconciling the code differences between the book & what I see if they were minor, but the difference I see is stark. I somehow don't like to run the code from the "Preconfigured incubator environment" as this inhibits my skill development.
I've actually been in the same boat--for the last week or two I've tried a ton of ways to produce comparable assembly code in my normal development environment (LMDE), including chroot, compiling with the -m32 flag, installing an x86 ubuntu, etc, and nothing really worked. Today I found http://www.nostarch.com/hackingCD.htm and I followed the instructions and was able to get the livecd to boot in vmware workstation 10. Here's what I did:
Download the iso from the link above (though it should work with the
livecd as well)
Create a .vmx file and copy and paste the config from the link
I took out the section defining the cdrom device, since I was using an iso
Open the file with VmWare Workstation--if you are using the iso, go to "Edit VM Settings" and set up a cdrom device and point it to the iso
VM booted without any issues
I know this isn't as convenient as going through the examples in your main OS/system, and that you were trying to avoid using the LiveCD, but after doing a lot of research I've discovered that this is an extremely common issue and hopefully this answer helps someone. Using the LiveCD might not be ideal but it is still a heck of a lot better than dual booting.
for some reason the assembly codes simply does not match the one on my actual linux
The most likely reason is that the book was published in 2008, and used then-stable GCC (you can see GCC release history here).
GCC that you are using now is likely much newer, and so generates significantly different (and one hopes better) code.
Is there any args that I can pass to gcc that lets me compile the code into an assembly that matches closely with the ones given in the book?
No. You can try to compile and install a version from 2008, perhaps 4.2.3 or 4.3.0, and check whether that gives you closer output.
P.S. It looks like the first revision of the book is from 2003, and it's unlikely that the authors rebuilt all of their examples for the second edition in 2008, so perhaps try GCC 3.3 instead?
This is why the book comes with a LiveCD with a linux distro and all of the example source code from the book on there. All of the examples in the book match exactly with what will happen in the LiveCD.
Just run the included LiveCD using VirtualBox or VMware and follow along with the book using that. If you don't have the CD, it can be downloaded from a torrent provided by No Starch (linked from their website)
it doesn´t matter whether the output of gcc is different, the only thing it changes is the memory addresses; plus, you said u r using a VM to run it, meaning that the memory u will get is dummy memory, try booting the iso and run it directly, it will almost the same.
https://www.youtube.com/watch?v=pIN7oFkz5rM
I am on Mac OSX 10.7 however I believe this would also appear in 10.8+
Try running (within erlang)
wx:demo().
Which will produce the following output:
beam.smp[2733:f0b] CFURLCreateWithString was passed this invalid URL string: '/System/Library/CoreServices/CommonCocoaPanels.bundle' (a file system path instead of an URL string). The URL created will not work with most file URL functions. CFURLCreateWithFileSystemPath or CFURLCreateWithFileSystemPathRelativeToBase should be used instead.
Now the demo runs just fine but why output this line then?
It speaks nothing of erlang and after some browsing around it seems as if this is a wxWidgets bug as people have the same issue in python and that it is Mac OSX centric due to the CommonCocoaPanels.bundle in the output.
Its really just an annoyance for now as everything runs just fine. But it is more than likely a bug, no?
How can it be fixed?
As far as I know wxErlang is currently broken on MacOS and maintainers promise to fix it after wxWidgets 3.0 release.
Which version of wxWidgets are you using? I used wxWidgets 2.8.12 under Mac OS 10.6.8, custom build for Carbon with -arch i386.
In wxWidgets 2.8.x, Carbon is the recommended library because it is the
more stable. Cocoa is incomplete in wxWidgets 2.8.x. If you are interested
in using Cocoa, you should start with wxWidgets 2.9.x where Cocoa is
much more complete.
The framework itself looked somehow alien to Max OS (maybe because of Carbon), a small part of API was broken (this does not prevent programs to actually run - just small annoyances).
For my future reference, and that of others..
The following will work without displaying the above error message.
P = wx:new(),
F = wxFrame:new(P, 1, "main", [{size, {600,600}]),
WindowOpts = [{size, {600,600}}, {style, ?wxSUNKEN_BORDER}],
W = wxWindow:new(F, ?wxID_ANY, WindowOpts),
wxFrame:connect(F, close_window, [{skip,true}]),
wxWindow:connect(W, paint, [{skip, true}]),
wxFrame:show(F),
wxFrame:centre(F).
Strangely enough even with all my trial and error debugging, line by line, there is really no easy way to get to the bottom of it. It turns out to be the inclusion of a:
process_flag(trap_errors, true)
Will generate that error. I am positive there is nothing crashing that would invoke the actions of the flag.
Deep error. Little consequence.
Lets hope they get it fixed along with the 3.0 upgrade.
I'd like to configure visual studio 2005 to copy .dll's based on whether the OS is 64-bit or 32-bit during a build.
I do not want to specify what the platform target is.
My first attempt was to use a batch file to lookup the Windows version, but some 32-bit and 64-bit versions of Windows share the same version number.
Anyone know of any way to check this?
Thanks!
You should be able to read the environment variable %PROCESSOR_ARCHITECTURE%. Here is some great information on it.
http://blogs.msdn.com/david.wang/archive/2006/03/26/HOWTO-Detect-Process-Bitness.aspx
Check out isWow64, I think that shopuld give you what you are after.
Determines whether the specified process is running under WOW64.
Jon's link is a total hack because it relies upon no new processor architectures being added.
See: http://support.microsoft.com/kb/556009 for the "official" batch file method.