https://github.com/sha0coder/self-evolving_exploit_offsets
https://github.com/sha0coder/self-evolving_exploit_offsets
Last synced: 9 months ago
JSON representation
- Host: GitHub
- URL: https://github.com/sha0coder/self-evolving_exploit_offsets
- Owner: sha0coder
- Created: 2021-09-10T17:38:32.000Z (over 4 years ago)
- Default Branch: main
- Last Pushed: 2021-09-10T18:41:59.000Z (over 4 years ago)
- Last Synced: 2025-02-06T11:46:44.711Z (11 months ago)
- Language: C
- Size: 1.62 MB
- Stars: 1
- Watchers: 1
- Forks: 1
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# self-evolving_exploit_offsets
Not always exploits are universal and contain offsets to be pin-pointed for a specific machine.
Often bruteforce is used to guess the offsets due to the complexity of doing it manually.
But many times bruteforce is not feasible because there are many combinations.
I have used an machine learning / optimization algorithm to improve a heap-fengshui from chaos to the most optimal allocation for the exploitation on a specific system.
It's not tecnically complicated, I have used a genetic algorithm to evolve the offsets, If you can measure how good are the offsets and put a score you can evolve them.
Having the vulnerable sudo compiled with symbols, the [free.gdb](src/free.gdb) gdb macro get the heap address where we are writing, and the address of what we want to overwrite to be root.
Having this we can messure the distance, which is the score of the offsets.
[trace_heap.sh](src/trace_heap.sh) launches the exploit under gdb with the free.gdb macro whith the provided offsets, and calculate the distance.
trace_heap is launched from the Genetic Algorithm evaluation function, for evaluating a group of offsets. The [genetic2.py](src/genetic2.py) is a simple implementation of a genetic algorithm, doing crossover of the best offsets, in same way a cell evolved to a human in many iterations.
When GA's dont work it becomes a simple random scan, in this case surprisingly there was a clear evolution getting every generation better allocations aproximating to the most near allocation in my system.
Regarding the exploit I took the worawit's with some modifications to have multiple offsets, the GA by modifying the offets is pin-pointing the heap fenshui automatically.
The build_exploit() function in the GA is the worawit exploit modified.
Some possible optimizations:
1. this could be implementing calling the exploit instead of writing it every time
2. modify the sudo code to print the distance instead of debugging, but this could alter the exploitationin some cases.
This is the previous version of the ga which implemented only 4 offsets and bl4sty's exploit.
I executed it several times arriving always to the most near allocation which is 336, in one of the executions it arrived to that value in only 229 generations:
This could have been done also with neural network, but a simple GA in a laptop cpu worked well.
With worawit's exploit and 5 offsets it got the distance enough for doing a correct exploitation.
This system cannot be used to generate universal exploits, but could be used to port exploits to specific systems, finding the right offsets for a specific setup.
In this case it evolved, because there was a pattern even it's difficult to see it manually, but not always is going to work it depends on the situation.