Plugin for IDA 8+ - Githubissues

naim94a commented 11 months ago

It seems that some users are having trouble connecting to unofficial lumina servers with TLS enabled. It seems that the current workarounds aren't simple enough.

We should have a plugin that securely connects to any lumen instance by approving preset certificates in addition to the builtin ones.

ElonGaties commented 10 months ago

As of IDA 1.8 you can have private Lumina servers up, of which you can just configure a connection to in IDA Options. IDA does not allow connection to a private server without credentials (for some reason) - patching it out causes a trusted cert issue. Apparently these instances also require a trusted certificate.

naim94a commented 10 months ago

Yes, that's why I would like to create an open source plugin for this (or use this one https://github.com/naim94a/lumen/issues/117#issuecomment-1858766501). FYI, if TLS isn't required - you can set the LUMINA_TLS environment variable and connect without TLS.

Hopfengetraenk commented 8 months ago

Okay, I guess found what is

The problem with the Lumina Servers Certificate.

So lumina.hex-rays.com:443 vs lumen.abda.nl:1235

I decompiled ida64.dll to of IDA Pro 8.3 to fix that stupid "invalid_remote_certificate" error. And found this: That is the only part where the flow of execution takes the 'wrong' path. On lumen TrustStatus_dwErrorStatus is 0x20-CERT_TRUST_IS_UNTRUSTED_ROOT while on lumina it is 0x10000 CERT_TRUST_IS_PARTIAL_CHAIN ) which is a requirement to be accepted by the IDA-client.

So it needs to have a broken chain:

Check the sites yourself: https://sslshopper.com/ssl-checker.html#hostname=lumina.hex-rays.com:443 vs https://sslshopper.com/ssl-checker.html#hostname=http://lumen.abda.nl:1235/

Here is the entire function:

bool IDA_CheckCert(struct_IdaCert *aCert)
{

  if ( aCert->CerErrCode =  QueryContextAttributesA(&aCert->sechandle78, 0x53u, &pBuffer) ) {
    aCert->CerErrText = "QueryContextAttributes(SECPKG_ATTR_REMOTE_CERT_CONTEXT)";
    return 0;
  }
  memset(&pChainPara, 0, sizeof(pChainPara));  pChainPara.cbSize = 32;

  // First time CertificateChain
  if ( !CertGetCertificateChain(0i64, pBuffer, 0i64, pBuffer->hCertStore, &pChainPara, 0, 0i64, &pChainContext) ) {
    aCert->CerErrText = "CertGetCertificateChain[1]"; aCert->CerErrCode = GetLastError();
    return 0;
  }
  TrustStatus_dwErrorStatus = pChainContext->TrustStatus.dwErrorStatus;     CertFreeCertificateChain(pChainContext);

  if ( (TrustStatus_dwErrorStatus & 1) != 0 ) { // =0x1 -> CERT_TRUST_IS_NOT_TIME_VALID 
    aCert->CerErrText = "expired_remote_certificate";
    return 0;
  }

 // Problem the lumina servers certificate must have the error of an broken certificate chain to be 'genuine' 
 // https://learn.microsoft.com/en-us/windows/win32/api/wincrypt/ns-wincrypt-cert_trust_status
  if ( TrustStatus_dwErrorStatus != CERT_TRUST_IS_PARTIAL_CHAIN ) { //= 0x10000 The certificate chain is not complete.
        aCert->CerErrText = "invalid_remote_certificate";
    return 0;
  }
  if ( !CertAddEncodedCertificateToStore(pBuffer->hCertStore, 1u, aCert->pbCertEncoded, aCert->cbCertEncoded, 2u, 0i64) ) {
    aCert->CerErrText = "CertAddEncodedCertificateToStore";  aCert->CerErrCode = GetLastError();
    return 0;
  }

  // Second time CertificateChain  
  if ( !CertGetCertificateChain(0i64, pBuffer, 0i64, pBuffer->hCertStore, &pChainPara, 0, 0i64, &pChainContext) ) {
    aCert->CerErrText = "CertGetCertificateChain[2]";   aCert->CerErrCode = GetLastError();
    return 0;
  }
  TrustStatus_dwErrorStatus = pChainContext->TrustStatus.dwErrorStatus;  CertFreeCertificateChain(pChainContext);

  // lumina server cert chain must NOT end in a root certificate
  // If lumen.abda.nl Cert is in Root Trust ; TrustStatus_dwErrorStatus gets 0x0 (CERT_TRUST_NO_ERROR) 
  if ( TrustStatus_dwErrorStatus != CERT_TRUST_IS_UNTRUSTED_ROOT ) { // = 0x20 The certificate or certificate chain is based on an untrusted root.
    aCert->CerErrText = "invalid_remote_certificate";
    return 0;
  }
  if ( CertVerifyTimeValidity(0i64, pBuffer->pCertInfo) ) {
    aCert->CerErrText = "expired_remote_certificate"; CertFreeCertificateContext(pBuffer);
    return 0;
  }
  else if ( CertGetNameStringA(pBuffer, 3u, 0, "2.5.4.3", pszNameString, 0x400u) <= 1
         || !strcmp(pszNameString, "internal.hex-rays.com") )
  {
    aCert->CerErrText = "invalid_remote_certificate"; CertFreeCertificateContext(pBuffer);
    return 0;
  }
  else {
                CertFreeCertificateContext(pBuffer);
    return 1;
  }
}

