Jump to content
Tuts 4 You

[keygenme]my Old Keygenme

juexing

By juexing
in KeygenMe

 Share

Recommended Posts

juexing

juexing

Posted
  • Author
Posted

Hehe.....

I have use Delphi Function : Copy() the Name and Modify MD5,RSA1024 Encrypt Protection.

If you can't do it.

I can Release the Number for it.

Hehe......

For Example

name：ddstudio

serial：8fBTU4f17vYc1asJXDB+Y+TU4f17vYc1k5ZIQLPacYd-dfc77558868f0dd3110dea343e1046d0-4331f7ffe305de224a714d359cabe426-v2FCCHwxXhb4TlShLaGJqJCs9LhrUS-DB+Y+TU4Y+TU46d0-4331f7

Link to comment
Share on other sites
Loki

Loki

Posted
Posted

Me thinks someone found a Delphi RSA library and doesn't really understand the concepts for creating a 'crackme' :P

Unless of course the author has a nice method for recovering these keys

Link to comment
Share on other sites
Ox87k

Ox87k

Posted
Posted (edited)

Wtf...

Ok, i need some hint! Loki, can you help a lil bit me?

I recognize all delphi's calls but i've problems with Rsa's parameters...

(damned delphi!)

:blink:

Edited by Ox87k
Link to comment
Share on other sites
Loki

Loki

Posted
Posted

Hey Ox87k - my above response was directed at the crackme author, not at you. It seems he's found some library and just created any old RSA keygenme without giving thought as to whether it would actually be possible to factorise.

Unless he can assure us that there is a way to do this without trying to factorise the 1024 bit key, then I think this is a waste of time.

Link to comment
Share on other sites
Ox87k

Ox87k

Posted
Posted

Ok but which is N??

We can patch N with another one :)

I don't understand very well the first part when it calculates the prime numbers

and then make some Mul, Gcd and ModInv operations.

:sick:

Link to comment
Share on other sites
Loki

Loki

Posted
Posted

Must admit I didn't look that closely - I just assumed that the author was having a laugh and looked at something else.

If he confirms its solvable then I'll take another look. :)

Link to comment
Share on other sites
juexing

juexing

Posted
  • Author
Posted

Ox87k, :cool: I have Download the ICU Team Release Some XM's music.

It's very cool.

I love it.

And have one of Music name is DFCG.KEY :biggrin: I very very like.Hehe......

DFCG Means:Decryption Fans Cracking Group. :kiss:

Link to comment
Share on other sites
juexing

juexing

Posted
  • Author
Posted (edited)
Excellent, that clears all our questions up :confused:

First,I'm sorry my English is poor.I'm a Chinese.

Ha-ha, I am also to discover the procedure that this writes previously's when turning my computer over in the evening just now. :mellow: I have not also been to much play having broken a solution now , I am one occupation programmer, ha-ha now, friend that organization and ICU joining DFCG organization , :sweat: being glad to be able to know your SND very much organize when I study in university before being very early. :laugh:

Edited by juexing
Link to comment
Share on other sites
HVC

HVC

Posted
Posted (edited)

This is hardly rocket science.

The modulus (N) is calculated by two prime numbers at runtime (and it's 426 bits, not 1024).

Even if you didn't have the two prime numbers, the modulus is attackable due to huge difference in the size of the used primes - it takes only a fraction of a second to factor it, using Pollard's method.

Anyway, even if we had a 2048 bits modulus, factoring is not needed, cause the author uses modular arithmetics rather than RSA. :^

[Part_of_the_Key = Name ^ 10001h mod N. (this part of the serial is encoded in b64 - FGInt style... )]

The rest of the key involves iteration of some data (some function's opcodes [which i don't really know if it was an intention of the coder...] + name + some hard-coded data) through a modified MD5 function (actualy only initialization values are modified).

From there on, one has to correctly format the key, and display it.

So in conclusion, yeah. This beast is solvable. :rudolph:

And besides... anything that echoes a valid key in memory can simply be ripped... :giveup:

Edited by HVC
Link to comment
Share on other sites
Ox87k

Ox87k

Posted
Posted (edited)

Well, HVC i understand this algo, it's quite simple but...

when i found the two primes numbers (p and q) and i used them

to make the modulus N, Rsa Tool told me that it wasn't a 1024 modulus,

as the author wrote here.

This is the reason i wrote my previous post where i said

that i'm confused about N.

If you read, i wrote:

"Ok but which is N??"

The author of keygenme said RSA1024, my modulus wasn't a 1024 bit

modulus but less -> then -> Confused!!

