How to find out where the main function in an .exe file is? - executable

I created a simple .exe file that just assigns a value of 3 to an integer called "x" and then prints out that value.Here is a picture of the source code:
source code
I opened the .exe file with an hex editor(named HxD) and used the disassembly function of Visual Studio 2017 to show me the opcodes of my main function. After a bit of search i found out that the main function is stored in the file at Offset 0xC10
Here is the disassembly:disassembly
And here is the file in the Hex-Editor:hexadecimal view of .exe file
I know that some values of the .exe file in the hex editor vary from what the visual studio debugger says but i know that the main starts there because i changed the value of x in the hex editor and then when i started the .exe it printed out another value instead of the 3. My question is where in the .exe file is the value that says:"At that point of the file start the opcodes of the main function."
For example in a .bmp file the 4 bytes at positions 0x0A,0x0B,0x0C and 0x0D tell you the offset of the first byte of the first pixel.

On Windows, the entry point of an executable (.exe) is set in the PE Header of the file.
WikiPedia illustrates the structure of this header like this (SVG file).
Relative to the beginning of the file, the PE Header starts at the position indicated at the address
DWORD 0x3C Pointer to PE Header
File Header / DOS Header
+--------------------+--------------------+
0000 | 0x5A4D | | |
0008 | | |
0010 | | |
0018 | | |
0020 | | |
0028 | | |
0030 | | |
0038 | | PE Header addr |
0040 | | |
.... | .................. | .................. |
And the entry point is designated at the position (relative to the address above)
DWORD 0x28 EntryPoint
PE Header
+--------------------+--------------------+
0000 | Signature | Machine | NumOfSect|
0008 | TimeDateStamp | PtrToSymTable |
0010 | NumOfSymTable |SizOfOHdr| Chars |
0018 | Magic | MJV| MNV | SizeOfCode |
0020 | SizeOfInitData | SizeOfUnInitData |
0028 | EntryPoint (RVA) | BaseOfCode (RVA) |
0030 | BaseOfData (RVA) | ImageBase |
0038 | SectionAlignment | FileAlignment |
0040 | ... | ... |
from the beginning of the PE Header. This address is a RVA (Relative Virtual Address) what means that it is relative to the Image Base address that the file is loaded to by the loader:
Relative virtual addresses (RVAs) are not to be confused with standard virtual addresses. A relative virtual address is the virtual address of an object from the file once it is loaded into memory, minus the base address of the file image.
This address is the address of the main function.

A .exe is a portable executable.
Layout
Structure of a Portable Executable 32 bit
A PE file consists of a number of headers and sections that tell the dynamic linker how to map the file into memory. An executable image consists of several different regions, each of which require different memory protection; so the start of each section must be aligned to a page boundary.[4] For instance, typically the .text section (which holds program code) is mapped as execute/readonly, and ...
So really it is a question of where the .text section is in the file. Exactly where depends on the headers and locations of the other sections.

Related

Can GraphDB load 10 million statements with OWL reasoning?

I am struggling to load most of the Drug Ontology OWL files and most of the ChEBI OWL files into GraphDB free v8.3 repository with Optimized OWL Horst reasoning on.
is this possible? Should I do something other than "be patient?"
Details:
I'm using the loadrdf offline bulk loader to populate an AWS r4.16xlarge instance with 488.0 GiB and 64 vCPUs
Over the weekend, I played around with different pool buffer sizes and found that most of these files individually load fastest with a pool buffer of 2,000 or 20,000 statements instead of the suggested 200,000. I also added -Xmx470g to the loadrdf script. Most of the OWL files would load individually in less than one hour.
Around 10 pm EDT last night, I started to load all of the files listed below simultaneously. Now it's 11 hours later, and there are still millions of statements to go. The load rate is around 70/second now. It appears that only 30% of my RAM is being used, but the CPU load is consistently around 60.
are there websites that document other people doing something of this scale?
should I be using a different reasoning configuration? I chose this configuration as it was the fastest loading OWL configuration, based on my experiments over the weekend. I think I will need to look for relationships that go beyond rdfs:subClassOf.
Files I'm trying to load:
+-------------+------------+---------------------+
| bytes | statements | file |
+-------------+------------+---------------------+
| 471,265,716 | 4,268,532 | chebi.owl |
| 61,529 | 451 | chebi-disjoints.owl |
| 82,449 | 1,076 | chebi-proteins.owl |
| 10,237,338 | 135,369 | dron-chebi.owl |
| 2,374 | 16 | dron-full.owl |
| 170,896 | 2,257 | dron-hand.owl |
| 140,434,070 | 1,986,609 | dron-ingredient.owl |
| 2,391 | 16 | dron-lite.owl |
| 234,853,064 | 2,495,144 | dron-ndc.owl |
| 4,970 | 28 | dron-pro.owl |
| 37,198,480 | 301,031 | dron-rxnorm.owl |
| 137,507 | 1,228 | dron-upper.owl |
+-------------+------------+---------------------+
#MarkMiller you can take a look at the Preload tool, which is part of GraphDB 8.4.0 release. It's specially designed to handle large amount of data with constant speed. Note that it works without inference, so you'll need to load your data and then change the ruleset and reinfer the statements.
http://graphdb.ontotext.com/documentation/free/loading-data-using-preload.html
Just typing out #Konstantin Petrov's correct suggestion with tidier formatting. All of these queries should be run in the repository of interest... at some point in working this out, I misled myself into thinking that I should be connected to the SYSTEM repo when running these queries.
All of these queries also require the following prefix definition
prefix sys: <http://www.ontotext.com/owlim/system#>
This doesn't directly address the timing/performance of loading large datasets into an OWL reasoning repository, but it does show how to switch to a higher level of reasoning after loading lots of triples into a no-inference ("empty" ruleset) repository.
Could start by querying for the current reasoning level/rule set, and then run this same select statement after each insert.
SELECT ?state ?ruleset {
?state sys:listRulesets ?ruleset
}
Add a predefined ruleset
INSERT DATA {
_:b sys:addRuleset "rdfsplus-optimized"
}
Make the new ruleset the default
INSERT DATA {
_:b sys:defaultRuleset "rdfsplus-optimized"
}
Re-infer... could take a long time!
INSERT DATA {
[] <http://www.ontotext.com/owlim/system#reinfer> []
}

