Hello, this is a question for the NSPR/NSS guys.

A few days ago, while having a problem parsing secmod.db contents we found:
    
http://stackoverflow.com/questions/2873581/is-it-possible-to-access-a-bdb-from-pure-java
and also:
    http://sethi.org/tmp/ssh/src/com/mindbright/bdb/DBHash.java
which helped us a lot parsing the secmod.db file to get the modules
installed on Firefox.

As Secmod Java object is not running properly on OSX, this (parsing)
is what we are going to use by now.
According to this sources, this is how the secmod.db file is organized:

    /**
     * (from page.h in dbm)
     * page format:
     *          +------------------------------+
     * p        | n | keyoff | datoff | keyoff |
     *          +------------+--------+--------+
     *          | datoff | free  |  ptr  | --> |
     *          +--------+---------------------+
     *          |        F R E E A R E A       |
     *          +--------------+---------------+
     *          |  <---- - - - | data          |
     *          +--------+-----+----+----------+
     *          |  key   | data     | key      |
     *          +--------+----------+----------+
     *
     * Pointer to the free space is always:  p[p[0] + 2]
     * Amount of free space on the page is:  p[p[0] + 1]
     */

For example, running the program we got (more or less) this output:

magic: 398689
version: 2
lorder: 1234
nkeys: 2
key:
NSS Internal PKCS #11 Module
data:
060322-27100000000000075000100000100000287883833273110116101114110971083280756783323549493277111100117108101002-93991111101021051031001051146139675892926879678577691264992926568777378731264992926865847983681264992927711112210510810897929270105114101102111120929280114111102105108101115929274756680818612649466869703932991011141168011410110210512061393932107101121801141011021051206139393211510199109111100613911510199109111100461009839321021089710311561111112116105109105122101831129799101321171121009711610110010511461393932117112100971161016710111411680114101102105120613939321171121009711610175101121801141011021051206139393211711210097116101105100613939321171121009711610184111107101110681011159911410511211610511111061393932321099711011710297991161171141011147368613977111122105108108974611111410339321081059811497114121681011159911410511211610511111061398310111411846329911410511211611110311497102-61-83973210511011610111411097328083773932991141211121161118411110710111068101115991141
 
0511211610511111061398310111411846329911410511211611110311497102-61-839732103101110-61-871141059911111539321009884111107101110681011159911410511211610511111061396810511511246321151111021161199711410132100101321151011031171141051009710039329911412111211611183108111116681011159911410511211610511111061398310111411810599105111115321001013299105102114971001113210511011610111411011132808377393210098831081111166810111599114105112116105111110613967108971181011153211211410511897100971153210010110832808377393270738083831081111166810111599114105112116105111110613968105115112463211510110311711410510097100321151111021161199711410132407073808341393270738083841111071011106810111599114105112116105111110613983101114118105991051111153299114105112116111103114-61-951021059911111544321001013299108971181013212132991011141161051021059997100111327073808332495248393210910511080836148010001-96363610003000000000000000000000
data len: 775
key:
DNIe
data:
060320750000000000000500000000000000468787310103367589287737868798783921151211151161011095150928511511480107991154949461001081080000
data len: 77

But we haven't been able to find any doc about what is the
schema/organization for the internal values.

For example:
    
060320750000000000000500000000000000468787310103367589287737868798783921151211151161011095150928511511480107991154949461001081080000
Can be matched to...
060320 = ???
750000000000000500000000000000 = ???
4 = length of name
687873101 0 = DNIe (\0?)
33 = length of path
6758928773786879878392115121115116101109515092851151148010799115494946100108108
0 =C:\Windows\...UsrPkcs11.dll (\0?)
0000 = ???

What are the bytes at the beginning or end?
Other PKCS#11 modules can have some extra bytes after the name...where
they came from?

And when reading "NSS Internal PKCS #11 Module" we get:
060322 = ???
-27100000000000075000100000100000 = ??? (negative must be overflow)
28 = length name
7883833273110116101114110971083280756783323549493277111100117108101 =
NSS Internal PKCS #11 Module
002-939911111010210... = ??? (Its configdir='C:\Documents..., but who
decides to store that in there? )

How is this stored?

Is there a better method (for java this time) to get the installed
PKCS#11 modules on Firefox, rather that parsing?
Is there a javascript code to get list of installed modules? (AFAIK,
only add or delete can be used)

Thanks a lot for your time (and reading until here)
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Reply via email to