6 ms·

can you please elaborate?

by iamrohitbanga 14y ago

jpollock 14y ago
It's computation that you can't see with a debugger, or with any sort of tracing.
- duaneb 14y ago
  You can't see the code, but surely it can't do anything useful—i.e. change anything outside its extremely limited memory.
  - phyalow 14y ago
    If you read through the slides @ https://github.com/jbangert/trapcc/blob/master/slides/PFLA-shmoocon.pdf https://github.com/jbangert/trapcc/blob/master/slides/PFLA-s... there is potential to bypass hardware memory protection. Very interesting.
    - 0x0 14y ago
      I must have missed the limited ram access when I browsed the slides the first time, I just assumed the youtube Game of Life proved they were poking ascii 'X' chars into video ram at 0xb8000 or whatever. Is there a trick/cheat to how that visualization was done? Edit: browsed around the code some more and it seems the ascii visualization stuff is done in regular c/asm polling the "virtual game of life" mem(?)
      - jbangert 14y ago
        Yes, there is a cheat, it moves values from RAM to VGA ...
        0x0 14y ago
        Thanks for clarifying, still extremely impressive! I wonder if you'll receive any fun comments from Intel/AMD/etc. :)
    - duaneb 14y ago
      Ahh, ok. Might actually be enough to, say, copy an encryption key out of kernel memory then?
      - limmeau 14y ago
        Most of the techniques described in the slides require ring-0 privileges (replacing descriptor tables and page tables etc). If you have those privileges, you can copy what you want anyway. Unless the encryption key is guarded by something with SMM privileges -- has that been done?
        duaneb 14y ago
        Well the original idea was a rootkit, which traditionally requires ring-0 privileges to install in the first case.
    - ithkuil 14y ago
      well, that's misleading. The spec says "don't put a tss cross page boundary". This might also have been the case in some x86 implementations, but surely they fixed that once that hardware virtualization was implemented. They actually depend on the sane behavior: they trigger the double fault when the cpu spills the tss across a page boundary. They mention the manual because according to the manual their idea wouldn't work, but it does. Then they also say "We should test it", and the result of the test is "CPU translates DWORD by DWORD" (i.e. doesn't miss a byte^H^H^H^Hword) And then a nice kitty to show how relieved they were from the good news! No dragons in the way. -- (Unless I got all wrong, but this topic is not the simplest one to reverse engineer from some slides, did anybody find a presentation video? It would really help to hear somebody commenting those slides, otherwise is a nested puzzle. And where is the patched qemu so one can play with that?)
      - jbangert 14y ago
        Shmoocon will release the video of the presentation in a bit, until then here is our talk at CCC http://www.youtube.com/watch?v=NGXvJ1GKBKM http://www.youtube.com/watch?v=NGXvJ1GKBKM

can you please elaborate?

jpollock 14y ago

It's computation that you can't see with a debugger, or with any sort of tracing.

duaneb 14y ago
You can't see the code, but surely it can't do anything useful—i.e. change anything outside its extremely limited memory.
- phyalow 14y ago
  If you read through the slides @ https://github.com/jbangert/trapcc/blob/master/slides/PFLA-shmoocon.pdf https://github.com/jbangert/trapcc/blob/master/slides/PFLA-s... there is potential to bypass hardware memory protection. Very interesting.
  - 0x0 14y ago
    I must have missed the limited ram access when I browsed the slides the first time, I just assumed the youtube Game of Life proved they were poking ascii 'X' chars into video ram at 0xb8000 or whatever. Is there a trick/cheat to how that visualization was done? Edit: browsed around the code some more and it seems the ascii visualization stuff is done in regular c/asm polling the "virtual game of life" mem(?)
    - jbangert 14y ago
      Yes, there is a cheat, it moves values from RAM to VGA ...
      - 0x0 14y ago
        Thanks for clarifying, still extremely impressive! I wonder if you'll receive any fun comments from Intel/AMD/etc. :)
  - duaneb 14y ago
    Ahh, ok. Might actually be enough to, say, copy an encryption key out of kernel memory then?
    - limmeau 14y ago
      Most of the techniques described in the slides require ring-0 privileges (replacing descriptor tables and page tables etc). If you have those privileges, you can copy what you want anyway. Unless the encryption key is guarded by something with SMM privileges -- has that been done?
      - duaneb 14y ago
        Well the original idea was a rootkit, which traditionally requires ring-0 privileges to install in the first case.
  - ithkuil 14y ago
    well, that's misleading. The spec says "don't put a tss cross page boundary". This might also have been the case in some x86 implementations, but surely they fixed that once that hardware virtualization was implemented. They actually depend on the sane behavior: they trigger the double fault when the cpu spills the tss across a page boundary. They mention the manual because according to the manual their idea wouldn't work, but it does. Then they also say "We should test it", and the result of the test is "CPU translates DWORD by DWORD" (i.e. doesn't miss a byte^H^H^H^Hword) And then a nice kitty to show how relieved they were from the good news! No dragons in the way. -- (Unless I got all wrong, but this topic is not the simplest one to reverse engineer from some slides, did anybody find a presentation video? It would really help to hear somebody commenting those slides, otherwise is a nested puzzle. And where is the patched qemu so one can play with that?)
    - jbangert 14y ago
      Shmoocon will release the video of the presentation in a bit, until then here is our talk at CCC http://www.youtube.com/watch?v=NGXvJ1GKBKM http://www.youtube.com/watch?v=NGXvJ1GKBKM