Discussion:
need a program that will print a percent of code in tehe exe/dll
Add Reply
fir
2017-04-29 12:44:53 UTC
Reply
Permalink
Raw Message
if you got exe or dll the most important sections are .code .data .const and .bss

need a simple console program that show the size of the code
(in bytes and also in percent) in given .exe .dll [also sieze of consts and initialised data, yet size of static arrays]

i think it will be simple like less than 100 lines probably
(maybe even more like 30 or 50) but needs a moment to write

some pieces?

(i can vrite it alone but posted this idea and question as i find it good and usefull)
bartc
2017-04-29 13:18:11 UTC
Reply
Permalink
Raw Message
Post by fir
if you got exe or dll the most important sections are .code .data .const and .bss
need a simple console program that show the size of the code
(in bytes and also in percent) in given .exe .dll [also sieze of consts and initialised data, yet size of static arrays]
i think it will be simple like less than 100 lines probably
(maybe even more like 30 or 50) but needs a moment to write
some pieces?
(i can vrite it alone but posted this idea and question as i find it good and usefull)
I've just started such a project actually. (To first read then write
object files, and probably executables too. Because existing programs to
do deal with them such as assemblers, linkers and dumpers are so full of
problems.)

But it might take some days before I can show that info.

The starting point however was some C code I posted in a ~2014 thread
you started, also about reading object files.
--
bartc
fir
2017-04-29 13:55:39 UTC
Reply
Permalink
Raw Message
Post by bartc
Post by fir
if you got exe or dll the most important sections are .code .data .const and .bss
need a simple console program that show the size of the code
(in bytes and also in percent) in given .exe .dll [also sieze of consts and initialised data, yet size of static arrays]
i think it will be simple like less than 100 lines probably
(maybe even more like 30 or 50) but needs a moment to write
some pieces?
(i can vrite it alone but posted this idea and question as i find it good and usefull)
I've just started such a project actually. (To first read then write
object files, and probably executables too. Because existing programs to
do deal with them such as assemblers, linkers and dumpers are so full of
problems.)
But it might take some days before I can show that info.
The starting point however was some C code I posted in a ~2014 thread
you started, also about reading object files.
--
bartc
ye i roughly know haow to do it (as it is much simpler than general p[e generation) but posted as it is good idea

i checked my power dll library (lister plugin for total commander allows you to read that info though in unreadable hex) which is

285 696 bytes size
code is 167 992
data is 91 276
rdata (consts most probably) is 4 020
and bss (packed arrays) is 110 984 784
yet .crt 24 bytes (got no ide whats that)
.tls 32 bytes
.eh_fram 852 bytes

most surprising was that large bss - it shows that wathing that sizes may be nice and usefull as i tend to forget i put
some big arrays there (also im nuhappy to get those eh_frame as i giwe switches "no exceptions god damn!")

if you got soem code you may post it if no i probably may post it too if i began to write it (now i yet a bit rest but need to write that few lines)
fir
2017-04-29 18:18:28 UTC
Reply
Permalink
Raw Message
Post by fir
Post by bartc
Post by fir
if you got exe or dll the most important sections are .code .data .const and .bss
need a simple console program that show the size of the code
(in bytes and also in percent) in given .exe .dll [also sieze of consts and initialised data, yet size of static arrays]
i think it will be simple like less than 100 lines probably
(maybe even more like 30 or 50) but needs a moment to write
some pieces?
(i can vrite it alone but posted this idea and question as i find it good and usefull)
I've just started such a project actually. (To first read then write
object files, and probably executables too. Because existing programs to
do deal with them such as assemblers, linkers and dumpers are so full of
problems.)
But it might take some days before I can show that info.
The starting point however was some C code I posted in a ~2014 thread
you started, also about reading object files.
--
bartc
ye i roughly know haow to do it (as it is much simpler than general p[e generation) but posted as it is good idea
i checked my power dll library (lister plugin for total commander allows you to read that info though in unreadable hex) which is
285 696 bytes size
code is 167 992
data is 91 276
rdata (consts most probably) is 4 020
and bss (packed arrays) is 110 984 784
yet .crt 24 bytes (got no ide whats that)
.tls 32 bytes
.eh_fram 852 bytes
most surprising was that large bss - it shows that wathing that sizes may be nice and usefull as i tend to forget i put
some big arrays there (also im nuhappy to get those eh_frame as i giwe switches "no exceptions god damn!")
if you got soem code you may post it if no i probably may post it too if i began to write it (now i yet a bit rest but need to write that few lines)
PS

i dont really like to dubble (if there is such word sorry im to exhausted to look up in dictionaries, u probably mean poke, fiddle) in this PE format and its tutorials - that PE is really bad thing, bad namas, badly explained (probably also slightly badly designed)

i dubbled a tiny bit in it last hour and probably quick hack to this approach would be
void main()
{
for(int n = 0; n<number_of_sections; n++)
{
char* section_name = pe_image[0x178 + n*0x28];
int* section_size = (int*) pe_image[0x178 + n*0x28 + 8];
unsigned* section_flags = pe_image[0x178 + n*0x28 + 36];

//printf it
}
}

something like that, this 0x178 may depend on one or two previous fields but may be typical (im not sure as now for correct recipe for that value).. witt try that soon
fir
2017-04-29 18:27:54 UTC
Reply
Permalink
Raw Message
Post by fir
Post by fir
Post by bartc
Post by fir
if you got exe or dll the most important sections are .code .data .const and .bss
need a simple console program that show the size of the code
(in bytes and also in percent) in given .exe .dll [also sieze of consts and initialised data, yet size of static arrays]
i think it will be simple like less than 100 lines probably
(maybe even more like 30 or 50) but needs a moment to write
some pieces?
(i can vrite it alone but posted this idea and question as i find it good and usefull)
I've just started such a project actually. (To first read then write
object files, and probably executables too. Because existing programs to
do deal with them such as assemblers, linkers and dumpers are so full of
problems.)
But it might take some days before I can show that info.
The starting point however was some C code I posted in a ~2014 thread
you started, also about reading object files.
--
bartc
ye i roughly know haow to do it (as it is much simpler than general p[e generation) but posted as it is good idea
i checked my power dll library (lister plugin for total commander allows you to read that info though in unreadable hex) which is
285 696 bytes size
code is 167 992
data is 91 276
rdata (consts most probably) is 4 020
and bss (packed arrays) is 110 984 784
yet .crt 24 bytes (got no ide whats that)
.tls 32 bytes
.eh_fram 852 bytes
most surprising was that large bss - it shows that wathing that sizes may be nice and usefull as i tend to forget i put
some big arrays there (also im nuhappy to get those eh_frame as i giwe switches "no exceptions god damn!")
if you got soem code you may post it if no i probably may post it too if i began to write it (now i yet a bit rest but need to write that few lines)
PS
i dont really like to dubble (if there is such word sorry im to exhausted to look up in dictionaries, u probably mean poke, fiddle) in this PE format and its tutorials - that PE is really bad thing, bad namas, badly explained (probably also slightly badly designed)
i dubbled a tiny bit in it last hour and probably quick hack to this approach would be
void main()
{
for(int n = 0; n<number_of_sections; n++)
{
char* section_name = pe_image[0x178 + n*0x28];
int* section_size = (int*) pe_image[0x178 + n*0x28 + 8];
unsigned* section_flags = pe_image[0x178 + n*0x28 + 36];
//printf it
}
}
something like that, this 0x178 may depend on one or two previous fields but may be typical (im not sure as now for correct recipe for that value).. witt try that soon
number of sections is itself

short* number_of_sections = (short*) &pe_image[0x86];

im radically exhausted after mixing coffe with slight antidepresants but will try make myself to check it
bartc
2017-04-29 21:08:24 UTC
Reply
Permalink
Raw Message
Post by fir
Post by bartc
But it might take some days before I can show that info.
It wasn't quite that long...
Post by fir
i dubbled a tiny bit in it last hour and probably quick hack to this approach would be
void main()
{
for(int n = 0; n<number_of_sections; n++)
{
char* section_name = pe_image[0x178 + n*0x28];
int* section_size = (int*) pe_image[0x178 + n*0x28 + 8];
unsigned* section_flags = pe_image[0x178 + n*0x28 + 36];
//printf it
}
}
something like that, this 0x178 may depend on one or two previous fields but may be typical (im not sure as now for correct recipe for that value).. witt try that soon
I came up with this. It avoids using 'windows.h' should ought to run
anywhere:

#include <stdio.h>
#include <stdint.h>

typedef int16_t wt_word;
typedef int32_t wt_dword;

typedef struct {
wt_word machine;
wt_word nsections;
wt_dword timedatestamp;
wt_dword stpointer;
wt_dword nsymbols;
wt_word optheadersize;
wt_word characteristics;
} imagefileheader;

typedef struct {
char name[8];
union {
wt_dword physical_address;
wt_dword virtual_size;
};
wt_dword virtual_address;
wt_dword rawdata_size;
wt_dword rawdata_ptr;
wt_dword relocations_ptr;
wt_dword linenos_ptr;
wt_word nrelocs;
wt_word nlinenos;
wt_dword characteristics;
} imagesectionheader;


int getfilesize(FILE *handle) {
int p,size;

p = ftell(handle);
fseek(handle,0,2);
size = ftell(handle);
fseek(handle,p,0);
return size;
}

char *readfile(char *filename) {
FILE *f;
int size;
char *m;

f = fopen(filename,"rb");
if (f==0) {
return NULL;
}
size = getfilesize(f);
m = malloc(size);
if (m==NULL) {
return NULL;
}

fseek(f,0,0);
fread(m,1,size,f);

fclose(f);
return m;
}

int main(int nargs, char**args) {
char *infile;
char *pe;
int peoffset,coffoffset,sectionoffset,nsections;
int i;
imagefileheader *coffptr;
imagesectionheader *sectionptr;

if (nargs<2) {
printf("Usage: %s file.exe\n",args[0]);
printf(" %s file.obj\n",args[0]);
exit(0);
}

infile=args[1];

printf("Loading: %s\n",infile);
pe=readfile(infile);
if (pe==NULL) {
printf("Can't load %s\n",infile);
exit(0);
}

if (*pe=='M' & *(pe+1)=='Z') { // exe file
puts("Executable file");
peoffset=*(wt_dword*)(pe+0x3c);
coffoffset=peoffset+4;
}
else {
puts("Object file");
coffoffset=0;
}

coffptr=(imagefileheader*)(pe+coffoffset);

nsections=coffptr->nsections;

sectionoffset=coffoffset+sizeof(imagefileheader)+coffptr->optheadersize;
sectionptr=(imagesectionheader*)(pe+sectionoffset);

printf("Nsections %d\n",nsections);

for (i=1; i<=nsections; ++i) {
printf("Section %d: %10.8s: Virtual Size=%6d Rawdata Size=%6d\n", i,
sectionptr->name,sectionptr->virtual_size,
sectionptr->rawdata_size);
++sectionptr;
}

}
--
bartc
bartc
2017-04-29 21:42:29 UTC
Reply
Permalink
Raw Message
Post by bartc
if (*pe=='M' & *(pe+1)=='Z') { // exe file
Should be && but will still work as both operands are 0 or 1.
fir
2017-04-29 22:37:16 UTC
Reply
Permalink
Raw Message
Post by bartc
Post by fir
Post by bartc
But it might take some days before I can show that info.
It wasn't quite that long...
Post by fir
i dubbled a tiny bit in it last hour and probably quick hack to this approach would be
void main()
{
for(int n = 0; n<number_of_sections; n++)
{
char* section_name = pe_image[0x178 + n*0x28];
int* section_size = (int*) pe_image[0x178 + n*0x28 + 8];
unsigned* section_flags = pe_image[0x178 + n*0x28 + 36];
//printf it
}
}
something like that, this 0x178 may depend on one or two previous fields but may be typical (im not sure as now for correct recipe for that value).. witt try that soon
I came up with this. It avoids using 'windows.h' should ought to run
#include <stdio.h>
#include <stdint.h>
typedef int16_t wt_word;
typedef int32_t wt_dword;
typedef struct {
wt_word machine;
wt_word nsections;
wt_dword timedatestamp;
wt_dword stpointer;
wt_dword nsymbols;
wt_word optheadersize;
wt_word characteristics;
} imagefileheader;
typedef struct {
char name[8];
union {
wt_dword physical_address;
wt_dword virtual_size;
};
wt_dword virtual_address;
wt_dword rawdata_size;
wt_dword rawdata_ptr;
wt_dword relocations_ptr;
wt_dword linenos_ptr;
wt_word nrelocs;
wt_word nlinenos;
wt_dword characteristics;
} imagesectionheader;
int getfilesize(FILE *handle) {
int p,size;
p = ftell(handle);
fseek(handle,0,2);
size = ftell(handle);
fseek(handle,p,0);
return size;
}
char *readfile(char *filename) {
FILE *f;
int size;
char *m;
f = fopen(filename,"rb");
if (f==0) {
return NULL;
}
size = getfilesize(f);
m = malloc(size);
if (m==NULL) {
return NULL;
}
fseek(f,0,0);
fread(m,1,size,f);
fclose(f);
return m;
}
int main(int nargs, char**args) {
char *infile;
char *pe;
int peoffset,coffoffset,sectionoffset,nsections;
int i;
imagefileheader *coffptr;
imagesectionheader *sectionptr;
if (nargs<2) {
printf("Usage: %s file.exe\n",args[0]);
printf(" %s file.obj\n",args[0]);
exit(0);
}
infile=args[1];
printf("Loading: %s\n",infile);
pe=readfile(infile);
if (pe==NULL) {
printf("Can't load %s\n",infile);
exit(0);
}
if (*pe=='M' & *(pe+1)=='Z') { // exe file
puts("Executable file");
peoffset=*(wt_dword*)(pe+0x3c);
coffoffset=peoffset+4;
}
else {
puts("Object file");
coffoffset=0;
}
coffptr=(imagefileheader*)(pe+coffoffset);
nsections=coffptr->nsections;
sectionoffset=coffoffset+sizeof(imagefileheader)+coffptr->optheadersize;
sectionptr=(imagesectionheader*)(pe+sectionoffset);
printf("Nsections %d\n",nsections);
for (i=1; i<=nsections; ++i) {
printf("Section %d: %10.8s: Virtual Size=%6d Rawdata Size=%6d\n", i,
sectionptr->name,sectionptr->virtual_size,
sectionptr->rawdata_size);
++sectionptr;
}
}
well tnx i come with (as first draft)

///////////////////////////////////////////

int GetFileSize1(FILE* file)
{
int seek_pos = ftell(file);
int error = fseek(file, 0, SEEK_END);

if(error) printf ("seek1 error"), exit (-1);

int file_length = ftell(file) ;
error = fseek(file, seek_pos, SEEK_SET);

if(error) printf ("seek2 error"), exit (-1);

return file_length;
}




int main(int argc, char **argv)
{
char* filename = NULL ;

if (argc>=2)
filename = argv[1];
else
printf ("\n this tiny program prints names and sizes of executable file sections (exe or dll) \n USE: firdump.exe filepath \n "), exit (-1);




FILE* file = fopen ( filename , "rb" );
if (!file) printf ("cant open file %s", filename), exit (-1);

static char pe_image[1024];
int result = fread (pe_image, 1, 1024, file);

int file_size = GetFileSize1(file);
fclose(file);

///////////

printf("\n --= fir's executable sections info =-- \n\n sections for %s ( %d bytes ) \n", filename, file_size);

int pe_header_offset = *((int*) &pe_image[0x3c]);
int size_of_image_file_header = 24;
short size_of_optional_header = *((short*) &pe_image[pe_header_offset+20]);
int sections_offset = pe_header_offset + size_of_image_file_header + size_of_optional_header;

short number_of_sections = *( (short*) &pe_image[pe_header_offset+6]);

for(int n = 0; n<number_of_sections; n++)
{
char* section_name = (char*) &pe_image[sections_offset + n*0x28];
int section_size = *((int*) &pe_image[sections_offset + n*0x28 + 8]);
unsigned section_flags = *((unsigned*) &pe_image[sections_offset + n*0x28 + 36]);

static char section_flags_binary_string [33];
itoa (section_flags, section_flags_binary_string, 2);

int percent_size = 100*section_size/file_size;
if(section_size>file_size)
printf("\n %10.8s %10d bytes %4s %33s", section_name, section_size, " ", section_flags_binary_string );
else
printf("\n %10.8s %10d bytes %4d%% %33s", section_name, section_size, percent_size, section_flags_binary_string );
}
printf("\n\n " );

////////////


}

it is the same, it gives for example

sections for c:\windows\system32\kernel32.dll ( 1018368 bytes )

.text 536777 bytes 52% 1100000000000000000000000100000
.data 17408 bytes 1% 11000000000000000000000001000000
.rsrc 446104 bytes 43% 1000000000000000000000001000000
.reloc 23680 bytes 2% 1000010000000000000000001000000


sections for c:\windows\system32\user32.dll ( 580096 bytes )

.text 389763 bytes 67% 1100000000000000000000000100000
.data 4480 bytes 0% 11000000000000000000000001000000
.rsrc 173924 bytes 29% 1000000000000000000000001000000
.reloc 11748 bytes 2% 1000010000000000000000001000000


sections for c:\windows\system32\gdi32.dll ( 285184 bytes )

.text 271738 bytes 95% 1100000000000000000000000100000
.data 4448 bytes 1% 11000000000000000000000001000000
.rsrc 960 bytes 0% 1000000000000000000000001000000
.reloc 6272 bytes 2% 1000010000000000000000001000000
fir
2017-04-30 09:36:23 UTC
Reply
Permalink
Raw Message
Post by bartc
Post by fir
Post by bartc
But it might take some days before I can show that info.
It wasn't quite that long...
Post by fir
i dubbled a tiny bit in it last hour and probably quick hack to this approach would be
void main()
{
for(int n = 0; n<number_of_sections; n++)
{
char* section_name = pe_image[0x178 + n*0x28];
int* section_size = (int*) pe_image[0x178 + n*0x28 + 8];
unsigned* section_flags = pe_image[0x178 + n*0x28 + 36];
//printf it
}
}
something like that, this 0x178 may depend on one or two previous fields but may be typical (im not sure as now for correct recipe for that value).. witt try that soon
I came up with this. It avoids using 'windows.h' should ought to run
#include <stdio.h>
#include <stdint.h>
typedef int16_t wt_word;
typedef int32_t wt_dword;
typedef struct {
wt_word machine;
wt_word nsections;
wt_dword timedatestamp;
wt_dword stpointer;
wt_dword nsymbols;
wt_word optheadersize;
wt_word characteristics;
} imagefileheader;
typedef struct {
char name[8];
union {
wt_dword physical_address;
wt_dword virtual_size;
};
wt_dword virtual_address;
wt_dword rawdata_size;
wt_dword rawdata_ptr;
wt_dword relocations_ptr;
wt_dword linenos_ptr;
wt_word nrelocs;
wt_word nlinenos;
wt_dword characteristics;
} imagesectionheader;
int getfilesize(FILE *handle) {
int p,size;
p = ftell(handle);
fseek(handle,0,2);
size = ftell(handle);
fseek(handle,p,0);
return size;
}
char *readfile(char *filename) {
FILE *f;
int size;
char *m;
f = fopen(filename,"rb");
if (f==0) {
return NULL;
}
size = getfilesize(f);
m = malloc(size);
if (m==NULL) {
return NULL;
}
fseek(f,0,0);
fread(m,1,size,f);
fclose(f);
return m;
}
int main(int nargs, char**args) {
char *infile;
char *pe;
int peoffset,coffoffset,sectionoffset,nsections;
int i;
imagefileheader *coffptr;
imagesectionheader *sectionptr;
if (nargs<2) {
printf("Usage: %s file.exe\n",args[0]);
printf(" %s file.obj\n",args[0]);
exit(0);
}
infile=args[1];
printf("Loading: %s\n",infile);
pe=readfile(infile);
if (pe==NULL) {
printf("Can't load %s\n",infile);
exit(0);
}
if (*pe=='M' & *(pe+1)=='Z') { // exe file
puts("Executable file");
peoffset=*(wt_dword*)(pe+0x3c);
coffoffset=peoffset+4;
}
else {
puts("Object file");
coffoffset=0;
}
coffptr=(imagefileheader*)(pe+coffoffset);
nsections=coffptr->nsections;
sectionoffset=coffoffset+sizeof(imagefileheader)+coffptr->optheadersize;
sectionptr=(imagesectionheader*)(pe+sectionoffset);
printf("Nsections %d\n",nsections);
for (i=1; i<=nsections; ++i) {
printf("Section %d: %10.8s: Virtual Size=%6d Rawdata Size=%6d\n", i,
sectionptr->name,sectionptr->virtual_size,
sectionptr->rawdata_size);
++sectionptr;
}
}
ps

wana you go further with this pe- related projects?
what directions?

(im presently resting and get bored a bit but i will need to learn it all i think anyway) wander if go sorta pe dumper just for ground understanding or what,

some new goal maybe?
fir
2017-04-30 10:07:09 UTC
Reply
Permalink
Raw Message
Post by fir
Post by bartc
Post by fir
Post by bartc
But it might take some days before I can show that info.
It wasn't quite that long...
Post by fir
i dubbled a tiny bit in it last hour and probably quick hack to this approach would be
void main()
{
for(int n = 0; n<number_of_sections; n++)
{
char* section_name = pe_image[0x178 + n*0x28];
int* section_size = (int*) pe_image[0x178 + n*0x28 + 8];
unsigned* section_flags = pe_image[0x178 + n*0x28 + 36];
//printf it
}
}
something like that, this 0x178 may depend on one or two previous fields but may be typical (im not sure as now for correct recipe for that value).. witt try that soon
I came up with this. It avoids using 'windows.h' should ought to run
#include <stdio.h>
#include <stdint.h>
typedef int16_t wt_word;
typedef int32_t wt_dword;
typedef struct {
wt_word machine;
wt_word nsections;
wt_dword timedatestamp;
wt_dword stpointer;
wt_dword nsymbols;
wt_word optheadersize;
wt_word characteristics;
} imagefileheader;
typedef struct {
char name[8];
union {
wt_dword physical_address;
wt_dword virtual_size;
};
wt_dword virtual_address;
wt_dword rawdata_size;
wt_dword rawdata_ptr;
wt_dword relocations_ptr;
wt_dword linenos_ptr;
wt_word nrelocs;
wt_word nlinenos;
wt_dword characteristics;
} imagesectionheader;
int getfilesize(FILE *handle) {
int p,size;
p = ftell(handle);
fseek(handle,0,2);
size = ftell(handle);
fseek(handle,p,0);
return size;
}
char *readfile(char *filename) {
FILE *f;
int size;
char *m;
f = fopen(filename,"rb");
if (f==0) {
return NULL;
}
size = getfilesize(f);
m = malloc(size);
if (m==NULL) {
return NULL;
}
fseek(f,0,0);
fread(m,1,size,f);
fclose(f);
return m;
}
int main(int nargs, char**args) {
char *infile;
char *pe;
int peoffset,coffoffset,sectionoffset,nsections;
int i;
imagefileheader *coffptr;
imagesectionheader *sectionptr;
if (nargs<2) {
printf("Usage: %s file.exe\n",args[0]);
printf(" %s file.obj\n",args[0]);
exit(0);
}
infile=args[1];
printf("Loading: %s\n",infile);
pe=readfile(infile);
if (pe==NULL) {
printf("Can't load %s\n",infile);
exit(0);
}
if (*pe=='M' & *(pe+1)=='Z') { // exe file
puts("Executable file");
peoffset=*(wt_dword*)(pe+0x3c);
coffoffset=peoffset+4;
}
else {
puts("Object file");
coffoffset=0;
}
coffptr=(imagefileheader*)(pe+coffoffset);
nsections=coffptr->nsections;
sectionoffset=coffoffset+sizeof(imagefileheader)+coffptr->optheadersize;
sectionptr=(imagesectionheader*)(pe+sectionoffset);
printf("Nsections %d\n",nsections);
for (i=1; i<=nsections; ++i) {
printf("Section %d: %10.8s: Virtual Size=%6d Rawdata Size=%6d\n", i,
sectionptr->name,sectionptr->virtual_size,
sectionptr->rawdata_size);
++sectionptr;
}
}
ps
wana you go further with this pe- related projects?
what directions?
(im presently resting and get bored a bit but i will need to learn it all i think anyway) wander if go sorta pe dumper just for ground understanding or what,
some new goal maybe?
ps
in probably all dlls there is .reloc section (dont know
as to exe, do you know maybe how exactly this work?)
bartc
2017-04-30 10:18:26 UTC
Reply
Permalink
Raw Message
Post by fir
ps
in probably all dlls there is .reloc section (dont know
as to exe, do you know maybe how exactly this work?)
Not yet. I understand .obj needs reloc info, but .exe is created to work
at a specific address.

.dll is less important to me as they are only created infrequently and I
might be able to use regular tools.

But this where a proper dump routine (better when you write it yourself)
can show the differences. So you learn, after trying to create the
string table for a .exe and it crashes, that string tables only exist
for .obj.
--
bartc
fir
2017-04-30 10:31:03 UTC
Reply
Permalink
Raw Message
Post by bartc
Post by fir
ps
in probably all dlls there is .reloc section (dont know
as to exe, do you know maybe how exactly this work?)
Not yet. I understand .obj needs reloc info, but .exe is created to work
at a specific address.
.dll is less important to me as they are only created infrequently and I
might be able to use regular tools.
But this where a proper dump routine (better when you write it yourself)
can show the differences. So you learn, after trying to create the
string table for a .exe and it crashes, that string tables only exist
for .obj.
for me .dll is much important (even probably more important than exe as dll seems like more general (has exports) and also is working really well) .obj is now
not much mportant to me - i used it for some years but droped it, i now generate dll's which i prefer (they replaced .obj for me)
Robert Wessel
2017-04-30 16:36:43 UTC
Reply
Permalink
Raw Message
Post by bartc
Post by fir
ps
in probably all dlls there is .reloc section (dont know
as to exe, do you know maybe how exactly this work?)
Not yet. I understand .obj needs reloc info, but .exe is created to work
at a specific address.
Only by default. You can ask the linker to include relocation
information for EXEs. And you can ask the linker to *omit* relocation
information from DLLs (thereby forcing them to execute only at the
base address resolved by the linker).

Adding relocation information to EXEs has become more popular on
Windows, since Windows (since Vista?) supports ASLR. ASLR also can be
disabled at the system level.
bartc
2017-04-30 10:11:26 UTC
Reply
Permalink
Raw Message
Post by fir
wana you go further with this pe- related projects?
what directions?
(im presently resting and get bored a bit but i will need to learn it all i think anyway) wander if go sorta pe dumper just for ground understanding or what,
some new goal maybe?
I'm looking at replacing dependencies such as assemblers and linkers
because what are available at the minute are slow and unreliable.

One product (Nasm) is so slow as to be unusable (it can be 1000 times
slower to turn .asm into .obj, as it takes me to turn .c into .asm).

Also I don't like external dependencies.

So I need to generate .obj and possibly .exe myself. For that I need to
fully understand how they work. I've never bothered before (for PE
format) because it looked dull, fiddly work.
--
bartc
fir
2017-04-30 10:24:20 UTC
Reply
Permalink
Raw Message
Post by bartc
Post by fir
wana you go further with this pe- related projects?
what directions?
(im presently resting and get bored a bit but i will need to learn it all i think anyway) wander if go sorta pe dumper just for ground understanding or what,
some new goal maybe?
I'm looking at replacing dependencies such as assemblers and linkers
because what are available at the minute are slow and unreliable.
One product (Nasm) is so slow as to be unusable (it can be 1000 times
slower to turn .asm into .obj, as it takes me to turn .c into .asm).
Also I don't like external dependencies.
So I need to generate .obj and possibly .exe myself. For that I need to
fully understand how they work. I've never bothered before (for PE
format) because it looked dull, fiddly work.
well it is..

