Up to MKB v68 KEYDB.cfg file [Archive]

libredr

29th August 2019, 09:51

Dear all,

I have created a KEYDB.cfg file with PK and Host certificate up to MKB v68, using information given on various threads in this forum. This can be useful to Linux users for instance, in addition to Nalor's FindVUK database. Obviously this will only work for drives which have not opened an MKB v70 disc.

Credits are given in the file. Please let me know of any mistake.

; KEYDB.cfg
; 2019-08-26 12:51:23
;
; processing keys: 31 (31 from doom9.org forum)
; host certificates: 9 (8 from doom9.org forum)
; disc VUK keys: feel free to add them from a public VUK database at then end of this file

; processing keys
| PK | 0x810827A76E5B2CC1685E3217A23E2186 ; DK_V01-V12
| PK | 0x44145A846F19D096F2C84A2E50C5C4F5 ; DK_V14-V16
| PK | 0xEB55A475080FBCF18534EFA0839A7373 ; DK_V17-V19
| PK | 0xFB4AC39009E82113D45ECF4B7EAEA467 ; DK_V20-V21
| PK | 0x8BF4FBD91A7FB7DB8576D1E5A15A8544 ; DK_V23-V28
| PK | 0xAA856A1BA814AB99FFDEBA6AEFBE1C04 ; DK_V01
| PK | 0x09F911029D74E35BD84156C5635688C0 ; v1
| PK | 0x455FE10422CA29C4933F95052B792AB2 ; v3
| PK | 0xF190A1E8178D80643494394F8031D9C8 ; v4
| PK | 0x7A5F8A09F833F7221BD41FA64C9C7933 ; v6-8
| PK | 0xC87294CE84F9CCEB5984B547EEC18D66 ; v9
| PK | 0x452F6E403CDF10714E41DFAA257D313F ; v10
| PK | 0x973940BB180E83266231EE596CEF65B2 ; v3-4/7-10/12-13
| PK | 0x58EBDADF88DCC93304CBBEDB9EE095F6 ; v14/15/16
| PK | 0x465FA8BE828509014D05D2FCCEFF35D2 ; v17
| PK | 0xAD5E546C46D72DC083AEB5686924E1B3 ; v18/19
| PK | 0x53FCE78ECD352DA50D526B5EE3D3D96B ; v20/21
| PK | 0xC32238976FF44A51E2D33553CFE85772 ; v23/25
| PK | 0x99AB6AE0A7E13504CE284B7CA401B26A ; v31-36
| PK | 0x19DF7DA3A1FB75AC4DC34CCB6AF6A5C7 ; v36-38 from maetel99 at https://forum.doom9.org/showthread.php?t=175334&page=2
| PK | 0x3FB9D3314AAC7F76581190A624A5C578 ; v39-43 "
| PK | 0x3ADE0AB7C9E4270055506C449E8EE6CF ; v24-48 "
| PK | 0x186D1BBA19487F6450C1FD5ADA9407E6 ; v44-51 "
| PK | 0xF2C416A45D806D964F567B5D7FED209D ; v49-52 "
| PK | 0x7A8BAB1B0C66C39D1A2EEE6883E4DD3C ; v53-54 "
| PK | 0x1F70D403A6D39B20A3F7131750ACAA22 ; v53-54 "
| PK | 0x8FBDD8452146552EF76136B0A348590B ; v55-57 "
| PK | 0x0EB5F81CF17405CAFDB97832F5EA11B4 ; v55-62 "
| PK | 0x76DDD7093216D28C15049A6B9C5C18B9 ; v63 from cyprus at https://forum.doom9.org/showthread.php?t=172472&page=22
| PK | 0x3B323C7A9AFC0921831D247239823DE6 ; v64-65 "
| PK | 0x7A4F40D8696B7B159BE8176CC9EDB85C ; v66-68 "

; host certificate from PS3, v25
| HC | HOST_PRIV_KEY 0x668C9A75EEFC8DA4261938E271285061BB09F0DD \
| HOST_CERT 0x0201005CFFFF80000039000065EAC9878B85EFF4 \
0xD77A62B1D600024ACE68DD3366880E4F844F34B7 \
0x7A050135A20E73B626DAEA5157B32EB84BC6E87B \
0x0DEE4D833CEADA86120151002C3C66D5256F71CF \
0xA68B7E55BA1B351F3403434E \
| HOST_NONCE 0x2923BE84E16CD6AE529049F1F1BBE9EBB3A6DB3C \
| HOST_KEY_POINT 0x8A60C80BD60C23605FBE90B27BF96B2DB38195C1 \
0x801F54EB29E0F6EC57AC2B9168E88B2D56977508

; host certificate from unknown, v20
| HC | HOST_PRIV_KEY 0x567A6A8EFFFD8967651CF1BB8D15EDB6D2463555 \
| HOST_CERT 0x0200005CFFFF0000006400006440BE797538E4FC \
0x369FC50BBE9F95CC694338210CDFACE0D2C878BA \
0xB96BB72BA5A29D0F7D2E9B836B4CE06781D93354 \
0x4E6258F1F38668B4733F24638CCB6F5B71220A22 \
0x20217367F833635E97784D9E \
| HOST_NONCE 0x2923BE84E16CD6AE529049F1F1BBE9EBB3A6DB3C \
| HOST_KEY_POINT 0x8A60C80BD60C23605FBE90B27BF96B2DB38195C1 \
0x801F54EB29E0F6EC57AC2B9168E88B2D56977508

