# ICOM Emulator Mysteries



## tinkerman (Mar 11, 2013)

The ICOM Emulator has left me with many unanswered questions. Some are:

1. How does the dongle security scheme work exactly?
Note: There is the ‘dongle-required’ version and a ‘dongle-free’(dongle-NOT required) version.

2. What is the role of Java within the ICOM Emulator?

3. What is ifhsrv32.exe(interface handler) doing exactly?
Is it ‘connecting’ ISID and EDIABAS that is installed within the ICOM Emulator VM? Or is it connecting to the host system?

4. Why is the ‘ecu’ folder within the EDIABAS installation in the ICOM Emulator VM practically empty (1-several files only)?
Note: My regular EDIABAS (7.3) installed in the host system has accumulated over 1,900 files.

5. Why does the ICOM Emulator make the system get so hot?
Even with the ISID VM NOT running, I noticed that when the ICOM Emu is activated, the system’s cooling fan rpm goes into full rpm, and the dongle gets really hot too.

Any ideas?


----------



## miotoo (May 23, 2012)

I have bought both an emulator & a clone and they are a world apart in reliability & speed.

If you have series intent in using ISTA/D or ISTA/P hooked up to a car, you should not waste your time with the ICOM emulator and instead spend a couple hundred bucks on a good ICOM clone.

Relating to your questions:

1. The original emulator included a security dongle due to it's tendency to be shared. The dongle-free version is a hack of the original that people are 're-distributing' on ebay. It is sold as VM snapshot in a suspended state - post checking for the dongle. If you shut down the machine, it will look for the dongle and not work. People are buying it as a 'unique' copy for them but it is in no way so.

2. Don't know, should ask the developer.
3. Don't know, should ask the developer.

4. It is my observation that the ICOM emulator - at least the one I have tried using, felt like a good hack at best. In no way it mirrors the full data exchange happening between the VM and a hardware device. Spending some minutes reviewing the log reveals a multitude of erroneous parameters being passed.

5. My guess would be sub-optimal coding, with a magnitude of unnecessary data exchange.

Here is a small performance comparison from my experience:

Running a full-car test in ISTA/D took just over a minute with the hardware ICOM vs. over 4 minutes with the emulator.

It is my personal experience, others may have different results.



tinkerman said:


> The ICOM Emulator has left me with many unanswered questions. Some are:
> 
> 1. How does the dongle security scheme work exactly?
> Note: There is the ***8216;dongle-required***8217; version and a ***8216;dongle-free***8217;(dongle-NOT required) version.
> ...


----------



## Tuesday (May 10, 2012)

That's a pretty solid review miotoo - you have me sold on clone vs. emulator.

Thanks for posting your experience, it mirrors my speculations.


----------



## tinkerman (Mar 11, 2013)

miotoo said:


> If you have series intent in using ISTA/D or ISTA/P hooked up to a car, you should not waste your time with the ICOM emulator and instead spend a couple hundred bucks on a good ICOM clone.


I fully agree with you. At the moment I am just trying to learn the pros and cons of ISID(ISTA-D/P). Since it will take some time, I am holding off on hardware/software purchases since it seems that they keep getting updated.



miotoo said:


> The dongle-free version is a hack of the original that people are 're-distributing' on ebay. It is sold as VM snapshot in a suspended state - post checking for the dongle. If you shut down the machine, it will look for the dongle and not work.


When you mention that, ***8220;If you shut down the machine, it will look for the dongle and not work***8221;, do you mean that if the ICOM Emulator***8217;s VM is shut down, that ISID will not work? Or do you mean that if ***8216;ICOM***8217;(emulation software in the guest OS) snap shot is ***8216;Quit***8217;(deactivated), the ICOM emulator will seek the dongle as normal? 
I had a feeling that the ***8216;dongle-free***8217; version utilizes the ***8216;snap shot***8217; method in VMware, and am trying to figure out how the snap shot is (seemingly) ***8216;automatically triggered***8217; when the VM is started. The only lead I***8217;ve got at the moment is a function in VMware Workstation that sets a VM to close(shut down) by reverting to a snap shot, but I***8217;m not sure if this is how it is actually done in the ***8216;dongle-free***8217; version.

