I removed an unintended bug, updated my exploit to RS4 and brought my elgoog challenge from 34c3ctf back to life for WCTF. @j00ru managed to solved it without the intended pool metadata corruption, nice
-
Show this thread
-
Replying to @_niklasb
Cool task! I'm curious about the metadata corruption, shall we exchange some more detailed write-ups/exploits? ;)
1 reply 1 retweet 3 likes -
Replying to @j00ru
We can absolutely, just didn’t want to publish much so far because I knew I might reuse it
1 reply 0 retweets 1 like -
Replying to @_niklasb
Great, I'll clean up the code a bit and let you know
1 reply 0 retweets 3 likes -
Replying to @j00ru
I dumped my own exploit (& sources) at https://github.com/niklasb/elgoog/ , but that's only some short comments in the exploit code so far. I'm just overwriting PrevSize, but it's quite painful to get the right data into the chunks under the constraints given by the driver.
2 replies 9 retweets 32 likes -
Replying to @_niklasb
Thanks, much appreciated. It's a neat exploit -- I haven't seen too many of them for 1-byte pool overflows in modern Windows. It's much more convoluted than mine, I'm quite happy I didn't actually have to deal with the pool grooming. :) I'll follow up with my code soon
1 reply 0 retweets 2 likes -
Replying to @j00ru
I guess getting the precise chunk addresses to survive the linked list checks would usually be a big problem, but my challenge gives those out for free.
1 reply 0 retweets 0 likes -
Replying to @_niklasb
By the way, set_addr(), read(), write(), steal_token() etc. seem to be artifacts of some other exploitation route?
1 reply 0 retweets 0 likes -
Replying to @j00ru
Yeah, the RS3 exploit used palettes because it was running as low integrity.
1 reply 0 retweets 0 likes
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.