4 ms·

Such sophisticated attacks always amaze me, and I've always wondered how people go about developing them in the first place.

mistrial9 4y ago
someone who worked on the UEFI implementation writes it
- j16sdiz 4y ago
  hooking into win32 kernel is not something uefi developers usually do
  - unnouinceput 4y ago
    You say it like the kernel is, at that moment in time, running, when in fact is just a simple .dll file just sitting there and is being manipulated by the uefi no different than what Notepad does to a text file. Also the article says it clearly that the uefi rootkit is searching and replacing functions within the kernel and then putting them back once the next phase is complete, in order to avoid security check. Hooking in windows is a technique allowed by the OS, while this "hooking" is nothing more than just simple search/replace file operation. That's being taught like in 1st month on any coding school.
- colinsane 4y ago
  if you were handed the UEFI implementation codebase like a new-hire, how long would it take to figure out this potential codepath? a couple days? now if you were handed only the binaries, and left to objdump them etc, how long? evidently there’s symbol names since the article uses those. so hopefully no more than an extra order of magnitude: a couple weeks, maybe a full month if my manager’s asking for a deadline and i want to be conservative? also, think about where/how they hooked: it sounds like they hooked at the equivalent of an interface boundary, where it’s easiest to inject a new implementation — but then they have to check the return address to know where in the larger scope of the process they’re currently at: if you had access to the codebase and build tools why wouldn’t you patch your exploit into the code more directly and just rebuild it? why abuse the return address like that? i don’t mean to say it’s not impressive, but it’s not magic. there are lots of competent engineers out there capable of reverse engineering a UEFI implementation.
- robotnikman 4y ago
  That was one theory I had in mind. My guess is the organization developing these exploits form teams of people focusing on a single exploit, with each person on the team having deep domain knowledge in a single subject (UEFI, Windows Kernel, etc), and they use that knowledge to develop their portion of the exploit chain. People who developed such specifications in the first place, like UEFI, would be great candidates for an organization looking for someone with deep knowledge of the subject.

mistrial9 4y ago

someone who worked on the UEFI implementation writes it

j16sdiz 4y ago
hooking into win32 kernel is not something uefi developers usually do
- unnouinceput 4y ago
  You say it like the kernel is, at that moment in time, running, when in fact is just a simple .dll file just sitting there and is being manipulated by the uefi no different than what Notepad does to a text file. Also the article says it clearly that the uefi rootkit is searching and replacing functions within the kernel and then putting them back once the next phase is complete, in order to avoid security check. Hooking in windows is a technique allowed by the OS, while this "hooking" is nothing more than just simple search/replace file operation. That's being taught like in 1st month on any coding school.
colinsane 4y ago
if you were handed the UEFI implementation codebase like a new-hire, how long would it take to figure out this potential codepath? a couple days? now if you were handed only the binaries, and left to objdump them etc, how long? evidently there’s symbol names since the article uses those. so hopefully no more than an extra order of magnitude: a couple weeks, maybe a full month if my manager’s asking for a deadline and i want to be conservative? also, think about where/how they hooked: it sounds like they hooked at the equivalent of an interface boundary, where it’s easiest to inject a new implementation — but then they have to check the return address to know where in the larger scope of the process they’re currently at: if you had access to the codebase and build tools why wouldn’t you patch your exploit into the code more directly and just rebuild it? why abuse the return address like that? i don’t mean to say it’s not impressive, but it’s not magic. there are lots of competent engineers out there capable of reverse engineering a UEFI implementation.
robotnikman 4y ago
That was one theory I had in mind. My guess is the organization developing these exploits form teams of people focusing on a single exploit, with each person on the team having deep domain knowledge in a single subject (UEFI, Windows Kernel, etc), and they use that knowledge to develop their portion of the exploit chain. People who developed such specifications in the first place, like UEFI, would be great candidates for an organization looking for someone with deep knowledge of the subject.