d2jsp
Log InRegister
d2jsp Forums > Off-Topic > Computers & IT > Programming & Development > X64 Assembly
Prev12
Add Reply New Topic New Poll
Member
Posts: 13,425
Joined: Sep 29 2007
Gold: 0.00
Warn: 20%
Feb 18 2013 01:31pm
Quote (SelfTaught @ Feb 18 2013 12:47pm)
That made more sense.

Alright thanks for the suggestion. Once I start playing around and getting more comfortable with Linux I'll download it and give it a gander.

I bought "Assembly language and Computer Architecture using C++ and Java" just recently and so far it's been a really great book. It's kind of old but it explains everything very well and in depth.

Assembly seems like it's going to be relatively easy to learn, I just can't wait until I can start using it to for the exciting stuff  :D


yea assembly is really fun to just dick around in, but if you want to write anything meaningful id always go to a high level language like C simple because i dont want to spend hours deving on one function.

for example a friend made a quick C app to search all open file descriptors for his active socket using getpeername() and it was done in like 20 minutes.

he tried to port it to asm. everything is right all his syscalls are there, but no matter what getpeername() doesnt want to write to the stack pointer address he gives it. since he is also stubborn he refuses to use a mmap'ed address like i told him to do which is understandable seeing as the sockaddr_in struct is only 16 bytes in size.
Member
Posts: 1,358
Joined: Dec 30 2012
Gold: 0.10
Feb 18 2013 02:25pm
Quote (AbDuCt @ Feb 18 2013 11:31am)
yea assembly is really fun to just dick around in, but if you want to write anything meaningful id always go to a  high level language like C simple because i dont want to spend hours deving on one function.

for example a friend made a quick C app to search all open file descriptors for his active socket using getpeername() and it was done  in like 20 minutes.

he tried to port it to asm. everything is right all his syscalls are there, but no matter what getpeername() doesnt want to write to the stack pointer address he gives it. since he is also stubborn he refuses to use a mmap'ed address like i told him to do which is understandable seeing as the sockaddr_in struct is only 16 bytes in size.


Don't some (meaningful) things have to be coded in assembly like a bios, a digital clock, or similar things?

Haha that's annoying. Why is it understandable that he didn't want to use mmap because sockaddr_in is 16 bytes?

and I looked up the sockaddr_in struct on msdn out of curiosity to see if I could figure out how it was 16 bytes in size.

Is this right?

Code
struct sockaddr_in{
 short sin_family; // 2 bytes
 unsigned short sin_port;// 2 bytes
 IN_ADDR sin_addr; // 4 bytes?
 char sin_zero[8]; // 8 bytes
};


Member
Posts: 13,425
Joined: Sep 29 2007
Gold: 0.00
Warn: 20%
Feb 18 2013 04:24pm
Quote (SelfTaught @ Feb 18 2013 04:25pm)
Don't some (meaningful) things have to be coded in assembly like a bios, a digital clock, or similar things?

Haha that's annoying. Why is it understandable that he didn't want to use mmap because sockaddr_in is 16 bytes?

and I looked up the sockaddr_in struct on msdn out of curiosity to see if I could figure out how it was 16 bytes in size.

Is this right?

Code
struct sockaddr_in{
 short sin_family; // 2 bytes
 unsigned short sin_port;// 2 bytes
 IN_ADDR sin_addr; // 4 bytes?
 char sin_zero[8]; // 8 bytes
};


yes that is correct chars are always 1 byte in size. as for the rest they can change depending on what type they are. aka int and longs are 4 bytes, shorts are 2 bytes and yea.

reason why he didnt want to use mmap is because it creates memory for him and returns the address to the start of the memory block kind of like malloc in C. well for a measily 16 bytes it not only adds at least 5-7 lines of asm code but now you have an external memory source to worry about and deallocate. writing to the stack on the other hand is literally 1-2 lines (you just move the esp address down 16 bytes to make room for the data then supply that address to the function). although as you can see sometimes less code means more hassle.

another thing i like about asm is that you can combine multiple statements into one line.

take this snippet for example.

Code

sub $0x10, %esp      #move %esp down 16 bytes
movl %esp, %eax     #move modified %esp into %eax


can also be expressed as

Code

lea -0x10(%esp), %eax   #load effective address of %esp - 16 and store it in %eax


if you want to learn more about asm and more of its uses you can visit blackhat library.

http://www.blackhatlibrary.net/Shellcode/Appendix

