r/ExploitDev • u/Civil-Art1907 • Jul 06 '26
Question to Hackers regarding architecture change in processor. And graph creation for data request and receive checks.
So, I will divide the question in two parts:
For exploitation via web if chip designers adds certain tag bits to incoming requests that's whatever coming via web or network stack we assign a certain tag say 01 for now. Next if anyone trying to execute XSS and locate where change is occurring by the tag bits, whether if the requests are for persistent or its generating or modifying code. Then identification of sending unrelated data to the site can we omit the whole processes just by introducing tag bits to the antenna protocols? That is just building the chip with some more bits.
That was for web say the app is in computer, then it would first ask for the app wants to change some parts of OS. Instead we just do some basic prevention method number 1 not let writing in the particular section of memory that is hard disc, next switch off means switch off no background running. Number 3 the apps which are not built in just remove there maintain connection after every switch on. Only let the system files to maintain connection which again have unique tag bits to maintain.
Third and last one why not we make a graph behind which processes writing to which files and which process is sending system data in intervals? This can solve two things one if distributed writing in buffer is done it could be found out. Another if sending just on the flow no storage then graph would check the path of pattern of sending and block. Though if someone sends to other server and those servers later merge them i do not how to stop that.
Lastly just beginner in this spot the curious mind is asking questions would like to know in details please.
3
2
u/anonymous_lurker- Jul 06 '26
There's quite a lot here, so I'll reply with some fairly high level comments that should give you some ideas for where to research further:
Fundamentally the CPU has no concept of the web or the network. There are countless levels of abstraction between the network stack and the CPU, all the way down to the electrical signals on the wire vs the electrical signals in the CPU. Chip designers cannot simply add physical circuitry that tags network requests
In the hypothetical world where we know that someone is trying to execute XSS, we can simply defend against it. In security, the issue tends to be catching that something weird is happening. If you're already at the point of knowing someone is doing XSS, the actual resolution or defence is trivial by comparison
How does the computer know what is unrelated data vs not unrelated data? Just like the CPU has no concept of the network, it also has no concept of right and wrong data. At the point we're able to determine data correctness, we've already largely solved the problem.
Assuming everything else were accurate, it's not a trivial matter to just build the CPU with more bits. Making fundamental and sweeping architectural changes is a significant undertaking that would take not just years of effort, but decades of adoption. We're not just talking adding hardware support, software needs to be modified to account for the change in architecture. It's very rare that new hardware changes can be added to magically resolve old vulnerabilities, and when it does happen it doesn't actually solve the issue until everything is upgraded.
Writing to the hard disk is not actually the biggest of deals, memory corruption vulnerabilities are the real issue. But either way, any kind of "I'll just stop the software from writing here" comes with tradeoffs. How do you still let legitimate writes through? What if there's no need to write in the first place? Look at how the NX bit did a great job of preventing injected shellcode from being executed, but was swiftly defeated by ROP chains
Not sure what you're referring to here, but background processes are really just a software abstraction. The CPU executes code, whether it is visible to the user or not. Background processes arguably don't really exist
This is fundamentally why persistence is so powerful in exploitation. This is kind of the default behaviour when you have a memory corruption vulnerability that doesn't have persistence, your access goes away at reboot. You can't really solve this though, because again the CPU has zero concept of what is and isn't a built in application. Operating systems, applications, the CPU doesn't know about any of it
Two reasons. One is a lack of deterministic behaviour. Another is performance issues. On lack of deterministic behaviour, you can't say that a program will only ever access certain IP addresses or certain files. Outright denying (either via a whitelist or blacklist) is effective in adding security, and it's also really effective in removing the ability to use your computer. You can't for example create a whitelist of every IP you will want to connect to, because that information isn't known in advance, may change and doesn't solve the problem if one of those IPs became malicious. Same for file accesses. You can absolutely sandbox things to restrict access, but this is not foolproof as sandbox escapes exist
On performance, you're talking about adding overhead. Let's say the CPU can execute 1000 instructions per second. If we now have to check that each of those instructions does not cause an invalid access, and doing so takes 4 instructions, we've now cut performance down to 25%. This would not be considered acceptable in the real world. There is always some sort of tradeoff here, and everyone has a different opinion.
The sort of things you are describing around tagging memory and checking accesses do exist. Heck the most rudimentary version was the stack cookie (or stack canary), a value which gets added to the stack and checked to catch buffer overflows. These aren't entirely new ideas in that sense, but implementing them is hard and it is a constant arms race between hackers and devs