; host certificate from aacskeys-0.4.0c original, v18
| HC | HOST_PRIV_KEY 0x8C8647FE2A70EF0388EA9E43F432CC441C6B108C \
| HOST_CERT 0x0200005CFFFF000000AE00004142A5411F1E63F1 \
0x85581C876B939FB40B523BF69C004CA69E047606 \
0xEE5183C0ABEF1E7D04CB6E65260677E7B0573D08 \
0xE60957935503ED78F7E27B190B4A7CAFCBAFF4A2 \
0x836453ECF72E49668DAF1DB9 \
| HOST_NONCE 0x2923BE84E16CD6AE529049F1F1BBE9EBB3A6DB3C \
| HOST_KEY_POINT 0x8A60C80BD60C23605FBE90B27BF96B2DB38195C1 \
0x801F54EB29E0F6EC57AC2B9168E88B2D56977508

; host certificate from powerdvd 7, v12
| HC | HOST_PRIV_KEY 0x4737676058D7029452514F0AB186DC4CCA8C578F \
| HOST_CERT 0x0200005CFFFF0000000C00006E3DEB679B9A16AD \
0xFAA8E30878767BA6EB2A9B415385AD1181B4446C \
0x31E9A5DD2AB808B364FF15885BAC490964318C9B \
0xF8029FCF76F688A54FBDA03F6D9332EF04E5A613 \
0x12DA85880A4D9CBB79D8602E \
| HOST_NONCE 0x2923BE84E16CD6AE529049F1F1BBE9EBB3A6DB3C \
| HOST_KEY_POINT 0x8A60C80BD60C23605FBE90B27BF96B2DB38195C1 \
0x801F54EB29E0F6EC57AC2B9168E88B2D56977508

; host certificate from aacskeys-0.4.0, v4
| HC | HOST_PRIV_KEY 0x88B245EA25315F46E6E99D9D521EB1194454A82D \
| HOST_CERT 0x0201005CFFFF800000C400005BF6843ED1AA9C9D \
0xEEFEAD8174479C72AB5457691EEB75669105BB19 \
0x5D4B9133069A18FD5357797116CEC22D7FE8F366 \
0xC2A092E1D00DB770E9E01DB687456B6FBFA28C96 \
0x2D88F05DD43F584ECC821AF7 \
| HOST_NONCE 0x2923BE84E16CD6AE529049F1F1BBE9EBB3A6DB3C \
| HOST_KEY_POINT 0x8A60C80BD60C23605FBE90B27BF96B2DB38195C1 \
0x801F54EB29E0F6EC57AC2B9168E88B2D56977508

; MKBv50 (revoked in MKBv51) from dizzier at doom9.org
| HC | HOST_PRIV_KEY 0x0F7B481182425FC4C32CDDE612DD05B1BD7863D6 \
| HOST_CERT 0x0203005CFFFF800000AD00005F27B91F047E60C2 \
0x51F4262DE74EC061F9261DCE3254EB737EDED53A \
0xD84E12805BBEEDB12C285A61627A529129BD98F8 \
0x590634CF35A9820CD213D5AF786BDE489EC37A75 \
0xD4D444B8AB40923E317169E9 \
| HOST_NONCE 0x2923BE84E16CD6AE529049F1F1BBE9EBB3A6DB3C \
| HOST_KEY_POINT 0x8A60C80BD60C23605FBE90B27BF96B2DB38195C1 \
0x801F54EB29E0F6EC57AC2B9168E88B2D56977508

; From Dizzier at doom9.org
| HC | HOST_PRIV_KEY 0x27263F402E2D6DB56B1FB7BB4524C6CD5C9F2EF4 \
| HOST_CERT 0x0201005CFFFF800001460000952D611B06911B0E \
0xAEE577D3715D1FA0E405914068752559DFBD845C \
0xB80F4FEE04A40B8FED842ACB78F9F898AEC39540 \
0x9E929C55A20A7EE853509BB84D8FB0DC99E5CAC5 \
0xF239F0CD79B38C0678702B1C \
| HOST_NONCE 0x2923BE84E16CD6AE529049F1F1BBE9EBB3A6DB3C \
| HOST_KEY_POINT 0x8A60C80BD60C23605FBE90B27BF96B2DB38195C1 \
0x801F54EB29E0F6EC57AC2B9168E88B2D56977508

; MKBv61 from dizzier at doom9.org
| HC | HOST_PRIV_KEY 0x5F291AE7CF68D67F58689A4CBFE2953064539FAA \
| HOST_CERT 0x0203005CFFFF8000018900003E7C4B0931C0045D \
0xFB017F24B1557F5BD0AF5B961FBC1B43519F9023 \
0xA1E84A3E8C06967B76469CC86527AA3807258C58 \
0xE00F73971F9BC8353165476454911E3A9D07D742 \
0x980598BFF9B3DF5EA18E0C7F \
| HOST_NONCE 0x2923BE84E16CD6AE529049F1F1BBE9EBB3A6DB3C \
| HOST_KEY_POINT 0x8A60C80BD60C23605FBE90B27BF96B2DB38195C1 \
0x801F54EB29E0F6EC57AC2B9168E88B2D56977508

