View Full Version : Pencil and paper decryption ?

August 17th, 2002, 06:43
My target is a java prog whose classes are zipped and crypted.
I attached a fragment of the crypted file and the same decrypted (by the prog itself at runtime). So we have plain and crypted text.
The decrypted file is 597776 bytes long and the crypted one is 597777.

I will modify a class, recompile it, rezipp it, and I will have to crypt it back, so I need to guess the algoritm.

If you compare both fragments you can see that all zeroes of the plain text are just xored with their position in the file plus 7.

But with the other bytes it seems a bit more complicated.

TIA for informations.

Sorry, I forgot to attach the files. I will do it in next message.

August 17th, 2002, 06:48
Here comes the attached file.



I can't understand why the attached file has been deleted, but I absolutely refuse to discuss it in order to avoid such boring serie of messages as in "JBuilder and DSA" thread about the threat of lawyers etc...

If someone wants to compare plain and crypted text, he may want to run the prog (Photopulse, whose only interest for me is the protection). The crypted file is photopulse.jar and at runtime the prog decrypts it in c:\temp. Save the 584Kb file before quitting the prog.
That simple...


August 17th, 2002, 12:49
>I can't understand why the attached file has been deleted, but I >absolutely refuse to discuss it in order to avoid such boring >serie of messages as in "JBuilder and DSA" thread about the >threat of lawyers etc...

>If someone wants to compare plain and crypted text, he may >want to run the prog (Photopulse, whose only interest for me is >the protection). The crypted file is photopulse.jar and at runtime >the prog decrypts it in c:\temp. Save the 584Kb file before >quitting the prog.
>That simple...

If thats simple?copy and paste the file in here.Why bothered to upload? Me thinks only only plain source code is allowed to upload here no utilities,exe,patched is allowed.


August 17th, 2002, 13:44
Hi, cluesurf.
Here is a fragment of plaintext :
00000000 504B 0304 0A00 0000 0000 6192 A82C 0000
00000010 0000 0000 0000 0000 0000 0900 0000 4D45
00000020 5441 2D49 4E46 2F50 4B03 040A 0000 0000
00000030 0061 92A8 2CD5 D202 09E3 0000 00E3 0000
00000040 0014 0000 004D 4554 412D 494E 462F 4D41
00000050 4E49 4645 5354 2E4D 464D 616E 6966 6573
00000060 742D 5665 7273 696F 6E3A 2031 2E30 0D0A
00000070 4372 6561 7465 642D 4279 3A20 416E 7420
00000080 312E 342E 310D 0A49 6D70 6C65 6D65 6E74
00000090 6174 696F 6E2D 5665 6E64 6F72 3A20 5068
000000A0 6F74 6963 6120 496E 632E 0D0A 436C 6173
000000B0 732D 5061 7468 3A20 6A67 656E 2E6A 6172
000000C0 2073 6178 7061 7468 2E6A 6172 206A 6178
000000D0 656E 2D63 6F72 652E 6A61 7220 6A61 7865
000000E0 6E2D 646F 6D2E 6A61 7220 6C6F 6734 6A2E
000000F0 6A61 0D0A 2072 0D0A 496D 706C 656D 656E
00000100 7461 7469 6F6E 2D56 6572 7369 6F6E 3A20
00000110 7631 2D30 2D31 0D0A 496D 706C 656D 656E
00000120 7461 7469 6F6E 2D54 6974 6C65 3A20 5068
00000130 6F74 6F50 756C 7365 0D0A 0D0A 504B 0304
00000140 0A00 0000 0000 6092 A82C 0000 0000 0000
00000150 0000 0000 0000 0400 0000 636F 6D2F 504B
00000160 0304 0A00 0000 0000 6092 A82C 0000 0000

Here is the encrypted version :
00000000 7A57 430A 0E01 0C0D 0E0F 1070 80BB 3815
00000010 1617 1819 1A1B 1C1D 1E1F 2028 2223 2468
00000020 6373 6904 6365 6A02 7E64 3335 3833 3435
00000030 3637 59AB 9217 E9EF 3C36 A341 4243 A745
00000040 4647 5C49 4A4B 0108 1A0E 7D18 1C15 7B18
00000050 1719 111F 1F08 0873 1319 2D00 0C0A 0200
00000060 1513 453F 0F19 1F04 0101 4A51 435D 4478
00000070 7C34 0A1C 1B0F 1919 533D F9BB A2C2 EAF1
00000080 A6B6 A6BD A4BA 8187 C7E2 E0FD F7FE F1FB
00000090 E2F6 ECF0 F5F5 B1CB FBF1 C4CE D099 84F5
000000A0 CEC8 DCC0 C9CA 8CE4 C0CC 9EBC B8F0 D8D4
000000B0 C5C4 95E9 DBCF D487 9ED5 A7A4 ACED AEA4
000000C0 B4E7 BBA8 B2BB ADB9 A6E1 BAB0 A0F3 BEB4
000000D0 AEB2 B6F4 B9B4 AEB8 F0B5 8193 C289 859D
000000E0 8389 C58D 8586 C287 8F9D D09D 9D94 C09F
000000F0 D89D 99F4 F0DB 8EF0 F4B6 6D71 6E66 6960
00000100 6873 697D 6364 6220 586A 6262 7B7C 7A2F
00000110 3661 2934 2A36 2D10 1456 4D51 4E46 4940
00000120 4853 495D 4344 4200 7A46 445D 5709 1465
00000130 5E58 4C56 6A4E 504E 5B32 4A4C 4813 0F46
00000140 424D 4849 4A4B 4C2D DCE7 7C51 5253 5455
00000150 5657 5859 5A5B 5C59 5E5F 6002 0D0E 4B35
00000160 2D64 6C63 6A6B 6C6D 6E0F E2D9 5E73 7475


