[BitPim-devel] Detecting if a Sanyo phone is refurbished.

[p***@nashclan.net]

I'm in the process of writing an application that gets specific pieces
of information from a Sanyo cellphone (various models) using a USB
serial port. I've used Bitpim and a port sniffer to figure out how to
get the ESN, GMM, PRL, Software version and MDN (phone number). The
only thing that I still need is the "Recondit" value. I know that I
can key in ##786# and the phone will display "Recondit=Yes" or
"Recondit=No". I need to get that value over the serial port. I've
read through the bitpim source-code, and sniffed packets enough to
figure out how to pull files off the filesystem. My problem is
figuring out where this flag might be stored in the phone's filesystem
-- and I'm praying that its consistent across models. I've tried
googling this, but there doesn't seem to be anyone else interested in
finding this information.

Does anyone have a good suggestion for how to do this? Is there an
AT-command that might pull the value? Is it in a known place in the
phone's filesystem?

If this post is off-topic, I apologize. And, I would appreciate someone
pointing me to a forum where it would be more on-topic.


Thanks!
Chris Nash

[Stephen Wood]

Post by p***@nashclan.net
Does anyone have a good suggestion for how to do this? Is there an
AT-command that might pull the value? Is it in a known place in the
phone's filesystem?

You might check out the responses to the "firmwarerequest" and
"sanyofirmwarerequest" packets. There are some unknown fields in the
responses to those that might have the reconditioned status information you
are looking for. You'll just have try phones that are both reconditioned
and not and compare the packet responses.

Stephen

[p***@nashclan.net]

Date: Wed, December 27, 2006 2:28 pm
You might check out the responses to the "firmwarerequest" and "sanyofirmwarerequest" packets. There are
some unknown fields in the responses to those that might have the reconditioned status information you are
looking for. You'll just have try phones that are both reconditioned and not and compare the packet
responses.

Thanks for the tip, Stephen. I'll let you know if it works out. At
this point, I haven't been able to get any two phones to behave
consistently.

I'm able to send the firmwarerequest (0x00) to some phones, and the
sanyofirmwarerequest (0xFA, 0x00, 0x00) to other phones, and get their
respective packets. I have still other models (like the SCP-2400) that
won't seem to accept either command. It looks like I'm going to need to
work up and maintain a model-map so I know how to query each phone --
unless I come up with something clever.

Once I've figured out how to talk consistently to each of my models,
I'll see if I can't turn around and help add bitpim support for any of
them that arent supported yet. That'll be a worthy challenge, as
Python is completely alien to me.

--Chris

[Stephen Wood]

The SCP-2400 ought to response do 0xfa,0,0. See below for a packet log
from someone helping to add SCP-2400 support. Did you use your own code to
send these packets? If so, did you put the phone in diagnostic mode first?

What Sanyo phones do you have access to? If you have BitPim running from
source, we should be able to add at least some of them rather quickly.

Stephen

14:43:16.203 MM-7500: sendbrewcommand Data - 3 bytes
<#! phones.p_sanyo3100.sanyofirmwarerequest !#>
00000000 fa 00 00 ...

14:43:16.219 MM-7500: brew response Data - 114 bytes
<#! phones.p_sanyo3100.sanyofirmwareresponse !#>
00000000 fa 00 00 4d 61 79 20 31 32 20 32 30 30 36 32 30 ...May 12
200620
00000010 3a 32 32 3a 31 30 53 65 70 20 30 37 20 32 30 30 :22:10Sep 07
200
00000020 34 30 39 3a 30 30 3a 30 30 53 43 50 2d 32 34 30
409:00:00SCP-240
00000030 30 00 53 65 70 20 30 37 20 32 30 30 34 00 30 39 0.Sep 07
2004.09
00000040 3a 30 30 3a 30 30 00 43 6f 6a 06 81 e7 01 00 f0 :00:00.Coj.....
.
00000050 58 31 2e 30 30 31 53 50 20 20 20 30 30 32 33 2d X1.001SP
0023-
00000060 2d 2d 53 43 50 2d 32 34 30 30 2f 55 53 20 20 20 --SCP-2400/US