that link is their appendix of shellcode (code used in overflow exploits. some of it which i contributed to. (mostly all the 32bit stuff))

http://www.blackhatlibrary.net/Assembly

that is a general assembly page which goes over the basics of the language. instructions, registers, standard sizes such as short, long, byte, ascii, char, halfword, word, doubleword, quadword, etc.

http://www.blackhatlibrary.net/Buffer_overflow

that one describes buffer overflows (on linux of course lol) and describes some common techniques to protect against them and as well as bypass them. it even has an example program you can compile and attack against and follow along the steps to create a successful buffer overflow.

http://www.blackhatlibrary.net/Alphanumeric_shellcode

alphanumeric shellcode is shellcode using instructions whose bytes are within the printable ascii range. these are generally harder to create because of lack of intstructions but they bypass IDS systems because they look like normal garbled text. such as

"TX4HPZTAZAYVH92"

translates into

Code
[root@ares bha]# objdump -d xarch32.o

xarch32.o:     file format elf32-i386

Disassembly of section .text:
00000000 <_start>:
  0:   54                      push   %esp
  1:   58                      pop    %eax
  2:   34 48                   xor    $0x48,%al
  4:   50                      push   %eax
  5:   5a                      pop    %edx
  6:   54                      push   %esp
  7:   41                      inc    %ecx
  8:   5a                      pop    %edx
  9:   41                      inc    %ecx
  a:   59                      pop    %ecx
  b:   56                      push   %esi
  c:   48                      dec    %eax
  d:   39 32                   cmp    %esi,(%edx)
[root@ares bha]# # Returns not-equal on a 64 bit system:
[root@ares bha]# objdump -d xarch64.o

xarch64.o:     file format elf64-x86-64


Disassembly of section .text:

0000000000000000 <_start>:
  0:   54                      push   %rsp
  1:   58                      pop    %rax
  2:   34 48                   xor    $0x48,%al
  4:   50                      push   %rax
  5:   5a                      pop    %rdx
  6:   54                      push   %rsp
  7:   41 5a                   pop    %r10
  9:   41 59                   pop    %r9
  b:   56                      push   %rsi
  c:   48 39 32                cmp    %rsi,(%rdx)


which actually detects if you are running on 32bit or 64bit or not so you can tailor code to a specific architecture

http://www.blackhatlibrary.net/Linux_assembly

and finally here is a list of all linux system calls that can be accessed through the kernel without needing an external library such as libc.

id just poke around and read some when youre bored most of this stuff is still in the works so its not proof read but it still mostly makes sense.
Member
Posts: 28,331
Joined: Jun 9 2007
Gold: 11,700.00
Feb 18 2013 04:46pm
Quote (SelfTaught @ 18 Feb 2013 16:47)
...
Assembly seems like it's going to be relatively easy to learn, I just can't wait until I can start using it to for the exciting stuff  :D


all programing languages are easy to learn once you understand the principle and the more programing languages you learn the easier they become
but it can be a little confusing if similar or even identical sounding commands have slightly different meaning
assembly languages have the disadvantage that you do not get much of a debugging help. tiny mistakes can be difficult to iron out

Quote (AbDuCt @ 18 Feb 2013 19:31)
yea assembly is really fun to just dick around in, but if you want to write anything meaningful id always go to a  high level language like C simple because i dont want to spend hours deving on one function.
...


while this is true for the general user for system programming you often don't have a choice
also if you want top performance it might be necessary to use assembler for at least part of your system
ps: once you have really 'digested' an assembly language you can write code pretty fast (especially if the assembler supports a macro facility)
Member
Posts: 13,425
Joined: Sep 29 2007
Gold: 0.00
Warn: 20%
Feb 18 2013 06:29pm
Quote (brmv @ Feb 18 2013 06:46pm)

while this is true for the general user for system programming you often don't have a choice
also if you want top performance it might be necessary to use assembler for at least part of your system
ps: once you have really 'digested' an assembly language you can write code pretty fast (especially if the assembler supports a macro facility)


compilers are at a stage in their life where there is little chance that you can out preform it by a great margin by hand. sure sometimes you can spot and simplify multiple operations into one line once in a while but saying you can out preform optimized compiler code is quite laughable.

on a side note i agree that for some programming a high level language doesnt quite have what you need and that you do need to dip down into some inline assembly.
Member
Posts: 1,358
Joined: Dec 30 2012
Gold: 0.10
Feb 18 2013 07:21pm
@AbDuCt