Btw, HVC is right, just a basic RSA Encrypt and two modified md5.

After that the crackme plays with many LStrCat and LStrCopy until

it got the final serial.

In other words, we don't need to factorize, just get P and Q, multiply them in order

to make own N (or get it directly from crackme) and encrypt own name with it.

WTF, my english really sucks! (sorry!)

Edited by Ox87k
Link to comment
Share on other sites
Ox87k

Ox87k

Posted
Posted (edited)
Hehe, maybe in Chinese "1024" actually means "426". :brow:

Ahahahahahah! :biggrin:

You rock man! :cool:

Btw,

if i'm not wrong, the modulus N should be this:

"59939659CE42B715D00A443F5C75E50DD6A5

3361286FB67F22C6691BF19EF478BEB5CF01A9

841B7C171AE81E2C998645D0D0761923D41B"

HVC, can you confirm that?

Edited by Ox87k
Link to comment
Share on other sites
juexing

juexing

Posted
  • Author
Posted
Hehe, maybe in Chinese "1024" actually means "426". :brow:

Hey, this written too long, I have forgotten their own is 426 or 1024, for a long time no see, and clean up disk at the time found on the line for everyone to see upload just ~

PS: It is not China's 426 is 1024, the international community this is the same. You

Link to comment
Share on other sites
juexing

juexing

Posted
  • Author
Posted
@juexing, don't be angry, HVC is just kidding! :)

Ha-ha, since former university graduates for 2 years, the broken solution is only my one kind of hobby to me. I am a programmer now , will be broken once in a while getting rid of a few solving a forum strolling around, that is one kind after all once recall that , find it hard to give up. :cool:

Link to comment
Share on other sites
HVC

HVC

Posted
Posted

@Ox87k

75BCD1775BCD17 * 6162636465666768696A6B6C6D4E4F505152535455565758595A21402324255E262A28295F2B2D3D

7C5C3C3E3F223A3B7B9D =

2CC9CB59CE42B72BA01488FD71D7946EB5299E1286FB6FE458CD26FC67BD3C5F5AE781A9841BF82E

35D078B2661A2E8683B1923D41B

@juexing

:D

Link to comment
Share on other sites
Ox87k

Ox87k

Posted
Posted (edited)
@Ox87k

75BCD1775BCD17 * 6162636465666768696A6B6C6D4E4F505152535455565758595A21402324255E262A28295F2B2D3D

7C5C3C3E3F223A3B7B9D =

2CC9CB59CE42B72BA01488FD71D7946EB5299E1286FB6FE458CD26FC67BD3C5F5AE781A9841BF82E

35D078B2661A2E8683B1923D41B

:blink:

0048D888 >|>LEA EDX,DWORD PTR SS:[EBP-34]		  ;  loc_48D888
0048D88B  |.  MOV EAX,<KeyGenme.a0123456789>		 ;  ASCII "0123456789"
0048D890  |.  CALL <KeyGenme.Base10StringToFGInt>	;  Convert 123456789d to 0x75BCD15 BigNum
0048D895  |.  LEA EAX,DWORD PTR SS:[EBP-34]		  ;  push that BigNum
0048D898  |.  CALL <KeyGenme.PrimeSearch>			;  prime number after -> 0x75BCD17 (123456791)
0048D89D  |.  LEA EDX,DWORD PTR SS:[EBP-3C]		 ; push and empty space for a new bignum
0048D8A0  |.  MOV EAX,<KeyGenme.aAbcdefghijklmn>	 ;  ASCII "abcdefghijklmNOPQRSTUVWXYZ!@#$%^&*()_+-=|\<>?":;{}"
0048D8A5  |.  CALL <KeyGenme.@Base256StringToFGInt> ; convert the string into bignum
0048D8AA  |.  LEA EAX,DWORD PTR SS:[EBP-3C]		; push that bignum
0048D8AD  |.  CALL <KeyGenme.PrimeSearch>			; and search the first prime number after
0048D8B2  |.  LEA ECX,DWORD PTR SS:[EBP-C]		;  empty space for N
0048D8B5  |.  LEA EDX,DWORD PTR SS:[EBP-3C]		  ;  rSecond prime number generated
0048D8B8  |.  LEA EAX,DWORD PTR SS:[EBP-34]		  ;  First prime number generated
0048D8BB  |.  CALL <KeyGenme.FGIntMul>			;  generate N

First Bignum = 0x75BCD17

Second Bignum = 0x6162636465666768696A6B6C6D4E4F505152535455565758595A21402324255E262A28295F2B2D

3D

