Is it theoretically possible to deploy backdoors on ports higher than 65535?
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.
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.
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
...
--> LOGIN ----> ROUTER --> LOGIN ----> 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
...
--> LOGIN ----> 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.