Re: [Hamlib-developer] Icom 91a

[Martin E. - A. <aa...@ew...>]

Ekki,

You have a great website - it has been very useful to me!  I should just 
check who I am emailing to more carefully! ;-)

Why would Icom use encryption?  Maybe they don't want you to screw up 
their internal registers?  The results are puzzling.  I agree that with 
enough work, you should be able to 'crack' the code, since you know the 
underlying data - more or less.  If you are brave, you could try probing 
with your own data, but maybe you will end up with an Icom brick.

[I was looking at the IC-91A manual - it says it accepts data from your 
GPS receiver on the same serial port.  What is up with that?]

Do you know about other VHF rigs?  I have an IC-208H which has a similar 
dump/restore situation.  I was thinking of checking that when I had 
nothing more important to do. :-)

Good luck.

73 Martin AA6E

Ekki Plicht (DF4OR) wrote:
> On Monday 01 October 2007, you wrote:
>> Interesting.  I heard from somewhere that the commands were probably
>> CI-V formatted.  
> 
> They are. They start with $FE $FE, adress etc., end in $FD, just like normal 
> CI-V. But in between it's pretty weird.
> 
> All these handhelds are not controllable like we are used from usual Icom 
> rigs, (you cannot just set the VFO or program one memory), but allow only for 
> a complete dump of all memories, VFOs etc.
> 
> [...]
> 
>> If what you want is to be able to change simple things like VFO
>> frequency, the rig might respond to the low-numbered Icom CI-V commands
>> that are more-or-less universal across their product line.  Check out
>> the info at http://www.plicht.de/ekki/civ/index.html, for example.
> 
> Well, that's my site, thanks :-)
> I consider myself somewhat knowledgable about Icom CI-V protocol, still I 
> couldn't make heads nor tails of that memory dump.
> 
> I started out really simple - I resetted the E91 (T91 in the US), than made a 
> dump. Then I programmed one memory, tuned the VFO back to the frequency which 
> is in the VFO after reset and made another dump. So only one memory should be 
> different.
> 
> Surprisingly two lines in the dump changed.
> Then I changed the memory contents again by just 25khZ, dumped again. Again 
> two lines were different. One line was the same as before, the second 
> different line was somewhere else. Another change by 25kHz did not yield a 
> consistent result, again a different line changed. And so on...
> 
> This reminds me of the standard crypto procedure of a polyalhabetic 
> encryption - same letters result in different codes. I am certaint hat this 
> is breakable, but I didnÄt spend enough effort on it. At least Icom made it a 
> little bit more difficult than with CI-V rigs.
> 
> A comparision with the E90 (T90) showed that the dumps are somewhat similiar, 
> but not identical. A change of the same memory contests resulted in different 
> lines changing between the two radios.
> 
> 
> If someone is interested and more knowledgeable in crypto work (deciphering) I 
> would love to work together to get that cracked. In contrast to someone who 
> already cracked the algorithm and sells a commercial program based on that, I 
> would be only interested in that work if the result is made public.
> 
> 73,
> Ekki, DF4OR
> 
> 
> 
>> Ekki Plicht (DF4OR) wrote:
>>> On Sunday 30 September 2007, mike wrote:
>>>> I recently purchased an Icom handheld that uses icoms own software
>>>> called RS91.  I would prefer to use multitude of programs that can
>>>> utilize your hamlib.
>>>>
>>>> I was wondering if there was someway for me to capture serial traffic in
>>>> a way that would allow you to look at the results and add them to your
>>>> project?
>>> Yes. Just connect it with a serial converter to your computer and hit the
>>> buttons which initiate a clone dump. That's what I did here to analyze
>>> the data traffic of this (and other) Icom handheld (using Gentoo Linux).
>>>
>>> And you know what - I gave up after some evenings. The contents is not
>>> exactly encrypted, but scrambled quite extensively. I was not able to
>>> figure out the scheme behind it, although I know that others did. Maybe
>>> someone with a better crypto background will be able to crack that
>>> system.
>>>
>>> 73,
>>> Ekki, DF4OR
>>>
>>> -------------------------------------------------------------------------
>>> This SF.net email is sponsored by: Microsoft
>>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>> _______________________________________________
>>> Hamlib-developer mailing list
>>> Ham...@li...
>>> https://lists.sourceforge.net/lists/listinfo/hamlib-developer
>