Hello,
Read an article about a protection software package named InTether, this is maybe the "next generation" of our copy protection blah blah...
the article can be found here:
http://www.inside.com/jcs/Story?article_id=25476

Found an evaluation copy version 1.0 (does work on W2000) and protected a txt file with it, there is a few options to apply and one of them is that the file is been erased from your harddrive when the the evaluation time that has been set on the file gets expired.
They are working a lot to get this application none-crackable I think.
Apply this wrapper to a file then dump the "dg32.exe" from memory, do a listing of it and take a good look.
To understand this sort of protection I want to start a small project around this subject, to get some help from the forum.
(of course under the small project area) msg me if it sounds intresting!

ftp://yippee.dataline.net.au/utilities/fileanddiskutilities/intether.exe
I found 2 copies of the file and one of them does not work on w2000, I have the other one too if someone want's it.

meRlin

Wow this is very interesting!
I can see lots of learning with this babe
ill give it a try and share findings with you!
Bye!

Latigo

The actual data protection is very easy.. they didnt even bother to encrypt their code.. "new standard in document protection" my ass

Is there no one intrested in this target except for me and latigo??
Take a look inside one of the *.VXD or *.SYS (don't remember wich one) and you have the most complete list of screencaptures utility in the whole world

meRlin

The entire concept of this thing is worthless..
The data is distributed in 'packages'.. this means that the package must contain the data of the original file.. now what exacly prevents you from ripping the data decryption algo and just read the data from the package, decrypt it and save it to the hdd?

You should start your project anyway, some people could join it as it evolves inside your topic.

Killer_3k, it's not that simple...there is a massive algo that works on the password used (if not used the program uses a defaul one) and goes through like 256 rounds of calculations to generate the 2 decryption seeds, there is pretty much no way to reverse from this angle. The other way I'm thinking to go but didn't have time just yet is to figure out the encryption algo and reverse that to make a decryptor or a password finder. The last way is to make a bruteforcer which I've made that will go through all letters, numbers, special chars and try to find a password but it's not praticle due to the possible number of characters (256) and the number of valid characters in the password. The one major weakness in the encryption is that there are repeating patterns therefore you can guess ALOT of plain text.

meRlin, I'm interested in this project just haven't had the time to work on it lately but will get back to working on it very soon....
e-mail me if you want and we can figure out where we both stand on this.

goatass

goatass: the entire idea of this data protection is not the password.. if you want password protection use pgp :P and as you can see password is OPTINAL.. they put it in there just for the hell for it :P

anyhow the idea of this thing is that you can only run/read a certain doc X ammount of times for X ammount of time etc and after it times out the doc gets deleted and you cant read the doc again.. if i wanted a password protection i would have used pgp :P


if you know the password (assuming password was used) you can easily decrypt the data (took me around 5 min to write a decoder for it).. thus the entire concept of this thing (you-may-only-read-the-doc-x-ammount-of-times) is useless

maybe I'm missing something here, but when I looked at it there was a default password that they used (if the user didn't use one) so yes a password is required to create the encryption seeds. Then there is a big round of calculations on the password that creates the encryption seeds...

From what I can see is that if you didn't enter the correct password (if the user chose to use one) then the bytes that decide how many times you can read the doc will not be decoded and therefore nothing will run.

If it took you 5 minutes to write a decoder could you please e-mail it to me just so I can take a look at it to see maybe I'm looking at this all wrong.

goatass

Another thing I forgot to comment on that you mentioned...you said, "if you know the password it's easy to decrypt" well yeah obviously but that's not the case many time...if I get a hold of a package and have no idea what the password is I want to be able to find it or decrypt the file.....

try decrypting the file WITH OUT knowing the password

goatass

by decoded i mean something that will read the data from the package (assuming that you have a valid password), decrypt it and save it to the hdd..
as for as the password... as i already said, the entire concept of this protection is NOT password protection, if i wanted a password protection scheme i would use pgp.. the entire concept of this protection which is 'you may only read the file x ammount of times' cant be securely implemented..
if you want i can send you the decrypter.. it assumes you didnt use a password so it wont work with password protected packages :~

I know that its probably impossible to decrypt a package without knowing the password but it doesnt really matter as the concept of this thing is NOT the password protection..

if you want i can send you the decrypter but im sure that you can write one urself in around 5minutes or so