So until you somehow get it done to craft a certificate with a broken chain for the lumina server on lumen.abda.nl. We need to patch ida64.dll.

Fileoffset: 000B00E8 32 C0 -> B0 01 Will turn all that above return 0; into return 1;

You are using a different Version of IDA?

->So that is how to find the file offset

Having ida64.dll loaded press Shift+F4 to open "Strings" ctrl+f and enter invalid_remote_certificate. Enter to follow that entry. Ctrl+x to show xrefs. There should be 2. Press Enter to follow the last xrefs. Now you are inside the right function. Some lines down there should be call cs:CertFreeCertificateContext. A little more down xor al, al . That's what needs the patch. Scroll to that line.

Edit\Patch program\Patch Bytes 32 C0 .... change it to B0 01 .... Edit\Patch program\Apply patch to input file. Ok to save and ya done.

Well file is probably in use and save not possible. But hey you smart, you'll get this done, don't ya. ;^)

tomrus88 commented 8 months ago

@naim94a you wanted open source? Here you go https://github.com/tomrus88/OpenLumina. But you will have to create new server certificate because your old certificate doesn't use certificate chains as intended by IDA and official Lumina servers (both public and private). Scripts to generate new compatible certificates can be found in plugin repo. Certificates generated by provided scripts use exact same settings that are used to generate official Lumina server certificates, the only difference is that we create our own private keys (because we don't have original ones). The idea is so that this plugin works with both your server as well as official private Lumina servers (but pirated).

In the feature, once you update your server certificate, I think it should be possible to include that new certificate within the plugin as preset certificate (hardcode it just like IDA does) so that users don't have to copy both certificate file and plugin to theirs IDA's.

There's also performance benefit from using new generated TLS certificates because they are ECC based certificates instead of RSA. ECC certificates use much shorter keys (256 bits instead of 4096 bits) and that means it's much easier for both server and client to deal with encryption.

Elliptic Curve Cryptography (ECC) is emerging as an attractive public-key cryptosystem for mobile/wireless environments. Compared to traditional cryptosystems like RSA, ECC offers equivalent security with smaller key sizes, which results in faster computations, lower power consumption, as well as memory and bandwidth savings.

This is completely new plugin that was created from scratch today and uses different method (compared to method used in old plugin I shared previously) to fix certificate issues in newer IDA versions.

Edit: there's appears to be a bug that prevents this method from working correctly if Lumen server is running on Windows OS, server doesn't send whole certificate chain from certificate file to client as intended for some reason, only first certificate from the chain is being sent and that causes validation on client to fail... Bug is probably somewhere in Windows schannel (less likely) or in rust-native-tls library and it's dependencies (most likely)...

Edit2: found a workaround for that bug where when hosting Lumen server on Windows OS it's not sending full certificate chain, if you manually install your generated intermediate certificate to "Current User" certificate store under "Intermediate Certificate Authorities" -> "Certificates" category, server will send certificate chain correctly and validation will succeed as intended.

Plugin is Windows only because:

I don't use any other OS but Windows personally
I don't know how to do hooking on other OS's nor I want to spend time figuring this out

Edit3: there's now experimental versions of plugin for Linux and MacOS.

If someone knows how to add Linux/MacOS support to the plugin, feel free to submit PR.

tomrus88 commented 7 months ago

I've also created plugins for Linux and MacOS, they seems to work fine during my limited testing on local server. I had to add support for Linux/MacOS to my closed source plugin that brings Lumina functionality to IDA Freeware to be able to test it, but for version 8.4 only, because those OS's are pain to work with and there's some differences in IDA internals between versions making it even more pain.

But we still need server certificate update for it to be useful.

At least people who run theirs own Lumina server can use plugin now as long as they generate new compatible certificate.

tomrus88 commented 3 months ago

@tomrus88 IDA 9 leaked today, are you going to be updating your plugin for it?

Update why exactly? Are you claiming it doesn't work with IDA 9.0?

ElonGaties commented 3 months ago

pretty sure it is working, ida 9 supports secondary servers which idk how to setup though

tomrus88 commented 3 months ago

C:\Program Files\IDA Professional 9.0\plugins\luminafix64.dll: incompatible plugin version, skipped

Ok, that means IDA now checks SDK version of the plugins and don't load any old ones. Need to recompile it with IDA 9.0 SDK.

Try this new version for IDA 9.0 Beta 2: luminafix64.zip

tomrus88 commented 3 months ago

I've published new release of OpenLumina plugins with support for IDA 9.0 Beta on https://github.com/tomrus88/OpenLumina/releases/tag/openlumina-v0.3.

There's issues with macos version due to bugs in third party plthook library used for hooking.

Sadly they still won't work with lumen.abda.nl server because it still uses incorrectly generated certificate...

But they should work with any other lumina server that is using correctly generated certificates. Information on how to generate correct certificate can be found here https://github.com/tomrus88/OpenLumina/tree/cmake-build/lumina_ca.

qwerty472123 commented 3 months ago

I've published new release of OpenLumina plugins with support for IDA 9.0 Beta on https://github.com/tomrus88/OpenLumina/releases/tag/openlumina-v0.3.

There's issues with macos version due to bugs in third party plthook library used for hooking.

Sadly they still won't work with lumen.abda.nl server because it still uses incorrectly generated certificate...

But they should work with any other lumina server that is using correctly generated certificates. Information on how to generate correct certificate can be found here https://github.com/tomrus88/OpenLumina/tree/cmake-build/lumina_ca.

I don't think there is a saying of "incorrectly generated certificates" for this case, or for the original expected code, any certificate not issued by Hex Rays is an "incorrectly generated certificate". OpenLumina uses hook to turn some "incorrectly generated certificates" into "considered correct certificates". Similarly, we only need more hooks to make Lumen's certificate also become a "considered correct certificate".

In addition, there are some components on IDA 9.0 beta that do not load plugins, such as vault/lumina client/server, so a version that is not a plugin is also required.

For these reasons, I wrote my own version, opensourced at https://gist.github.com/qwerty472123/c2155683c6c4713bdf160cf8add3fe52 with binaries.

udrwxa commented 3 months ago

@qwerty472123 Is your solution only for Windows?

qwerty472123 commented 3 months ago

@qwerty472123 Is your solution only for Windows?

Just open the link https://gist.github.com/qwerty472123/c2155683c6c4713bdf160cf8add3fe52. The linux is prior to the Windows。

I tested for Windows and Linux, and I donnot have a mac.

tomrus88 commented 3 months ago

I don't think there is a saying of "incorrectly generated certificates" for this case, or for the original expected code, any certificate not issued by Hex Rays is an "incorrectly generated certificate".

Any certificate that is not generated using same settings as original one are considered incorrectly generated. That's matter of a fact. With correctly generated certificate you can just replace hardcoded certificate in any of IDA executable and it will work without any additional changes to the code, need of injection, hooks etc.

OpenLumina uses hook to turn some "incorrectly generated certificates" into "considered correct certificates".

This is not true at all. What OpenLumina does is it adds more trusted certificates in addition to hardcoded one.

Similarly, we only need more hooks to make Lumen's certificate also become a "considered correct certificate".

Yeah and that makes it so much more complicated for no reason. It's much easier to just generate correct certificate instead.

In addition, there are some components on IDA 9.0 beta that do not load plugins, such as vault/lumina client/server, so a version that is not a plugin is also required.

For those I choose to either patch them manually by changing either certificate validation code or replacing original certificate inside them with our own. Those components were not a scope of the plugin anyway.

For these reasons, I wrote my own version, opensourced at https://gist.github.com/qwerty472123/c2155683c6c4713bdf160cf8add3fe52 with binaries.

Your approach is so unnecessary overcomplicated...

qwerty472123 commented 3 months ago

With correctly generated certificate you can just replace hardcoded certificate in any of IDA executable and it will work without any additional changes to the code, need of injection, hooks etc.

Interesting definition, I admit that I did not notice this possibility. But I prefer the definition 'making the existing Lumen server work is the correct implementation of the plugin for this issue'.

This is not true at all. What OpenLumina does is it adds more trusted certificates in addition to hardcoded one.

Maybe you're talking about something other than https://github.com/tomrus88/OpenLumina/blob/b96ef4f0e58624f190635e01eaca5195c6540dff/OpenLumina/OpenLumina.cpp#L245.

At least this code is clearly using hook. The "adds more trusted certificates in addition" is just the goal that hook achieved. And hook can achieve other things like "adds more trusted certificates in addition even if it is using current lumen settings".

Yeah and that makes it so much more complicated for no reason. It's much easier to just generate correct certificate isntead.

This does make sense. For example, users using the old version of IDA+lumen(this repository) and users using the new version of IDA+lumen can continue to access the same domain as their Lumina server without any modifications from Lumen itself or settings for the old version of IDA now. Or someone may want to use Lumina certificates that are trusted by Windows certificate store.

Your approach is so unnecessary overcomplicated...

I think the complexity of this approach lies in its code implementation, but not in its dependencies and its users.

In fact, the version that only supports “Lumen settings” certificates is equally simple (only requiring a hook, a memcmp). But after reading your version, I realized that it can support for other "settings", and the "overcomplicated" is actually introduced to support certificates with trusted(by Windows certificate store) roots.

Note: this approach does not trust all root certificates in the Windows certificate store, but only allows users to add trust to the certificates stored there.

tomrus88 commented 3 months ago

But I prefer the definition 'making the existing Lumen server work is the correct implementation of the plugin for this issue'.

No it's not correct implementation as it makes it work with incorrectly generated certificates. Existing server must update its certificate to be compatible with a plugin. Updating it is not that hard. But it's been a months and certificate used by lumen.abda.nl is still not updated...

qwerty472123 commented 2 months ago

No it's not correct implementation as it makes it work with incorrectly generated certificates. Existing server must update its certificate to be compatible with a plugin. Updating it is not that hard. But it's been a months and certificate used by lumen.abda.nl is still not updated...

Well, if you insist on a definition of "correctness" that has inconsistent behavior with the Linux version (the Linux version allows any root certificate to be trusted), relies on the user's specific configuration of the operating system (the user cannot add any root certificate trusted by IDA to the system root certificate store, otherwise it will be prompted that the certificate is "invalid"), and is incompatible with existing lumen services. I admit that is indeed an interesting point of view.

tomrus88 commented 2 months ago

Well, if you insist on a definition of "correctness" that has inconsistent behavior with the Linux version (the Linux version allows any root certificate to be trusted), relies on the user's specific configuration of the operating system (the user cannot add any root certificate trusted by IDA to the system root certificate store, otherwise it will be prompted that the certificate is "invalid"), and is incompatible with existing lumen services. I admit that is indeed an interesting point of view.

There's nothing inconsistent or special about Linux version, it works exactly like on windows, you just use same correctly generated certificate and it works across all supported OS be it Linux, Windows or MacOS, simple as that...
Users should not be adding any IDA certificates into system certificate store as its not intended way by IDA developers and will break connection to official and third party lumina servers as well as cloud decompilers, hexvault, licsrv, tlm and so on resulting in "invalid remote certificate" error...
Existing lumen services should not be running with incorrectly generated certificates for years to begin with when it only takes few seconds to make proper one... There's simply no excuse for them to use bad certificates.

qwerty472123 commented 2 months ago

There's nothing inconsistent or special about Linux version, it works exactly like on windows, you just use same correctly generated certificate and it works across all supported OS be it Linux, Windows or MacOS, simple as that...

Your linux version works fine for lumen server, which you called it "bad certificate". The correct certificate verification process should clearly not trust any certificate that is considered "bad" by its writer.

Users should not be adding any IDA certificates into system certificate store as its not intended way by IDA developers and will break connection to official and third party lumina servers as well as cloud decompilers, hexvault, licsrv, tlm and so on resulting in "invalid remote certificate" error...

As you mentioned, the prompt is "invalid remote certificate". If you believe this is caused by improper local configuration, then IDA should prompt "improper local configuration". Like those crashes in IDA 9.0 beta for Arm, this is another IDA bug, has minor effects.

Existing lumen services should not be running with incorrectly generated certificates for years to begin with when it only takes few seconds to make proper one... There's simply no excuse for them to use bad certificates.

The existing Lumen server requests people to add "End Entity" trust to a domain owned by its owner, which is a very normal and reasonable certificate behavior. And your configuration requires people to trust a "CA" organization, which will have a clear dishonest behavior of issuing a certificate to someone who has never owned the vault.hex-rays.com domain. Obviously, the former method is more correct.

tomrus88 commented 2 months ago

Your linux version works fine for lumen server, which you called it "bad certificate". The correct certificate verification process should clearly not trust any certificate that is considered "bad" by its writer.

If this is a case (which i'm not even sure is true), then it's IDA's internal certificate verification logic flaw, we have no control over it and we should not interfere with it as long as connection to server works.

As you mentioned, the prompt is "invalid remote certificate". If you believe this is caused by improper local configuration, then IDA should prompt "improper local configuration". Like those crashes in IDA 9.0 beta for Arm, this is another IDA bug, has minor effects.

I don't believe anything, it's matter of a fact. Error message may not be great, but we don't have a control over what error IDA shows when it doesn't like remote server certificate. This is non issue.

The existing Lumen server requests people to add "End Entity" trust to a domain owned by its owner, which is a very normal and reasonable certificate behavior. And your configuration requires people to trust a "CA" organization, which will have a clear dishonest behavior of issuing a certificate to someone who has never owned the vault.hex-rays.com domain. Obviously, the former method is more correct.

This is a lie. In both cases user must trust certificate of the server. There's absolutely no difference if it's so called "End Entity" or CA. They are both self signed certificates issued by server owner. You either trust them or not, simple as that. Somehow official Hex-Rays customers doesn't complain they have to trust to self signed CA certificates. Basically you just taken it all out of your arse just to argue with me.

There's also many benefits of having CA and certificate chain. For example this way you can re-issue server certificate literally every day and users won't have to do anything on theirs end as long as root CA certificate is still valid (not expired), since IDA uses CA root certificate for validation. Contrary if server used incorrectly generated certificates without CA and chain like you are suggesting, users will be forced to download new certificate every single time new certificate is issued to continue using server, which is not great user experience.

Another benefit of correctly generated certificate is performance (i've already talked about that before) as it uses different encryption algo that is faster, but provides same (if not better) security.

qwerty472123 commented 2 months ago

we should not interfere with it as long as connection to server works

The purpose of a certificate is not just to work, otherwise we wouldn't even need TLS.

what error IDA shows when it doesn't like remote server certificate

But this situation is that the remote certificate has not changed, only the configuration of the user's operating system has changed to add more trust to the certificate.

There's absolutely no difference if it's so called "End Entity" or CA. They are both self signed certificates issued by server owner. You either trust them or not, simple as that.

End Entity cannot issue certificates.

Somehow official Hex-Rays customers doesn't complain they have to trust to self signed CA certificates.

Hex Rays' self signed certificates have honest behavior of issuing certificates for the domains they own, while the "correctly generated certificates" you claim are the opposite.

Basically you just taken it all out of your arse just to argue with me.

In fact, it is you not me. There are no technical issues with supporting existing Lumen certificates, but in order to oppose this, you have created the concept of "correctly generated certificates" that must have the same settings as Hex Rays. But if you acknowledge that these "settings" have make sense, then it cannot be avoided that the settings you provide involve dishonest behavior such as claiming to be the owner of "Hex-Rays" and "vault.hexrays. com".

For example this way you can re-issue server certificate literally every day and users won't have to do anything on theirs end as long as root CA certificate is still valid (not expired), since IDA uses CA root certificate for validation.

In fact, during the IDA7.0 era, Lumen certificates could be easily trusted, even easier than what you call "correctly generated certificates", as it did not require any change in binaries. Obviously, in that era, it was a "more correct certificate". The counts for user-participated certificate updates to adhere to "correctly generated certificates" (yes, this does not matter for new version IDA users, but old version IDA users are also required to synchronize certificate updates) will only increase.

Another benefit of correctly generated certificate is performance (i've already talked about that before) as it uses different encryption algo that is faster, but provides same (if not better) security.

This is a lie. Longer certificate chains require more network traffic, and clients must verify the entire certificate chain (including multiple RSA and ECDSA signature verifications), which wastes more resources (if not ignorable). Any signature on the certificate chain that can be forged can achieve a MITM attack, so its security will be the minimum value of RSA and ECDSA, so this scheme will only be less secure (if not equal).

tomrus88 commented 2 months ago

The purpose of a certificate is not just to work, otherwise we wouldn't even need TLS.

Majority of people don't care. All they want is things to work.

But this situation is that the remote certificate has not changed, only the configuration of the user's operating system has changed to add more trust to the certificate.

Adding random self signed certificate into system certificate store doesn't "add more trust to the certificate", stop being delusional.

End Entity cannot issue certificates.

Doesn't matter if it can or can't issue certificates. I repeat it again: you either trust it or not.

Hex Rays' self signed certificates have honest behavior of issuing certificates for the domains they own, while the "correctly generated certificates" you claim are the opposite.

No they don't have "honest behavior", you keep pulling shit out of your arse, they are even more dishonest, because you are not even connecting to domain that is specified in theirs certificate when using official lumina servers, you are connecting to absolutely different domain. The reason they do it is because domain doesn't matter, you can put literally anything as domain name and it will still work just fine. Neither you can verify that they in fact own that domain listed in theirs certificate. Not that it actually matters...

There are no technical issues with supporting existing Lumen certificates, but in order to oppose this, you have created the concept of "correctly generated certificates" that must have the same settings as Hex Rays. But if you acknowledge that these "settings" have make sense, then it cannot be avoided that the settings you provide involve dishonest behavior such as claiming to be the owner of "Hex-Rays" and "vault.hexrays. com".

There's no technical issues other than wasting more time to support those incorrectly generated, broken certificates. So why bother when anyone can make proper ones in a matter of seconds. Also there's no claim of being owner of some domain, you are pulling that shit out of your arse again. It's just settings that are identical to official certificate, nothing more. If anything, it only makes those proper certificates more of official ones. In the end no one is preventing you from changing organization and domain name in provided openssl configuration. It's just a template for people to use, but you are too dumb to understand that...

The counts for user-participated certificate updates to adhere to "correctly generated certificates" (yes, this does not matter for new version IDA users, but old version IDA users are also required to synchronize certificate updates) will only increase.

No they won't increase, stop pulling shit out of your arse.

This is a lie. Longer certificate chains require more network traffic, and clients must verify the entire certificate chain (including multiple RSA and ECDSA signature verifications), which wastes more resources (if not ignorable). Any signature on the certificate chain that can be forged can achieve a MITM attack, so its security will be the minimum value of RSA and ECDSA, so this scheme will only be less secure (if not equal).

Stop making claims when you have absolutely no clue what you are talking about, you are starting to look like a clown that comes here every day just to argue with me and make me laugh so hard... So please shut the fuck up and stop wasting my time.

Elliptic Curve Cryptography (ECC) is emerging as an attractive public-key cryptosystem for mobile/wireless environments. Compared to traditional cryptosystems like RSA, ECC offers equivalent security with smaller key sizes, which results in faster computations, lower power consumption, as well as memory and bandwidth savings.

https://www.ssl2buy.com/wiki/rsa-vs-ecc-which-is-better-algorithm-for-security https://cheapsslweb.com/resources/ecc-vs-rsa-certificate https://www.reddit.com/r/cryptography/comments/1aouz9u/rsa_vs_ecc_which_one_is_better_and_why/ https://sslinsights.com/ecc-vs-rsa/ https://www.tencentcloud.com/document/product/1007/39989 and so on...

qwerty472123 commented 2 months ago

https://www.ssl2buy.com/wiki/rsa-vs-ecc-which-is-better-algorithm-for-security https://cheapsslweb.com/resources/ecc-vs-rsa-certificate https://www.reddit.com/r/cryptography/comments/1aouz9u/rsa_vs_ecc_which_one_is_better_and_why/ https://sslinsights.com/ecc-vs-rsa/ https://www.tencentcloud.com/document/product/1007/39989 and so on...

The certificate chain you issued consists of two 4096-bit RSA certificates and one 256-bit ECDSA certificate. The consumption during transmission and client verification is the sum of the three, and security is the minimum value of the three.

As mentioned in the link you provided(do you read it actually?), the security of 256 bit ECDSA is generally considered to be the same as 3072 bit RSA, rather than 4096 bit.

If you believe that the final level certificate requires more time, please review the TLS handshake process instead of engaging in verbal harassment.

One more thing, these beginner's introduction do not inform you that signature algorithms that rely solely on ECDLP including EdDSA which based on Fiat-Shamir transform, while ECDSA need extra relies on the correctness of ECCDH assumption. The selection of the P-256 curve is also highly controversial. If you are interested in getting started with cryptography instead of continue arguing without reason, please refer to https://safecurves.cr.yp.to/.

No they don't have "honest behavior", you keep pulling shit out of your arse, they are even more dishonest, because you are not even connecting to domain that is specified in theirs certificate when using official lumina servers, you are connecting to absolutely different domain.

Please review the meaning of the CN field (Common Name) in the certificate, rather than engaging in speech attacks. If you still can't understand, please create a website yourself and use a CDN to proxy it by TLS , and then read the CN field of the certificate it provides.

Adding random self signed certificate into system certificate store doesn't "add more trust to the certificate", stop being delusional.

Please read the section in Microsoft documentation about the usage of adding a certificate to root certificate store, rather than questioning it out of thin air.

No they won't increase, stop pulling shit out of your arse.

My reasons have been given, please respond with reason instead of using aggressive language to refute.

Majority of people don't care. All they want is things to work.

Yes, and my tools(https://gist.github.com/qwerty472123/c2155683c6c4713bdf160cf8add3fe52) work, your tools need extra server-side changes. So don't argue with me just to argue with me, don't waste my time anymore, okay?

tomrus88 commented 2 months ago

the security of 256 bit ECDSA is generally considered to be the same as 3072 bit RSA, rather than 4096 bit.

And this is more than enough, unless you can share a method to crack it in reasonable time.

Please review the meaning of the CN field (Common Name) in the certificate, rather than engaging in speech attacks. If you still can't understand, please create a website yourself and use a CDN to proxy it by TLS , and then read the CN field of the certificate it provides.

The Common Name (AKA CN) represents the server name protected by the SSL certificate. The certificate is valid only if the request hostname matches the certificate common name.

I did and it only proves my point that according to you Hex-Rays company is engaging in as you call it "dishonest behavior" by using certificate with CN that doesn't match requested hostname. But absolutely none of theirs customers care about it. And this is fine.

Please read the section in Microsoft documentation about the usage of adding a certificate to root certificate store

I lol'ed so hard on this one. Microsoft documentation, really?

Yes, and my tools ... work

Yes, your tools work like piece of crap and no one should ever use them. End of story.

your tools need extra server-side changes

My tools don't require any server side changes other than generating correct, more of official certificates which takes a few seconds at most and provide improved performance and security at no cost.

So don't argue with me just to argue with me, don't waste my time anymore, okay?

Ofc, you are retarded so I won't waste my time on you anymore. This was my last response. Goodbye.

qwerty472123 commented 2 months ago

The Common Name (AKA CN) represents the server name protected by the SSL certificate. The certificate is valid only if the request hostname matches the certificate common name.

This is the only viewpoint with one reason, but obviously it is incorrect.

As I mentioned before, don't try to enthusiastically refute the views of others after reading half of the introductory document for beginners, as it will waste the time of both sides.

If you read the entire article(https://support.dnsimple.com/articles/what-is-common-name/), it is obvious that the SAN mentioned at the end violates this statement. In fact, browsers have gone further than this for a long time(another refer for beginners(https://security.stackexchange.com/questions/256509/what-is-the-security-advantage-of-requiring-the-cn-to-be-in-the-san-list)).

And ....

but provides same (if not better) security.

And this is more than enough

provide improved performance and security at no cost.

opposite statements in the same reply, too strange...

Anyway, refuse to use any tool workable for current lumen server for strange definition is punish yourself, not me.(Not limited for my tool, but also any other tools violates your definition, Unless you are saying here that the lumen certificate is how incorrect and the plugin cannot be written like this, but you secretly wrote such a plugin for your own use, doge)

Good luck.

arialpew commented 2 months ago

So what's the tldr after all of theses discussions ? The certificat of lumen.abda.nl/ is still invalid ? Do we have any alternative ?

Having the ability to swap from a server to another without adding root CA or change system wide configuration is mandatory imo. It's possible there's others server than lumen.abda.nl/ that have way more signatures in their databases, and switching between both should be smooth.

qwerty472123 commented 2 months ago

So what's the tldr after all of theses discussions ? The certificat of lumen.abda.nl/ is still invalid ? Do we have any alternative ?

Having the ability to swap from a server to another without adding root CA or change system wide configuration is mandatory imo. It's possible there's others server than lumen.abda.nl/ that have way more signatures in their databases, and switching between both should be smooth.

@arialpew

If you don't mind run a socat when using Lumen, then the guidance at https://abda.nl/lumen/ provided is completely usable for now(until IDA 9 beta, inclusive).

If you need a plugin as mentioned in this issue (which can be used directly with Lumen server after installing it and placing a trusted certificate in the appropriate location), you can use either my tool (supporting Windows/Linux) or tomrus88's tool (supporting Linux/macOS, with one exception for Windows) directly for now(until IDA 9 beta, inclusive).

Both plugins support placing multiple trusted certificates at the same time, switching between them is smooth enough.

The exception for tomrus88's tool is not compat with current lumen server in Windows, for detail you can see the above discussion.

RynerNO commented 2 months ago

So until you somehow get it done to craft a certificate with a broken chain for the lumina server on lumen.abda.nl. We need to patch ida64.dll.

Fileoffset: 000B00E8 32 C0 -> B0 01 Will turn all that above return 0; into return 1;

You are using a different Version of IDA?

->So that is how to find the file offset

Having ida64.dll loaded press Shift+F4 to open "Strings" ctrl+f and enter invalid_remote_certificate. Enter to follow that entry. Ctrl+x to show xrefs. There should be 2. Press Enter to follow the last xrefs. Now you are inside the right function. Some lines down there should be call cs:CertFreeCertificateContext. A little more down xor al, al . That's what needs the patch. Scroll to that line.

Edit\Patch program\Patch Bytes 32 C0 .... change it to B0 01 .... Edit\Patch program\Apply patch to input file. Ok to save and ya done.

Well file is probably in use and save not possible. But hey you smart, you'll get this done, don't ya. ;^)

The only solution that actually worked for IDA 9.0, and the simplest one (except for the plugin, which is not working for some reason).

tomrus88 commented 2 months ago

The only solution that actually worked for IDA 9.0, and the simplest one (except for the plugin, which is not working for some reason).

Which plugin is not working? The one posted here https://github.com/naim94a/lumen/issues/124#issuecomment-2282842167 should be working fine for IDA 9.0 Beta 2 on Windows. It won't work with IDA 9.0 Beta 3 due to additional SDK changes and needs to be recompiled again with new Beta 3 SDK, but I doubt you have Beta 3 (and if you do I can compile one for beta 3).

tomrus88 commented 1 month ago

@tomrus88 Your plugin needs to be updated for 240925 because ida64.dll has been renamed to ida.dll.

It was checking both ida.dll and ida64.dll, but I think here were some changes in SDK, so I recompiled it with latest SDK. Try it out. For IDA 9.0.240925: luminafix64.zip

OpenLumina plugin also updated for IDA 9.0.240925.

greenozon commented 1 month ago

Thanks! updated plugin luminafix64.dll works fine on IDA9 GA

eg:

lumina: applied metadata to 386 functions.

udrwxa commented 1 month ago

@greenozon what's the password under Private server auth?

greenozon commented 1 month ago

heh, good question:) I filled it in long time ago... do you know where does it keep it? an edu. guess - try guest/guest

tomrus88 commented 1 week ago

Hmm I'm wondering what happened to this issue https://github.com/naim94a/lumen/issues/117? It's just gone...

naim94a / lumen

Plugin for IDA 8+ #124

The problem with the Lumina Servers Certificate.

You are using a different Version of IDA?

You are using a different Version of IDA?

eg: