# Is it theoretically possible to deploy backdoors on ports higher than 65535?

Assuming you were able to modify the OS/firmware/device for server/client to send and listen on ports higher than 65535, could it be possible to plant a backdoor and have it listen on, say, port 70000?

I guess the real question is this:

If you rebuilt the TCP/IP stack locally on the machine, would the overall concept not work due to how the RFC 793 - Transmission Control Protocol Standard works as mentioned below in some of the answers? Making it impossible to access a service running on a port higher then 65535.

There has been so much talk about hardware and devices having backdoors created that only government have access to for monitoring, and I was just curious if this was possibly one of the ways they were doing it and avoiding detection and being found?

• If you're going to rebuild TCP/IP anyway, you might as well just make your backdoor intercept special packets you build and send to port 80. – joe snyder Jan 14 '17 at 20:57
• I could imagine that if you were clever enough to pass "port 70000" to some implementations, they'd just end up truncating it to 4464. – Nick T Jan 15 '17 at 8:06
• If you can modify the client to accept your hacked TCP packets you already pawned it. Why would you need to backdoor it as well? – Tonny Jan 15 '17 at 11:32
• Theoretically you can put the backdoor on port 0, provided that you modify both the server and the client's TCP stack. I have a feeling any sane firewall is not going to let that pass – user69874 Jan 15 '17 at 19:16
• @JPhi1618 "provided that you modify both the server and the client's TCP stack" is meant to include even the kernel. In theory if you really wanted to you can stuff 0 into the port field in the TCP packets, it might not be valid TCP anymore, but can circumvent bad firewalls(who actually blocks port 0?) and be hard to guess. – user69874 Jan 17 '17 at 2:32

No, the port number field in a TCP header is technically limited to 2 bytes. (giving you 2^16=65536 possible ports)

If you alter the protocol by reserving more bits for higher ports, you're violating the specification for TCP segments and wouldn't be understood by a client. In other words, you're not speaking TCP anymore and the term "port" as in "TCP source/destination port" wouldn't apply. The same limitation exists for UDP ports.

That said, a backdoor could instead communicate over a different protocol than TCP or UDP to obscure its communication. For example, icmpsh is a reverse shell that uses ICMP only. Ultimately, you can also implement your own custom transport-layer protocol using raw sockets that can have its own notion of ports with a greater range than 0-65535.

• Not only the client wouldn't understand it. Also every router along the path of client to server would consider it a garbled packet and discard it. – Tonny Jan 15 '17 at 11:31
• @Tonny: Not necessarily. Routers are only supposed to route at the IP level, not even see TCP/UDP headers. Of course then NAT happened.... – R.. Jan 15 '17 at 13:26
• @Tonny: I'm unsure how many actually do. Certainly weird boundary NAT routers will mangle/drop it, but I don't know what portion of normal routers will. – R.. Jan 15 '17 at 14:26
• NAT works on the port level, so each protocol forwarded via NAT needs support in NAT. Not all routers do NAT, this is common for home routers and SOHO routers, but the carrier-grade routers that your ISP uses to forward network to the greater Internet likely does not use NAT (but there is such a thing as Carrier Grade NAT or CGN). – LawrenceC Jan 15 '17 at 19:49
• @R.. Now I give it some more thought... I think most routers would actually be ok with the IP packets themselves as long as the protocol type in the IP packet is changed to something else than the normal value for TCP. When it says TCP things like DPI, ip-tables, etc.. would try to analyze the packet which is then considered to be malformed as it doesn't adhere to the TCP specification. Routers with sloppy error-handling could potentially crash... (Now I think about it.. Possible attack vector ?) – Tonny Jan 16 '17 at 13:50

No, it's that number because the TCP field for that is only 16 bits long (65536, but starting at 0), so it is fundamentally impossible to communicate a higher port than 65535

This post has a really nice writeup on why this is so in IPv4, how it's the same in IPv6, and how you can reuse ports in regular use.

• Note that your second post doesn't explain how to increase the port range but how to have additional IP addresses. The port numbers will still stay in [0, 65535]. – Arminius Jan 14 '17 at 21:23
• @Arminius indeed it's very roundabout, the only way to extend them would be ways that are not supported by generic hops inbetween, such as optional fields in the IP header. – J.A.K. Mar 19 at 17:41

If you rebuilt the TCP/IP stack locally on the machine, would the overall concept not work due to how the RFC 793 - Transmission Control Protocol Standard works as mentioned below in some of the answers? Making it impossible to access a service running on a port higher then 65535.