You are missing the point here. Yes the idea of this program is to limit you to x number of uses, which when implemented with the default password (if the user didn't enter a password) would be very easy to decrypt the data stored in the package and retore the original file since the default password is known. BUT, if I for example write a paper, package it with a password that I picked and send it to you to read, you will NOT be able to read it not even once, so what the idea behind the password is to implement an extra measure of security because I might want to allow a person to read the document only once but I only want that person to read it and not anyone else, so you see the password is a good idea for the program to increase security.

You are assuming that the package would have no password, but assumption is the mother of all fuckups. If I was to use the program to protect my document I would for sure use a password even if I only let the other person read it once, I don't want anyone else reading it.

so to comment on what you said: "the entire concept of this protection which is 'you may only read the file x ammount of times' cant be securely implemented.." you are incorrect because by having the password you won't be able to even read the document once and you won't be able to decrypt it using your tool since you are assuming the person using the decryptor knows the password and in 99% of the time you won't know the password.

So, Yes the concept of this program is to limit the user to x number of uses but you can add an extra measure of protection against praying eyes by using a password.

You are saying that this protection is lame, but it's not it's pretty good because if I package something with a password you won't be able to read it. Yes PGP is great for encrypting messages but we are not encrypting messages here it's encrypting entire files, like MS Word document, MS PowerPoint file, etc. which you can't encrypt using PGP.

What I want to do is write a program that no matter what password was used to package a document would be able to decrypt the data and restore the original document.

I hope you are following what I'm saying here.

goatass

erm actually you can encrypt any goddamn data file with pgp.. that includes word docs&powerpoint stuff

yes the password thingy does make it impossible to read the document BUT as i already said like 10 times, the idea of this protection is that you may only read the doc X ammount of times.. as a proof to that read works.txt that comes with it.. they clearly state that the entire purpose of this protection is that you can allow people to only read smth you wrote x ammount of times.. they brag about how they block cut&paste operations, screencaptures&printing operations..
kinda like a time-bombed e-book

quote from works.txt:
"if multiple downloads are attempted, InTether automatically detects that the file permissions have been exhausted and disables copying."

basiclly they made a util that allows you to timebomb documents..

I am not arguing about the password scheme strength because im pretty sure you cant break it, but the concept of this thing is not the password, its the timebomb thing.. if the entire idea of this thing was the password then how come its optional and hardly even mentioned in their txts?

Hiya,
I think everyone misses the point here. 8P
Why argue about how good or how bad the protection is? Get together and see if we are bypass the protection about reading x times instead.
Ideas I have (not having seen nor tried the program),
1) Write your own program that will read what's on the screen
2) Have a program that will recover *ANY* files that are deleted
3) Write a program that copies from MEMORY the decrypted file and write it down (thus removing the reading x times protection)

Regards
EB

Eternal Bliss:
Writing a package data decrypter (gived that you have a password/no password was used) is not a problem, it took me about 5 minutes to do it
also you cant recover the deleted files because it does a secure wipe of them but it doesnt really matter, because as long as you have the package you can get the data

My point here is that this whole timebombed documents idea cant be implemented properly, i honestly dont care about the password protection, they might as well use pgp-style encryption on it, my point here that the whole concept of this thing is NOT the password, its the timebomb, thats the part that cannot be implemented securely as everyone can just read the data from the package and decrypt it (assuming no pw was used/you know the pw)..

to goatsass: I think its a waste of time to come after the password protection because even if you manage to break it they'll just change the algo to something stronger (blowfish+md5 comes to mind )..
The whole hype about it is because this thing timebombs documents, its not the password..
and as i already said like 1243 times, thats the part that CANNOT be implemented securely..

Killer_3k, I know that the point is the x number of uses, what I'm trying to make you aware of here is that I don't care what's the purpose of the program what I care about is if I get my hands on a package and it was packed with a password (which will most likey be the case 99% of the times) then what do I do to decrypt it.

You are always assuming that a document was packaged with no password and in that case yes the implementation of the timebomb will be weak but going back to you example of PGP, if you encrypt something with PGP but don't use a password or the password is known then you can say that PGP is useless too because I was able to decrypt the message with ease.

Do you see where I'm getting at ? you have to look at all of the security measures that the program has to offer to the user and not focus on only one of them. Because if I package something with a password then your weak implemented timebomb algo all of the sudden becomes so much more powerfull because you will not be able to decrypt the file at all not even the portion that determines how many times you can view the document.

By the way, using Blowfish wouldn't make the enryption that much more stroger, and again if I know the modulus for the encryption in Blowfish (just like you know the password for this program) I would have no problem decrypting anything.

The encryption algorithm used in this program is pretty good, all the rounds of encryption and table look ups makes it extremely hard to reverse.

Well I tried to make my point as clear as I can and if you still don't see my point it doesn't matter anymore.

goatass

Goatass: Hi
I see your point, but i think you are wasting your time.. IF you manage to break it rest assure that they will change it to something else (TEA/blowfish w/ MD5ed password as the key comes to mind)

Last time i checked the entire point of PGP is the password hardly the same thing as this program..

anyhow good luck attacking that algo =)

by the way, even if you manage to find an attack on cipher algo you will (prolly) still need a plaintext, and since this thing is supposed to encrypt .txts i doubt you will have any plaintext in most cases

Best Regards =)

Killer_3k, I totally agree with you that this algo is a waste of time to figure out....I doubt they will use Blowfish, RSA or whatever because they spent so much time and money on designing this protection they won't just redo everything, but all they need to do is add another XOR or something similar to the algo and any decryptor tool would be defeated just like Alexi does with ASProtect.

BTW, there is planty of plaintext that I can use to make a bruteforcer. There is a section at the end of the file which is the encrypted information of how many uses the person has, whether or not they can copy and paste, etc. If you look at it you will see there is a repeating pattern there and that pattern decrypted is zeros. Also I know that the first DWORD in that section MUST return a 00000001 which they use to check whether the password used (if any) was the correct one...basically check if the decryption keys are the correct ones before trying to decrypt everything. I figured everything out already concering copy&paste, shreding of the file after use, x number of uses, etc. that's very easy (assuming again you know the password or none was used).

Anyways, I haven't seen this program being used anywhere yet so there is really no need to invest much time and effort in reversing the enc/dec algo (which I have figured out but haven't spent the time trying to reverse it).

Well I just got home from a club and I'm dead tired.....l8r

goatass