juexing Posted March 9, 2008 Posted March 9, 2008 (edited) Hehe.....My Old KeyGenMe,It's my first KeyGenme, :cool:keygenmes1.rar :cool: Edited March 9, 2008 by juexing
juexing Posted March 11, 2008 Author Posted March 11, 2008 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 Examplename:ddstudioserial:8fBTU4f17vYc1asJXDB+Y+TU4f17vYc1k5ZIQLPacYd-dfc77558868f0dd3110dea343e1046d0-4331f7ffe305de224a714d359cabe426-v2FCCHwxXhb4TlShLaGJqJCs9LhrUS-DB+Y+TU4Y+TU46d0-4331f7
Ox87k Posted March 12, 2008 Posted March 12, 2008 RSA1024? Are you kidding me?! Can i have N and D please? How it can be possible to factorize RSA1024?!
Loki Posted March 12, 2008 Posted March 12, 2008 Me thinks someone found a Delphi RSA library and doesn't really understand the concepts for creating a 'crackme' Unless of course the author has a nice method for recovering these keys
Ox87k Posted March 12, 2008 Posted March 12, 2008 (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!) Edited March 12, 2008 by Ox87k
Loki Posted March 12, 2008 Posted March 12, 2008 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.
Ox87k Posted March 12, 2008 Posted March 12, 2008 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.
Loki Posted March 12, 2008 Posted March 12, 2008 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.
juexing Posted March 12, 2008 Author Posted March 12, 2008 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.
juexing Posted March 12, 2008 Author Posted March 12, 2008 (edited) Excellent, that clears all our questions up 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. 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 , being glad to be able to know your SND very much organize when I study in university before being very early. :laugh: Edited March 12, 2008 by juexing
HVC Posted March 12, 2008 Posted March 12, 2008 (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. And besides... anything that echoes a valid key in memory can simply be ripped... Edited March 12, 2008 by HVC
Ox87k Posted March 13, 2008 Posted March 13, 2008 (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 themto 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 saidthat 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 bitmodulus 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 untilit got the final serial.In other words, we don't need to factorize, just get P and Q, multiply them in orderto make own N (or get it directly from crackme) and encrypt own name with it.WTF, my english really sucks! (sorry!) Edited March 13, 2008 by Ox87k
HVC Posted March 13, 2008 Posted March 13, 2008 (edited) Hehe, maybe in Chinese "1024" actually means "426". Edited March 13, 2008 by HVC
Ox87k Posted March 13, 2008 Posted March 13, 2008 (edited) Hehe, maybe in Chinese "1024" actually means "426". 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 March 13, 2008 by Ox87k
juexing Posted March 13, 2008 Author Posted March 13, 2008 Hehe, maybe in Chinese "1024" actually means "426". 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
juexing Posted March 13, 2008 Author Posted March 13, 2008 @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:
HVC Posted March 13, 2008 Posted March 13, 2008 @Ox87k 75BCD1775BCD17 * 6162636465666768696A6B6C6D4E4F505152535455565758595A21402324255E262A28295F2B2D3D 7C5C3C3E3F223A3B7B9D = 2CC9CB59CE42B72BA01488FD71D7946EB5299E1286FB6FE458CD26FC67BD3C5F5AE781A9841BF82E 35D078B2661A2E8683B1923D41B @juexing
Ox87k Posted March 13, 2008 Posted March 13, 2008 (edited) @Ox87k75BCD1775BCD17 * 6162636465666768696A6B6C6D4E4F505152535455565758595A21402324255E262A28295F2B2D3D 7C5C3C3E3F223A3B7B9D = 2CC9CB59CE42B72BA01488FD71D7946EB5299E1286FB6FE458CD26FC67BD3C5F5AE781A9841BF82E 35D078B2661A2E8683B1923D41B 0048D888 >|>LEA EDX,DWORD PTR SS:[EBP-34] ; loc_48D8880048D88B |. MOV EAX,<KeyGenme.a0123456789> ; ASCII "0123456789"0048D890 |. CALL <KeyGenme.Base10StringToFGInt> ; Convert 123456789d to 0x75BCD15 BigNum0048D895 |. LEA EAX,DWORD PTR SS:[EBP-34] ; push that BigNum0048D898 |. CALL <KeyGenme.PrimeSearch> ; prime number after -> 0x75BCD17 (123456791)0048D89D |. LEA EDX,DWORD PTR SS:[EBP-3C] ; push and empty space for a new bignum0048D8A0 |. MOV EAX,<KeyGenme.aAbcdefghijklmn> ; ASCII "abcdefghijklmNOPQRSTUVWXYZ!@#$%^&*()_+-=|\<>?":;{}"0048D8A5 |. CALL <KeyGenme.@Base256StringToFGInt> ; convert the string into bignum0048D8AA |. LEA EAX,DWORD PTR SS:[EBP-3C] ; push that bignum0048D8AD |. CALL <KeyGenme.PrimeSearch> ; and search the first prime number after0048D8B2 |. LEA ECX,DWORD PTR SS:[EBP-C] ; empty space for N0048D8B5 |. LEA EDX,DWORD PTR SS:[EBP-3C] ; rSecond prime number generated0048D8B8 |. LEA EAX,DWORD PTR SS:[EBP-34] ; First prime number generated0048D8BB |. 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 name0048D9FE |. PUSH EAX ; name stored in the stack0048D9FF |. LEA ECX,DWORD PTR SS:[EBP-C] ; ecx points to modulus N (0x599396...etc...)0048DA02 |. LEA EDX,DWORD PTR SS:[EBP-14] ; 0x100010048DA05 |. MOV EAX,DWORD PTR SS:[EBP-70]; eax points to own name0048DA08 |. CALL <KeyGenme.@RSAEncrypt> So HVC, where you find that 75BCD1775BCD17 * 6162636465666768696A6B6C6D4E4F505152535455565758595A21402324255E262A28295F2B2D3D7C5C3C3E3F223A3B7B9D = 2CC9CB59CE42B72BA01488FD71D7946EB5299E1286FB6FE458CD26FC67BD3C5F5AE781A9841BF82E 35D078B2661A2E8683B1923D41B ? Edited March 13, 2008 by Ox87k
HVC Posted March 13, 2008 Posted March 13, 2008 (edited) Well, i admit i made i mistake at pasting the first prime (damn sh1tty notes )... There you go: 1st Prime (P): 75BCD172nd Prime (Q): 6162636465666768696A6B6C6D4E4F505152535455565758595A21402324255E262A28295F2B2D3D7C5C3C3E3F223A3B7B9D But, the mistake is irrelevant, cause i put the modulus right... P*Q = 2CC9CB59CE42B72BA01488FD71D7946EB5299E1286FB6FE458CD26FC67BD3C5F5AE781A9841BF82E35D078B2661A2E8683B1923D41B How P*Q = 59939659CE42B715D00A443F5C75E50DD6A53361286FB67F22C6691BF19EF478BEB5CF01A9841B7C 171AE81E2C998645D0D0761923D41B ??? 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... ). 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 March 13, 2008 by HVC
Ox87k Posted March 13, 2008 Posted March 13, 2008 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
HVC Posted March 13, 2008 Posted March 13, 2008 (edited) Man, i'm unable to own anyone... 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... Edited March 13, 2008 by HVC
Ox87k Posted March 13, 2008 Posted March 13, 2008 (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 0059 F9 4A 41 00 00 00 00 A2 62 E2 55 00 00 00 0084 64 04 28 00 00 00 00 88 56 16 56 00 00 00 002B AB 2A 2A 00 00 00 00 53 52 51 50 00 00 00 009E 9C DA 58 00 00 00 00 AD A9 A5 21 00 00 00 003B 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 March 13, 2008 by Ox87k
HVC Posted March 13, 2008 Posted March 13, 2008 (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 0059 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: 6162636465666768696A6B6C6D4E4F505152535455565758595A21402324255E262A28295F2B2D3D7C5C3C3E3F223A3B7B9D 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... 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... Now, lets make Ziggy to add to the Ollydbg data-ripper plugin an option to rip GInts. Then, make it public. Edited March 13, 2008 by HVC
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now