Unable to open p/word protected file anymore

[peegiddy]

Having created a number of ODP files and saved them withg a password. I can no longer open them. I have checked to ensure correct capitals.
I did save a back up with no p/word to ensure they all opened OK Now I find none of the p/waord protected files will open any more. I have also deleted the old non protected files as the later protected versions were woring fine and I could open and close them once the password was ented into the msg box
Is there any work around or have I now lost these files?
Thanks for any help
Peeter

[John_Ha]

Welcome to the forum.

We know no easy way using AOO but you could search the forums just in case.

Google lost password open office for ideas and utilities which claim to recover a password.

Let us know how you get on.

You will be wise in future to store all passwords in a password manager like KeePass or Password Safe.

[RoryOF]

By any chance have the files been moved from another computer in their passworded form? If so, it may be that they became corrupted in the move, hence the password wont work.

I see so many reports of problems (for whatever reason) with passworded files that I would not use them; if security was essential, I would archive the files using a password, or store then to a USB HD which I would keep in my case (note: not a USB stick).

[peegiddy]

Thanks for your reply
Yes - I did also copy them all to another HDD and in addtion I also copied them to my NAS I have tried all of these but get the same result i.e. will not recognise the p/word. After I copied them I did in fact try to open them after the copy was succesful and found the p/word(s) were recognised and the files opened. Since them I have not had the need to use these presentation files. So its only in recent days I have encounted this issue
BTW I tend not to use USB drives for anything that is not already on the PC or backed up but thanks for the warning

[John_Ha]

1. Rename the .odp file to a .zip file (ie fred.odp > fred.zip)
2. Double click fred.zip.

Does it look like this?

If it looks like the image above the file is unlikely to be corrupted - you just need to keep on trying password variants.

If not, post an image of what it does look like (Alt+PrtScrn takes a copy of the active window), or upload a file here or to a file share site, or send me a copy to the email ID I sent you.

Having created a number of ODP files and saved them with a password. I can no longer open them.

Also, what is the exact sequence of events you do and the exact error message you get when you go File > Open ..., and try to open a file? Are the files merely blocked because they come from another PC?

[peegiddy]

I did try this and have the same set of folders and files as the image you sent. No sure what the next process is
Inorder toopen a p/word protected file The msg box asks for a password. After entering the p/w I have the next window msg box to say the p/w is incorrect and the file cannot be opened. I have tried to use various combinations of the p/word I feel certain is correct as I base this on the name of the file as a memory jogger. Not the exact file name of course.

[John_Ha]

The file is therefore probably OK but you probably mistyped the password when you last saved it.

What I would suggest is that you type in all possible passwords into a Notepad file including possible typos (adjacent keys, Ctrl instead of shift, Caps lock instead of Shift etc) and paste them one by one into the password field. That way you can be sure of no typos, and also be sure you try all possible combinations.

Or use one of the password cracking sites or utilities you found when you Googled.

[peegiddy]

Will resting the PC used to create thefiles and p/waords makea difference I did recover the windows system drive/partion some months back - but I also have these files ona laptop and have the same issue with that so Im fairly certain this shouldnt be the problem?

[John_Ha]

A thought. Is it possible the file(s) have been saved with MS Office? or LibreOffice?

AOO does not support some of the newer cryptographic systems used by MS Office - see [Tutorial] Differences between Writer and MS Word files for information on passwords. Try opening them with MS Office or LO. Manifest.xml from \META-INF in the .odp file lists the encryption method used - see excerpt below.

That being said what I cannot understand is why more than one file no longer opens.

If it was just one file I would say it was a mistake typing or you have forgotten you changed it.

As it is more than one file, a typo becomes less likely and we need to look for something systematic. It could be a faulty key on your keyboard, or a repetitive typo you make, or something else. Have you changed your "memory jog" method? Do any password protected old files open OK? Try and establish a timeline of how and when the files opened OK, and when, and in which order, they started failing to open OK.

Create a new file and give it the password you thought you were using. Does it work OK? Does the encryption in manifest.xml look the same as in your other files which will not open?

Excerpt from manifest.xml for a password protected .odp file.

Code: Select all   Expand viewCollapse view

