This is expected right, HTTP is not only used for human consumable web applications but for API servers as well
The bulk of these would just be embedded devices running multiple API services, like port 7547 highlighted in the article is your typical TR-069 service running on most consumer internet routers
I would argue most non-API/non embedded devices web applications would still be running on 80 and 443
Yeah there is, the video chat is not P2P, everyone uses the SFU model where all your media goes through daily's server, so they have to pay for the instances and the bandwidth
So under the hood it's chromium headless and you are streaming screenshots back using an extension
Curious why not run normal chromium and vnc the whole screen back using a web client such as novnc, would have solved most of your "Normal Browser UI things not yet implemented"
Cool diagram. Putting the shellcode in headers is very innovative. I didn't have too much assembly knowledge to trim it further during the competition.
I once wrote an ELF by hand for a CTF challenge. The challenge was to have an shared library such that when it is passed to LD_PRELOAD it spawns a shell by execve
LD_PRELOAD=<ELF> /bin/true
The constraint being the ELF needed to be less than 196 bytes so obviously it could not be created by gcc. In the end I could not believe it ran, considering the amount of hacks that I had to do to trim it to 193 bytes.
The bulk of these would just be embedded devices running multiple API services, like port 7547 highlighted in the article is your typical TR-069 service running on most consumer internet routers
I would argue most non-API/non embedded devices web applications would still be running on 80 and 443