NASM - The Netwide Assembler

NASM Forum => Programming with NASM => Topic started by: mik3ca on February 08, 2021, 09:04:08 PM

Title: TCP flags and header length extraction in asm
Post by: mik3ca on February 08, 2021, 09:04:08 PM
I finally managed to make an ICMP reply host, but now I'm moving on to TCP.

There is one field in which the flags and the header size are embedded into the same 16-bits.
Since the data endianness is different between networks and my PC, I made it where all the incoming data is flipped, so that the first thing is the data itself, then the TCP header then IP header then ether type then network addresses.

This means reading from start to end, the ether type in byte format is 00h 08h, where as if I loaded the data as-is, the ether type would be 08h 00h.

I have determined the flags and header length 16-bit field to have the value 02h A0h (or it would be A0h 02h if read without flipping the whole packet)

The entire packet with mac address included is calculated to be 74 bytes. This was generated after using CURL for linux to attempt to access the server with no options other than extended verbosity.

I made two pieces of code. one to separate the TCP header length from the flags, and the other code puts the pieces together again.

This code is for putting the pieces together to make the packet ready for output.
Assume CX holds the header length and BX holds the flags, and AX is the result:

Code: [Select]
      mov AX,CX ;take length
      and AX,0Fh ;only use 4 bits
      mov DX,BX ;take flags
      and DX,03Fh ;only use 6 bits
      ror AX,4 ;make length most significant nibble
      or AX,DX ;combine both together

And this code is for separating the length and flags from the incoming packet:
Assume AX is a value directly loaded from memory representing length and flags (the bytes are backwards remember). CX will be length of the TCP header and BX will be the TCP flags.

Code: [Select]
     mov DX,AX
     rol AX,4
    and AX,0Fh
    mov CX,AX
    and DX,3Fh
    mov BX,DX

I didn't do anything about the middle 3 bits when extracting data and I attempted to make such bits a value of zero because in the TCP spec, it states 3 bits out of the 16 are "reserved".

I use TCPDUMP for linux to test how my TCP data is doing, and it reports issues.

I noticed that when I set the tcp header length to 20 in my first above (CX=14h), the tcpdump program claims my header is set to 16.
When I set the length to 24 (CX=18h), the tcpdump program claims my header is set to 32.

So I think something in my math above is wrong when extracting and putting in the TCP header length and TCP flag data from incoming data that's backwards.

I deliberately did backwards data because the other fields that are 8 and 16-bits are easier to extract.

Any ideas?