i got the same attitude also like my own code which is far mole flexible also grants important understanding

if so we could do some tasks in parrallel posting a bit
on some inner topics.. important is only to do it with small/slight steps one after another

so maybe next goal to dump a bit more info from those executables?

(ps my code posted is badly shaped i know, but it is becouse i do not code edge cases firstly also do not
shape code stylistically firstly (just to spare as
much energy i can) - anyway one must establish some level on which one think "this code is ENOUGH good"
and it is not excluded that setting this level lower
is better than setting it higher (i know using structs and do some edge case checking, reformating names and
shape etc is in fact better.. but form other point of view go worse is better - so i write this disclimer
to say that for sure i know thic coede i post could
look better but i also deny to tace comments on this as i code how i code for some practical purpose and dont like to meet morons with their stupid comments like your code is ugly ;c hope im understood)
fir
2017-05-01 10:03:45 UTC
Reply
Permalink
Raw Message
So I need to generate .obj and possibly .exe myself. For that I need to
Post by bartc
fully understand how they work. I've never bothered before (for PE
format) because it looked dull, fiddly work.
in fact going thru such specifications (topics based on some
documentations) its partially like debugging

where in debugging you need sometimes hard way to find a
source of the bugs in a crowd of code here you need to find
the most important points in the crowd of documentation/tutorial
sentences - and it is sorta hard as debugging

