Talking to the MediaTek preloader - Android Q&A, Help & Troubleshooting

I have been doing some work, trying to figure out how to talk to the MediaTek preloader on a couple of different devices. I believe it has more functionality than what is available to us through SP-Flashtool. I came across an interesting article here. The preloader seems to accept some combination of commands via raw serial bytes and AT commands to do its work. In an attempt to reverse engineer the protocol, I have attempted to set up Wireshark to capture the usb traffic between my system and the preloader while using SP-flashtool, but I have been unsuccessful. I'm able to capture all sort of adb traffic, so I think my usb sniffing setup is working, but it's as if Wireshark just doesn't see the connection to the preloader or any of the SP-flashtool traffic.
With some python script, I have been able to at least attempt to send commands to the preloader, but I just keep getting a response along the lines of "device reports it is ready to read but sent no reply."
From the article I linked: The USB port will assume that the tool is connected if it receives a “set line coding” (configures baudrate etc.) CDC message. It then sends the string READY to the tool and waits for the reception of a token of eight bytes.
Has anyone ever been able to work out how to send this "set line coding" message? Or does anyone out there have any insight about how to configure Wireshark to capture this communication with the preloader so this protocol might be reverse engineered?

threadreaper said:
I have been doing some work, trying to figure out how to talk to the MediaTek preloader on a couple of different devices. I believe it has more functionality than what is available to us through SP-Flashtool. I came across an interesting article here. The preloader seems to accept some combination of commands via raw serial bytes and AT commands to do its work. In an attempt to reverse engineer the protocol, I have attempted to set up Wireshark to capture the usb traffic between my system and the preloader while using SP-flashtool, but I have been unsuccessful. I'm able to capture all sort of adb traffic, so I think my usb sniffing setup is working, but it's as if Wireshark just doesn't see the connection to the preloader or any of the SP-flashtool traffic.
With some python script, I have been able to at least attempt to send commands to the preloader, but I just keep getting a response along the lines of "device reports it is ready to read but sent no reply."
From the article I linked: The USB port will assume that the tool is connected if it receives a “set line coding” (configures baudrate etc.) CDC message. It then sends the string READY to the tool and waits for the reception of a token of eight bytes.
Has anyone ever been able to work out how to send this "set line coding" message? Or does anyone out there have any insight about how to configure Wireshark to capture this communication with the preloader so this protocol might be reverse engineered?
Click to expand...
Click to collapse
Hello ive been trying to learn this im using libusdotnet for talking with the device

Related

usb serial in diagnostic

Hi I have just noticed in the nokia diagnostic tool in the bottom right the three dots when pressed gives you settings option and within that option it says usb mode Zune or usb serial with an option to choose which one ... What's this serial in this case ?? Will this allow direct access to hdd and find a way to use as mass storage ? or can we use this to access the cpu or other parts of the phone ?? im not sure were the serial point to yet ...
Probably that would be the way to flash rom.
It seems to be used for reparing the device or OS level software debugging - it won't give you USB Mass storage device....Or it maybe if you found the right driver...from Nokia Engineer. On HTC phones, this can be used for tethering with the right driver.
Serial Ports are the port that were used for Modem and Mouse before USB was invented (COM ports) It is the very basic form of communication port that most device implements - which the chipset on Lumia also emulate Serial Port over USB cable. (http://en.wikipedia.org/wiki/Serial_port)
Ahhhh ok thanks very much guys
Didn‘t notice that before, I'll poke at it using a serial debugger once I get home, could be some interesting/fun stuff that can be done
In winxp you can load a driver for a system device. maybe at driver level the connection data can be verified. How:
connect in serial mode. it will at first time detect a nokia rm801 or whatever device and ask for a driver. it finds 4 devices.
for the first, the xp system will itself suggest
1) USB Composite Device
2) will not find anything, and show the dialog to go onto internet, search etc.
Don't search and choose the driver to install yourself, with the downmost radiobutton and click next, in the categories go to System Devices, the driver assist will suggest a Compaq Deskpro Thermal Sensor, install this. Will install without error
3) see 2.
4) see 2.
Because it installs a temperature sensor driver, it must be possible to monitor or probe somehow. help?
My guess that will only gain you access to temprature data from the phone.
Have you tried putty and a baudrate of 9600? this is the most common used baudrate, tho It is quite possible they use 16000 instead if the serial connection is ment to handle data transfer.
I've been looking at the schematics for the phone and I can not seem to find out which chip they have used for GPIO. We would probably need to get hold of service level 3 or 4 manuals for Nokia Care (unless someone wants to dissasemble their phone and have a look at the mainboard)
Edit:
After a bit more digging I think I've traced serial to be managed directly by the CPU.
This suggests that it's a purely SW serial console.
I haven't been able to find any details on WP7/7.1/7.5 SW serial.
Worth looking into but I guess would require disassembly of the software?
what is the protocol for example when doing a software update through Zune? It gets into some kind of bootloader mode then too.
can imagine the serial connection is hosted as sw in the phones sw environment when running the mango os. But is the serial mode still fully sw if you boot it? Don't know if you could find anything in the 15 sec of booting to mango
I think the easiest way of figuring out how this is done is to disassemble the .net library that is used in the WP7 update tool.
I will have access to the required tools when I get home. The tool is this one if you want to get cracking on it:
http://xboxmod.sylvester20007.com/TOOLS/WP7_update_tool.rar