Get version of rich edit library

ALL,
Is it possible to get the version of the RichEdit control the program uses?
| Version | Class name | Library | Shipped with | New features
|------------|---------------|--------------|-----------------|
| 1.0 | "RICHEDIT" | Riched32.dll | Windows 95 |
| 2.0 | "RichEdit20W" | Riched20.dll | Windows 98 | ITextDocument
| 3.0 | "RichEdit20W" | Riched20.dll | Windows 2000 | ITextDocument2
| 3.1 | "RichEdit20W" | Riched20.dll | Server 2003 |
| 4.1 | "RICHEDIT50" | Msftedit.dll | Windows XP SP1 | tomApplyTmp
| 7.5 | "RICHEDIT50" | Msftedit.dll | Windows 8 | ITextDocument2 (new), ITextDocument2Old, Spell checking, Ink support, Office Math
| 8.5 | "RICHEDIT50" | Msftedit.dll | Windows 10 | LocaleName, more image formats
I know I can just have some variable and assign it appropriately if Msftedit.dll library is loaded or not. However if I do load RichEd20.dll, I can get either RichEdit 2 or RichEdit 3 implementation. And they are quite different. A lot of stuff were added in the latter.
If i did load Msftedit.dll, there are features that 7.5 that would not be available in earlier versions (e.g. automatic spell checking).
It's even possible that the same process can have all three DLLs loaded, and even using all three versions of RichEdit in the same process:
"RICHEDIT" → 1.0
"RichEdit20W" → 2.0, 3.0
"RICHEDIT50" → 4.1, 7.5, 8.5
Given a RichEdit control (e.g. WinForms RichTextBox, WPF RichTextBox, WinRT RichEditBox, VCL TRichEdit) is there a way to determine the version of a RichEdit control?
Or maybe I can somehow differentiate them by Windows version where it is available?
If using c++ you may find the following snippet useful to read out the class name :
TCHAR className[MAX_PATH];
GetClassName(GetRichEditCtrl().GetSafeHwnd(), className, _countof(className));
GetRichEditCtrl() is function on another control, you may need to substitute with whatever gives you a hwnd to the control.
Another method is using a tool like spy++ to inspect the class name.

Read a file from a position in Robot Framework

How can I read a file from a specific byte position in Robot Framework?
Let's say I have a process running for a long time writing a long log file. I want to get the current file size, then I execute something that affects the behaviour of the process and I wait until some message appears in the log file. I want to read only the portion of the file starting from the previous file size.
I am new to Robot Framework. I think this is a very common scenario, but I haven't found how to do it.
There are no built-in keywords to do this, but writing one in python is pretty simple.
For example, create a file named "readmore.py" with the following:
from robot.libraries.BuiltIn import BuiltIn
class readmore(object):
ROBOT_LIBRARY_SCOPE = "TEST SUITE"
def __init__(self):
self.fp = {}
def read_more(self, path):
# if we don't already know about this file,
# set the file pointer to zero
if path not in self.fp:
BuiltIn().log("setting fp to zero", "DEBUG")
self.fp[path] = 0
# open the file, move the pointer to the stored
# position, read the file, and reset the pointer
with open(path) as f:
BuiltIn().log("seeking to %s" % self.fp[path], "DEBUG")
f.seek(self.fp[path])
data = f.read()
self.fp[path] = f.tell()
BuiltIn().log("resetting fp to %s" % self.fp[path], "DEBUG")
return data
You can then use it like this:
*** Settings ***
| Library | readmore.py
| Library | OperatingSystem
*** test cases ***
| Example of "tail-like" reading of a file
| | # read the current contents of the file
| | ${original}= | read more | /tmp/junk.txt
| | # do something to add more data to the file
| | Append to file | /tmp/junk.txt | this is new content\n
| | # read the new data
| | ${new}= | Read more | /tmp/junk.txt
| | Should be equal | ${new.strip()} | this is new content