7C5C3C3E3F223A3B7B9D

FGIntMul = 0x59939659CE42B715D00A443F5C75E50DD6A5

3361286FB67F22C6691BF19EF478BEB5CF01A9

841B7C171AE81E2C998645D0D0761923D41B

After that we have another FGIntMul and some FGModInv.

Btw the main call is RSAEncrypt and we have:

0048D9FB  |.  LEA EAX,DWORD PTR SS:[EBP-70]; eax points to own name
0048D9FE  |.  PUSH EAX					;  name stored in the stack
0048D9FF  |.  LEA ECX,DWORD PTR SS:[EBP-C]	;  ecx points to modulus N (0x599396...etc...)
0048DA02  |.  LEA EDX,DWORD PTR SS:[EBP-14]	;  0x10001
0048DA05  |.  MOV EAX,DWORD PTR SS:[EBP-70];  eax points to own name
0048DA08  |.  CALL <KeyGenme.@RSAEncrypt>

So HVC, where you find that

75BCD1775BCD17 * 6162636465666768696A6B6C6D4E4F505152535455565758595A21402324255E262A28295F2B2D3D

7C5C3C3E3F223A3B7B9D =

2CC9CB59CE42B72BA01488FD71D7946EB5299E1286FB6FE458CD26FC67BD3C5F5AE781A9841BF82E

35D078B2661A2E8683B1923D41B

?

Edited by Ox87k
Link to comment
Share on other sites
HVC

HVC

Posted
Posted (edited)

Well, i admit i made i mistake at pasting the first prime (damn sh1tty notes :rolleyes: )...

There you go:

1st Prime (P): 75BCD17
2nd Prime (Q): 6162636465666768696A6B6C6D4E4F505152535455565758595A21402324255E262A28295F2B2D3D
7C5C3C3E3F223A3B7B9D

But, the mistake is irrelevant, cause i put the modulus right... :hitler:

P*Q = 2CC9CB59CE42B72BA01488FD71D7946EB5299E1286FB6FE458CD26FC67BD3C5F5AE781A9841BF82E
35D078B2661A2E8683B1923D41B

How P*Q = 59939659CE42B715D00A443F5C75E50DD6A53361286FB67F22C6691BF19EF478BEB5CF01A9841B7C

171AE81E2C998645D0D0761923D41B ??? :g:

Besides, that number is not even a product of two primes...

Did you directly ripped the GInt from memory??? Well, it doesn't appear to be a raw bignum, but it seems to be in some proprietary form.

To verify it, just replace the string "abcdefghijklmNOPQRSTUVWXYZ!@#$%^&*()_+-=|\<>?":;{}" with raw bytes {01,02,03.....} and take a look at the resulting GInt.

( This could also mean that FGint was modified for this keygenme, but i checked that with other programs that use FGInt, and the format looks consistent in all... :osama: ).

After that we have another FGIntMul and some FGModInv.

Yeah, after that, the private exponent is calculated... but is not used...

Do you have Delphi installed? I don't.

If you do have it installed, just make a program that initializes a GInt to the modulus i gave you, this thing about the GInt internal format is worth a little more insight...

Regards

Edited by HVC
Link to comment
Share on other sites
Ox87k

Ox87k

Posted
Posted

Yeah, you right and owned another time me! :)

But...

P and Q are right, i copied my modulus N directly from memory and exactly when the keygenme calls the RSAEncrypt function. Such call has as parameters the message to encode, the Public Exponent and the Modulus.

I haven't delphi, i don't know delphi and moreover never used delphi in all of my life!

Are you sure the FGInt library was modified? I don't think..

I can try to make a rsa encrypt message with C and miracl and compare it with the result of RSAEncrypt function used in the keygenme.

Maybe it works!

Cheers HVC :)

Link to comment
Share on other sites
HVC

HVC

Posted
Posted (edited)

Man, i'm unable to own anyone... :P

More over, i haven't said that the FGInt library was modified - i said that its bignum implementation, seems not to store bignums as raw bytes, but in some other format. So if you rip the bignum from memory, you have to apply some sort of transformation on it to get the *real* number.

What i'm trying to say is that if someone would upload a delphi compiled executable that initializes a GInt with the number 123456789ABCDE, and you dumped the GInt from memory, you wouldn't get a hexdump containing the bytes 123456789ABCDE, but a dump containing different bytes - FGint seems to use an internal format to store bignums.

Needless to say anything about the base-64 conversion of FGInt... :giveup:

Edited by HVC
Link to comment
Share on other sites
Ox87k

Ox87k

Posted
Posted (edited)