i remember a couple of such cases in my life - opengl, opencl,
this pe format, winapi itself, .. other topics are also based on documentation mixed with sorta domain knowledge (related to matchematics of physics etc or hardware).. it is for example
3d graphics rasteristation pipeline or raytracing, 2d physics
etc.. it is allso all hard as itmakes people not doing stright
writing/designing but makes them dwell in this virtuall debugging
of topics
fir
2017-05-01 10:46:59 UTC
Reply
Permalink
Raw Message
Post by bartc
So I need to generate .obj and possibly .exe myself. For that I need to
Post by bartc
fully understand how they work. I've never bothered before (for PE
format) because it looked dull, fiddly work.
in fact going thru such specifications (topics based on some
documentations) its partially like debugging
where in debugging you need sometimes hard way to find a
source of the bugs in a crowd of code here you need to find
the most important points in the crowd of documentation/tutorial
sentences - and it is sorta hard as debugging
i remember a couple of such cases in my life - opengl, opencl,
this pe format, winapi itself, .. other topics are also based on documentation mixed with sorta domain knowledge (related to matchematics of physics etc or hardware).. it is for example
3d graphics rasteristation pipeline or raytracing, 2d physics
etc.. it is allso all hard as itmakes people not doing stright
writing/designing but makes them dwell in this virtuall debugging
of topics
probably the more good situation in programming would be
'linear reading' and 'linear writing' (instead of such
'debuglike reading' 'debuglike writing') but it is not easy
obtainable, if fully obtainable at all

