pgo

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

Agreed, If you have retries then you also need circuit breakers

Yes, palash [at] dyte.io Thanks for the invite

Would you happen to have an invite for zed.dev ? I typically have 10-15 VSCode windows open and have been looking for an performant but modern IDE

It's a one time authorization

No, this is about alerts from cross origin content, like from an iframe that loads from a different origin than the parent page

Try our free demo (uncapped for the near future) with collaborative plugins at demo.dyte.io (YC W21)

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"

There are no typos here, the root issue is package manager preferring public packages of the same name over private ones

Didn't we get support for it last month

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.

https://github.com/TeamGreyFang/CTF-Writeups/tree/master/Pla...

Source for this ? I can only see mentions of plans implementing this, not of it being actually deployed

The rooting process is actually very standardized. On most of the phones you just have to patch a su manager tool called Magisk[1]. Its open-source and been under a lot of eyes.Also the dev works at apple and is a community favorite.

Custom roms are a lot more risky, there are 100s of different flavors made by relatively unknown developers and even though they are technically open source, I find it highly unlikely that none of them contain malware. I mean you can introduce a memory corruption bug in few handful characters, these custom roms are practically unauditable.

1. https://github.com/topjohnwu/Magisk

Well its called managed infrastructure for a reason.

Legal, encouraged and rewarded. Bug bounty programs allow hackers doing these kind of explorations. Although most programs advise you not to do anything once you get code execution as it might break things on production, so the final part where they started intercepting traffic might not be something I would do, but they took a calculated risk, that this is is docker container that does no critical work and it would be interesting to see if we could break out of it. So that's fine.

You can read up more of such reports at hackerone.com/hackitivity or just searching about bug bounty writeups for X organization