I fully agree that a software emulation of hardware/firmware is NOT as good as the real thing. For general diagnostic reference though, the emulator seems to suffice at the moment. If I need to do serious diagnostic trouble-shooting, coding or programming, I***8217;d likely use INPA, NCS Expert, Tool32, WinKFPT.

I***8217;d like to understand how the emulator works, at least its core/critical functions, so I can make a hybrid emulator between the older dongle-free version(2011) and the newer 3.0.3 version(dongle-required), into a ***8216;dongle-free 3.0.3***8217; version while reducing the unnecessary default guest OS files and non-essential references in general(like 'DOKU' references in BMW software).

Thanks for your input! Cheers.


----------



## miotoo (May 23, 2012)

tinkerman said:


> When you mention that, "If you shut down the machine, it will look for the dongle and not work", do you mean that if the ICOM Emulator's VM is shut down, that ISID will not work? Or do you mean that if 'ICOM'(emulation software in the guest OS) snap shot is 'Quit'(deactivated), the ICOM emulator will seek the dongle as normal?


In the version I'm familiar with, the dongle is being accessed on startup of the emulator runtime. I never bothered tinkering with which library exactly. Once it passes the control, the application starts. From this point onwards, the dongle is not in use any more, it can be removed from the machine. If you create a VM snapshot at this point, you can always revert to it and use the emulator without the dongle.

So, if you shut down the machine completely, then at next startup the dongle will be looked for again. But even if that happens, you can always revert to the snapshot taken which I referred to as a 'post dongle' snapshot.

The dongle-free 3.0.3 is the same thing. It is not originally dongle-free. Someone (or more) bought it, created the snapshot and started selling as a dongle-free version.

There is no 'automatic triggering' or anything. It's quite simply done.

I think what you are seeing as 'guest OS file access and non-essential references in general' may be either poor attempts to enhance the importance of the dongle without real merit for the runtime protocol functionality, or additional requirement of the later ICOM firmware code albeit poorly emulated.

Don't get me wrong - I do believe the original effort to build an ICOM emulator should be applauded. However, if those working on it would be busy optimizing it instead of desperately having to compete with hackers on market share, the community would have better solutions.


----------



## tinkerman (Mar 11, 2013)

I see what you mean. I have both versions the 'dongle-required' version (v3.0.3 publicly shared by someone that goes by 'Gini' online), and a 'dongle-free' version provided by an acquaintance online. 

The 'dongle-required' version 3.0.3 is from around mid 2012. It was provided with snap shots of 'post dongle check' state by Gini, and to run it without a dongle, the snap shot must be manually 'run' after the VM has started up. If the 'snap shot' is not used, then running the 'ICOM' program will seek out a dongle.

The 'dongle-free' version (not sure of actual version number) is from around mid 2011, so it's an older version. This version seems to incorporate the 'post dongle check' state 'automatically'. In other words, there is no need to select a snap shot after starting up the VM. The VM itself starts up in a 'state' that does not require a dongle. Upon close observation of the contents of the VM related files, there are a couple of snap shot related files each just under about 200MB. I have a feeling that these are being referenced at runtime instead of requiring manual selection after the regular VM starts. Hence, to the user it seems like there is no need for a dongle. At least this is my 'gut feeling' about how this version operates, but I'm trying to see if anyone nimble in programming or VMware has already figured it out.

The non-essential files I referred to are not files laid out on a platter say on the desktop. These I've found by digging into multiple layers of folders after mounting the virtual disk in VMware Workstation. Pardon me for misleading you into thinking that I was referring to 'add-ons' by '2nd-hand marketers'. No, I'm referring to the original default files that got loaded as part of the virtual machine setup by the original programmer 'Darksys' if I'm correct.

I think that 'Darksys' is busy optimizing the emulator, especially because of all the security bypasses recently publicized, but I'm told that the reason all the bypasses have occurred in the first place is because 'Darksys' has kept on charging customers for 'updates' (as you may have experienced?).


----------