Notes :
First byte of encrypted version (0x7a) is surely relevant, but it is not an encrypted byte of the plain text.
First encrypted byte is at offset : 00000001 (0x57) and encrypts the plain text byte which is at offset 00000000 (0x50).

As I wrote in first message, 0x00 ---> 0x00 + 7 + position.

I am working on byte 0x0a and listing the encrypted values according to position, and trying to guess the algorithm.


August 17th, 2002, 14:01
Excuse me but isn't is a bit stupid to guess the algorithm when you have the target which does the decryption itself?

You wrote yourself that the program decrypts it at runtime. So naturally it must hold the algorithm as a parts of it's code. Why not look for that instead of guessing? For all I know it could be OTP (study some book if you're in doubt what it is).

Somehow this reminds me the newbies in programming who wrote a program that failes in one way or another and then instead of using a debugger to find out where the program fails they are trying to guess it by reviewing the source code.

// CyberHeg

August 17th, 2002, 15:13
hi, cyberheg, and thanks for your comments.

As you asked gently for it, I excuse you.

As you didn't suppose, I tried to find the decoding routine somewhere in the prog, but didn't succeed (it is a short .exe and a lot of java classes, some in the two crypted packages and some in clear packages, but very numerous and I didn't choose to decompile them all, eventhough I have the tools).

BTW, don't tell me that the decrypting routine can't be in the crypted packages, because I already guessed that.

I run the short .exe in Softice,
decoding is at :004016b1 call 401190
and I got lost (it seems that it calls the java virtual machine).

With paper and pencil I'm working on encryption of 0x0a and 0x65.
It can be OTP, but :
-the first suite of zeroes giving 0x0c, 0x0d, 0x0e, 0x0f and 0x10
-the second suite giving 0x15, 0x16, 0x17...0x20
-0x0a coded as 0x0a+3+position
make me feel that there is an algorithm.


August 18th, 2002, 00:43
Look harder. Look harder. Look harder. Java encryption techniques are lame just a couple of xor and what not I am guessing based on what I have seen. There is a damn java decompiler you have your work cut out for you. This is a cakewalk. Dont try to figure it out by comparing thats bad technologies. Reverse better.


August 18th, 2002, 04:20
Who deleted it? I didn't, and I don't know why it should have been. It's not a serial number or a cracked program. I might not check the forum every couple of hours, but I usually check every day and read all the new posts. I read them yesterday and today. (This thread pooped up fast).

If you disagree with something that has been posted, there's a link on evey post that says "Report this thread to a moderator." Please don't go around deleting stuff without telling me.

By the way, you can use something like grep to search through the jad files for xor or names like "encrypt".

August 18th, 2002, 06:21
To Mike :
OK, Mike. No problem.

To Snatch :
I will look harder, but I didn't make the choice yet of decompiling all those classes.
I thought I would not have to command : jad *.class


August 18th, 2002, 09:33
Hi, all fellows.

No need to encrypt back the .jar file after rewriting and recompiling ! No need to guess the encryption algoritm !

I tried the following manoeuver :
I replaced the encrypted .jar files with the decrypted ones. I thought that the prog would crash, because, at runtime, it will decrypt not the files it expected but the already decrypted ones.
It didn't crash ! The decryption of the decrypted files doesn't change the bytes, i.e. gives the decrypted files !

The cause may be the presence of that supplementary first byte (0x7a) in the encrypted file. Without it (i.e with the decrypted file) there is no transformation of the following bytes.

It is now possible to rub out the RSA protection, and rezip the classes.
Fellow Gordon Freeman are you there ?


August 29th, 2002, 20:13
Hi Artifex:

The encryption Algo is waht you said and only what you said:

Cypherbyte = plaintextbyte XOR (position + 7)

Look at it in binary and you will see the light.
Attached you will find an Excel Worksheet with the details.

August 31st, 2002, 07:28
Hi, naides, and many thanks for the information.
I didn't guess it myself because I made a sum instead of an XOR.

Naides, eres alguien !