can mantion even after that (where i got probably some moments of
linear writing etc) it is still wery tiredmaking / on the other side
it has some pluses (there is some beauty in coding and architecture for sure) and when im rested i feel partially ok with coding
GOTHIER Nathan
2017-04-30 14:10:44 UTC
Reply
Permalink
Raw Message
On Sat, 29 Apr 2017 22:08:24 +0100
Post by bartc
int getfilesize(FILE *handle) {
int p,size;
p = ftell(handle);
fseek(handle,0,2);
size = ftell(handle);
fseek(handle,p,0);
return size;
}
Let me suggest you this instead:

#include <errno.h>
#include <stdio.h>
#include <stdlib.h>

long fgetsize(FILE *stream)
{
fpos_t pos;

int n = fgetpos(stream, &pos);

if (n == 0)
{
n = fseek(stream, 0, SEEK_END);

if (n == 0)
{
long size = fell(stream);

if (size != -1L)
{
n = fsetpos(stream, &pos);

if (n == 0)
{
return size;
}
}
}
}

perror(NULL);
exit(EXIT_SUCCESS);
}
Chad
2017-04-30 17:43:23 UTC
Reply
Permalink
Raw Message
Post by GOTHIER Nathan
On Sat, 29 Apr 2017 22:08:24 +0100
Post by bartc
int getfilesize(FILE *handle) {
int p,size;
p = ftell(handle);
fseek(handle,0,2);
size = ftell(handle);
fseek(handle,p,0);
return size;
}
#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
long fgetsize(FILE *stream)
{
fpos_t pos;
int n = fgetpos(stream, &pos);
if (n == 0)
{
n = fseek(stream, 0, SEEK_END);
if (n == 0)
{
long size = fell(stream);
if (size != -1L)
{
n = fsetpos(stream, &pos);
if (n == 0)
{
return size;
}
}
}
}
perror(NULL);
exit(EXIT_SUCCESS);
}
Alex, I'll take deferred initialization abuses for $200.
GOTHIER Nathan
2017-04-30 21:59:34 UTC
Reply
Permalink
Raw Message
On Sun, 30 Apr 2017 10:43:23 -0700 (PDT)
Post by Chad
Alex, I'll take deferred initialization abuses for $200.
I'm afraid you confused initializations with assignments. ;-)
fir
2017-05-01 13:06:55 UTC
Reply
Permalink
Raw Message
Post by bartc
Post by fir
Post by bartc
But it might take some days before I can show that info.
It wasn't quite that long...
Post by fir
i dubbled a tiny bit in it last hour and probably quick hack to this approach would be
void main()
{
for(int n = 0; n<number_of_sections; n++)
{
char* section_name = pe_image[0x178 + n*0x28];
int* section_size = (int*) pe_image[0x178 + n*0x28 + 8];
unsigned* section_flags = pe_image[0x178 + n*0x28 + 36];
//printf it
}
}
something like that, this 0x178 may depend on one or two previous fields but may be typical (im not sure as now for correct recipe for that value).. witt try that soon
I came up with this. It avoids using 'windows.h' should ought to run
#include <stdio.h>
#include <stdint.h>
typedef int16_t wt_word;
typedef int32_t wt_dword;
typedef struct {
wt_word machine;
wt_word nsections;
wt_dword timedatestamp;
wt_dword stpointer;
wt_dword nsymbols;
wt_word optheadersize;
wt_word characteristics;
} imagefileheader;
typedef struct {
char name[8];
union {
wt_dword physical_address;
wt_dword virtual_size;
};
wt_dword virtual_address;
wt_dword rawdata_size;
wt_dword rawdata_ptr;
wt_dword relocations_ptr;
wt_dword linenos_ptr;
wt_word nrelocs;
wt_word nlinenos;
wt_dword characteristics;
} imagesectionheader;
int getfilesize(FILE *handle) {
int p,size;
p = ftell(handle);
fseek(handle,0,2);
size = ftell(handle);
fseek(handle,p,0);
return size;
}
char *readfile(char *filename) {
FILE *f;
int size;
char *m;
f = fopen(filename,"rb");
if (f==0) {
return NULL;
}
size = getfilesize(f);
m = malloc(size);
if (m==NULL) {
return NULL;
}
fseek(f,0,0);
fread(m,1,size,f);
fclose(f);
return m;
}
int main(int nargs, char**args) {
char *infile;
char *pe;
int peoffset,coffoffset,sectionoffset,nsections;
int i;
imagefileheader *coffptr;
imagesectionheader *sectionptr;
if (nargs<2) {
printf("Usage: %s file.exe\n",args[0]);
printf(" %s file.obj\n",args[0]);
exit(0);
}
infile=args[1];
printf("Loading: %s\n",infile);
pe=readfile(infile);
if (pe==NULL) {
printf("Can't load %s\n",infile);
exit(0);
}
if (*pe=='M' & *(pe+1)=='Z') { // exe file
puts("Executable file");
peoffset=*(wt_dword*)(pe+0x3c);
coffoffset=peoffset+4;
}
else {
puts("Object file");
coffoffset=0;
}
coffptr=(imagefileheader*)(pe+coffoffset);
nsections=coffptr->nsections;
sectionoffset=coffoffset+sizeof(imagefileheader)+coffptr->optheadersize;
sectionptr=(imagesectionheader*)(pe+sectionoffset);
printf("Nsections %d\n",nsections);
for (i=1; i<=nsections; ++i) {
printf("Section %d: %10.8s: Virtual Size=%6d Rawdata Size=%6d\n", i,
sectionptr->name,sectionptr->virtual_size,
sectionptr->rawdata_size);
++sectionptr;
}
}
--
bartc
this naming convention all lowercase no underlines i weird, rarely seen that, though its thin, seems oldschool though im not sure even KT & DR used that (dont remember)