Thanks for the links. That is an excellent source of assembly information. I'll definitely be using those regularly through my learning process.

Quote (brmv @ Feb 18 2013 02:46pm)
all programing languages are easy to learn once you understand the principle and the more programing languages you learn the easier they become
but it can be a little confusing if similar or even identical sounding commands have slightly different meaning
assembly languages have the disadvantage that you do not get much of a debugging help. tiny mistakes can be difficult to iron out


while this is true for the general user for system programming you often don't have a choice
also if you want top performance it might be necessary to use assembler for at least part of your system
ps: once you have really 'digested' an assembly language you can write code pretty fast (especially if the assembler supports a macro facility)


Yeah I definitely agree that once you learn one or more programming languages the rest are easier to pick up. I started out with c++ and once I got pretty familiar it then I was able to pick up Java no problem. Also coded for a few days in C sharp and was able to make a couple of nifty little applications.

True about assembly being hard to debug. I've realized this just from the couple of weeks I've been learning assembly. This thread is a perfect example of that lol.




Member
Posts: 28,331
Joined: Jun 9 2007
Gold: 11,700.00
Feb 18 2013 07:52pm
Quote (AbDuCt @ 19 Feb 2013 00:29)
compilers are at a stage in their life where there is little chance that you can out preform it by a great margin by hand. sure sometimes you can spot and simplify multiple operations into one line once in a while but saying you can out preform optimized compiler code is quite laughable.
on a side note i agree that for some programming a high level language doesnt quite have what you need and that you do need to dip down into some inline assembly.


sorry that i have to disagree, most languages are not optimised for performance but for ease of use
and for many applications needing high performance any decent margin of improvement will be beneficial
and i am not talking about optimising compiler output but rather designing it from scratch
(eg all airline booking systems rely on substantial amounts of original assembler code)
it is quite easy to outperform optimised compiler code if you know what you are doing
once you have done a few years systems programming on various platforms you will not find it laughable any more
but i do agree that in the majority of applications the effort is not worth it because they do not fit the necessary profile
Member
Posts: 13,425
Joined: Sep 29 2007
Gold: 0.00
Warn: 20%
Feb 18 2013 08:08pm
Quote (brmv @ Feb 18 2013 09:52pm)
sorry that i have to disagree, most languages are not optimised for performance but for ease of use
and for many applications needing high performance any decent margin of improvement will be beneficial
and i am not talking about optimising compiler output but rather designing it from scratch
(eg all airline booking systems rely on substantial amounts of original assembler code)
it is quite easy to outperform optimised compiler code if you know what you are doing
once you have done a few years systems programming on various platforms you will not find it laughable any more
but i do agree that in the majority of applications the effort is not worth it because they do not fit the necessary profile


i concur.

i also must say it is also dependent on the language and the programmer wither or not if the code is efficient or not. two people can write two different C programs to solve the same simple problem but with doing so the two may have two different assembler outputs. one may be more efficient then the other just via way of programming/solving said problem.

overall hand optimizing is a bitch and for most cases not needed.

This post was edited by AbDuCt on Feb 18 2013 08:11pm
Member
Posts: 28,331
Joined: Jun 9 2007
Gold: 11,700.00
Feb 18 2013 08:39pm
Quote (AbDuCt @ 19 Feb 2013 02:08)
i concur.
i also must say it is also dependent on the language and the programmer wither or not if the code is efficient or not. two people can write two different C programs to solve the same simple problem but with doing so the two may have two different assembler outputs. one may be more efficient then the other just via way of programming/solving said problem.
overall hand optimizing is a bitch and for most cases not needed.


windows is definitely the worst operating system when it comes to performance B)

btw, because good systems programmer are difficult to find and expensive the major part of most operating systems is nowadays written in C or some variant thereof
but there are essential parts which are not accessible to higher level languages and one has to crawl into assembler

and yes, hand optimisation of code written by someone else is one of the worst tasks
some time ago we encountered sporadic system crashes and digging through full system dumps for a few days we found that under specific circumstances an interupt pre-processing routine ran out of time, not just missing the interupting event but also messing up some random memory address which in the end caused the crash after some time
it took me a couple days of redesigning the routine (less than hundred assembly instructions) to reduce the maximum execution time by a dozen cycles (and include a forced error for future debugging ease)
Go Back To Programming & Development Topic List
Prev12
Add Reply New Topic New Poll