; MKBv68 (revoked in MKBv70) from mick0 at https://forum.doom9.org/showthread.php?t=172472&page=22
| HC | HOST_PRIV_KEY 0x5924778E74CC2B18B95BAE7D93A09505B1BF08CE \
| HOST_CERT 0x0201005CFFFF800001B100005F1407EDBF9D1CD3 \
0x8F33A625209B5ED10D48F71E2AB2A1C53CCF9E25 \
0xD6AEB4BEE968FBBD10DC44064841C35810673158 \
0x9A2C12DD5B4D86FE840D2C6525594E72A19C2EDB \
0xC3DD6A28F75E9A9C00D684BB \
| HOST_NONCE 0x2923BE84E16CD6AE529049F1F1BBE9EBB3A6DB3C \
| HOST_KEY_POINT 0x8A60C80BD60C23605FBE90B27BF96B2DB38195C1 \
0x801F54EB29E0F6EC57AC2B9168E88B2D56977508

; disc VUK keys (add them below)

candela

29th August 2019, 17:10

unless you want to make a keydb.cfg which includes all known keys up to this point (in which case a lot are missing), it's pointless
- including the ; DK_ keys since they are device keys and don't work in libaacs with a |PK| tag
- including any of these certs below MKBv68 because those are also revoked in MKBv70

and btw, it's a very bad idea to start using this and stop contributing to FindVUK's database because all your discs play. Once the cert is revoked and you no longer have VLC's cached key files, you will not be playing your discs anymore

mick0

29th August 2019, 20:37

Dear all,

I have created a KEYDB.cfg file with PK and Host certificate up to MKB v68, using information given on various threads in this forum. This can be useful to Linux users for instance, in addition to Nalor's FindVUK database. Obviously this will only work for drives which have not opened an MKB v70 disc.

Credits are given in the file. Please let me know of any mistake.

Those "DK" keys are actually device keys so those won't work when used as "PK".

This should contain all currently known host certs, device keys and processing keys in proper libaacs format. Only one host certificate is required (the first one).
; KEYDB.cfg

; Contents:
; - Device Keys: 15
; - Processing Keys: 29
; - Host Certificates: 10

; Device Keys
| DK | DEVICE_KEY 0xAA856A1BA814AB99FFDEBA6AEFBE1C04 | DEVICE_NODE 0x0018 | KEY_UV 0x00000001 | KEY_U_MASK_SHIFT 0x17 ; MKBv01
| DK | DEVICE_KEY 0x810827A76E5B2CC1685E3217A23E2186 | DEVICE_NODE 0x0100 | KEY_UV 0x00000100 | KEY_U_MASK_SHIFT 0x17 ; MKBv01-MKBv12
| DK | DEVICE_KEY 0x44145A846F19D096F2C84A2E50C5C4F5 | DEVICE_NODE 0x0200 | KEY_UV 0x00000280 | KEY_U_MASK_SHIFT 0x09 ; MKBv14-MKBv16
| DK | DEVICE_KEY 0xEB55A475080FBCF18534EFA0839A7373 | DEVICE_NODE 0x0340 | KEY_UV 0x00000340 | KEY_U_MASK_SHIFT 0x08 ; MKBv17-MKBv19
| DK | DEVICE_KEY 0xFB4AC39009E82113D45ECF4B7EAEA467 | DEVICE_NODE 0x0388 | KEY_UV 0x00000384 | KEY_U_MASK_SHIFT 0x07 ; MKBv20-MKBv21
| DK | DEVICE_KEY 0x8BF4FBD91A7FB7DB8576D1E5A15A8544 | DEVICE_NODE 0x0388 | KEY_UV 0x00000384 | KEY_U_MASK_SHIFT 0x05 ; MKBv22-MKBv30
| DK | DEVICE_KEY 0xA088BC72424478EACAF237A9E258351E | DEVICE_NODE 0x0400 | KEY_UV 0x00000200 | KEY_U_MASK_SHIFT 0x17 ; MKBv01-MKBv23
| DK | DEVICE_KEY 0x5FB86EF127C19C171E799F61C27BDC2A | DEVICE_NODE 0x0800 | KEY_UV 0x00000400 | KEY_U_MASK_SHIFT 0x17 ; MKBv01-MKBv48
| DK | DEVICE_KEY 0x6C02A9C4DF6DE9314F6F4BB44677BD67 | DEVICE_NODE 0x0600 | KEY_UV 0x00000500 | KEY_U_MASK_SHIFT 0x0A ; MKBv24-MKBv35
| DK | DEVICE_KEY 0x4D84E4D6D434A08D6EF0B523B6D891B2 | DEVICE_NODE 0x0700 | KEY_UV 0x00000680 | KEY_U_MASK_SHIFT 0x09 ; MKBv36-MKBv43
| DK | DEVICE_KEY 0xF2F56575C0C5448042298FA9B316AB9A | DEVICE_NODE 0x0710 | KEY_UV 0x00000714 | KEY_U_MASK_SHIFT 0x04 ; MKBv44-MKBv51
| DK | DEVICE_KEY 0x31A194B61D3119D2B09DC0D8B9A73A00 | DEVICE_NODE 0x0880 | KEY_UV 0x00000840 | KEY_U_MASK_SHIFT 0x0B ; MKBv49-MKBv52
| DK | DEVICE_KEY 0x25F9782764D026413C3D4868F891E81E | DEVICE_NODE 0x0884 | KEY_UV 0x000008A0 | KEY_U_MASK_SHIFT 0x07 ; MKBv53-MKBv54
| DK | DEVICE_KEY 0xFDAD855E9A89E5335288AF2805DC0497 | DEVICE_NODE 0x08F0 | KEY_UV 0x000008FC | KEY_U_MASK_SHIFT 0x04 ; MKBv55-MKBv57
| DK | DEVICE_KEY 0x7FD1F7966AD2B0E4F4901205E32A69BA | DEVICE_NODE 0x0A00 | KEY_UV 0x00000900 | KEY_U_MASK_SHIFT 0x0B ; MKBv49-MKBv62