How to communicate with Android from a PC ?

Hi,
I want to write a program ,which will communicate to the available android mobile device via wi-fi .(Note :I do not want to use the USB cable)
That moblile device is having an IP in it by a wi-fi connection with it.The major thing is that i pinged that IP and I am getting connection packets getting back to my pc,means I can communicate with the devices. so can I able to get the details of the device.
details means
1.its name what user sets on it.
2.some address like mac in computers.
3.model name.
4.type of os in it.
etc
I really find this interesting but,no idea how to do but i got something like ARP protocol for getting the mac address but I do not know how to communicate with a phone with this ARP protocol.
Can we communicate by the SSH as it a linux kernel based OS .Kindly give me a way how to get these information.
can any one have some idea ,kindly tell me,it is very important for my project.
Thanks

Qualcomm Diag Mode without USB connection to PC

Hello guys,
I am curious, what the /dev/diag device can be used for. Does anyone know its purpose? Regarding the Kconfig of /drivers/char/diag, this virtual device is an interface for exchanging diag data. However, performing a cat on that device file, resulted in an error:
Code:
cat: /dev/diag: Bad address
Echo-ing the 4-byte-version-query into the diag-device did not result in an error. But nothing else happened, either.
I would like to be able to access the baseband's diag data without having a computer attached to the phone's USB port - and, if even possible, without even modifying the kernel.
Regards

[Q] Unsolvable ADB error Windows 7