<?xml version="1.0" encoding="UTF-8"?>
<manifest:manifest xmlns:manifest="urn:oasis:names:tc:opendocument:xmlns:manifest:1.0" manifest:version="1.2">

   <manifest:file-entry manifest:media-type="application/vnd.oasis.opendocument.presentation" manifest:version="1.2" manifest:full-path="/"/>

   <manifest:file-entry manifest:media-type="" manifest:full-path="Configurations2/accelerator/current.xml" manifest:size="0">
      <manifest:encryption-data manifest:checksum-type="SHA1/1K" manifest:checksum="aIk0hF8iBJyxRmiDLvoz1FATtrk=">
         <manifest:algorithm manifest:algorithm-name="Blowfish CFB" manifest:initialisation-vector="orsvidqQ9SE="/>
         <manifest:key-derivation manifest:key-derivation-name="PBKDF2" manifest:key-size="16" manifest:iteration-count="1024" manifest:salt="+2jAZa9wZ7dO718PJ0ePjw=="/>
         <manifest:start-key-generation manifest:start-key-generation-name="SHA1" manifest:key-size="20"/>
      </manifest:encryption-data>
   </manifest:file-entry>

   <manifest:file-entry manifest:media-type="application/vnd.sun.xml.ui.configuration" manifest:full-path="Configurations2/"/>
   <manifest:file-entry manifest:media-type="text/xml" manifest:full-path="content.xml" manifest:size="173305">
      <manifest:encryption-data manifest:checksum-type="SHA1/1K" manifest:checksum="ek+xCaFx6gN7pdMU+wHrEoy9kGA=">
         <manifest:algorithm manifest:algorithm-name="Blowfish CFB" manifest:initialisation-vector="fYdMUocNotE="/>
         <manifest:key-derivation manifest:key-derivation-name="PBKDF2" manifest:key-size="16" manifest:iteration-count="1024" manifest:salt="qsYb+L7P8jGgJG5+6QX0SQ=="/>
         <manifest:start-key-generation manifest:start-key-generation-name="SHA1" manifest:key-size="20"/>
      </manifest:encryption-data>
   </manifest:file-entry>

   <manifest:file-entry manifest:media-type="image/png" manifest:full-path="Pictures/100000000000032E00000297FAFC88C5.png" manifest:size="160179">
      <manifest:encryption-data manifest:checksum-type="SHA1/1K" manifest:checksum="YYZEhBTxEiS/f70l2vBksE8NhNE=">
         <manifest:algorithm manifest:algorithm-name="Blowfish CFB" manifest:initialisation-vector="OlBGIyOREPQ="/>
         <manifest:key-derivation manifest:key-derivation-name="PBKDF2" manifest:key-size="16" manifest:iteration-count="1024" manifest:salt="uC4WxQrgeDtwg+1okMYfAQ=="/>
         <manifest:start-key-generation manifest:start-key-generation-name="SHA1" manifest:key-size="20"/>
      </manifest:encryption-data>
   </manifest:file-entry>

   <manifest:file-entry manifest:media-type="image/jpeg" manifest:full-path="Pictures/10000000000002580000023ED8BD9987.jpg" manifest:size="72502">
      <manifest:encryption-data manifest:checksum-type="SHA1/1K" manifest:checksum="dOvlwOGTb72BVM9/s9wb87Ivb2w=">
         <manifest:algorithm manifest:algorithm-name="Blowfish CFB" manifest:initialisation-vector="I+Rf4uEZMns="/>
         <manifest:key-derivation manifest:key-derivation-name="PBKDF2" manifest:key-size="16" manifest:iteration-count="1024" manifest:salt="NClHVAj3NaS4cDzNcDHcIw=="/>
         <manifest:start-key-generation manifest:start-key-generation-name="SHA1" manifest:key-size="20"/>
      </manifest:encryption-data>
   </manifest:file-entry>

   <manifest:file-entry manifest:media-type="image/jpeg" manifest:full-path="Pictures/10000000000007D0000003B95A972D22.jpg" manifest:size="370385">
      <manifest:encryption-data manifest:checksum-type="SHA1/1K" manifest:checksum="SpOrml6yPN1XFGsKJuJ0WxHUdME=">
         <manifest:algorithm manifest:algorithm-name="Blowfish CFB" manifest:initialisation-vector="E05xdjYwpzk="/>
         <manifest:key-derivation manifest:key-derivation-name="PBKDF2" manifest:key-size="16" manifest:iteration-count="1024" manifest:salt="trVDJxaiG5m/2LxuHOUnLw=="/>
         <manifest:start-key-generation manifest:start-key-generation-name="SHA1" manifest:key-size="20"/>
      </manifest:encryption-data>
   </manifest:file-entry>


