[bt-devel] BibleTime Locked Module Issue

Gary Holmlund gary.holmlund at gmail.com
Sun May 13 21:17:23 MST 2012


Troy,

BibleTime stores the key in its $HOME/.bibletime/bibletimerc file. It 
sends it to sword using SWMgr::setCipherKey(). I don't see the key in 
the $HOME/.sword/mods.d/net.conf file.

The BibleTime test for being unlocked looks like this:

bool CSwordModuleInfo::unlockKeyIsValid() const {
     m_module->setPosition(sword::TOP);

     // This needs to use ::fromLatin1 because if the text is still locked,
     // a lot of garbage will show up. It will also work with properly 
decrypted
     // Unicode text, because all non-ASCII Unicode chars consist of 
bytes >127
     // and therefore contain no control (nonprintable) characters, 
which are all <127.
     QString test = isUnicode()
                    ? QString::fromUtf8(m_module->getRawEntryBuf().c_str())
                    : QString::fromLatin1( 
m_module->getRawEntryBuf().c_str() );

     if (test.isEmpty()) {
         return false;
     }

     for (int i = 0; i <= test.length() && i < 100; i++) {
         if ( !test[i].isPrint() && !test[i].isNull() ) {
             return false;
         }
     }

     return true;
}

When the failure to think it is unlocked occurs, the getRawEntryBuf() is 
returning an empty string. Does that seem right?

Gary


>SWORD does not have a means to determine if a key is valid, other than user confirmation that they see ungarbled text. This is intentional to impede brute force key hacking.
>
>I am not sure what logic BT uses to determine if a module is unlocked, but in BibleCS we ask the user for the key, use the key to retrieve text from the module, and then ask them if everything looks ok. Then save the key in the .conf file. If the .conf file has a key, we assume it has been unlocked. Hope this helps.
>
>Troy



On 05/12/2012 11:04 AM, Gary Holmlund wrote:
> I have been investigating issues in BibleTime related to locked 
> modules. I have found a repeatable case I have tried in 2.8, 2.9 and 
> 2.10git on linux. I can have a window open to the NET Bible (paid 
> version, I have the key installed) and am able to change Bible 
> references, etc. but at the same time the Bookshelf will show the 
> module as being locked and won't let me open another window. So it 
> appears that the method of determining locked status in the Bookshelf 
> is not consistent with the module actually  being unlocked.
>
> The module is unlocked when we call setCipherKey in CSwordModuleInfo. 
> This is working fine.
>
> The Bookshelf calls CSwordModuleInfo::unlockKeyIsValid() to determine 
> if the module is unlocked. In the repeatable problem case the 
> unlockKeyIsValid function calls getRawEntryBuf in sword and it returns 
> an empty string which indicates the module is locked. I have debugged 
> down into sword at this point, but because of the lack of comments in 
> sword code and the fact that involves calculating offsets into buffers 
> (no documentation on how this works), uncompress, etc. I have not been 
> able to figure out where the problem is.
>
> I am getting a little frustrated and wondering if anyone has thoughts 
> about this.
>
> Here is the repeatable case:
>
> Open BibleTime
> Open NET Bible (paid version with key)
> Open ESV Bible in parallel in same window as NET Bible
> Changing verse references works fine.
> Bookshelf shows NET Bible unlocked
> Close BibleTime
> Open BibleTime
> Session is restored showing NET and ESV in parallel
> Changing verse references works fine.
> Bookshelf shows NET Bible locked <--- error
> Remove the ESV Bible that is in parallel
> Bookshelf show NET Bible unlocked
>
> I have not seen the problem without having a second Bible in parallel 
> with NET. I am not sure how to write a small example using only sword. 
> I was able to write a small example for a different sword issue recently.
>
> Gary
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/bt-devel/attachments/20120513/b5477fde/attachment.html>


More information about the bt-devel mailing list