just learned something about PE file from the tutorial. and i thought of a way to create a software without assembler. :green2
but i still haven't figured out something in a PE file. can i talk about that here?
Quote from: supercoollee on May 01, 2010, 06:03:44 PM
just learned something about PE file from the tutorial. and i thought of a way to create a software without assembler. :green2
but i still haven't figured out something in a PE file. can i talk about that here?
It depends.
You can talk/ask about it IF it does not break the rules. When in doubt please do present the purpose of your program / applications in a very clear and open way and/or ask a moderator. From what info you have written here it is still unclear. And if you had to ask it is a "gray" start anyway.
General questions about the PE structure are usually OK.
A decission is usually made once a real question is asked and once "enough" information about your target and application is presented or because of failure to present such information when asked by a member or a moderator.
For example if you want to modify an PE file that you have not created yourself then we usually do not allow it in here because it can also be used for malware. Yes we do know the "ambiguity" resulting from the fact that it can also be used for packers and protectors. However many times those are also used to "pack" and "protect" or obfuscate malware and there is no way we can safely decide your real intentions over the internet.
Once you become experienced enough from making many "standard" ASM apllications you should also become able (all by yourself and without our help here) to make your own "security" or "packer" or "protector" or wahtever "monitor" or "hooking" application and you will also have to bear the risks and responsability for doing it yourself.
We simply can not aford the risk to allow such code and explanations in here in order to be accesed by "any internet ID/kid".
Besides, as it has been said many times, there are many other sites that have such content and also have a more imature attitude on this subject BUT in here we do like to keep this site / foum clean of such "nonsense".
Hence if your question or interests are clean of such issues then it is OK to post and/or ask otherwise it will get deleted or locked fast.
PS.
- this link about PE might be of interest: http://msdn.microsoft.com/en-us/magazine/cc301805.aspx
here is a document that may be of some help, converted to PDF by Hutch
http://www.masm32.com/board/index.php?action=dlattach;topic=13135.0;id=7165
also, Erol (Vortex) is pretty sharp when it comes to this kind of stuff - his ste...
http://www.vortex.masmcode.com/
i plan to create a simple game with OPENGL graphics and sound.
due to my knowledge in mnemonics codes and lack of knowledge in assembler syntax, i think it's easier for me to create an PE file with an HEX editor, then write mnemonics codes in the file, as long as i know how to call the functions in DLLs.
so the part that enable me to use windows build-in functions is the IMPORT TABLE, and the parameters for each callee. then i can focus on my own program.
my way to construct an PE file is to write header, import table, data, program codes. i think an assembler is doing this job, but if i can do it myself, i don't need to learn the rules/syntax in an assembler.
now what i need to know is the rules of import table, and how to find out the parameters for the functions in DLLs.
supercoollee,
you really think that creating programs with an hexeditor is easier than writing assembler? :dazzled:
i use softwares with dissemble/assemble functions to help me convert mnemonics into opcodes, then i write opcodes into file with HEX editor.
i find mnemonics codes to be shorter in each line, hence easier to read. and there are not too many forms of mnemonics - i don't need to remember something like this : glGetIntegerv glGetTexLevelParameterfv . i only need to look them up in a table when i call a function.
The tool for creating the PE file is the linker. I don't think I'd be trying to generate PE files manually in a hex editor, it is more of a task you'd want to automate in a higher level language designed to handle structures and file.
The PE file format is well documented, and there are obviously tens of thousands examples to look at or examine.
You really need to understand how to use assemblers, compilers and linkers first. If you think they are complicated, then you're going to get very frustrated with the hex editor.
wow ... you want to say that something like this:
E8 0C 00 00 00is easyer to read than:
call SensefulApiName
However, all related documents has been shown in privious posts - read them.
it is much easier to learn assembler
you don't have to learn all the syntax, like macros and if/while structures
i don't use those things much, myself
but, the hours you spend learning the basics will be useful over and over again
the hours you spend entering code "manually" will not be useful again - only for this one program
poke around on the forum - try to find some simple programs that do not use advanced syntax
here are some links to programs/routines i have written that use basic assembler syntax
http://www.masm32.com/board/index.php?action=dlattach;topic=12363.0;id=7070
http://www.masm32.com/board/index.php?action=dlattach;topic=13233.0;id=7204
http://www.masm32.com/board/index.php?action=dlattach;topic=13044.0;id=7094
http://www.masm32.com/board/index.php?action=dlattach;topic=11963.0;id=6537
Just to give you an idea of the scope of what you are trying to do, make a program in masm32 which consists of just a ret. Dump that with a hex editor and compare it with the source you just wrote..
Quote from: supercoollee on May 02, 2010, 01:24:28 AM
i plan to create a simple game with OPENGL graphics and sound.
OpenGL does not have sound. Also in Windows it is better to use DirectX for games. The only reason to use OpenGL is to obtain compatibility with Unix / Linux since DirectX is not available on those operating systems.
Then, considering doing a game in OpenGL/ Windows by writting raw hex numbers in a file is "priceless" :P
Quote
due to my knowledge in mnemonics codes and lack of knowledge in assembler syntax,
I see. Then I ask: how have you obtained this "exhaustive" knowledge in menemonics :D eh? I do hope it was not by disassembling and reversing other people's work; but I suspect it was.
And I also guess that once you have made the effort and learn some "assembler syntax" you will realize that it is much easier to use an assembler in order to write an application in ASM when compared to using raw opcodes written with a hex editor into an handcrafteed PE file.
Besides, unless you have a "savant" kind of mental disorder it is impossible to remember and know all of the x86 and x64 hex values for all variations.
However it is kind of easy for most people to remember mnemonics like: MOV, ADD, SUB, XOR, CALL or even INVOKE, .IF eax == 1 .ELSE ... .ENDIF.
Ancient greeks established that for ease of memorization it is better to use 3 or 4 letter "menemonics" that have a simple meaning instead of more complicated details like a plain sequence of numbers. That is how the brain works.
Mnemonics: ADD, XOR, SUB, RAX, CALL, INVOKE, .IF EQU
Opcodes: b6, FF, 25, B8, E8,
Do you really know the hex opcodes for:
mov eax,[esi+4*ecx+0dbc5837h]
xor ebx,[ebp+16h]
fld [edi+ecx-3]
popcnt ecx,[esi+ebx+13h]
pcmpestri xmm7,oword ptr [r12+r9+0bc7856h],packed_signed_words+force_true+equal
DO you really know them by heart, without checking any Intel documents or other opcode maps or manuals? I find this kind of statements hard to belive and I really think you are making fun of us here and that is not nice :P
Now I see your posts as one of 3 options:
a) you are joking
b) an "elaborated" hoax in order to obtain information for malware and circumvent forum rules
c) extremely naive
Quote
i think it's easier for me to create an PE file with an HEX editor, then write mnemonics codes in the file, as long as i know how to call the functions in DLLs.
You "think" wrong.
Creating an application is much more than writting opcodes in a hex file by hand and calling system functions in DLL's. For example it is about logic and algorithms and here you will have huge problems with raw opcodes because changing the game logic or an algorithm or it's implementation can trigger a wave of thousands of changes into opcodes. This is handled by the assembler but you will have to do it by hand.
Quote
so the part that enable me to use windows build-in functions is the IMPORT TABLE, and the parameters for each callee. then i can focus on my own program.
No, you will not be able to focus on you own program. Instead you will always have to adjust the import tables and the call's to them and patch thousands of locations in your file and remember thousands of numbers to symbol mappings ... for ever and ever until the end of your "coding". Not a very funny perspective.
However an assembler does all this calculations and fixes and mappings in a blink of an eye and never gets tired or bored of doing it and it never makes any mistake. Can you change 1000 "random" places in your code with the hex editor in under 1 seccond?
I agree that one can make a small PE file "by hand" once in his lifetime. You can do it for fun or for testing or to get a deeper understanding of it's raw structures and how they relate .... but after that "once" there is no need to keep doing it.
Alternatively you can also gain this kind of understanding by reading the PE documentation and viewing a few example PE files with PEView or Lord PE and checking them in Ollydebug.
Quote
my way to construct an PE file is to write header, import table, data, program codes. i think an assembler is doing this job, but if i can do it myself, i don't need to learn the rules/syntax in an assembler.
Hmmm ... "your way" ;) IMHO you do think wrong again.
Yes, it is true that some assemblers can create a PE directly but the standard way for assemblers is to create an OBJ file and that OBJ file is linked by the LINKER with other libraries for DLL's or for other static LIBS and from this linking it results the final PE executable file. If you do not handle OBJ's and linking then you loose to posibility to use external static libraries.
Then an assembler does a LOT more than just to create an PE file. In fact creating the PE or OBJ files is a "trivial" task for the assembler.
Here is a fast list of a few things done by an assembler:
===================================
1) it generates the raw hex opcodes for you for all the combinations of registers, memory operands, and variations
2) it calculates and fixes offsets for jumps and instructions or data references when those change (and they change offten)
3) it keeps tracks of labels locations in code
4) it allows you to use meaningfull human readable names for all symbols (instead of plain numbers)
5) it keeps tracks of data sizes and types
6) allows you to use STRUCTURES, EQU and ENUM to organize data access
7) keeps tracks of functions parameters count and types and sizes with PROTO, PROC / ENPPROC, LOCALS, ARGS, INVOKE
8) allows you to use .IF .ELSE .ENDIF, .WHILE .ENDWHILE in order to give structure and organization to your code and algorithms
9) handles MACROs for automating repetitive tasks
You can avoid using some of the High level stuf if you intend to make only very small and super optimized code fragments.
Howeve IMHO you can not avoid PROC and INVOKE and .IF .ELSEIF .ENDIF and MACRO's when you intend to make a full application in ASM... Not when you "intend" to make something like in an "OpenGL game" in ASM :P
Quote
now what i need to know is the rules of import table, and how to find out the parameters for the functions in DLLs.
I do not think that you really need to know this.
However the "rulles" for IMPORT TABLE are clearely written in the documents/links that so many kind people have provided in their posts above. The parameters for functions in DLL's are stated in MSDN or API help files that can be downloaded even from this site.
Let us know if you "think" that you need something "else" also :D
Quote from: BogdanOntanu on May 02, 2010, 01:48:05 PM
Howeve IMHO you can not avoid PROC and INVOKE and .IF .ELSEIF .ENDIF and MACRO's when you intend to make a full application in ASM... Not when you "intend" to make something like in an "OpenGL game" in ASM.
I disagree but i don't have a full application to prove it yet :)
Quote from: joemc on May 03, 2010, 01:09:37 AM
Quote from: BogdanOntanu on May 02, 2010, 01:48:05 PM
Howeve IMHO you can not avoid PROC and INVOKE and .IF .ELSEIF .ENDIF and MACRO's when you intend to make a full application in ASM... Not when you "intend" to make something like in an "OpenGL game" in ASM.
I disagree but i don't have a full application to prove it yet :)
You disagree about avoiding PROC ? You kidding me ? How do you go about making your code reusable ? Jumps ?
Slugsnack,
proc does not do that much for you, and does not prevent you from using call. But it does do some tedious work, and I generally use proc. I read his "and"s to mean mean using the invoke/proc pair. I generally avoid invoke because i pass pointers often and i prefer to push them myself because i run in to problems with invoke. Definitely nothing wrong with invoke, i just prefer it the other way. The other part of his AND was the .IF .ELSEIF .ENDIF which i avoid since my plan is to learn assembly, and i don't think they are required for a full application. Regardless writing an OpenGL game in a hex editor instead of assembly because it is "easier" does sound a little bit like a joke.
Quote from: BogdanOntanu on May 02, 2010, 01:48:05 PM
Howeve IMHO you can not avoid PROC and INVOKE and .IF .ELSEIF .ENDIF and MACRO's when you intend to make a full application in ASM... Not when you "intend" to make something like in an "OpenGL game" in ASM :P
As you say, that is your opinion, I agree with PROC/INVOKE, automating the stack frame and call make for much clearer code, but runtime conditionals are not necessary and neither are macros. I write applications in ASM and rarely use macros and runtime conditionals are not available to me.
Edgar
I think Bogdan is very much on the money here, while most old timers can in fact edit binary code in hex, it is not a viable method to create working executable files from scratch and the suggestion that it is from a person who is not experienced in assembler programming is simply nonsense.
Discussions about the structure of PE files are in fact reasonable but re-interpreting them in the context of manually editing existing binary files has little to do with PE specs and much more to do with activities that are closer to cracking than programming.
This topic is dead if it even hints in that direction.
ok, i have tried to read some example source codes and start to understand the codes in the "low level mnemonics" way.
now what i need is the explanations of the functions in DLLs, starting with creating a window. where should i find them? i prefer CHM files or PDF files if there is any.
BTW: i did successfully bloat up opengl.exe in /examples/ folder to 4Mbytes in size, in case i want to program in that way. but now it's not necessary.
there are a variety of ways to get info about API functions
a good starting point is MSDN online library
http://msdn.microsoft.com/en-us/library/ms123401(v=MSDN.10).aspx
which, btw, i don't care for their new format because i was used to the old one
you won't have that problem :P
you can plug an API function name into google and usually the MSDN library entry will be first in the list
for example, try typing "ExitiProcess" into google
this is also true for most structure and lib equate names
Quote from: supercoollee on May 03, 2010, 09:24:14 AM
ok, i have tried to read some example source codes and start to understand the codes in the "low level mnemonics" way.
now what i need is the explanations of the functions in DLLs, starting with creating a window. where should i find them? i prefer CHM files or PDF files if there is any.
You can also check Iczelion's tutorials for creating a simple window and other simple API examples. This should get you started and familiar with the Windows API and basic concepts of Windows programming. You need to understand this basic API stuff very well before moving into more advanced topics like OpenGL or DirectX.
Quote
BTW: i did successfully bloat up opengl.exe in /examples/ folder to 4Mbytes in size, in case i want to program in that way. but now it's not necessary.
Adding null bloatware to an PE is usually not a problem but things will get out of control fast when you try to fix labels and jumps and code references and/or when you insert new code in complex algorithms.