0patch Blog: No Source Code for a 14-Year Old Vulnerable DLL? No Problem | Hacker News Reader

0patch Blog: No Source Code for a 14-Year Old Vulnerable DLL? No Problem

blog.0patch.com

54 pointstouristtam6 comments

Binary patching is something you just have to do sometimes. Done this now twice for actual production purposes. Sometimes you can't compile without excessive amount of work even if you have the source code!

A lot more when I was younger for some other purposes, like making some (non-multiplayer) games behave differently, like never losing lives.

I've had to do it once in production for an old application without source, but the changes were substantial enough that I opted to write a wrapper dll for one of the dependencies. Once in it's easy to hook whatever else is needed and add major modifications.

This has some potential to be similar in philosophy to the ‘strangling a service’ process. Use a wrapper and slowly move the functionality away, until one day you can turn off the old service.

> Sometimes you can't compile without excessive amount of work even if you have the source code!

I've had to do this a couple of times (usually due to fraudulent transitive dependecies[0]). Eg:

  [to make glib applications display kilo-,mega-,etc in multiples of 2^10]
  change 4 bytes in g_format_size_full
  from: 41 F6 C4 02  test r12b 0x02      # if(flags&G_FORMAT_SIZE_IEC_UNITS)
  into: 48 83 FB 00  cmp rbx byte(+0x00) # if(size!=0)

0: eg, libfoo build-depends on X in libbar, and Y in libbar depends on something evil like systemd

This fixes the specific exploit, which is good.

However, the patched DLL is still be missing ASLR/DEP, which is suboptimal.

It would be difficult to add back in ASLR if the exe was not complied with it. Every absolute address must provide a reloc entry.

Reply on news.ycombinator.com