OBD2 Check via Internet: Permanent Password Query

Hi,

Is there a quick way to access a log file from Kobd2check that would show me why STGCheck, when using the internet connection, repeatedly asks for the password?

I suspect that the .exe file is not allowed through the firewall. Or, is it possible that my account is not actually authorized to use this feature?

For testing purposes, I temporarily disabled the firewall, but the login window keeps reappearing, even though I've confirmed that the login credentials for shop.dieselschrauber.org are correct.

Hello.
Oli.

Hello,

Which operating system is installed on the computer?
Is everything running in a virtual machine that might be reset at any time?

The password prompt (for CVN check and software version check) is always active by default when the computer has internet access.

Does the password prompt reappear immediately after entering it? If so, it was not possible to connect to the Dieselmechanic server. This could be due to a firewall issue, malware on the computer that intercepts/eavesdrops on TLS connections, or simply an incorrect username/password.
If this is the case and the password dialog appears every time you start KOBD2Check, it means that the login token provided by the server could not be saved in the registry.

Best regards, Rainer.

Hello Rainer,

The software is running normally on a Windows 10 laptop.

Malware can be categorically ruled out I am deeply involved in data protection.

The password prompt appears immediately after entering it, and the login credentials have been verified and work on the website.

Is the server's IP address hardcoded? Because, by default, AVM's Fritzbox routers block direct IP address requests to the internet.
Because disabling the Windows Firewall didn't improve the situation. I don't have any other hardware at the moment to perform a cross-test.

KData-Scope also reports that the version is outdated, but it cannot find a version on the server.

Scope is installed in the latest version. It is likely that an expiration date was set in the configuration?

Hello Rainer,

I let a few "weeks" pass in order to become aware of the cause.

Unfortunately, the query is still not working.

OS: Win10
Login to the shop: OK.
MS Defender Firewall inactive: OK.
Virus scan: MS Built-in.
There is no malware in my networks.


I'm returning to my question about log files. How can I determine what KOBD2Check is doing in the background using Wireshark? I'm seeing a connection attempt via TLS V1.2 to the IP address 178.209.53.204.

I see the Comodo CA in the certificate chain of your web server, but it appears that the certificate expired on May 30, 2020.

Hi,

No, my certificate is valid until November 30, 2020, which means the connection your computer is trying to establish might already be redirected somewhere else.

Please check this:

https://www.grc.com/fingerprints.htm

Best regards, Rainer.

Hello Rainer,

No, not the certificate for your host, but the root certificate of your Certificate Authority (CA) that issued the certificate for dieselschrauber.org.

Serial 27:66:EE:56:EB:49:F3:8E:AB:D7:70:A2:FC:84:DE:22
COMODO RSA Certification Authority.

Your web server is providing a chain of certificates, and it appears that an old root CA certificate is still included in that chain. As can be seen in the test report below, the web server is providing multiple certificate paths.

https://www.ssllabs.com/ssltest/analyze.html?d=dieselschrauber.org

One could also take a closer look at the older TLS protocols .

Thanks for the heads-up, I'll have to take a look at that... So far, neither my phone nor any other laptop I've used has been affected by this.

Best regards, Rainer.

Schrauber.Guru wrote:

Hello Rainer, No, not the certificate for your host, but the root certificate of your Certificate Authority (CA) that issued the certificate for dieselschrauber.org. Serial: 27:66:EE:56:EB:49:F3:8E:AB:D7:70:A2:FC:84:DE:22 COMODO RSA Certification Authority. Your web server is providing a chain of certificates, and it appears that an old root CA certificate is still included in that chain. As can be seen in the test report below, the web server is providing multiple certificate paths. https://www.ssllabs.com/ssltest/analyze.html?d=dieselschrauber.org One could also take a closer look at the older TLS protocols

.
Hello,

So, the thing is, it's not a problem because all the relevant operating systems use newer root certificates.

Apart from that, this isn't an issue with my server or its configuration, but rather with Comodo's certificate chain.

And completely apart from that, the Diesel Mechanic license exam has absolutely nothing to do with SSL/TLS; it would be just as secure and functional even if HTTP were used.

The identification and verification of participant pages does not rely on SSL or TLS.
Therefore, it cannot be intercepted by breaking the SSL/TLS encryption, as is common in many corporate LANs.

If the license check fails, you can assume that the data connection has been compromised and someone is able to intercept your HTTPS traffic.

If you try again and let me know the exact time, I can tell you whether the issue is due to incorrect login credentials or if the license request is being rejected beforehand.

Best regards, Rainer.

Good evening.
Although I'm brand new here, I still want to mention that I repeatedly receive the same prompt followed by the same message.

I also have Windows 10 version 18363.959. I have tried disabling and enabling the Windows Firewall, and enabling and disabling Windows Defender. I also have a Fritzbox router, but I would like to rule it out as a cause, since using a mobile hotspot doesn't improve the situation.

I assume that KOBD2Check should transmit the email/password to a server (where the authentication takes place), which apparently isn't working for me either.
I work in the IT field myself, and I can very likely rule out the possibility of third-party eavesdropping (I won't comment on what Microsoft is trying to do with Windows).

Best regards,
Markus.

Hi,

Generally, the problem is caused by other software that is already installed on the Windows system.
Specifically, for example, a tool for virtually comparing the hardware specifications of computers.

The described effect has never occurred on a fresh Windows installation before.

What I could also imagine is that certain characters are being filtered out during the password entry process, and it's possible that the implementations on the website and the program are different.
However, this can be easily verified by having the shop send you a new password.

And a popular option: The email address is used as the login, but capitalization is taken into account!
[email protected] is not the same as [email protected], even though both email addresses may lead to the same email account.

Best regards, Rainer.

Dear Rainer,

Thank you for the information! Since I can also rule out the tail comparison, it's quite possible that my password is the issue, and it might be of a more complex nature.
I'd be happy to try that out and will get back to you about it.

Best regards,
Markus.

Dear Rainer,

Password cleaned of special characters and it now works perfectly!
Thank you very much for the information!
Could it be possible to support more complex passwords in a future version, or to make the character set that can be used for passwords publicly available?

Best regards,
Markus.

Fenix_ARE-C2 wrote:

Dear Rainer, Password cleaned of special characters and it now works perfectly! Thank you very much for the information! Could it be possible to support more complex passwords in a future version, or to make the character set that can be used for passwords publicly available? Best regards, Markus

Hi Markus, great feedback! May I ask which special characters were involved? Yes, I need to take a look at the code and synchronize it. The goal is to ensure that only the allowed characters can be entered, and that the user is also aware of which characters these are.

After code review, all characters are accepted as passwords on the server. The same applies to the Windows client. The maximum password length is 32 characters.
The website can handle UTF-8 encoding, but the Windows control only understands ASCII. This might be the problem.

Best regards, Rainer.

Dear Rainer,
In this specific case, it was just a ".", which now surprises me, considering your response.
I usually have passwords generated by a password manager, which generally works well.
I always enjoy being able to contribute and learn something.

Best regards,
Markus.

Hello,

Should the length of the password also not exceed 32 characters?

Best regards, Rainer.

Dear Rainer,

The password was even less than 20 characters long. It included numbers, uppercase and lowercase letters, and a period. The same password without the period (which was the third character) works perfectly fine.

Best regards,
Markus.