[peegiddy]

I c an open some files I created around the same time at the end of last year. I use the same or simialr meory jogger.
Thanks for your input
I have restored the system to the PC at least once since then. I have the files on a laptop and this has not been retored BUT I have the same issue with the same files.

None of the files were created and saved with a p/w other than open office. However, there a few that had been created with MS powerpoint and then imported intio AOO. Most but not all were modified or created as part completed for testing but some of the images were not up to requirements. They were kept as a lot of hours had been put in on them and then updated / modified to final version(s) However, some of these now also fail to open with a p/word that was or is the same as the file name clarity purposes and testing on other PC's

I tried your suggestion of using notepad to list lots of variations but again no sucess

I dont think it can be a keyboard issue as I have the same problems with my laptop (Win7 AOO 4)

I followed your other sugetion of creatijng a new file with a PW this is all ok and no issues.
I'm not certain what the manifest script is for - I cant see any clue to a PW and with the newly created file I get a simialr result to that you gave

Regarding manifest XLM there are some differences but I knwo there are many more slides with images compared to the new one I created earlier . Again I'm certain what I am looking for in the manifest.xlm All I knwo id that it looks like HTML code that I have very littel knowledge of

[John_Ha]

I'm not certain what the manifest script is for - I cant see any clue to a PW and with the newly created file I get a simialr result to that you gave

The password is not stored anywhere.

manifest.xml tells what encryption is used. I don't know full details, but essentially:

Code: Select all   Expand viewCollapse view

<manifest:algorithm manifest:algorithm-name="Blowfish CFB"

says Blowfish CFB is being used to do the encryption. The other fields give the random variables created by AOO which are hashed with the password to do the encryption so that no two items are encrypted with the identical value.

See OpenOffice Encryption which may or may not be correct.

Edit: I copied this from OASIS OpenDocument v 1.1 standard as it explains exactly how files are encrypted. I cannot upload the complete file here as it is 475kB. 17.3 Encryption The encryption process takes place in the following multiple stages: 1. A 20-byte SHA1 digest of the user entered password is created and passed to the package component. 2. The package component initializes a random number generator with the current time. 3. The random number generator is used to generate a random 8-byte initialization vector and 16-byte salt for each file. 4. This salt is used together with the 20-byte SHA1 digest of the password to derive a unique 128-bit key for each file. The algorithm used to derive the key is PBKDF2 using HMAC-SHA-1 (see [RFC2898]) with an iteration count of 1024. 5. The derived key is used together with the initialization vector to encrypt the file using the Blowfish algorithm in cipher-feedback (CFB) mode. Each file that is encrypted is compressed before being encrypted. To allow the contents of the package file to be verified, it is necessary that encrypted files are flagged as 'STORED' rather than 'DEFLATED'. As entries which are 'STORED' must have their size equal to the compressed size, it is necessary to store the uncompressed size in the manifest. The compressed size is stored in both the local file header and central directory record of the Zip file.

[John_Ha]

See attached password is fred.odp. It has one slide with no background. The slide has title "Title", text "First slide" and a red image. The password to open it is fred Its manifest.xml is below.

Code: Select all   Expand viewCollapse view

<?xml version="1.0" encoding="UTF-8"?>
<manifest:manifest xmlns:manifest="urn:oasis:names:tc:opendocument:xmlns:manifest:1.0" manifest:version="1.2">
<manifest:file-entry manifest:media-type="application/vnd.oasis.opendocument.presentation" manifest:version="1.2" manifest:full-path="/"/>
<manifest:file-entry manifest:media-type="" manifest:full-path="Configurations2/accelerator/current.xml" manifest:size="0">
  <manifest:encryption-data manifest:checksum-type="SHA1/1K" manifest:checksum="aIk0hF8iBJyxRmiDLvoz1FATtrk=">
   <manifest:algorithm manifest:algorithm-name="Blowfish CFB" manifest:initialisation-vector="rivFdd+DNQc="/>
   <manifest:key-derivation manifest:key-derivation-name="PBKDF2" manifest:key-size="16" manifest:iteration-count="1024" manifest:salt="L/Xovm4rarig7SK4QXZCqA=="/>
   <manifest:start-key-generation manifest:start-key-generation-name="SHA1" manifest:key-size="20"/>
  </manifest:encryption-data>