There are no TCP/UDP services on ports higher than 65535. If it supports port numbers above 216-1, then it no longer is TCP (or UDP).

Can you have something else that...? Sure. And could it be very similar to TCP? To the point of being backwards compatible? Yes to both questions.

There has been so much talk about hardware and devices having backdoors created that only government have access too for monitoring, and I was just curious if this was possibly one of the ways they were doing it and avoiding detection and being found?

If I had developed such a device, it would rely on a protocol common enough as to be unremarkable. An unknown/illegal protocol packet, after which some extra traffic ensues, would be quite suspicious.

# Hide in (almost) plain sight

What such a device could do might be, for example, inspect some bytes in the payload. They would usually be noncorrelated values; I could then send packets to the target, or if it is a router, without even a IP address of its own, to some random, possibly even nonexistent host beyond the target, masquerading as (say) a HTTPS request, or a SSH login attempt.

If you see a packet you do not know, you might get suspicious. But even if you saw in the logs something like

SSH: failed attempt for user maintenance
SSH: failed attempt for user maintenance
SSH: failed attempt for user maintenance


you would not worry, especially if you had no user "maintenance". You would perhaps assume someone, somewhere, discovered an attack against some device with a default user of "maintenance" (heck, if I was a government, I could market such a device, have it vulnerable, and not fix it, for the sole purpose of justifying such connections on totally different devices. What's the first thing you would do in seeing such attempts? Either nothing ("harmless bruteforce. Idiot"), google and shrug ("Oh, someone thinking I have a CheapRouter 2000. Idiot", possibly write a firewall rule to block the IP - except that the packets still arrive to the network card).

And what actually happens is that the evil firmware in the router, network card, motherboard or what have you, recognizes the packet and sends back an answer. It could do so by forging response packets overwriting the "real" ones.

The only symptom of something very bad happening would be if you compared, say, the inbound and outbound traffic from an evil router:

Host with SSH server:

--> SSH SYN --> ROUTER --> SSH SYN --> HOST
<-- SSH S+A --- ROUTER <-- SSH S+A <-- HOST
--> SSH ACK --> ROUTER --> SSH ACK --> HOST
...
<-- FAIL2------ ROUTER <-- FAIL1 <---- HOST    packets are different!


Host without SSH server:

--> SSH SYN --> ROUTER --> SSH SYN --> HOST
<-- SSH S+A --- ROUTER <-- SSH RST <-- HOST    wait, WTF?
--> SSH ACK --> ROUTER                 HOST
...
<-- FAIL2------ ROUTER                 HOST


If you sniffed on a cable, either to the left or to the right of the compromised device, you would notice nothing immediately amiss.

The other suspicious thing would then be that the sender apparently uses the TCP Fast Open extension. Note that you can send extra data in the SYN even without TCP/FO, it will simply be ignored by devices that are both non-FO and non-compromised.

• Your router reminds me of teamten.com/lawrence/writings/coding-machines. – user21820 Jan 15 '17 at 2:06
• @user21820 thanks, now I'm going to have nightmares. – André Borie Jan 16 '17 at 16:53
• @AndréBorie: If you think really carefully about it, you'll realize that it's not realistic. It takes a great deal of planning and design to purposely target only one group at a time. What is "one group" anyway? This is merely one of the subtle flaws in the plot. If you want to sleep better, you could go and find more. But it was an amusing read. =) – user21820 Jan 17 '17 at 4:54
• @user21820, Thanks for sharing, I just read the whole thing. Very interesting! – user8437812 Jan 19 '17 at 8:52
• @user8437812: Maybe someone can come up with a more realistic one based on today's knowledge? =P – user21820 Jan 19 '17 at 11:01

As already said, port numbers are represented with unsigned 16-bit integer and cannot be above 65535.

But there is a possibility to use different protocols (not TCP or UDP). In IP header there is a 8-bit field called «protocol number», which denotes what transport protocol is used inside this packet.

You can look at the table of transport protocols here: http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml

Some protocols from this list are user widely (for example, TCP or UDP), some more rarely (DCCP or UDPLite). Some protocol numbers are not used yet, and some are deprecated (ARGUS, EMCON).

So, backdoor can use unused protocol numbers to send data to its server. Of course, this technique are difficult to implement (needs access to rawsocket or implementing backdoor as OS kernel module).

This would be possible to achieve but you would not be able to use protocols such as UDP and TCP since their max port is 65535.

You would need to implement your own protocol on top of the IP protocol.