; Processing Keys
| PK | 0x09F911029D74E35BD84156C5635688C0 ; MKBv01
| PK | 0x455FE10422CA29C4933F95052B792AB2 ; MKBv03
| PK | 0x973940BB180E83266231EE596CEF65B2 ; MKBv03-MKBv12
| PK | 0xF190A1E8178D80643494394F8031D9C8 ; MKBv04
| PK | 0x7A5F8A09F833F7221BD41FA64C9C7933 ; MKBv06-MKBv08
| PK | 0xC87294CE84F9CCEB5984B547EEC18D66 ; MKBv09
| PK | 0x452F6E403CDF10714E41DFAA257D313F ; MKBv10
| PK | 0x58EBDADF88DCC93304CBBEDB9EE095F6 ; MKBv14-MKBv16
| PK | 0xCC72242D4CC8156B960502805987DED0 ; MKBv14-MKBv23
| PK | 0x465FA8BE828509014D05D2FCCEFF35D2 ; MKBv17
| PK | 0xAD5E546C46D72DC083AEB5686924E1B3 ; MKBv18-MKBv19
| PK | 0x53FCE78ECD352DA50D526B5EE3D3D96B ; MKBv20-MKBv21
| PK | 0xC32238976FF44A51E2D33553CFE85772 ; MKBv22-MKBv30
| PK | 0x3ADE0AB7C9E4270055506C449E8EE6CF ; MKBv24-MKBv48
| PK | 0xD11E3DBA323D37DE3DE0D6A0DC5EC807 ; MKBv24-MKBv25
| PK | 0xAAAF8A16F829DA16A124D837F64EE2D8 ; MKBv26-MKBv28
| PK | 0xC0F535929D59CD071BEE9CB53F0C21C2 ; MKBv30-MKBv35
| PK | 0x99AB6AE0A7E13504CE284B7CA401B26A ; MKBv31-MKBv36
| PK | 0x19DF7DA3A1FB75AC4DC34CCB6AF6A5C7 ; MKBv36-MKBv38
| PK | 0x3FB9D3314AAC7F76581190A624A5C578 ; MKBv39-MKBv43
| PK | 0x186D1BBA19487F6450C1FD5ADA9407E6 ; MKBv44-MKBv51
| PK | 0xF2C416A45D806D964F567B5D7FED209D ; MKBv49-MKBv52
| PK | 0x7A8BAB1B0C66C39D1A2EEE6883E4DD3C ; MKBv53-MKBv54
| PK | 0x1F70D403A6D39B20A3F7131750ACAA22 ; MKBv53-MKBv54
| PK | 0x8FBDD8452146552EF76136B0A348590B ; MKBv55-MKBv57
| PK | 0x0EB5F81CF17405CAFDB97832F5EA11B4 ; MKBv55-MKBv62
| PK | 0x76DDD7093216D28C15049A6B9C5C18B9 ; MKBv63
| PK | 0x3B323C7A9AFC0921831D247239823DE6 ; MKBv64-MKBv65
| PK | 0x7A4F40D8696B7B159BE8176CC9EDB85C ; MKBv66-MKBv68