</manifest:file-entry>
<manifest:file-entry manifest:media-type="application/vnd.sun.xml.ui.configuration" manifest:full-path="Configurations2/"/>
<manifest:file-entry manifest:media-type="text/xml" manifest:full-path="content.xml" manifest:size="8438">
  <manifest:encryption-data manifest:checksum-type="SHA1/1K" manifest:checksum="J9/a456I8whuby+mJykNU+bkWNo=">
   <manifest:algorithm manifest:algorithm-name="Blowfish CFB" manifest:initialisation-vector="RGoMB32vl1o="/>
   <manifest:key-derivation manifest:key-derivation-name="PBKDF2" manifest:key-size="16" manifest:iteration-count="1024" manifest:salt="ZniuCrn0Ywl8SWV0+Vfb+A=="/>
   <manifest:start-key-generation manifest:start-key-generation-name="SHA1" manifest:key-size="20"/>
  </manifest:encryption-data>
</manifest:file-entry>
<manifest:file-entry manifest:media-type="image/gif" manifest:full-path="Pictures/10000000000000C8000000C8410EA8A4.gif" manifest:size="1129">
  <manifest:encryption-data manifest:checksum-type="SHA1/1K" manifest:checksum="6O+IB0VbwvzuZb1iaCPTTTvVqBw=">
   <manifest:algorithm manifest:algorithm-name="Blowfish CFB" manifest:initialisation-vector="GY7v4pGZ/kE="/>
   <manifest:key-derivation manifest:key-derivation-name="PBKDF2" manifest:key-size="16" manifest:iteration-count="1024" manifest:salt="rXbXTgBzJQyjaZ4gxNTofg=="/>
   <manifest:start-key-generation manifest:start-key-generation-name="SHA1" manifest:key-size="20"/>
  </manifest:encryption-data>
</manifest:file-entry>
<manifest:file-entry manifest:media-type="text/xml" manifest:full-path="settings.xml" manifest:size="9472">
  <manifest:encryption-data manifest:checksum-type="SHA1/1K" manifest:checksum="ATGFYb/7fd29/O2S20jA9FQUWzE=">
   <manifest:algorithm manifest:algorithm-name="Blowfish CFB" manifest:initialisation-vector="iPHNFCrQS/0="/>
   <manifest:key-derivation manifest:key-derivation-name="PBKDF2" manifest:key-size="16" manifest:iteration-count="1024" manifest:salt="YaOJc6TO8nnuE3HtDS1IUw=="/>
   <manifest:start-key-generation manifest:start-key-generation-name="SHA1" manifest:key-size="20"/>
  </manifest:encryption-data>
</manifest:file-entry>
<manifest:file-entry manifest:media-type="text/xml" manifest:full-path="styles.xml" manifest:size="44857">
  <manifest:encryption-data manifest:checksum-type="SHA1/1K" manifest:checksum="AL+91IV7KvL0ZNc/5gkfbPuYmE4=">
   <manifest:algorithm manifest:algorithm-name="Blowfish CFB" manifest:initialisation-vector="EeuXcehLLtY="/>
   <manifest:key-derivation manifest:key-derivation-name="PBKDF2" manifest:key-size="16" manifest:iteration-count="1024" manifest:salt="co/eLZAf35IaqT6KFb9Rfw=="/>
   <manifest:start-key-generation manifest:start-key-generation-name="SHA1" manifest:key-size="20"/>
  </manifest:encryption-data>
</manifest:file-entry>
<manifest:file-entry manifest:media-type="text/xml" manifest:full-path="meta.xml" manifest:size="1176">
  <manifest:encryption-data manifest:checksum-type="SHA1/1K" manifest:checksum="csv4mPgbGZ1PKdzo8AHNKowzoFE=">
   <manifest:algorithm manifest:algorithm-name="Blowfish CFB" manifest:initialisation-vector="bQ3YcVEpR8I="/>
   <manifest:key-derivation manifest:key-derivation-name="PBKDF2" manifest:key-size="16" manifest:iteration-count="1024" manifest:salt="V6hL5rhqqFwv+hvt6ER78g=="/>
   <manifest:start-key-generation manifest:start-key-generation-name="SHA1" manifest:key-size="20"/>
  </manifest:encryption-data>
