[question] SOMC flash device

[nailyk-fr]

Hi,

This is not really an issue with your tool, mostly a question. My device is a Sony (shame on me) shinano family. That shinano family doesn't seems to have a way to reach the 9008 mode. Instead, we got this: Bus 004 Device 009: ID 0fce:9dde Sony Ericsson Mobile Communications AB Looks proprietary but from the internet seems to be similar to 9008 mode. However that proprietary 9dde mode doesn't provide the needed uart access.

The only way where I can get an answer from the device is with s1 tool april 2016 version, using the flash button: We can notice that the tool mention:

Will use sahara protocol

There is no uart device connected.

Does a way exist to cheat/improve your code to make it discuss anyway with that device? Many thanks!

P.S.: I have another 'working' device (exact same model) and adb reboot edl bring that 9dde mode. P.S.2: on my bricked device 9dde mode is reached with 'testpoint'.

[ghassani]

Based on your screenshot, it looks like it is issuing Sahara command mode commands. You can tell because it reads out the Serial Number, HW ID, OEM PK Hash. These are definitely Sahara related commands. Now what mode in Sahara is it in, I do not know. It could be memory debug mode, it could be loader mode.

Vendors CAN change the VID/PID pair for the exposed devices in Sahara and probably any other exposed USB devices with the SoC. I know this because LG will sometimes put the memory debug sahara mode on their own VID/PID device but it is just in fact Sahara memory debug.

The tool should work with the device if it is truly in Sahara mode. However, Sahara mode can be very finicky if you are trying between tools because the way the start of sessions work by sending a hello from the device to your local machine and you responding back from there. So when you for instance try with one tool and try with another tool the session is probably already established or finished (or even transferred to a completely different protocol for EMMC recovery, such as Streaming DLOAD or Firehose) so any other tools made to work in a certain way will not work as intended. You can get by this problem by restarting the device on each attempt.

Have you tried my tool with a fresh EDL boot up, not using any other tools?

Can you sniff the USB traffic with the working tool and attach it to this issue so I can take a look at it?

[nailyk-fr]

Many thanks for your answer. I made a detailed thread on xda Like you said, I tried to 'fake' the driver and force qdload 9006 or qdload 9008 but doesn't worked at all. QFIL answer timeout. Yes I notice the fact a restart on every attempt is needed. I did not tried your tool because it rely on /dev/tty* which is not exposed by that device. I tried a wireshark capture but the result was almost not understandable for me. (Display filter: usb.device_address == 17) This capture is made from the debian host while windows guest was displaying the error on the screenshot. I find lot of doc about this but are sadly for 9008 mode only.

I have no idea in what direction I should go. Replay the s1tool payloads is my actual idea. Many thanks for the help.

P.S.: I have a working exact same device in case it is helpful. P.S.2: Am mostly reachable in IRC

[ghassani]

I checked out the attached capture. It is definitely Sahara Memory Debug mode. You can easily see the packet received from the device (#17360) is the hello packet. The 3rd DWORD (LE) in the packet is the mode Sahara is in, 0x2 which is Memory Debug (see /include/qualcomm/sahara.h) You can see the hello reply in packet #23706. The rest of the packets sent are command mode packets, requesting the device info (SN, HWID, PK Hash)

So it does not expose on an actual USB port device to connect to, you will need to use something like libusb and transfer it over that way by connecting to the usb bus directly and writing to the bulk interfaces.

However, it is in debug mode and you can't transfer programmer files (MGRGXXXX.mbn, .hex, etc) in this mode through Sahara.

I would consider this a soft brick in most cases because generally 9006 mode enumerates a mass storage device on the host machine which you could then manually fix-up the bad partitions by writing using something like dd. to each exposed partition on your machine.

If you get into 9006 mode then SBL1 is loaded, and passed any signature verification. Sahara 9008 mode is only entered when SBL1 fails or in the case of fusion devices (like iphone for example where the SoC is separated, I think the galaxy s3 does this as well) where additional firmware is transferred during the bootup process (like modem)

Sadly the tool in its current state only supports serial :( I have some prototype version that uses boost libraries and abstracts away the transport layer so it could potentially be sent over serial, tcp, usb, etc. but its far from working correctly and given I have a full time job and part time freelance I probably will not get to it until later this year.

I rarely get on IRC these days. I assume freenode? I will try to get on (user is ghassani) or you can connect with me through Google Hangouts

[ghassani]

Maybe you can find more info in those java sources [ https://forum.xda-developers.com/showpost.php?p=72379351&postcount=24 ]

[nailyk-fr]

You linked me to my post :s Does that mean am over?

Many thanks for your capture analysis. Yes my idea was to write something between the kernel and your tool. Actually the device bringup nothing, maybe related to the lack of driver for this into linux kernel. The actual trouble on the device is I flashed junk into the TZ partition (bad flashtool extract) so s1 fail to load while attempting to run the TZ ELF (more details into the xda thread), but that is not the purpose.

If you can link me to that other version of the tool maybe I could write something? Mostly I opened this question because of this, working with you to improve that tool and allow more device unbricking. Someone else is actually working on a HTC device (he got the serial opened) but the tool doesn't seems to implement the right protocol for HTC. So I choose your tool to start working. I have a full time job too and am not a good code writer but am patient and wanna learn :)

Yes am on IRC on a lot of servers with 'nailyk' nick. Sadly I don't have hangouts (or any other google affiliated products). You can join #Carbon-Fusion on freenode, we both are into.

Many thanks

[ghassani]

I linked your post because you decompiled the jar library for their protocol, so I thought you might find more information in there. If you share it with me I can take a closer look.

Sure I will give you access to the repository. It is currently quite a mess tho and no GUI is available, mostly just test programs trying out my ideas.

I will try to get on IRC later.

[nailyk-fr]

Yes uncompiling the java is still an idea I got. Also because java is easy to implement another lib.

No problem, am not a code writer. Mostly am able to understand what it do ;)

Many thanks. Will see if I can fork then work on my own branch-mess. Hope I will be able to help you to improve your app.

[cuynu]

Same results on xperia xz2, bricked