; Host Certificates
| HC | HOST_PRIV_KEY 0x909250D0C7FC2EE0F0383409D896993B723FA965 | HOST_CERT 0x0203005CFFFF800001C100003A5907E685E4CBA2A8CD5616665DFAA74421A14F6020D4CFC9847C23107697C39F9D109C8B2D5B93280499661AAE588AD3BF887C48DE144D48226ABC2C7ADAD0030893D1F3F1832B61B8D82D1FAFFF81 ; Revoked in MKBv72
| HC | HOST_PRIV_KEY 0x5924778E74CC2B18B95BAE7D93A09505B1BF08CE | HOST_CERT 0x0201005CFFFF800001B100005F1407EDBF9D1CD38F33A625209B5ED10D48F71E2AB2A1C53CCF9E25D6AEB4BEE968FBBD10DC44064841C358106731589A2C12DD5B4D86FE840D2C6525594E72A19C2EDBC3DD6A28F75E9A9C00D684BB ; Revoked in MKBv70
| HC | HOST_PRIV_KEY 0x5F291AE7CF68D67F58689A4CBFE2953064539FAA | HOST_CERT 0x0203005CFFFF8000018900003E7C4B0931C0045DFB017F24B1557F5BD0AF5B961FBC1B43519F9023A1E84A3E8C06967B76469CC86527AA3807258C58E00F73971F9BC8353165476454911E3A9D07D742980598BFF9B3DF5EA18E0C7F ; Revoked in MKBv63
| HC | HOST_PRIV_KEY 0x27263F402E2D6DB56B1FB7BB4524C6CD5C9F2EF4 | HOST_CERT 0x0201005CFFFF800001460000952D611B06911B0EAEE577D3715D1FA0E405914068752559DFBD845CB80F4FEE04A40B8FED842ACB78F9F898AEC395409E929C55A20A7EE853509BB84D8FB0DC99E5CAC5F239F0CD79B38C0678702B1C ; Revoked in MKBv58
| HC | HOST_PRIV_KEY 0x0F7B481182425FC4C32CDDE612DD05B1BD7863D6 | HOST_CERT 0x0203005CFFFF800000AD00005F27B91F047E60C251F4262DE74EC061F9261DCE3254EB737EDED53AD84E12805BBEEDB12C285A61627A529129BD98F8590634CF35A9820CD213D5AF786BDE489EC37A75D4D444B8AB40923E317169E9 ; Revoked in MKBv51
| HC | HOST_PRIV_KEY 0x88B245EA25315F46E6E99D9D521EB1194454A82D | HOST_CERT 0x0201005CFFFF800000C400005BF6843ED1AA9C9DEEFEAD8174479C72AB5457691EEB75669105BB195D4B9133069A18FD5357797116CEC22D7FE8F366C2A092E1D00DB770E9E01DB687456B6FBFA28C962D88F05DD43F584ECC821AF7 ; Revoked in MKBv46
| HC | HOST_PRIV_KEY 0x668C9A75EEFC8DA4261938E271285061BB09F0DD | HOST_CERT 0x0201005CFFFF80000039000065EAC9878B85EFF4D77A62B1D600024ACE68DD3366880E4F844F34B77A050135A20E73B626DAEA5157B32EB84BC6E87B0DEE4D833CEADA86120151002C3C66D5256F71CFA68B7E55BA1B351F3403434E ; Revoked in MKBv32
| HC | HOST_PRIV_KEY 0x567A6A8EFFFD8967651CF1BB8D15EDB6D2463555 | HOST_CERT 0x0200005CFFFF0000006400006440BE797538E4FC369FC50BBE9F95CC694338210CDFACE0D2C878BAB96BB72BA5A29D0F7D2E9B836B4CE06781D933544E6258F1F38668B4733F24638CCB6F5B71220A2220217367F833635E97784D9E ; Revoked in MKBv22
| HC | HOST_PRIV_KEY 0x8C8647FE2A70EF0388EA9E43F432CC441C6B108C | HOST_CERT 0x0200005CFFFF000000AE00004142A5411F1E63F185581C876B939FB40B523BF69C004CA69E047606EE5183C0ABEF1E7D04CB6E65260677E7B0573D08E60957935503ED78F7E27B190B4A7CAFCBAFF4A2836453ECF72E49668DAF1DB9 ; Revoked in MKBv17
| HC | HOST_PRIV_KEY 0x4737676058D7029452514F0AB186DC4CCA8C578F | HOST_CERT 0x0200005CFFFF0000000C00006E3DEB679B9A16ADFAA8E30878767BA6EB2A9B415385AD1181B4446C31E9A5DD2AB808B364FF15885BAC490964318C9BF8029FCF76F688A54FBDA03F6D9332EF04E5A61312DA85880A4D9CBB79D8602E ; Revoked in MKBv03

; Insert Disc Keys Here

However, I agree with what candela said, disc keys should be cached and collected. Once the host certificate gets revoked, libaacs/aacskeys can't calculate VUKs anymore.

libredr

30th August 2019, 07:25

Hi,

Thanks for your comments and corrections.

I think there is a misunderstanding about what I am trying to achieve. I entirely agree with you candela, and my goal was certainly not to stop contributing to FindVUK database. I have been sharing VUKs and intend to continue. However I am a Linux user and it is quite difficult to find native ways to decrypt AACS and feed the FindVUK database on that system. The only native software that can decrypt is makemkv, since DVDFab for Linux has been discontinued and there are no known ways to collect the VUKs with it. Hence the importance to keep the PK/Host KC decryption method.

libredr

16th October 2019, 13:33

Thanks mick0 for maintaining the list!

DanTheMann15

21st October 2019, 00:02

I don't really see why you need to use all the old revoked host certificates, all you really need is just the latest one.

as for Processing keys and device keys, i have just the 3 newest processing keys since i never needed the older ones because i got device keys up to MKBv62.

my setup with just these few entries works perfectly well for me.

EDIT: here's my revised config with mick0's new host certificate that works up to MKBv71 (revoked in MKBv72), but it still won't decrypt any blurays above MKBv68 because there are no known processing keys available for MKBv70-71 discs yet, but it still should help anyone play BEE blurays in VLC if they inserted a MKBv70-71 disc.