Ops, sorry for this misunderstanding!

To verify it, just replace the string "abcdefghijklmNOPQRSTUVWXYZ!@#$%^&*()_+-=|\<>?":;{}" with raw bytes {01,02,03.....} and take a look at the resulting GInt.

( This could also mean that FGint was modified for this keygenme, but i checked that with other programs that use FGInt, and the format looks consistent in all... ).

Ok, i done it and i saw that the Bignum init is a lil bit strange as you said.

****ing delphi and ****ing FGInt!

Example:

Q dumped from memory:

0D 00 00 00 00 00 00 00 9D 7B 3B 3A 00 00 00 00 
44 7E 7C 78 00 00 00 00 70 F1 F5 34 00 00 00 00
59 F9 4A 41 00 00 00 00 A2 62 E2 55 00 00 00 00
84 64 04 28 00 00 00 00 88 56 16 56 00 00 00 00
2B AB 2A 2A 00 00 00 00 53 52 51 50 00 00 00 00
9E 9C DA 58 00 00 00 00 AD A9 A5 21 00 00 00 00
3B 33 2B 23 00 00 00 00 36 26 16 06

Last dword: 36 26 16 06 -> bswap -> 6162636 OK (own Q begin in this way!)

Q = 6162636465666768696A6B6C6D4E4F505152535455565758595A21402324255E262A28295F2B2D3D

7C5C3C3E3F223A3B7B9D

Next to the last dword: 3B 33 2B 23 -> bswap and multiplied by 2 -> 23*2 2B*2 33*2 3B*2 -> (...)46566676(...)

Q = 6162636465666768696A6B6C6D4E4F505152535455565758595A21402324255E262A28295F2B2D3D

7C5C3C3E3F223A3B7B9D

First dword: 9D 7B 3B 3A -> bswap -> 3A3B7B9D (own Q finish in this way!)

Q = 6162636465666768696A6B6C6D4E4F505152535455565758595A21402324255E262A28295F2B2D3D

7C5C3C3E3F223A3B7B9D

Second dword: 44 7E 7C 78 -> bswap and divided by 2 -> 78/2 7C/2 7E/2 44/2 -> (...)3C3E3F22(...)

Q = 6162636465666768696A6B6C6D4E4F505152535455565758595A21402324255E262A28295F2B2D3D

7C5C3C3E3F223A3B7B9D

Strange, don't you think?

Unfortunatelly it's valid only for these dwords, try the third..

WTF FGInt!

:)

Edited by Ox87k
Link to comment
Share on other sites
HVC

HVC

Posted
Posted (edited)

Well,

75BCD17 is small enough to fit in the first "slot" of the GInt ( you get what "Slot" is, eh?).

The first slot holds the last 32 bits of the GInt, and it seems to be in all cases equal to the actual 32 bits of the bignum stored.

But... The problems start after the second "slot", which should logically store the next 32-bits of the bignum.

The values held there, differ from the actual number stored in the GInt...

Its, the second prime i can't understand how you ripped...

Here is the dump of the second GInt after the call to NextPrime...

0D 00 00 00 00 00 00 00 9D 7B 3B 3A 00 00 00 00 44 7E 7C 78 00 00 00 00 70 F1 F5 34 00 00 00 00

59 F9 4A 41 00 00 00 00 A2 62 E2 55 00 00 00 00 84 64 04 28 00 00 00 00 88 56 16 56 00 00 00 00

2B AB 2A 2A 00 00 00 00 53 52 51 50 00 00 00 00 9E 9C DA 58 00 00 00 00 AD A9 A5 21 00 00 00 00

3B 33 2B 23 00 00 00 00 36 26 16 06 00 00 00 00 0C 36 49 00

The actual number held in the GInt:

6162636465666768696A6B6C6D4E4F505152535455565758595A21402324255E262A28295F2B2D3D
7C5C3C3E3F223A3B7B9D

I have highlighted the first "slot", that represents the contents of the last 32 bits of the actual number (in little endian).

Now, can you see any other slots making a direct analogy to the actual number stored in the GInt?

How did you dumped the second prime from memory?

I just calculated the next prime after the number that was initialized in the GInt... :P

Off the record, i have seen a quite skilled cracker making a claim that GInt produces wrong results, but this is not the case.

Maybe it has something to do with what we are discussing now...

EDIT: Oh, i see you got my point and expanded it... :flowers:

Now, lets make Ziggy to add to the Ollydbg data-ripper plugin an option to rip GInts. :^

Then, make it public. :1:

Edited by HVC
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share
Go to topic listing
×
×
  • Create New...