00000070 20 20

Post by p***@nashclan.net
Thanks for the tip, Stephen. I'll let you know if it works out. At
this point, I haven't been able to get any two phones to behave
consistently.
I'm able to send the firmwarerequest (0x00) to some phones, and the
sanyofirmwarerequest (0xFA, 0x00, 0x00) to other phones, and get their
respective packets. I have still other models (like the SCP-2400) that
won't seem to accept either command. It looks like I'm going to need to
work up and maintain a model-map so I know how to query each phone --
unless I come up with something clever.
Once I've figured out how to talk consistently to each of my models,
I'll see if I can't turn around and help add bitpim support for any of
them that arent supported yet. That'll be a worthy challenge, as
Python is completely alien to me.

[p***@nashclan.net]

Did you use your own code to send these packets?

Yes.

If so, did you put the phone in diagnostic mode first?

I came into this fairly ignorant. It is my understanding that
"AT$QCDMG" puts it into diagnostic mode. If so, then yes.

What Sanyo phones do you have access to?

On my desk right now: 200, 2400, 3100, 4920, 5600, 6600, 7500, 8100,
8200 and 8300. I can probably get my hands on more.

Unfortunately, the 2400 is the only one with "Recondit=No", and I cant
seem to get the firmware request to work with it. I'll try some more
:)

[·· ħþø ··]

Post by p***@nashclan.net
Unfortunately, the 2400 is the only one with "Recondit=No", and I cant
seem to get the firmware request to work with it. I'll try some more

I have an 8200 that isn't reconditioned that you could test against if
you'd like. How exactly are you developing? Is there a way I could help
without installing too much software?


Chris

[Stephen Wood]

Post by p***@nashclan.net
Unfortunately, the 2400 is the only one with "Recondit=No", and I cant
seem to get the firmware request to work with it. I'll try some more
:)

Try running phone detect using the latest BitPim with the 2400 plugged in.
It won't detect the phone because SCP-2400 support isn't in BitPim yet, but
the firmware request responses should show up in the protocol log.

Stephen

[Mc Kiernan, Daniel Kian]

Post by p***@nashclan.net
On my desk right now: 200, 2400, 3100, 4920, 5600, 6600, 7500, 8100,
8200 and 8300. I can probably get my hands on more.

I have an RL-4930 with Recondit=No. I'll provide testing within reason.

[p***@nashclan.net]

I finally realized that the newer models create two COM ports when I
plug them in. One shows up as "Sanyo USB Phone" under Modems in the
Device Manager and it accepts the AT commands. The other is "SANYO
Serial Port" and shows up under "Ports" in the Device Manager. This
second port seems to respond to the brew-commands without needing to go
into diagnostic mode.

My install of BitPim doesn't seem to like the phones with the two ports.


ħ��, can you send me a firmware response packet from your 8200?

In answer to your questions, I'm working in C using Visual Studio. The
only extra thing that I've used is a GPLed Serial Port library that I
found at http://home.ict.nl/~ramklein/Projects/Serial.html. (Many
thanks to Ramon de Klein).

I'm attempting to write a very fast console app that pulls the ESN, PRL,
SW, MDN (phone number) and Recondition flags off whatever phone is
attached, and dumps them to a flat text-file. I can get the ESN, PRL
and SW using AT commands. And, thanks to you guys, I've figured out
how to find the same info using the brew firmware request. The MDN
seems to be at position 590 in the file nvm/nvm/nvm_0000 -- if you know
a more reliable way to get this, I'd love to know it. That leaves the
Reconditioned flag -- which is where I'm stuck.

--Chris Nash

[·· ħþø ··]

ħþø, can you send me a firmware response packet from your 8200?

