#1
|
|||
|
|||
Strange RSA modulus N value
I have an old Delphi application I’m trying to reverse.
The app uses the FGIntRSA RSADecrypt procedure plus slightly modified FGIntRSA Base64 chars to validate the UserName and RegCode Code:
The Exponent N=49608307214148501933851667872461788859314634414960570968576805395 And the possible prime divisors are: PRIME FACTOR: 3 PRIME FACTOR: 5 PRIME FACTOR: 5573 PRIME FACTOR: 1694327 PRIME FACTOR: 1606452225507735500339279 PRIME FACTOR: 218026387802762543011518916577 https://en.wikipedia.org/wiki/RSA_(cryptosystem) Quote:
Consequently I’m unable to find the correct factors p and q to retrieve the Private Exponent D. Also the app does not use the most common Public Exponents like 65537 (0x10001) or 7967 (0x1F1F) but rather 57167651080132926337657020661 (0x B8B7F8FED9427AB1E07720F5) The original keys from the disassembly of the app are Code:
Exponent E: r=JwZQM2jP7kIt3U Modulus N: j9I4D7HqaQTdXNtl3mgWtnkQiz6aN+RKlqoe Base64 CharSet= 0123456789+=aAbBcCdDeEfFgGhHiIjJkKlLmMnNoOpPqQrRsStTuUvVwWxXyYzZ If anyone wants to play with it. |
#3
|
|||
|
|||
I don't think it is ElGamal.
The Elgamal Encrypt/Decrypt procedures from the FGInt library do not use the 3 padding bits "111" as in the RSA. Also I have keygened a few applications that use almost the same version of the FGInt library so I could easily identify the decryption routine and confirmed it with a compare. Furthermore the Elgamal procedures use for conversions "only" the procedure "FGIntToBase256String" whereas the RSA En/Decrypt procedures use "Base2StringToFGInt", FGIntToBase2String, "convertBase256to2" The program is very old and the original homepage is no more available. I have therefore attached it here, if you want to try your hands on it. The main application is compressed with Aspack, so it should not be a problem for a pro like you to unpack it. By the way it uses BlowFish to save the entered UserName and RegCode in an app_name.fdb file and the RegData are checked on application restart. My observation is that Kanal plugin in PEID is not able to detect older implementations of the FGIntRSA routines, especially when the RSA values are not in plain ASCII texts. Using the RE-SIGS v0.18 PUBLIC by dihuxx in IDA to create MAP-file helped to resolve some of the FGIntRSA procedures. Regards, TemPoMat |
#4
|
|||
|
|||
The conversion from base64 (Custom Base64 CharSet) to decimal for "Exponent E" is correct.
But, I think there is a conversion error on converting "Modulus N": Code:
j9I4D7HqaQTdXNtl3mgWtnkQiz6aN+RKlqoe Code:
49608307214148501933851667872461788859314634414960570968576805395 Code:
49608213082142399816039386263750142317464556599709660835501230612 Regards |
#5
|
|||
|
|||
[QUOTE=aliali;110541]
Quote:
The correct modulus N is then obtained from the conversion of the binary to hexadecimal. Now if we use this number which should actually be the correct Modulus N we get the following factors: Code:
PRIME FACTOR: 2 PRIME FACTOR: 2 PRIME FACTOR: 3 PRIME FACTOR: 193 PRIME FACTOR: 21419781123550258987927196141515605491133228238216606578368407 Quote:
|
#6
|
|||
|
|||
It's ElGamal as Kerlingen said.
Take a look at: https://github.com/SnakeDoctor/FGInt Code:
Femta.exe :: 0047E8F0 == FGIntElGamal.pas :: Procedure ElGamalDecrypt(E : String; Var x, p : TFGInt; Var D : String); |
#7
|
|||
|
|||
Thanks to Kerlingen And MistHill
Thanks to Kerlingen (my apology to you) for the correct assertion that it is ElGamal and not RSA and also to MishHill for the confirmation.
I have check the FGIntElGamal.pas from Walied Othman and could see that the 3 padding bits "111" are also used in both the encryption and decryption procedures. I will work from here and see if I can generate valid keys for this application and write a keygen for it if possible. Best Regards, TemPoMat |
The Following User Says Thank You to TempoMat For This Useful Post: | ||
e0qs (12-16-2017) |
#8
|
|||
|
|||
You can use
000000000000000000000000000870 ... 000000000000000000000000000879 for Registration Code. It is not related to Registration Name. |
#9
|
|||
|
|||
Good, raduga_fb found bugs in the application.
1. the customized Base64 encoding/decoding has problem. UserCode 000000000000000000000000000870~879 and 87a, 87A, 87b, 87B result same after decoded. 2. validation logic The success flag is set if UserCode length greater than 0x1D. But next it will jump over the UserName check if ElGamalDecrypt() failed. We need to counterfeit a UserCode with the correct checksum, and cause ElGamalDecrypt() return NULL, the trick is done. Some "valid" UserCode: 00000000000000000000000000004s 000000000000000000000000000+6s 0000000000000ca210e81sg92ku=gs 000000000000YRi210e81sg92kuaFs 000000000000JS0mA591h7l9nhR2Yc 000000000000Mt4tE4AMIojgpaJbQc 0000000000000AstE4AMIojgpaJbDCq 00000000000007yc93CdcfKwlGnPsRk |
The Following User Says Thank You to MistHill For This Useful Post: | ||
TempoMat (02-25-2018) |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Strange Instruction CTS BE | thomasantony | General Discussion | 2 | 03-23-2005 04:41 |