I found a program which uses a dll-file, which starts with MZx in the DOS header. I never saw this before in my life. I get ZERO results at google when i try to find explanations what this means. Here is a screenshot:
View in HexEditor
What exactly does the MZx mean? Are there differences to a typical MZ header? Can i replace the dll with a "normal" one which starts with MZ or will it be not compatible?
Only the first two bytes are part of the signature, the rest is the configuration of the DOS program:
typedef struct _IMAGE_DOS_HEADER
{
WORD e_magic; // MZ
WORD e_cblp; // Bytes on last page of file
WORD e_cp; // Pages in file
...
These "unusual" values are either required by the DOS program (unlikely in a .dll) or used as some kind of marker/storage for something. Either way, leave the values alone...
Related
While compiling a c file, gcc by default compiles it to a file called "a.out". My professor said that the output file contains the binaries, but I when I open it I usually encounter unreadable text (VS Code says something like "This file contains unsupported text encoding").
I assumed that by 'binaries', I would be able to see literal zeroes and ones in the file but that does not seem to be the case. So what exactly does it output file look like or what exactly does it contain and what is 'text encoding'? Why can I not read it? What special characters might it contain? I'm aware of the fact that gcc first pre-processes, which means it removes all comments, expands all macros and copies the contents of any header files that might be included. You get the header file by running gcc -E <file_name>.c, then the this processed file is complied into assembly. Up to this point, the output files are readable, i.e., I can open them with VS Code, but after this the assembled code and the object file thereafter are human-unreadable.
For reference, I have no prior experience with programming or any language for that matter and this is my first CS related course in my first sem of college, and I apologize if this is too trivial of a question to ask.
I actually had the same confusion early on. Not about that file type specifically, but about binary vs text files.
After all aren't all files, even text ones binary? In the sense that all information is 1s and 0s? Well, yes, all information can be stored/transmitted as 1s and 0s, but that's not what binary/text files refer to.
It refers to what that information, the content of the file, those 1s and 0s represent.
In a text file the bytes encode characters. In a binary file the bits encode some information that is not text. The format and semantics of that information is completely free, it can mean anything and use whatever encoding scheme. It's up to the application that writes/reads the file to properly understand the bit patterns.
Most text editors (like VS Code) when open a file they treat it as a text file. I.e. they try to interpret the bit patterns as a text encoding scheme (e.g. ASCII or UTF-8) But not all bit patterns are valid ASCII/UTF-8 so that's why you get "unsupported text encoding".
If you want to inspect the actual 1s and 0 for both text and binary files you need to use a utility that shows you that, e.g. hex viewers/editors.
In the IMAGE_DOS_HEADER for the PE (Windows executable) format there is a field known as e_lfanew, it serves a very important role in that it points to the actual PE header data.
My question is, what does "e_lfanew" actually stand for? what does it mean? It's so cryptic.
EDIT: I'm NOT asking what it does, i know what it does, i want to know what the letters in e_lfanew actually stand for, why was it given that name?
My interpretation would be that it's the long file address for the New Executable header.
Mainly based on the comment in this P/Invoke article about IMAGE_DOS_HEADER:
public Int32 e_lfanew; // File address of new exe header
"Long" because it's from the 16-bit era and the variable size is 32 bits.
I'm working with visual studio 2003 on Windows 7.
I'm trying to embed a binary file into a windows console application (c++).
I added into the resource script (.rc file) the following line:
SampleFile RCDATA "c:\\sample.zip"
and also added the following code to access the file:
HRSRC hResource = FindResource(NULL, (LPCSTR)"SampleFile", RT_RCDATA);
LPVOID l = LockResource(hResource);
now, hResource is a valid handle and LockResource also succeeds but the pointer l points to some struct, probably a header, that is followed by the actual data of the zip file I was trying to embed.
I managed to spot that the second DWORD in the said header is the size of the file, and the name of the resource ("SampleFile") also appears in the header, but couldn't manage to find a description of the header or at least the header size.
As Luke said, You're missing a LoadResource() call in the middle.
FindResource() essentially gives you a pointer/handle to the resource header, LoadResource() reads that header and gives you a value that (on win32) points to the data itself, but used to be an HGlobal that could be moved in memory. You would then lock this location and get a pointer using LockResource().
The usage stays the same on Win32 though.
From MSDN
Do not try to lock a resource by using the handle returned by the FindResource or FindResourceEx function. Such a handle points to random data.
The resource header is described in MSDN as the fictional RESOURCEHEADER structure.
This reply is largely taken from Raymond Chen's article on 16-bit resource management
You have an Api function to get size of resource SizeofResource.
The pointer points to the beginning of the file added as resource (in your case "c:\sample.zip).
If you want you can pass that pointer to a uncompress library or simply write to disk.
thanks for the help.
Actually I did have LoadResource in my code, which got lost in the copy paste to the site.
However, that is related to the problem in my code.
The code looked like this: (Psuedo code this time)
HANDLE hFindHandle = FindResource(...);
LoadResource(hFindHandle and Module Handle);
and then
LPVOID l = LockResource(hFindHandle);
I didn't use the returned value from the LoadResource but kept using the one from the FindResource, so even though I did call LoadResource, I didn't get the correct pointer from LockResource.
I have been looking for a way of modifying static strings stored in Windows .exe files in the .rdata section, however I haven't found a real way to do so yet.
The whole thing is too complicated to do by hand (in this case by a HEX editor) and so I wanted to know if you have a solution to do so.
What is complicated about doing it in a hex editor? One 'gotcha' that might be tripping you up is that you have to maintain each string's original length. You can do so with spaces at the end or (sometimes) by null-terminating it early, depending on how it's accessed in the executable.
If you really want to get tricky, you can try finding every cross reference to said string in the code and modify the length parameter passed to functions that use it.
Are comments allowed in Windows ini files? (...assuming you're using the GetPrivateProfileString api functions to read them...)
[Section]
Name=Value ; comment
; full line comment
And, is there a proper spec of the .INI file format anywhere?
Thanks for the replies - However maybe I wasn't clear enough. It's only the format as read by Windows API Calls that I'm interested in. I know other implementations allow comments, but it's specifically the MS Windows spec and implementation that I need to know about.
Windows INI API support for:
Line comments: yes, using semi-colon ;
Trailing comments: No
The authoritative source is the Windows API function that reads values out of INI files
GetPrivateProfileString
Retrieves a string from the specified section in an initialization file.
The reason "full line comments" work is because the requested value does not exist. For example, when parsing the following ini file contents:
[Application]
UseLiveData=1
;coke=zero
pepsi=diet ;gag
#stackoverflow=splotchy
Reading the values:
UseLiveData: 1
coke: not present
;coke: not present
pepsi: diet ;gag
stackoverflow: not present
#stackoverflow: splotchy
Update: I used to think that the number sign (#) was a pseudo line-comment character. The reason using leading # works to hide stackoverflow is because the name stackoverflow no longer exists. And it turns out that semi-colon (;) is a line-comment.
But there is no support for trailing comments.
I have seen comments in INI files, so yes. Please refer to this Wikipedia article. I could not find an official specification, but that is the correct syntax for comments, as many game INI files had this as I remember.
Edit
The API returns the Value and the Comment (forgot to mention this in my reply), just construct and example INI file and call the API on this (with comments) and you can see how this is returned.
USE A SEMI-COLON AT BEGINING OF LINE --->> ; <<---
Ex.
; last modified 1 April 2001 by John Doe
[owner]
name=John Doe
organization=Acme Widgets Inc.
I like the analysis of #Ian Boyd, because it is based on the official GetPrivateProfileString() method of Microsoft.
In my attempts of writing a Microsoft compatible INI parser, I'm having a closer look at the said Microsoft API and for comments I found out:
you can have line comments using semicolon
the semicolon needn't be the first character of the line; it can be preceded by space, tab or vertical tab
you can have trailing "comments" after a section even without semicolon. It's probably not intended to be a comment, but the parser will ignore it.
values outside a section cannot be accessed (at least I did not find a way), effectively making them useless except for commenting purposes
certainly abuse, but the parser overflows at 65536 characters, so anything after that will not be part of the value either. I would not rely on this, since Microsoft could fix this in later versions of Windows. Also, it's not very useful as a comment when you don't see it.
Example:
this=cannot be accessed
[section]this=is ignored
;this=is a line comment
;this=is a comment preceded by spaces
key=value <... 65530 spaces ...>this=cannot be parsed
Yes, it allows.
The way to comment is to use ; for a new line rather than just after the content you want to comment in the same line, which is allowable for other files where you want to comment.
Let me show you an example:
I use .ini file to pass some parameters for my training file when I use SUMO software. If I write like this:
width_layers = 400 ;the number of neurons per layer in the neural network.
I will get an error message which is
ValueError: invalid literal for int() with base 10: '400 ;the number of neurons per layer in the neural network.'
I have to create a line for that, which is
width_layers = 400
;the number of neurons per layer in the neural network.
Then, it will work. Hope it helps in detail!