; KEYDB.cfg

; Processing Keys
| PK | 0x76DDD7093216D28C15049A6B9C5C18B9 ; v63
| PK | 0x3B323C7A9AFC0921831D247239823DE6 ; v64-65
| PK | 0x7A4F40D8696B7B159BE8176CC9EDB85C ; v66-68

; Device Keys
| DK | DEVICE_KEY 0x5FB86EF127C19C171E799F61C27BDC2A | DEVICE_NODE 0x0A00 | KEY_UV 0x00000400 | KEY_U_MASK_SHIFT 0x17 ; MKBv01-MKBv48
| DK | DEVICE_KEY 0x7FD1F7966AD2B0E4F4901205E32A69BA | DEVICE_NODE 0x0A00 | KEY_UV 0x00000900 | KEY_U_MASK_SHIFT 0x0B ; MKBv49-MKBv62

; Host Certificate
| HC | HOST_PRIV_KEY 0x909250D0C7FC2EE0F0383409D896993B723FA965 | HOST_CERT 0x0203005CFFFF800001C100003A5907E685E4CBA2A8CD5616665DFAA74421A14F6020D4CFC9847C23107697C39F9D109C8B2D5B93280499661AAE588AD3BF887C48DE144D48226ABC2C7ADAD0030893D1F3F1832B61B8D82D1FAFFF81 ; MKBv71

; Bluray Disc VUK Keys ;

nevcairiel

21st October 2019, 00:17

Archiving all known keys is still valuable - how much you actually need is entirely different. mick0 already pointed out in his post that you do indeed only need the newest host certificate, for example.

DanTheMann15

21st October 2019, 05:55

@nevcairiel ; i agree with you that archiving all known keys is valuable, as they can help down the road if anyone needs them for any reason.

but for those who want a basic keydb.cfg, they can use a 2kb file that contains the basic stuff needed for AACS authentication with libaacs. :)

Balling

2nd August 2020, 17:35

Hi,

I think there is a misunderstanding about what I am trying to achieve. I entirely agree with you candela, and my goal was certainly not to stop contributing to FindVUK database. I have been sharing VUKs and intend

But mmm... "LibreDrive tells compatible drives to ignore that table, so it won't affect people using LD mode. But it does affect drives those drives in non-LD mode." No?

candela

28th July 2023, 18:29

magician

1st August 2023, 09:42

Here's a new minimal keydb.cfg header with all necessary device keys and a host certificate to play Blu-rays up to MKBv81.

Amazing, thanks!

MrPenguin

31st October 2023, 13:13

Here's a new minimal keydb.cfg header with all necessary device keys and a host certificate to play Blu-rays up to MKBv81.

I have just tested this minimal KEYDB.cfg with a MKBv38 disk, and aacs_info cannot use this host certificate to obtain the disk's Volume ID:
mmc.c:472: Host key / Certificate (id 0xffff80000217) has been revoked by your drive ?
libaacs open failed: Revoked certificate
mmc.c:472: Host key / Certificate (id 0xffff80000217) has been revoked by your drive ?
aacs.c:1545: aacs_get_vid() failed
mmc.c:472: Host key / Certificate (id 0xffff80000217) has been revoked by your drive ?
My drive's revocation list is from MKBv76.

candela

31st October 2023, 18:42

I have just tested this minimal KEYDB.cfg with a MKBv38 disk, and aacs_info cannot use this host certificate to obtain the disk's Volume ID:

My drive's revocation list is from MKBv76.

Play an MKBv81 disc first and it works again for lower MKBv. Don't ask why, just do it :)

Also, I have changed the device nodes

MrPenguin

31st October 2023, 19:46

Play an MKBv81 disc first and it works again for lower MKBv. Don't ask why, just do it :)
Err, OK. But unfortunately, MKBv76 is the highest version disc I possess.

MrPenguin

18th November 2023, 15:28

Err, OK. But unfortunately, MKBv76 is the highest version disc I possess.

I have now acquired "Dungeons and Dragons - Honor Among Thieves", which has cast "MKBv+5" on my drive :sly:.

pitsie

21st November 2023, 10:28

Play an MKBv81 disc first and it works again for lower MKBv. Don't ask why, just do it :)

Also, I have changed the device nodes

Would you be able to post a copy of MKB81 somewhere? Having trouble finding it and would like to keep myself entertained by analyzing it :)

candela

21st November 2023, 21:59

Would you be able to post a copy of MKB81 somewhere? Having trouble finding it and would like to keep myself entertained by analyzing it :)

