1. 16 Aug, 2018 1 commit
  2. 22 Jul, 2018 1 commit
  3. 04 May, 2017 1 commit
  4. 22 Feb, 2016 1 commit
  5. 05 Feb, 2016 2 commits
  6. 26 Apr, 2015 3 commits
  7. 13 Mar, 2015 1 commit
    • npzacs's avatar
      0.8.1 · 2d777824
      npzacs authored
  8. 17 Feb, 2015 1 commit
  9. 22 Jan, 2015 1 commit
    • npzacs's avatar
      0.8.0 · 61460ba3
      npzacs authored
  10. 05 Jan, 2015 1 commit
  11. 27 May, 2014 1 commit
  12. 29 Dec, 2013 1 commit
    • Janusz Dziemidowicz's avatar
      Support gcrypt 1.6.0 · cbc200ff
      Janusz Dziemidowicz authored
      There seems to be a slight change in S-expressions (fortunately
      backward compatible). There is also additional flag needed in rather
      strange place (data section instead of key section), most probably a
      bug in gcrypt.
      Decrypting a 350MB file with gcrypt 1.5 takes around 4 seconds on Core
      Quad Q9450 2.66GHz while with gcrypt 1.6 around 2.8s (the processor
      does not support AES-NI).
  13. 18 Dec, 2013 1 commit
  14. 11 Dec, 2013 1 commit
    • npzacs's avatar
      0.7.0 · 2bb0fcc4
      npzacs authored
  15. 08 Oct, 2013 2 commits
  16. 07 Oct, 2013 2 commits
    • npzacs's avatar
      Dropped support for compile-time PATCHED_DRIVE flag. · 91bda6ce
      npzacs authored
      If this is still needed, it should be implemented as run-time option (environment variable ?).
    • Janusz Dziemidowicz's avatar
      Support for AACS bus encryption · 583df16f
      Janusz Dziemidowicz authored
      Due to the fact that AACS bus encryption was only hinted by early AACS
      specification there seems to be some misconceptions.
      First, what bus encryption is _not_:
      - it does not encrypt all communication between drive and host
      - it does not encrypt VID retrieval
      - it does not use bus key (this is only poor wording in the
      Second, what is required for bus encryption to be activated:
      - a bus encryption capable drive, drive certificate will have 0x01 as
        a second byte
      - a bus encryption capable disc, content certificate (located in
        AACS/Content000.cer) will have 0x80 as a second byte
      - a bus encryption capable host, host certificate will have 0x01 as a
        second byte
      There are various combinations of all of those flags, so let's provide
      a short summary:
      - if drive is not bus encryption capable, then bus encryption will not
        be used, other flags are not relevant and normal AACS procedure will
        work as usual
      - if drive is bus encryption capable but disc is not bus encryption
        enabled then bus encryption will not be used; however, drive will
        only allow hosts with bus encryption capable certificates, without
        one normal VID retrieval will fail, but getting VID from other
        source will make the disc playable
      - if drive is bus encryption capable and disc is bus encryption
        enabled then bus encryption will be used, only hosts with bus
        encryption capable certificates can read such discs; getting VID
        from other source is not enought to read such disc as one must also
        have Read Data Key to decrypt bus encryption which is drive specific
      While most of the current drives are supposed to be bus encryption
      capable, most of the discs currently are not and it is quite hard to
      come across one. Obviously this might change in the future.
      So what is encrypted by bus encryption? Excatly the same data that is
      encrypted by normal AACS, this means .m2ts files located in
      BDMV/STREAM directory. Only this and nothing else. Bus encryption is
      applied on the fly by the drive. Since the disc is already AACS
      encrypted the host must first decrypt bus encryption and then perform
      normal AACS decryption. So what is the difference? Bus encryption uses
      encryption key that is drive specific, this means that the same disc
      read on another drive model will produce differently encrypted
      data. Without bus encryption, files simply copied from disc can be
      decrypted if one gets proper VID. With bus encryption, such copy is
      useless, unless proper decryption key is retrieved from the exact same
      model of the drive. I am not sure if the encryption key is specific to
      the drive model or every drive unit will have a different one.
      This and several previous commits implement everything that is needed
      to support bus encryption:
      - determining if bus encryption is enabled from certificates
      - retrieval of read data key that is used to encrypt data
      - proper decryption (bus encryption works on sector boundary) before
        main AACS decryption
      Code was tested with mplayer on LG BH16NS40 with "The Alien Anthology
      Archives" disc from Alien Anthology (it is the only bus encryption
      enabled disc out of 6 in the anthology).
  17. 04 Mar, 2013 1 commit
  18. 04 Jan, 2013 1 commit
  19. 17 Aug, 2012 1 commit
  20. 07 May, 2012 3 commits
  21. 04 May, 2012 2 commits
  22. 01 May, 2012 1 commit
  23. 30 Apr, 2012 1 commit
  24. 29 Apr, 2012 1 commit
  25. 21 Mar, 2012 1 commit
  26. 18 Feb, 2012 7 commits