Forgive my ignorance, but what exactly is involved in doing that?
Running 0.9.10-official I poked around a bit, but couldn't find a way
for BitPim to ask the phone for the firmware response packet. Phone
Detect apparently doesn't work with my phone/8200's, despite the log
saying it looked for a PM-8200.

[·· ħþø ··]

ħþø, can you send me a firmware response packet from your 8200?

Ha, I lie. Here's my Detect Phone string:

14:02:27.265 Detect Phone result: {'COM3': {'mode_modem': True,
'mode_brew': False, 'firmwareresponse': None, 'esn': '2D58F674',
'model': 'SCP-8200/US ', 'firmware_version': '1.007SP ,10033',
'manufacturer': 'SANYO Electric Co.,Ltd. '}}

[Roger Binns]

***@nashclan.net wrote:
| My install of BitPim doesn't seem to like the phones with the two ports.

Incidentally that is how LG phones have always behaved when connected
via a straight USB cable.

Roger

[p***@nashclan.net]

ħ��,
I was looking more for something like the hexidecimal stuff that Stephen
sent below.

Don't worry about it though. I have determined that the value I'm
looking for is not in this packet. I located two identical 3100s, one
was reconditioned and the other wasnt. Their firmware reponse packets
were identical.

So, I'm back to where I was a week ago. I have been unable to determine
(programmatically) if a phone is reconditioned or not. Whats more, my
method of determining the internal phone number (MDN) doesn't seem to
work all the time either. :o(

If anyone has any more suggestions, I'm all ears (..err eyes).

--Chris Nash

-------- Original Message --------
Subject: Re: [BitPim-devel] Detecting if a Sanyo phone is refurbished.
Date: Thu, December 28, 2006 11:28 pm
The SCP-2400 ought to response do 0xfa,0,0. See below for a packet log from someone helping to add SCP-2400 support. Did you use your own code to send these packets? If so, did you put the phone in diagnostic mode first?
What Sanyo phones do you have access to? If you have BitPim running from source, we should be able to add at least some of them rather quickly.
Stephen
14:43:16.203 MM-7500: sendbrewcommand Data - 3 bytes
<#! phones.p_sanyo3100.sanyofirmwarerequest !#>
00000000 fa 00 00 ...
14:43:16.219 MM-7500: brew response Data - 114 bytes
<#! phones.p_sanyo3100.sanyofirmwareresponse !#>
00000000 fa 00 00 4d 61 79 20 31 32 20 32 30 30 36 32 30 ...May 12 200620
00000010 3a 32 32 3a 31 30 53 65 70 20 30 37 20 32 30 30 :22:10Sep 07 200
00000020 34 30 39 3a 30 30 3a 30 30 53 43 50 2d 32 34 30 409:00:00SCP-240
00000030 30 00 53 65 70 20 30 37 20 32 30 30 34 00 30 39 0.Sep 07 2004.09
00000040 3a 30 30 3a 30 30 00 43 6f 6a 06 81 e7 01 00 f0 :00:00.Coj......
00000050 58 31 2e 30 30 31 53 50 20 20 20 30 30 32 33 2d X1.001SP 0023-
00000060 2d 2d 53 43 50 2d 32 34 30 30 2f 55 53 20 20 20 --SCP-2400/US
00000070 20 20
Thanks for the tip, Stephen. I'll let you know if it works out. At
this point, I haven't been able to get any two phones to behave
consistently.
I'm able to send the firmwarerequest (0x00) to some phones, and the
sanyofirmwarerequest (0xFA, 0x00, 0x00) to other phones, and get their
respective packets. I have still other models (like the SCP-2400) that
won't seem to accept either command. It looks like I'm going to need to
work up and maintain a model-map so I know how to query each phone --
unless I come up with something clever.
Once I've figured out how to talk consistently to each of my models,
I'll see if I can't turn around and help add bitpim support for any of
them that arent supported yet. That'll be a worthy challenge, as
Python is completely alien to me.
---------------------------------------------------------------------
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
---------------------------------------------------------------------
_______________________________________________
BitPim-devel mailing list
https://lists.sourceforge.net/lists/listinfo/bitpim-devel

[Stephen Wood]

Checkout the protocol document on http://qcplink.sourceforge.net/, an
inactive sourceforge project. The link to the protocol document seems not
to work, so use:

http://qcplink.cvs.sourceforge.net/qcplink/qcplink/PROTOCOL?view=log
You might try out all combinations of packets starting with 0x26, xx, yy.
For example, 0x26, 0x52, 00 gives the lock code. Others might have have
other things you are looking for.

For the SCP-2400 and other new phones, make sure you have the Sanyo driver
from Datapilot installed if you are using Windows.

Stephen

Post by p***@nashclan.net
...
If anyone has any more suggestions, I'm all ears (..err eyes).
--Chris Nash

[p***@nashclan.net]

Thanks for pointing me to the protocol document. At least I learned
that I needed to escape 7D and 7E if they appear in a packet.

I wrote a loop that queries the phone with {0x26, 0xXX, 0x00} where 0xXX
is the range from 0x00 to 0xFF. I piped the output to a file for each
of my 3100s (one refurb, one not). Now I'm poring over the diff of the
two files. So far I haven't found anything useful. I'm probably
talking about a 1-bit difference.

Anyway, thanks for the help. I'll let you know if I figure it out.

-------- Original Message --------
Subject: Re: [BitPim-devel] Detecting if a Sanyo phone is refurbished.
Date: Fri, December 29, 2006 6:58 pm
http://qcplink.cvs.sourceforge.net/qcplink/qcplink/PROTOCOL?view=log
You might try out all combinations of packets starting with 0x26, xx, yy. For example, 0x26, 0x52, 00 gives the lock code. Others might have have other things you are looking for.
For the SCP-2400 and other new phones, make sure you have the Sanyo driver from Datapilot installed if you are using Windows.
Stephen
If anyone has any more suggestions, I'm all ears (..err eyes).
--Chris Nash
---------------------------------------------------------------------
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
---------------------------------------------------------------------
_______________________________________________
BitPim-devel mailing list
https://lists.sourceforge.net/lists/listinfo/bitpim-devel

[Roger Binns]

Post by p***@nashclan.net
Thanks for pointing me to the protocol document. At least I learned
that I needed to escape 7D and 7E if they appear in a packet.

You should read up on how to do the checksumming which that is part of.
It is the same algorithm used in PPP, X.25 and a few other places.

Roger

[p***@nashclan.net]

In case there is anyone keeping up with my progress, I have successfully
determined how to get (and set) the reconditioned flag on a Sanyo unit
-- and probably others as well.

I used the "Get attribute" command (0x26), and the attribute ID was
0x0C1B (flipped for little-endian). This is debug output from my
little program:

Getting reconditioned flag.
Sending:

26 1B 0C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 66 02 7E
Reading...

26 1B 0C 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 69 CF 7E

Recon:YES


The fourth byte in the response is 0x01 if the unit is reconditioned,
and 0x00 if its not.

I've tested this on about 8 models. I'm crossing my fingers and hoping
it holds true for all of them.

Thanks for all the advice guys. Now its time for me to learn some
Python so I can return the favor.

--Chris Nash

[Stephen Wood]

Post by p***@nashclan.net
In case there is anyone keeping up with my progress, I have successfully
determined how to get (and set) the reconditioned flag on a Sanyo unit
-- and probably others as well.

Nice!
...

Post by p***@nashclan.net
Thanks for all the advice guys. Now its time for me to learn some
Python so I can return the favor.

One nice little project would be to implement to the "phoneinfo" method for
Sanyo phones, which I never got around to doing. Phone Info is a menu
option to display handset specific info like manufacturer, firmware
revision, etc, all the stuff you are an expert on! For the Sanyo's we could
display all the information you are retrieving. Have you also figured out
how to get the 4 digit lock code? 0x26, 0x52, 0x0 should get that.

Stephen