They are in topic Public MKBs (https://forum.doom9.org/showthread.php?p=1972563#post1972563)

magician

6th December 2023, 23:30

Over the past few months the FindVUK database has been gaining MK and VUK entries for many UHD discs, including on freshly released titles, where before the vast majority only had the decrypted unit keys. Likely someone out there who has a AACS2.x processing key decided to start publicly contributing more data from discs.

DanTheMann15

7th December 2023, 04:32

Over the past few months the FindVUK database has been gaining MK and VUK entries for many UHD discs, including on freshly released titles, where before the vast majority only had the decrypted unit keys. Likely someone out there who has a AACS2.x processing key decided to start publicly contributing more data from discs.

I believe this is because some UHD drives are "UHD Friendly" drives, in which on the right firmware they'll accept valid AACSv1 Host certificates and keys to decrypt UHD discs, plus may be able to disable BUS Encryption so validation can succeed.

that's my two cents.

magician

7th December 2023, 09:00

I believe this is because some UHD drives are "UHD Friendly" drives, in which on the right firmware they'll accept valid AACSv1 Host certificates and keys to decrypt UHD discs, plus may be able to disable BUS Encryption so validation can succeed.

that's my two cents.

AIUI... successfully authenticating to a drive with a host certificate (HC) allows you to ask for the volume ID (VID) of the disc as well as defeat bus encryption, but the HC alone doesn't help you decrypt titles.

(apologies for the below recap of how AACS works)

The so-called "UHD friendly" drives accept v1 HC for UHD discs because they are older than the v2 spec but can still read larger capacity and sometimes triple layer BDs. Official drives would only accept v2 HC for UHD discs. MakeMKV probably has embedded non-revoked v1 and v2 HC so it can get the VID of any disc up to its currently supported MKB version.

Titles are encrypted with title keys, and encrypted title keys are stored on the disc along with the MKB. The volume unique key (VUK) is used to decrypt the encrypted title keys. The VUK is computed from a media key (MK) and VID. To get a MK, you need a processing key (PK), which is partially derived from the device keys (DK) specific to the player (drive or software).

I speculated someone with access to an AACS2 PK is using it to contribute key data since as of yet no such PK/DK is publicly available. Otherwise you and I could just as easily compute VUKs locally for any UHD discs with the MKB versions the PK is valid for. But I don't think that's the case right now.

(In case my position isn't clear: Yes, I know that the only way new UHD titles are being decrypted at all is that certain individuals connected to popular decryption programs have sources to obtain AACS2 keys. My point isn't that this is news to me. It's that up until recently, the more versatile data like VUKs for discs weren't appearing in the online FindVUK database.)

elsanto

1st March 2024, 00:04

Play an MKBv81 disc first and it works again for lower MKBv. Don't ask why, just do it :)

I think that I have the same problem than MrPenguin, and I don't know why this is happening.

I am supposed to no asking why is this necessary, but can you point to some source of information so I can discover for myself?

Thank you and regards.

MrPenguin

7th March 2024, 14:01

I am supposed to no asking why is this necessary, but can you point to some source of information so I can discover for myself?

Errr, err, it must be due to Evil Pixies.

RealSnoopyDog

13th March 2024, 05:25

It is logical why this happens. The information what should be revoked or unrevoked is stored on a Blu-Ray

coricopat

19th March 2024, 04:18

Hey.

Play an MKBv81 disc first and it works again for lower MKBv. Don't ask why, just do it :)

Is there any way to "simulate" this? E.g. with by using the downloadable MKBs and... I don't know... getting libaacs to do as if it would play back a disk with one (the newest) of them?
(It's a bit annoying having to buy some newish disc just to get the drive working - in the sense of decrypting bus encryption - for old ones again.)

Also, I have changed the device nodes

Could you possibly explain what that means? :-)

Thanks,
Coricopat

Bandits

24th May 2025, 23:04

Here's a new minimal keydb.cfg header with all necessary device keys and a host certificate to play Blu-rays up to MKBv81

; KEYDB.cfg

; Processing Keys

; Device Keys
| DK | DEVICE_KEY 0x5FB86EF127C19C171E799F61C27BDC2A | DEVICE_NODE 0x0800 | KEY_UV 0x00000400 | KEY_U_MASK_SHIFT 0x17 ; MKBv01-MKBv48
| DK | DEVICE_KEY 0x38841673E2B4E05191659899606CFFB8 | DEVICE_NODE 0x0C00 | KEY_UV 0x00000A00 | KEY_U_MASK_SHIFT 0x0B ; MKBv49-MKBv71
| DK | DEVICE_KEY 0x861B3719B02F24BE6F1A30E2E3ABEE94 | DEVICE_NODE 0x0E00 | KEY_UV 0x00000D00 | KEY_U_MASK_SHIFT 0x0A ; MKBv72-MKBv81
| DK | DEVICE_KEY 0x7C06DEAE7F49B551DAF538C8CF1811C9 | DEVICE_NODE 0x0E20 | KEY_UV 0x00000E23 | KEY_U_MASK_SHIFT 0x02 ; MKBv82-...

; Host Certificate
| HC | HOST_PRIV_KEY 0x4B7AEF00859AF7F8E88AE97418D862FBE404571A | HOST_CERT 0x0203005CFFFF800002170000473B98057A4A91296C0A6FDF0E314F449A557C2A146BF1E54C25E36595210C4CAAE373872178B47A7E46A766A550EA6C0B8895855E29DA80C77FF37837EEE336C7FA9F1A95E86F2F4D03E3DEE3BE9217 ; revoked in MKBv82

; Bluray Disc VUK Keys ;

Will this still work for MKBv81 and below if a drive sees a MKBv82 disc? I thought you needed a non-revoked HC.

How are MKBv82 keys being generated? Is there a HC that hasn't been shared yet that works with MKBv82?

SamuriHL

25th May 2025, 02:29

There's no non-revoked HC that I'm aware of but I'm no expert. I can, however, tell you how I've dealt with V82 discs given this new device key. The HC is only relevant to get the VID. So if you have other means of acquiring the VID, e.g. MakeMKV and parsing it from the discatt.dat file from an encrypted backup or a dump file, then you can bypass the HC completely. Easiest way I've seen is using AACSKeys and providing it the VID. It'll take care of the rest with the device key. :)