This may be possible using raw sockets.

There has been so much talk about hardware and devices having backdoors created that only government have access too for monitoring, and I was just curious if this was possibly one of the ways they were doing it and avoiding detection and being found?

I don't think this would help making the connection stealthier since you would still be able to see packets going though the network.

So as a lot of the other answers have pointed out, TCP says port numbers are 16 bits. That 16 1s and 0s. This has a limit of 65535 repeatable ports. For the rest of the example were going to use 4 bits because I am lazy.

So with 4 bits I can represent 15 ports.

Your theatrical backdoor would have to rely on how it handled malformed TCP packets. So (remember 4 bits instead of 16). Lets send some traffic on port 17.

The header would be malformed as 10001. Your TCP stack could state that if you get a malformed header, then go down a different logic path, attaching data to the port of the "right most" four bits. In this case port 1 or 0001. The real trick is that TCP just uses bit count. It's not like xml where there is a [port]10001[/port]. So you would need some way to detect your port header overflow. SYN is right next to port so you could do, a SYN of exactly "1073741823" means your destination port is larger by one.

This different logic path could then stay active for the entire time the connection is active on port 1.

In this way it you could have a TCP backdoor around somewhere that accepted malformed packets and did something special with them. The real problem is that nothing but your special TCP stack could understand them. Routers, smart switches, even in theory some NIC cards would drop the packet, because it is malformed. There would be almost no way to tell if a packet would make it to it's destination with that malformed header.

But, if you connected two devices with the wonky TCP stack to a "dumb" switch or hub. In theory, you could get this to work, however this would not be in the TCP spec.

• The SYN flag is stored in a single bit, no room to place magic values there. You could use the sequence number of the packet marked with the SYN flag. – Ben Voigt Jan 18 '17 at 22:05
• I thought it was port:port:syn number might be wrong it's been a while. Either way far more reasonable to use something like port knocking. – coteyr Jan 18 '17 at 22:38
• destport is next to seqnum, but TCP uses seqnum values starting at a random value (not zero) and counting by bytes (pretty fast) so your 'different logic' would totally screw up more than half of all normal connections, maybe every single one, which users would notice and investigate. Also 'theatrical' doesn't make sense here, you probably meant 'theoretical'. – dave_thompson_085 Apr 7 '18 at 3:07

This truly extensive document clearly indicates how bits are assigned on the internet over TCP. It show the source and destination ports next to each other.

So you made a 32 bit source port? NOPE as soon as it touch the internet bytes 3 & 4 (the lower order) of your source port will be treated at the destination.

The destination port with wipe out the sequence number, and everything will be push further down the line.

Now since the sequence number has been smashed the destination won't be expecting that sequence number, and it will drop it like it was a spoofed packet.

Even if it made it past this point the acknowledge number will be smashed by the sequence number and since that number is now invalid, as far as the internet is concern, it will never be acknowledged.

Everyone explained it in terms of TCP/IP packet: the port field is only 16bits long.

But how about the Linux kernel source code and how it handle the port? Everywhere in linux kernel, for TCP/IP port it is always cast as "short", or 16 bits. And when it is compiled into x86 assembly, the 16bit version of the instructions are used for handling the 16bit data.

And if you are wondering about IPv6, then it is the same os IPv4 - everything about TCP and UDP.

https://stackoverflow.com/questions/186829/how-do-ports-work-with-ipv6

But of course you could setup a weird communication like using TWO server for communcation - each one having individual 16-bit ports and so when you combine them you have a virtual 32-bit port. But the whole world only you will know how to talk to the two server - eg, splitting the data in half and dividing it between the two server, to be reconstructed back again at the client side.

It really seemed like longer than 16bits is almost impossible.

Yes, since you specified that you can modify the OS, but with the major caveat that only modified devices would see it as being at a non-standard port number.

Most current implementations store the port number in a 16-bit field, so all possible combinations of bits are mapped to integers from 0 to 65,535. These implementations simply can't recognize any other port number because no combination of bits would map to it.

But, if you really wanted a particular client to recognize traffic as though it were at a different port number, you could rewrite how that client interprets packets at the lower level. Instead of just using the 16-bit port number, you could write the OS to recognize modifications to it based on the data contained in the Options or Message sections of the packet. The system could then could then operate as though there were a wider range of possible port numbers.

This trick would only function on devices that have their packet-interpretation algorithms rewritten. External devices could still forward these packets without being compromised, but they would view the packets as being on a standard port number.