</manifest:file-entry>
</manifest:manifest>

The key question is: Examine manifest.xml in a file you cannot open and compare it with manifest.xml in a file you create today.

If they are very similar and the same structure, it implies that the saved file was created with the same software you are using today and the problem is that you have forgotten the password. What date is it - and what "memory jog" were you using at that date?

If it is different, what program was used to save the file?

It is unlikely to be a corrupted file or a typo when entering the password because more than one file is affected.

I therefore think you have forgotten the "memory jog" you were then using so you are entering the wrong password.

Another thought: Have you renamed the files? if so, the "memory jog" won't work.

[peegiddy]

Thanks for your reply
The manifest.xlm files are very similar in structure witrh the exception of "picture" "checksum" etc and of course the size of the test file compared to the longer original file.
I am certain the files were saved with the same s/ware i.e. AOO but it may have been a previous version. Same with OS version of win7 home but with various updates. I have also restored (reinstated) the OS on the system partion of the HDD.
The files were rename as they progressed to the final version but I have long since deleted the older versions once the final was seen to be the version wanted with the correct images and proof read etc had been completed. The p/w was updated when or before the the older file(s) were moved off the HDD to a tempory home on a USB HDD.
I'll have to keep bashing away at making the list of possible p/words to see if this was the problem.
Thanks again
Pete

[peegiddy]

Would altering the date of the file make any difference to the p/word protection ?
Also would altering PC system date have any bearing ?
I ask as the system date and file save date were altered to have them all having same date toe ensure the correct version was used
TIA
Peter

[John_Ha]

Would altering the date of the file make any difference to the p/word protection ?
Also would altering PC system date have any bearing ?
I ask as the system date and file save date were altered to have them all having same date toe ensure the correct version was used
TIA
Peter

No and no.

I think this is basically correct though I don't know the exact difference between the "initialisation-vector" and the "salt".

Edit: It appears that AOO uses both the randomly generated "initialisation-vector" and the "salt" in the encryption of a component

See the manifest.xml example for one component below.

Code: Select all   Expand viewCollapse view

<manifest:file-entry manifest:media-type="" manifest:full-path="Configurations2/accelerator/current.xml" manifest:size="0">
  <manifest:encryption-data manifest:checksum-type="SHA1/1K" manifest:checksum="aIk0hF8iBJyxRmiDLvoz1FATtrk=">
   <manifest:algorithm manifest:algorithm-name="Blowfish CFB" manifest:initialisation-vector="rivFdd+DNQc="/>
   <manifest:key-derivation manifest:key-derivation-name="PBKDF2" manifest:key-size="16" manifest:iteration-count="1024" manifest:salt="L/Xovm4rarig7SK4QXZCqA=="/>
   <manifest:start-key-generation manifest:start-key-generation-name="SHA1" manifest:key-size="20"/>
  </manifest:encryption-data>
</manifest:file-entry>

You enter a password which is, say zebra to encrypt the entire document, where the document has many components (eg four photos and content.xml). Each component is encrypted separately.

When AOO encrypts the first component, it creates a random number based on the current PC time. That random number is stored in manifest.XML as the "initialisation-vector"? "salt"? for that component. The first component (a single image, content.xml etc) is then encrypted by a hashing of zebra and the stored random number for that component.

When AOO encrypts the next component, it creates a new random number (based on the changed time) and this new number is stored in manifest.xml as the "initialisation-vector"? "salt" for that component. AOO hashes zebra and the new number, and uses it to encrypt the next component. Hence, although you use just zebra as your password, every component is encrypted with a different password, which makes cracking much more difficult.

To decrypt a component, AOO reads the password you enter, namely zebra, and reads the random number for that component. AOO hashes zebra and the stored random number and decrypts that component with it.

Hence, once the random number is created and stored, the fact that it was based on time is irrelevant.

Do a simple test to prove it. Create a file with a password. Change the date of creation and the file name. It will still decrypt with the original password you used.

[John_Ha]

OpenOffice Encryption suggests one tiny potential avenue of attack. It says:

The above, which is in section 17.7.4, seems to be about a close as the standard gets to explaining the SHA1/1K password check. SH1A1/1K means that the SHA1 of the first 1024 bytes of the decrypted content.xml (which is deflate compressed data) is compared to the SHA1/1K in META-INF/manifest.xml. It it matches the password was almost certainly correct. This seems ok to me, but there may be some corner cases where it could leak information about the plaintext document. For example, if the attacker is able come up with a close guess for the initial part of the password plaintext document (perhaps the document mostly consist of a known header, or the attacker has an earlier version) he/she may be able to try variations of the document until the SHA1/1K is matched. Either adding random bytes to the start of the plaintext content.xml or encrypting the SHA1/1K with the same blowfish algorithm and key would help.

I don't know enough about it but it is possible that the first 1000 or so characters of content.xml are pretty standard - there is a lot of oasis etc stuff. If AOO does not add a random header in front of this, then you have some plaintext which could help.

I think the situation is:

1. There are multiple files which will not open
2. The files do not seem to be corrupted - unzipping shows them to be well structured
3. Changing the file name and/or date had no effect on the password

Hence you have forgotten the password.

You options are therefore

1. Keep on guessing passwords. This is not as silly as it sounds as you use a memory jog so you drastically reduce the variants.
2. Employ someone with cryptography skills to mount an attack based on the above comment
3. Contract with one of the web sites which says it can crack AOO passwords and sign a non-disclosure agreement with them.

[peegiddy]

Thanks for speedy reply and your help on this
I continue to try to variantions with the notepad trick you previously mentioned. Its going to be tiresome as the p/w were long - about 12 charaters I think

I may have to look into a web service or maybe find a local firm who will crack at least one of the files. If so and the p/w is reaved it may help to job memory to the others

Peter

[John_Ha]

See LastBit which sells a number of password crackers. One is OpenOffice Password, costing 39 Euros, which attacks OpenOdffice passwords. It does not mention .odp as a supported file but just rename the .odp to .odt if necessary - all AOO files are encrypted the same way. For a business €39 is trivial.

OpenOffice Password claims to have a Password Variation mode which may be the best method for you to use as you probably "almost know" the password.

Password Variation

Often the problem with the password is that it was typed incorrectly. The user can make a mistake or type the password with CAPS LOCK turned on. Moreover, the user often remembers the approximate appearance of the password but fails to recall it in detail. In this case we can take the approximate password and test every possible variant, such as case changes (password -> PASSWORD, Password, PAssword, pASSWORD etc), omission of one of the characters, doubling characters, inserting or replacing the character with the neighboring characters and so on. Usually the number of combinations is not very large and it is possible to test them all in a little time.

Let us know if it works.

[Villeroy]

https://sourceforge.net/projects/ooomac ... p/download
is a free Calc document with a macro. It reads one or more password files (plain text, one password per line) and tries to open a given document. This way you can type/copy all your possible passwords first and then let the macro do the rest.
The program is 13 years old. I would test it with some dummy files and well known passwords.

[peegiddy]

Thanks I'll give that a try over thenext few days.

[Sea Mac]

I know of a SURE workaround for "The password is incorrect. The file cannot be opened."
Simply switch to LibreOffice ... that's what I did ... problem solved: the password works again.
This problem has been in the OpenOffice codebase for over a DECADE - affecting ANY password protected file type - and the developers are powerless to find and fix it.
If you don't believe me - search the forum for

The password is incorrect

for yourself, and you'll see most of them conclude "LibreOffice Worked!!!"

[peegiddy]

Thanks for your help and the info on a workaround
I'll give this a try as we almopst gave up

I have tried Libre and that will not open any password protected file(s)

[John_Ha]

This problem has been in the OpenOffice codebase for over a DECADE - affecting ANY password protected file type - and the developers are powerless to find and fix it.

Did you report it as a bug, with an example file which failed with AOO but worked with LO? I searched but could not find any bug report

You didn't? In that case how do you expect it to be fixed? The developers are not mind readers - they rely on users reporting problems. If no problems get reported nothing gets fixed.

Please create a bug report here and include a file which does not open with AOO but does open with LO.

If you cannot be bothered then please at least upload an example file so that I can create a bug report.

Incidentally I assume you are talking about .odt files created by AOO and not .doc. or .docx files created by MS Word.