I have looked everywhere, spent countless hours and days trying to find a PERMANENT solution for this. Only solution i could find was to use TaskManager and kill adb process. Not a permanent solution. As the same error will come back.
This is the error. Nothing causes it, just happens randomly with any device im using.
Code:
* daemon not running. starting it now on port 5037 *
ADB server didn't ACK
* failed to start daemon *
error: cannot connect to daemon
Thanks guys. A permanent solution would be awesome. I'm tired of this..
elesbb said:
This is the error. Nothing causes it, just happens randomly with any device im using.
Code:
* daemon not running. starting it now on port 5037 *
ADB server didn't ACK
* failed to start daemon *
error: cannot connect to daemon
A permanent solution would be awesome. I'm tired of this..
Click to expand...
Click to collapse
First, the obvious: have you tried different USB cables and different USB ports on your machine? (I'll assume the answer is "yes").
Now, the more likely: get a copy of USBDeview and use it to remove all copies of your ADB USB drivers. In case you're not familiar with it, this util will list every USB driver installed on your machine and (among other things) will let you delete the ones you don't want. If you've been using your current setup for a while, you'll be appalled at the cruft that's built up. Be aware that there are separate 32 and 64-bit versions, so get the one appropriate for your system.
The ADB driver(s) may be identified as "Android ADB Interface" or any of several other names. You'll see entries for various USB Vendor and Product IDs, with at least one entry for each Android device you've connected. The one thing all of the relevant entries will have in common are the values in the columns labeled USB Class, USB Subclass, and USB Protocol. Those values are ff, 42, and 01, respectively.
Sort the list by Class to group them, then uninstall all of them. When you're done, reboot. You may want to reopen the util to confirm they're really gone. Finally, attach each device in turn and let the New Hardware Wizard walk you through reinstalling the driver (which means, of course, that you'll want to have your driver packages ready before you go deleting anything).
Note: there's really only one driver (i.e. binary) for all devices. The difference in the packages is their .INF files, each of which usually only identifies Vendor and Product IDs for a single manufacturer. If you know those values for each device, you can edit the .INF file for one and add all your devices to make a one-size-fits all package (be sure to add each entry under both the 32-bit and 64-bit headings in the file). You'll still have to reinstall for each device but you won't need multiple packages to do it.
adb kill-server
adb start-server
Should get you back on track.
es0tericcha0s said:
adb kill-server
adb start-server
Should get you back on track.
Click to expand...
Click to collapse
No.. you're wrong.
dolorespark said:
First, the obvious: have you tried different USB cables and different USB ports on your machine? (I'll assume the answer is "yes").
Now, the more likely: get a copy of USBDeview and use it to remove all copies of your ADB USB drivers. In case you're not familiar with it, this util will list every USB driver installed on your machine and (among other things) will let you delete the ones you don't want. If you've been using your current setup for a while, you'll be appalled at the cruft that's built up. Be aware that there are separate 32 and 64-bit versions, so get the one appropriate for your system.
The ADB driver(s) may be identified as "Android ADB Interface" or any of several other names. You'll see entries for various USB Vendor and Product IDs, with at least one entry for each Android device you've connected. The one thing all of the relevant entries will have in common are the values in the columns labeled USB Class, USB Subclass, and USB Protocol. Those values are ff, 42, and 01, respectively.
Sort the list by Class to group them, then uninstall all of them. When you're done, reboot. You may want to reopen the util to confirm they're really gone. Finally, attach each device in turn and let the New Hardware Wizard walk you through reinstalling the driver (which means, of course, that you'll want to have your driver packages ready before you go deleting anything).
Note: there's really only one driver (i.e. binary) for all devices. The difference in the packages is their .INF files, each of which usually only identifies Vendor and Product IDs for a single manufacturer. If you know those values for each device, you can edit the .INF file for one and add all your devices to make a one-size-fits all package (be sure to add each entry under both the 32-bit and 64-bit headings in the file). You'll still have to reinstall for each device but you won't need multiple packages to do it.
Click to expand...
Click to collapse
I thank you a million! This looks promising! I did notice like 20 different adb devices installed. So far it's been good hopefully it stays that way!
Sent from my SGH-M919 using Tapatalk
Yea, sorry, that is the temp solution, not a permanent one.
es0tericcha0s said:
Yea, sorry, that is the temp solution, not a permanent one.
Click to expand...
Click to collapse
Not only that, but it's not even a temp solution. How can I or anyone kill a server you can't connect to?
Sent from my SGH-M919 using Tapatalk
elesbb said:
Not only that, but it's not even a temp solution. How can I or anyone kill a server you can't connect to?
Sent from my SGH-M919 using Tapatalk
Click to expand...
Click to collapse
Oh. I see you don't understand the commands. You said that you had to continue to go to the Task Manager to kill the process and then you would restart it. That's what those commands do, without taking that step. I've solved this issue before with doing that, though it's never been an ongoing thing, so haven't had to deal with making it permanent. Guess we have a different idea of what wrong is...
es0tericcha0s said:
Oh. I see you don't understand the commands. You said that you had to continue to go to the Task Manager to kill the process and then you would restart it. That's what those commands do, without taking that step. I've solved this issue before with doing that, though it's never been an ongoing thing, so haven't had to deal with making it permanent. Guess we have a different idea of what wrong is...
Click to expand...
Click to collapse
What I'm saying is, running adb kill server wouldn't do anything because it can't connect to the adb server daemon due to that error I was receiving. After running adb kill server then running adb start server I would still get that same exact error. Which makes sense because it can't connect to the server so therefore is unable to kill it making task manager the only way of killing the server.
Sent from my SGH-M919 using Tapatalk
elesbb said:
What I'm saying is, running adb kill server wouldn't do anything because it can't connect to the adb server daemon due to that error I was receiving. After running adb kill server then running adb start server I would still get that same exact error. Which makes sense because it can't connect to the server so therefore is unable to kill it making task manager the only way of killing the server.
Sent from my SGH-M919 using Tapatalk
Click to expand...
Click to collapse
What I'm saying is that command is specifically for that issue, because the adb server is not starting correctly because it's kind of stuck. If the server wasn't on at all, it wouldn't be listed in the Task Manager, right? I've had this issue multiple times before on various devices, and that's what got it to come back on and connect again. I literally do this stuff for a living and have modded 100s of devices. Weird things pop up like this all the time and it's not always the same solution for everyone or every device.
start-server Checks whether the adb server process is running and starts it, if not.
kill-server Terminates the adb server process (which the Task Manager also does, but this is the command for it)
So yea, my solution didn't work for you, but it is a solution for this issue. Been there. Done that. Probably will have to do it again some day.
es0tericcha0s said:
What I'm saying is that command is specifically for that issue, because the adb server is not starting correctly because it's kind of stuck. If the server wasn't on at all, it wouldn't be listed in the Task Manager, right? I've had this issue multiple times before on various devices, and that's what got it to come back on and connect again. I literally do this stuff for a living and have modded 100s of devices. Weird things pop up like this all the time and it's not always the same solution for everyone or every device.
start-server Checks whether the adb server process is running and starts it, if not.
kill-server Terminates the adb server process (which the Task Manager also does, but this is the command for it)
So yea, my solution didn't work for you, but it is a solution for this issue. Been there. Done that. Probably will have to do it again some day.
Click to expand...
Click to collapse
I understand that this solution may work for a temporary issue. I myself us it all the time when I can't see a device or something. But what im trying to say is the error says "server didn't ACK" in my searching of this error, ACK means acknowledge. Therefore communication with the server fails. So sending the server a kill command fails as well. See what i mean?
Lets just hope the other guys method works. Was surprised to see about 12 or so ADB devices when i only have 3

[Serial Port API] - Connection can not be opened

Hello,
I am writing here to see if somebody faced this problem before. I am trying to control a very specific Hardware from an Android device using the android-serialport-api lib: code.google.com/archive/p/android-serialport-api/
My hardware uses a RS232 connector and I connect it to Android with a USB to RS232 adapter, just as it shows on the "solution 2" of this image: code.google.com/archive/p/android-serialport-api/wikis/android_to_rs232_guideline.wiki (Solution 4 seems to be the ideal one, but I do not understand it, I will appreciate any indication here as well)
When I try to open a connection to the port, I always get an error indicating the the connection can not be open. The problem with this approach is, as the wiki mentions, you "may need to root your device in order to change /dev/ttyUSB0 file permission, and to load a kernel module.".
Does anybody had to root their device in order to be able to open tty connections? The tablet I am using is a HANNSpree HSG1351 (which I could not find any rooting guide).
Thanks
I will answer myself here just in case it can be useful for someone else in the future:
I ended up using this serial controller for Android, which makes read / write operations easy: github.com/felHR85/UsbSerial
Before being able to open a serial connection with the device, you should give permissions to the USB as it is explained here: developer.android.com/guide/topics/connectivity/usb/accessory.html#permission-a
Just to clarify, this is generic for any device, doesn't matter if it is rooted or not.

Categories

Resources