I want to put two landscape A5 pages (.ps or .pdf) on one portrait A4 page (.ps or .pdf)

I created a document in A5 size and managed to reshuffle the pages of the produced .pdf output with psbook, so that the pages have the perfect order for a booklet.
There are lots of hints that the next step would work with psnup, but that's not true. I also tried a2ps and pstops with various options. The last thing I found was bookletimposer (Ubuntu), but it has failed as well.
It seems so easy, because no scaling and no rotating is involved. Just put one page # position 0,0 and the following on # 0,14,85cm (half the height of the A4 page).
input:
+----------+
| this is |
| page one |
+----------+
+----------+
| this is |
| page two |
+----------+
output:
+----------+
| this is |
| page one |
| |
| this is |
| page two |
+----------+
assuming you had a multipage pdf file, let's say consisting in 16 sequentially ordered pages:
1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16
and you already reordered the pages to have this new sequence:
16,1,2,15,14,3,4,13,12,5,6,11,10,7,8,9
and these pages are oriented in landscape mode
you can use, on this last file,
Multivalent.jar (last free version with pdf tools included)
https://rg.to/file/c6bd7f31bf8885bcaa69b50ffab7e355
with this syntax:
java -cp /path/to.../Multivalent.jar tool.pdf.Impose -dim 1x2 -paper A4 A5-already-huffled_for_imposing.pdf
since you have already the pages rightly shuffled for imposing:
16,1,2,15,14,3,4,13,12,5,6,11,10,7,8,9
Multivalent will pick
pages 16,1 ...and put on same page (front 1)
pages 2,15 ...and put on same page (back 1)
and so on... achieving the goal to create a perfectly imposed booklet

Font metrics for the "base 14" fonts in the PDF specification

I've been writing software to parse content from PDFs, specifically text broken into regions. For this I need font metrics such as glyph displacements, font-wide ascent, descent and glyph bounding box, etc. In short, the type of metrics that should be available in the FontDescriptor dictionary of a font definition in a PDF.
Unfortunately a FontDescriptor doesn't have to be included for fonts whose base font is one of the "base 14" set of standard fonts.
Where can I find or how can I generate font metrics for the base 14 fonts?
Meanwhile I've found these links on an Adobe Website, which contain the information asked for:
Font Metrics for Base 14 fonts (Windows)
Font Metrics for Base 14 fonts (UNIX)
Font Metrics for Base 14 fonts (Macintosh)
On Linux (and probably on Mac OS X too) you can easily use the font2afm script which creates font metrics files from PostScript or TrueType fonts (.pfa, .pfb, .ttf, .otf).
If you don't have the original Base 14 available, you can use the clones provided by Ghostscript. These clones may use completely different font names, but they can only be clones by using the very same metrics for each glyph.
Here is a Ghostscript commandline, that lists you all the base 14 fontnames:
Windows:
gswin32c.exe -q -dNODISPLAY -dSAFER -c "systemdict /.standardfonts get == quit"
Linux/Unix/Mac:
gs -q -dNODISPLAY -dSAFER -c "systemdict /.standardfonts get == quit"
In recent versions of Ghostscript, the filenames for cloned fonts usually match the clone's fontname. Older GS versions may have used more cryptic nameing conventions. Here is the list of fontname mappings to the cloned fonts:
+===============+========================+==========================+
| Base 14 name | Ghostscript name | Font filename (older GS) |
+===============+========================+==========================+
| Courier | | |
| standard | NimbusMonL-Regu | n022003l.pfb |
| bold | NimbusMonL-Bold | n022004l.pfb |
| italic | NimbusMonL-ReguObli | n022023l.pfb |
| bolditalic | NimbusMonL-BoldObli | n022024l.pfb |
+---------------+------------------------+--------------------------+
| Helvetica | | |
| standard | NimbusSanL-Regu | n019003l.pfb |
| bold | NimbusSanL-Bold | n019004l.pfb |
| italic | NimbusSanL-ReguItal | n019023l.pfb |
| bolditalic | NimbusSanL-BoldItal | n019024l.pfb |
+---------------+------------------------+--------------------------+
| Times-Roman | | |
| standard | NimbusRomNo9L-Regu | n021003l.pfb |
| bold | NimbusRomNo9L-Medi | n021004l.pfb |
| italic | NimbusRomNo9L-ReguItal | n021023l.pfb |
| bolditalic | NimbusRomNo9L-MediItal | n021024l.pfb |
+---------------+------------------------+--------------------------+
| Symbol | StandardSymL | s050000l.pfb |
+---------------+------------------------+--------------------------+
| ZapfDingbats | Dingbats | d050000l.pfb |
+---------------+------------------------+--------------------------+
You can download the Ghostscript fonts from many places on the 'net (f.e. from here). Then run f.e. this command:
font2afm StandardSymL.ttf
and the resulting file, StandardSymL.afm should contain the font metrics for the Symbol font in standard .afm format....
I'm sure those font metrics are widely available. For instance, in my Ubuntu they're in /usr/share/fonts/type1/gsfonts/ -- maybe you don't recognize some of the font names, but they're metrically compatible to Helvetica etc.