could you maybe remember me what is with that obj? they dont have dos header and start from coff?

ps.. if you check MZ signature here you could also check the PE also, MZ has small chance to be random or crafted
in like text file, MZ+PE is really nearli zero chance to random and needs someone who knows what he do if he will craft it so it is far better check

Now im upgrading a bit my program (i named it firex - fir executable examiner ;c ) quite nice to write after going thru this first obstacle of pe crap
bartc
2017-05-01 13:25:37 UTC
Reply
Permalink
Raw Message
Post by fir
Post by bartc
wt_dword timedatestamp;
} imagesectionheader;
this naming convention all lowercase no underlines i weird, rarely seen that, though its thin, seems oldschool though im not sure even KT & DR used that (dont remember)
With all lower case, you don't have to remember which bits are upper and
which bits are lower, as used in the MS original specs. I do use
underscores but not here much, and this is only temporary code while I
investigate exe.

(I think I will only do exe, not obj; for the latter I can use my own
format, or I can go straight to exe. That is generating exe files. But
I've had to put this aside now as I need to finish something else.)
Post by fir
could you maybe remember me what is with that obj? they dont have dos header and start from coff?
I've never looked closely until now. Yes, object files, in this COFF
format, seem to start with IMAGE_FILE_HEADER without the MZ/PE stuff or
signature. Object files have a symbol and string table, but EXE don't.
EXE files always have the 'optional' header, but object files don't. Etc.

It would have been simpler to have kept them separate formats I think!
Post by fir
ps.. if you check MZ signature here you could also check the PE also, MZ has small chance to be random or crafted
in like text file, MZ+PE is really nearli zero chance to random and needs someone who knows what he do if he will craft it so it is far better check
I posted a cut-down C version of the actual code which is in a more
dynamic language. That doesn't check PE but it does display the
signature. If there's something wrong, then it will be obvious as the
data will be nonsense.
Post by fir
Now im upgrading a bit my program (i named it firex - fir executable examiner ;c ) quite nice to write after going thru this first obstacle of pe crap
Yes, but there's a lot of it. And it's not immediately clear what is
important and what isn't until it's investigated.
--
bartc
Robert Wessel
2017-05-01 17:20:41 UTC
Reply
Permalink
Raw Message
Post by bartc
Post by fir
Post by bartc
wt_dword timedatestamp;
} imagesectionheader;
this naming convention all lowercase no underlines i weird, rarely seen that, though its thin, seems oldschool though im not sure even KT & DR used that (dont remember)
With all lower case, you don't have to remember which bits are upper and
which bits are lower, as used in the MS original specs. I do use
underscores but not here much, and this is only temporary code while I
investigate exe.
(I think I will only do exe, not obj; for the latter I can use my own
format, or I can go straight to exe. That is generating exe files. But
I've had to put this aside now as I need to finish something else.)
Post by fir
could you maybe remember me what is with that obj? they dont have dos header and start from coff?
I've never looked closely until now. Yes, object files, in this COFF
format, seem to start with IMAGE_FILE_HEADER without the MZ/PE stuff or
signature. Object files have a symbol and string table, but EXE don't.
EXE files always have the 'optional' header, but object files don't. Etc.
It would have been simpler to have kept them separate formats I think!
The requirements of an executable image format are pretty obviously a
fair subset of the requirements for an object module format. And COFF
and ELF executables are really just that - a somewhat simplified
version of the object module format.

jacobnavia
2017-04-29 14:06:33 UTC
Reply
Permalink
Raw Message
Post by fir
if you got exe or dll the most important sections are .code .data .const and .bss
need a simple console program that show the size of the code
(in bytes and also in percent) in given .exe .dll [also sieze of consts and initialised data, yet size of static arrays]
i think it will be simple like less than 100 lines probably
(maybe even more like 30 or 50) but needs a moment to write
some pieces?
(i can vrite it alone but posted this idea and question as i find it good and usefull)
If you have lcc-win32 you write:

pedump /summary Myprogram.exe

You will get the size of the sections text(code) data, bss and debug (if
any)
fir
2017-04-29 14:12:27 UTC
Reply
Permalink
Raw Message
Post by jacobnavia
Post by fir
if you got exe or dll the most important sections are .code .data .const and .bss
need a simple console program that show the size of the code
(in bytes and also in percent) in given .exe .dll [also sieze of consts and initialised data, yet size of static arrays]
i think it will be simple like less than 100 lines probably
(maybe even more like 30 or 50) but needs a moment to write
some pieces?
(i can vrite it alone but posted this idea and question as i find it good and usefull)
pedump /summary Myprogram.exe
You will get the size of the sections text(code) data, bss and debug (if
any)
i need source.. you could put those few lines
(but anyway i will write it too it is not hard some
few reads at some offsets in file nad printfs to console thats all)
Loading...