[bt-devel] BibleTime Locked Module Issue

[Troy A. Griffitts]

I would rather BT not assist hackers with providing them a method to guess if their unlock attempt works, but about your question, getRawEntryBuf will return whatever raw data the module has stored at the current key position of the module. Is the module positioned at a key which has data?
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Gary Holmlund <gary.holmlund at gmail.com> wrote:

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/b1bd5b16/attachment.html>