Hacker News new | past | comments | ask | show | jobs | submit login

I'd love to know how many hours were needed to develop this exploit from start to finish, and how many dead ends the researcher ran into along the way.

Just writing the blog post and generating all the images for it must've taken many days.




From the project-zero bug (https://bugs.chromium.org/p/project-zero/issues/detail?id=13...), it looks like the first discussion on the issue dates back to July 3, with a working exploit posted just yesterday.


I have followed iOS JB for years and keep up with exploit dev and mitigation/defense.

The usage of source code and avoiding deep assembly documenting helped a lot. You are still looking at several man days of deep work on understanding the driver and stack.

KASLR was the only real mitigation to bypass. That could have been a difficult part worth it's own discussion. Bypassing ASLR typically requires an info leak.

I think 3-4 weeks of one person's effort is a good guess. +/- 1wk depending.


If others don't know, the K is for kernel. I had guessed that it was, but decided to look it up. I figure this may save others some time.

It looks pretty neat, conceptually. It loads the kernel into a random location in memory on boot. I haven't looked into how random it is, but it's a good idea.


Goodness, it takes only several days to reverse engineer a driver and stack now? Wow. I know the project zero guys are good, but damn.


Is the source for this code only Apple's open-source publishings?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: