[dddr100t]

Hi to all the Experts on the Forum!


I've been struggling the last 2 days on a problems getting my Xentry and DAS to work properly. They were working fine, but I must have changed something which broke the license. Generating a new license for Xentry through the Xentry Developer Tool is NOT fixing the issue.

It looks like there is some kind of confusion around the hardware ID of the system (see the attached screenshots). EPC recognises the correct hardware ID, but the StartKey Center and Xentry do not.


I've run filesystem and registry searches to see where the hardware ID is coming from, but I cannot find anything. I suspect that possibly one of the .jar files is generating it when you start StartKeyCenter.exe?

The only solid reference I have been able to find is in the SKC.properties & hwid.properties files (see StartKey_Center_4.JPG & StartKey_Center_5.JPG). Changing the hwid.properties file has no effect. It is overwritten by the StartKeyCenter.exe when it starts. So SKC is getting the info from somewhere. I just don't know where!!

Any ideas how I can fix this?


Thank you!

[dddr100t]

For closure, I think I may have tracked down where the Hardware ID is coming from, and why this problem was happening. I don't have a solution for this, but at least I know what is causing the issue. 

I bought a SDConnect C4 in a C5 case with a laptop and a SSD from Aliexpress. When I run the SSD in the Laptop, everything works fine, and the license for Xentry works. However, the SSD is too small, and I want to use this laptop for more than one diagnostic software, so I wanted to virtualise the Xentry SSD. I did this successfully with VMware Converter. 

The VM starts fine, but it encounters the license issues I mentioned in the first post. And so far I've been unable to resolve them. Luckily I still have the original SSD, so I can still use Xentry, but its a bit of a pain in the a*se to have to swap SSD's every time I want to use Xentry.

So, after some more digging and a couple of hours more time burned:

It looks like the hardware ID is encoded in the license.key file, in the Xentry 'bin' directory. (See screenshot license_2.jpg). 

Additionally, it looks like CSHPSK32.dll is responsible for reading out the hardware ID from the license.key file. See the second screenshot license_1.jpg. I found this info in the ConfigAssist.log

I'll do some more digging to see if there's a chance of figuring out what this license encoding algorithm is. Maybe it can be reverse engineered.

[mbAlan]

I'm in a similar spot. EPC works fine since it is based on MAC address and you can set this in VM NIC properties. However, XENTRY hardware ID is an issue. Here's what I'm going to try next on original laptop: Run this from command prompt: wmic csproduct get "UUID". Then modify VM UUIDs based on https://superuser.com/questions/472951/m...ation-afte

[W123]

The UUID on a physical machine is written into the BIOS/UEFI of that machine. This number is static and normally does not change, but it can be changed (i.e. if you have to exchange your motherboard due to a hardware defect, you can write your original UUID back to the replacement board). The HW ID depending on the algorithm used, probably comes from many different values of various components in the system.

The junk you are seeing on your computer with the HW ID that is completely different than what StartKey Center is showing referencing "peguard" is the Chinese protection crap where they are selling someone else's intellectual property as their own and even have the guts to install a silly "protection" on it. It it were mine, I would clean that SSD and reinstall the system to get the Chinese junk off of it.

[Glintweb]

send me your tvi will Unlocked for you