ADF-Workshop (formerly DMS-Workshop)

[Crashdisk]

Originally Posted by ma693541

Have it been decrypted correct with DMS-Workshop version 2013122.184?

The disk has been correctly identified:
[69025330] Amiga Format #110 (1998-04)(Future Publishing)(GB)(Disk 3 of 3)[May 1998][Subscriber Disk]
So yes, that is correct, there is no reason why it does not work

Originally Posted by mai

nice feature!
Is it possible to enter a known password before, instead of time consuming decryption?

I thought to save passwords after they have been decrypted but these files are so rare that I have not taken the time to incorporate this possibility in the program.

[ma693541]

Wish all decryption programs worked as fast as DMS-Workshop.
When will we see a new updated version of DMS-Workshop for the public?

[Crashdisk]

Originally Posted by ma693541

Wish all decryption programs worked as fast as DMS-Workshop.

it is really slow compared to the number of key tested. I had an idea to drastically reduce the time needed, but we must recognize that there is not much interest to work on this.

Originally Posted by ma693541

When will we see a new updated version of DMS-Workshop for the public?

Since there is no major bug in the program, I await the next release of TOSEC

[ma693541]

Thank's for a very good program. I have ordered a 4TB drive to have my TOSEC collection on.

[Crashdisk]

Originally Posted by mai

I have got a bunch of protected DMS, but DMSW fails, at least it seems so.

I have put examples in the zone.

It seems, that WinUAE is able to handle those DMS.

I wonder, how to bunch converting this obscure DMS files?

I finished working on this issue!

The problem is that the decryption of the first block (Banner) can not be resolved automatically by the fact that several keys are possible. In addition, they give all the right key for the following blocks (the key changes after decryption of each block)

First key : $0323 | Next key : $0060
First key : $052D | Next key : $0060
First key : $052E | Next key : $0060
First key : $05E2 | Next key : $0060
First key : $07F7 | Next key : $0060
First key : $088B | Next key : $0060
First key : $0AA4 | Next key : $0060
First key : $0AA9 | Next key : $0060
First key : $12C7 | Next key : $0060
First key : $12F4 | Next key : $0060
First key : $2AC3 | Next key : $0060
First key : $2AFF | Next key : $0060
First key : $2EE5 | Next key : $0060
First key : $2EEA | Next key : $0060
First key : $3493 | Next key : $0060
First key : $34C2 | Next key : $0060
First key : $36B1 | Next key : $0060
First key : $72A2 | Next key : $0060
First key : $7335 | Next key : $0060
First key : $76A5 | Next key : $0060
First key : $76AA | Next key : $0060
First key : $84C6 | Next key : $0060
First key : $8685 | Next key : $0060
First key : $868A | Next key : $0060
First key : $869D | Next key : $0060
First key : $869E | Next key : $0060
First key : $86B9 | Next key : $0060
First key : $D347 | Next key : $0060
First key : $D546 | Next key : $0060
First key : $E2EF | Next key : $0060
First key : $E662 | Next key : $0060
First key : $E8CB | Next key : $0060
First key : $ECED | Next key : $0060
First key : $ECEE | Next key : $0060
First key : $F1C1 | Next key : $0060
First key : $F5C4 | Next key : $0060
First key : $F5C9 | Next key : $0060
First key : $F7D0 | Next key : $0060

All these keys allows to decompress the ADF, but only the key green is good (banner + ADF) otherwise, with the other key, the banner is corrupt.
In case of doubt on key and for safety reasons, DMS-W refuses to decrypt the file.
So I made a lot of changes for the next version:
- In cases where there is doubt on the key of the first block, but not on the second block, the decoding starts directly from the second block.
- All keys on which DMS-W has no doubt will be memorized
- If a stored key is used, decryption is almost transparent
- If keys have been added during the use of DMS-W then a database is saved for future use when you exit the program

Note : If the first encrypted block is the same for several DMS, the same key will be applied (ref: A00001.DMS, A00004.DMS, ...)

[mai]

Originally Posted by Crashdisk

I finished working on this issue!

The problem is that the decryption of the first block (Banner) can not be resolved automatically by the fact that several keys are possible. In addition, they give all the right key for the following blocks (the key changes after decryption of each block)

All these keys allows to decompress the ADF, but only the key green is good (banner + ADF) otherwise, with the other key, the banner is corrupt.
In case of doubt on key and for safety reasons, DMS-W refuses to decrypt the file.
So I made a lot of changes for the next version:
- In cases where there is doubt on the key of the first block, but not on the second block, the decoding starts directly from the second block.
- All keys on which DMS-W has no doubt will be memorized
- If a stored key is used, decryption is almost transparent
- If keys have been added during the use of DMS-W then a database is saved for future use when you exit the program

Note : If the first encrypted block is the same for several DMS, the same key will be applied (ref: A00001.DMS, A00004.DMS, ...)

Thanks for efforts, a lot of work, i suppose!

I have got while batch converting the message:

Decryption is incomlete

Anyway, DMSW saves file as ADF.
Is this message normal?

[Crashdisk]

03 March 2014

Originally Posted by mai

Thanks for efforts, a lot of work, i suppose!

I have got while batch converting the message:

Anyway, DMSW saves file as ADF.
Is this message normal?

This refers to this note:

Originally Posted by Crashdisk

- In cases where there is doubt on the key of the first block, but not on the second block, the decoding starts directly from the second block

This means that DMS-W has failed to determine the correct key for the first block (probably a banner), but he has found the key to the second block. Thus, the decryption is incomplete but it still allows to decompress the ADF correctly. Do not forget that in this case, DMS-W is not the save key.
Send me the files that are problematic, I find the right key and would incorporate in the next version

------

06 March 2014

A new version of DMS-Workshop is out:

 Version 20140305
 - Fixed a rare problem with crypted DMS files
 - Updated auto-fix DMS databases
 - Updated auto-decrypt DMS databases

 Version 20140302 [Private release]
 - Enhanced support for protected DMS
 - Enhanced ANSI filter for bootblock and startup-sequence
 - Updated auto-fix DMS databases
 - Added specific support for "RattleHead BootPage" bootloader
 - Added auto-decrypt DMS databases

Version 20140220 [Private release]
 - Fixed and enhanced support for bootloaders
 - Updated auto-fix DMS databases
 - Added detection of some "empty" sectors

Version 20140123 [Private release]
 - Fixed some texts (thanks Arnie)
 - Fixed a rare problem with damaged DMS files (thanks mai)
 - Updated auto-fix DMS databases
 - Added support for hacks done with DmsChecker
 - Added support for "Sanity Operating System" (thanks Cybfree)
 - Added preliminary support for noDOS data used by the bootloaders
 - Better management for duplicate filenames

I also updated the TOSEC database. Everything is available beginning this topic:
http://eab.abime.net/showpost.php?p=928711

[mai]

Originally Posted by Crashdisk

I also updated the TOSEC database. Everything is available beginning this topic:
http://eab.abime.net/showpost.php?p=928711

Thanks.

[emufan]

thanks for the updates, both of you

[mai]

I still dont undertand this DMS decrypting in DMSW.
I have a bunch of enncrypted DMS here, with one and the same known password, but every time DMSW starts time consuming decrypting, instead of using known password.
If i set this known password in emulation, it works!
Should i upload another bunch of those protected DMS?

Another small issue related to batch converting decrypted DMS.
It is nearly impossible to abort the batch converting!

[Crashdisk]

Originally Posted by mai

I still dont undertand this DMS decrypting in DMSW.
I have a bunch of enncrypted DMS here, with one and the same known password, but every time DMSW starts time consuming decrypting, instead of using known password.
If i set this known password in emulation, it works!
Should i upload another bunch of those protected DMS?

Another small issue related to batch converting decrypted DMS.
It is nearly impossible to abort the batch converting!

I understand your problem. In your case, you have a lot of files that use the same password but DMSW can not guess... It uses the first encrypted block to determine if the key is already known. Files A00001 and A00004 use the same key and start with the same block :

File selected             : A00001.DMS
File size                 : 385.140 bytes
CRC32                     : $80A9DD2A
File loaded as an DMS     : DMS Archive

  Cyl    Dec Len   RLE Len  Comp Len  C.Mode & Flag  U.SUM  D.CRC  H.CRC  Crypt
------  --------  --------  --------  -------------  -----  -----  -----  -----
Banner       883       655         -  Simple  - - -  $BE3C  $86AB  $A56A    Yes

File selected             : A00004.DMS
File size                 : 555.253 bytes
CRC32                     : $8FA771B5
File loaded as an DMS     : DMS Archive

  Cyl    Dec Len   RLE Len  Comp Len  C.Mode & Flag  U.SUM  D.CRC  H.CRC  Crypt
------  --------  --------  --------  -------------  -----  -----  -----  -----
Banner       883       655         -  Simple  - - -  $BE3C  $86AB  $A56A    Yes

I improved the autonomy of DMSW to determine the correct key (in the last WiP) but I think he will never find all the keys alone, this is the second utility of the database. If you have files that problem, I had previously asked you send them to me, so yes, I'm interested!

In a second step, I will add the possibility to activate a key by default and the ability to interrupt decrypts batch, I have the same problem

PS: Today my database contains more than 550 keys

[mai]

Originally Posted by Crashdisk

If you have files that problem, I had previously asked you send them to me, so yes, I'm interested!

I have uploaded to my FTP another bunch of protected DMS.

[Crashdisk]

Originally Posted by mai

I have uploaded to my FTP another bunch of protected DMS.

Ok, thanks. The first two files were obviously exceptions. The files you put online all require an initial analysis to find the key ... even if it is the same key every time. The solution is to specify a default key to facilitate the work of DMSW. No delay but it should not be too long

Last WiP:
- Use a default key => Done
- Stop the decryption process => Done
I still have to make some adjustment

[mai]

COPY-DISK 10 | 9.740|00000000|OK|OK|KO|1989.07.28 00:44|Sect 2 seq 1 => Data block crushed by a RAW Data |
!BOOT-$00000000.bin | 11.264|8761FD9E|OK|OK|NA|1978.01.01 00:00|Fake file : This hidden data are used by the bootblock

Is this really an error, probably its not?
I have seen this often.

[Crashdisk]

A new version of DMS-Workshop is out:

 Version 20140310
 - Improved method for discovering the decryption key
 - Improved control of the application during decryption
 - Updated auto-decrypt DMS databases with 904 keys
 - Added a menu to set a default decryption key
 - Added option to automatically switch the decryption key
 - Added detection of another "empty" sector

Download link on the first post:
http://eab.abime.net/showpost.php?p=928711

Note: I posted a test file in "The Zone" to check the progress of DMS-Workshop for decryption of DMS file

Originally Posted by mai

 COPY-DISK 10       |   9.740|00000000|OK|OK|KO|1989.07.28 00:44|Sect 2 seq 1 => Data block crushed by a RAW Data
!BOOT-$00000000.bin |  11.264|8761FD9E|OK|OK|NA|1978.01.01 00:00|Fake file : This hidden data are used by the bootblock

Is this really an error, probably its not?
I have seen this often.

"COPY-DISK 10" is probably a custom fake file to protect the raw data used by the bootblock

[mai]

Originally Posted by Crashdisk

A new version of DMS-Workshop is out:

Thanks.

[Crashdisk]

Thank you for your suggestions and encouragement. You tell me if it work properly, I have not tested a lot ...

[mai]

sd03 | 208.498|00000000|OK|OK|KO|1990.11.08 22:07|Sect 230 seq 41 => Data block destroyed >>Lamer Exterminator type A<<

sd03 | 208.498|00000000|OK|OK|KO|1990.11.08 22:07|Sect 1749 seq 260 => Data block filled >>$00 Filled<<

DMSW detects not the $00 filled sectors in the first file, if there is another error before, right?
The first file has the same error at seq 260.

[Crashdisk]

Originally Posted by mai

DMSW detects not the $00 filled sectors in the first file, if there is another error before, right?
The first file has the same error at seq 260.

Yes, DMSW stops parsing a file after the first fatal error detected.

[Crashdisk]

Last news of my WiP version:

I decided to externalize the detection of certain files based on the size and CRC32. So I added a new folder:
.../database_FIL

File - Trojan (2014-03-15).txt

1224;E3EC7D48;Trojan;BBS NoGuru v2.0
2260;E676C69A;Trojan;BBS Mongo Mania (MST-HCTR)
2260;39547C27;Trojan;BBS Mongo Mania (ATX_NADA)
3368;C431760A;Trojan;BBS Mongo Mania (FLT_DSQ)
4764;F1D11B3C;Trojan;BBS ZAPA Adder (DM-Trash)
7636;14463436;Trojan;BBS ZAPA Adder (DM-Trash) [unpacked]
...

The format is very simple and plain text:
Size;CRC32;Type;Name

Anyone can add the files to be detected in the program (but currently limited to executables)
For me, the advantage is that certain file detection can be updated without affecting the program code.