EDIT: Sorry I should be more clear here. You need to use a LibreDrive capable drive in order to use the method I outlined. And parsing the discatt.dat....there's instructions in another thread on this forum. The thread was about pulling the read data key for bus encryption but also has information on parsing the VID.

https://forum.doom9.org/showthread.php?t=184373

Bandits

25th May 2025, 16:42

There's no non-revoked HC that I'm aware of but I'm no expert. I can, however, tell you how I've dealt with V82 discs given this new device key. The HC is only relevant to get the VID. So if you have other means of acquiring the VID, e.g. MakeMKV and parsing it from the discatt.dat file from an encrypted backup or a dump file, then you can bypass the HC completely. Easiest way I've seen is using AACSKeys and providing it the VID. It'll take care of the rest with the device key. :)

EDIT: Sorry I should be more clear here. You need to use a LibreDrive capable drive in order to use the method I outlined. And parsing the discatt.dat....there's instructions in another thread on this forum. The thread was about pulling the read data key for bus encryption but also has information on parsing the VID.

https://forum.doom9.org/showthread.php?t=184373

I use a MakeMKV > VID fallback method when I cannot get a VID with aacs_info. The drive I use is not flashed with LibreDrive and works fine to get the VID on AACSv1 including MKBv82 disc's (I don't do many AACSv2 disc's and use a different drive when I do).

I usually use aacs_info and aacskeys to generate all the required keys (Script is in my sig). I inserted a MKBv82 disc yesterday and now I can no longer use aacs_info to get a VID on any MKBv unless the keys are cached in a DB or in the \aacs\vid directory.

aacs_info reports no valid HC to process disc. This is why I questioned the ability to still use the quoted information to calculate MKBv81 and below if your drive sees a MKBv82 disc.

I still have an automated way to use MakeMKV, aacs_info, and aacskeys. It is way more clunky, but it keeps me going until a new HC gets leaked. Also, the KeyDB.cfg helps a lot, but I just had to do 3 disc's that were not in there.

I agree, I am no expert here, but I have been doing ok since Slysoft went away. I only have 1 disc that has stopped me and that's a AACSv2.1 disc.

SamuriHL

25th May 2025, 17:06

I use a MakeMKV > VID fallback method when I cannot get a VID with aacs_info. The drive I use is not flashed with LibreDrive and works fine to get the VID on AACSv1 including MKBv82 disc's (I don't do many AACSv2 disc's and use a different drive when I do).

I usually use aacs_info and aacskeys to generate all the required keys (Script is in my sig). I inserted a MKBv82 disc yesterday and now I can no longer use aacs_info to get a VID on any MKBv unless the keys are cached in a DB or in the \aacs\vid directory.

aacs_info reports no valid HC to process disc. This is why I questioned the ability to still use the quoted information to calculate MKBv81 and below if your drive sees a MKBv82 disc.

I still have an automated way to use MakeMKV, aacs_info, and aacskeys. It is way more clunky, but it keeps me going until a new HC gets leaked. Also, the KeyDB.cfg helps a lot, but I just had to do 3 disc's that were not in there.

I agree, I am no expert here, but I have been doing ok since Slysoft went away. I only have 1 disc that has stopped me and that's a AACSv2.1 disc.

Right, once your drive sees v82, the MKB revocation list gets updated and the cert that used to work is now revoked. So until (if?) a new cert that's not revoked is leaked, that cert can no longer be used with ANY disc now if your drive has the v82 MKB revocation list. I wrote my own tool to deal with this nonsense. LOL It uses MakeMKV to retrieve the VID and then generates the rest of the keys, bypassing any host cert issues. The leaked device key for v82 is a godsend and god bless those who were able to find it.

MrPenguin

25th May 2025, 23:54

Also, the KeyDB.cfg helps a lot, but I just had to do 3 disc's that were not in there.
Out of interest, do you have any (UHD?) disks which aren't currently in KEYDB.cfg? And what is your AACSv2.1 disk?

Bandits

26th May 2025, 17:59

Out of interest, do you have any (UHD?) disks which aren't currently in KEYDB.cfg? And what is your AACSv2.1 disk?

All my discs are listed in the DB. I don't know if they are the same versions. I would have to break out my UHD drive and discs to check.

Only have 11 UHD. I used both MakeMKV and AnyDVD-HD to decrypt them at the time to test the differences in decrypting. I use the extracted data to test my ripping program because they all have different specs.

I have the one version of Zombieland that still hasn't been broken.

MrPenguin

27th May 2025, 00:22

All my discs are listed in the DB. I don't know if they are the same versions. I would have to break out my UHD drive and discs to check.
OK, I am just saying that if your particular DiscIDs do not have full entries in KEYDB with MK/VID/VUK then IMHO it would be worth trying to add them :).