yashsingh1/xdaforums huggingface dataset:
[Hardware Hacking General] alecxs:
there exist different revisions of that board, 95% identical, but all have these unused antenna connectors on it. I can't see any jumpers, that are spring contacts for more antennas in the cover. I don't know if there is any eMMC it's all under the hood.

the battery is only backup for GPS and GSM.
[Hardware Hacking General] alecxs:
So I shorted the reed sensor and now on the oscilloscope I can definitely see 1.8 V transmission (on the yellow pin) but nothing on usb. will try to connect to PC and see what happens.
[Hardware Hacking General] Renate:
You may find that it wants a password.
[Hardware Hacking General] alecxs:
will see. today I got my FT232RL 1V8 from china, curious I can understand something at all.
[Hardware Hacking General] alecxs:
I got something. looks like Android 6.0.1 with ubifs file system. let me connect usb too...
[Hardware Hacking General] Renate:
If you can get to EDL and also find a loader you can do a full dump.

My edl.exe handles ubifs and volumes.

Since lots of stuff is only written once you'll find all the blocks contiguous.

I also have a utility for getting an overview of raw ubifs dumps.
[Hardware Hacking General] alecxs:
can you determine the loader? looks I can get the volume keys somewhere... pin37

attached the log but it wasn't uploaded, so here again.

edit: nothing on usb. guess it's because of the missing vbus wire.
[Hardware Hacking General] Renate:
If you have lived virtuously and eaten all your vegetables, this should be the loader and it should be non-SecureBoot.

C:\>edl /lwhatever.bin
C:\>edl /n /g
C:\>edl /z
[Hardware Hacking General] alecxs:
Now I soldered the dots on the pcb and get usb. but no edl mode.

Bus 001 Device 008: ID 05c6:f626 Qualcomm, Inc. Android
[Hardware Hacking General] Renate:
Well, what is it? CDC? Print the descriptors.

Did you ever register and get the pinout of the module?

One of those pins is USB_BOOT.

Give it 1.8V (Safely through a resistor.)
[Hardware Hacking General] alecxs:
I can't register, no matter what password tried, it doesn't accept. tried several length and complexity. So I don't even come that far.

another thing is, it's very hard to get lsusb something recognized at all.
[Hardware Hacking General] alecxs:
I tried harder, couldn't get it connected again. what other descriptors than the above do you have in mind?

I can see the usb data connection is on pins 5 + 6 pins 69 + 70.
[Hardware Hacking General] Renate:
You're on Linux?

lsusb -v
[Hardware Hacking General] alecxs:
I found another pinout. at least the GND pins and antennas are identical, also usb-dm and dp. but I think I damaged something meanwhile, cannot get usb detected ever. I will solder Vbus and check again.

https://forums.quectel.com/t/ec2x-jtag-debug/12556/2

edit: just by coincidence

xubuntu@xubuntu:~$ sudo lsusb -s 001:007 -vvv

Bus 001 Device 007: ID 05c6:f626 Qualcomm, Inc. Android
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x05c6 Qualcomm, Inc.
idProduct 0xf626
bcdDevice 3.18
iManufacturer 1 Android
iProduct 2 Android
iSerial 3 124346
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x004b
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 500mA
Interface Association:
bLength 8
bDescriptorType 11
bFirstInterface 0
bInterfaceCount 2
bFunctionClass 224 Wireless
bFunctionSubClass 1 Radio Frequency
bFunctionProtocol 3 RNDIS
iFunction 8 RNDIS
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 3 RNDIS
iInterface 6 RNDIS Communications Control
** UNRECOGNIZED: 05 24 00 10 01
** UNRECOGNIZED: 05 24 01 00 01
** UNRECOGNIZED: 04 24 02 00
** UNRECOGNIZED: 05 24 06 00 01
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 9
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 7 RNDIS Ethernet Data
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 1
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x0000
(Bus Powered)
[Hardware Hacking General] Renate:
Hmm, there's plenty that I don't know.

Apparently, the Python EDL knows how to dump stuff without a Firehose loader.

The log doesn't seem to indicate that it ever used 000480e100000000_cc3153a80293939b_fhprg_9x07.mbn

Is that so?

Why do you think that this device is an EC25 (and has USB_BOOT on pad 115)?
[Hardware Hacking General] alecxs:
I am not sure a loader is required for 900E diag mode at all, but the script will use a loader from its Loader directory automatically for 9008 edl mode (if no loader given)

The pinout is just coincidence, maybe MeiG Smart is just a copy-cat labeled Quectel. They only have in common mentioned 'mdm9607' on the UART log.

https://wiki.pine64.org/wiki/PineModems#Quectel_EG25-G_Modem
[Hardware Hacking General] Renate:
Check the continuity of your TX and RX to either 11, 12 or 67, 68.

That will confirm there is some possibility of them being the same.
[Hardware Hacking General] alecxs:
Nope, I cannot find UART on any of the 80 outer pins.

edit: someone found this for me. looks more or less copy-paste to the EG25 docs.

https://fccid.io/2APJ4-SLM750V/User-Manual/Users-Manual-revised-4514377.pdf

in the Quectel EG25-G Hardware Design docs there is a hint:

"It is not recommended to pull up USB_BOOT to 1.8 V before powering up VBAT."
[Hardware Hacking General] Renate:
Well, 115 is not in the same place in the MEIG as it is in the EC25 (which you quoted).

And that MEIG manual doesn't say that it's a EG25.

So, did you try 115 where the manual says it's the USB_BOOT?
[Hardware Hacking General] alecxs:
I haven't checked the whole pinout but I believe the pinouts are identical. you did notice it is 90° degree turned?

;)

​

Will solder some buttons tomorrow, so I can press power + boot with battery connected.
[Hardware Hacking General] alecxs:
still no luck with EDL mode. but I think I broke it, because the VDD_EXT should be 1.8 V but it is much higher 2.4 V.

I am back on windows and I noticed it connects as RNDIS modem. I did a port scan and found 53, 5037, 5555, 10080 so I tried to connect adb tcp or ftp socket, but it failed. there is no COM port so I can't send AT commands. also the debug uart gives me no console to type something.

according to this it's not possible to do something in RNDIS mode. also I don't know what to do in windows with 900e diag mode.

Is it possible to send AT commands through TCP?

I have a SIM900 GSM/GPRS device, I can send AT commands through HyperTerminal and everything is fine. I can configure GPRS connection through AT commands: AT+CGATT=1 AT+CIPMUX=0 AT+CSTT="INTERNET"...

electronics.stackexchange.com

I think I will start over with another module and double check VDD_EXT = 1.8 V before connecting to USB_BOOT next time.

this tool looks promising, but I am afraid it won't work with my MeiG VID/PID anyway.

https://forums.quectel.com/t/how-to-send-at-commands-in-windows-by-qcom/15562
[Hardware Hacking General] alecxs:
I soldered some buttons with 10k resistors and tried another module, but no success either.

I noticed VDD_EXT raises up to 2.4 V when USB_VBUS is connected to PC, and drops to 1.8 V when disconnected. Don't know if that is intended, but without USB_VBUS there is no USB connection recognized. I set a jumper so I can try with/without.

when VBAT is first connected to battery it stays in sleep, so there is no voltage on VDD_EXT, until I wake up device on the WAKEUP_IN pin. guess that is the reason short-circuiting USB_BOOT with VDD_EXT and then wake up can't trigger 9008 EDL mode. I tried opposite order (USB_BOOT, then VBAT) without success.

the only other wake up I found is with USB_VBUS, but this will immediately boot into 900E diag mode.

so... I have two modes, RNDIS mode (but no tty registered in kernel) and 900E diag mode. what can we do with this?

should I go for FASTBOOT_KEY_GPIO_ID=37 and see if I can reach fastboot mode, or do you have any idea how to reboot via AT commands?
[Hardware Hacking General] Renate:
Hmm...

There's a bunch of Vdd there and some things run at different logic levels.

An SD card need 3.3V but could do 1.8V after it gets scanned.

If Vdd_ext goes to 1.8V normally, then jumps to 2.4V when you put voltage on Vbus, then I'd guess that the Vbus comes from a charge pump to turn 1.8V to 5V when the device is in host mode.

I think that the 2.4V on the Vdd_ext could be because you're back-feeding your external Vbus into the 1.8V supply.

But I don't know because I don't have the manual.
[Hardware Hacking General] alecxs:
there is no manual for the power supply, but the manual for the modem is linked in post #37 (unfortunately without application notes).

what really disturbs me is the wire test for continuity from FT232RL to the Debug-UART pins. either there is some optocoupler or very big resistors, but no direct wiring.

I tried to send AT commands in 900E diag mode but no matter what char I type, PuTTY only types zeros.

I will connect the FT232RL to the main UART and try to send AT commands over UART. maybe I can send AT command to enable ADB. Last but not least I could try to pull files with AT commands directly, but I prefer adb (if edl is no option)

or connect a µC and let it enter EDL with the perfect timing sequence ;)

​
[Hardware Hacking General] Renate:
Yeah, but that's a bit ambiguous. They say before, but there is no reason that USB_BOOT can't be high from the start.

Ok, if the device is not powered then USB_BOOT could back feed the Vdd.

That's why you could/should use a resistor.
[Hardware Hacking General] alecxs:
Does the AAA battery trick work on your Netgear LM1200? on which point should I connect the usb cable to pc? is the main power connected?
[Hardware Hacking General] Renate:
I've never tried it with a battery. I just use the test points (GPIO in and 1.8V) and a magnetic reed switch.

I'd tell you to just put a resistor between Vdd_ext and USB_BOOT, but I'm concerned about that 2.4V

Use a resistor on the higher side, 4.7k to 10k.
[Hardware Hacking General] alecxs:
No problem, I disconnected VBUS on start so there is 1.8 V on VDD_EXT (if awake).

And I use 5 V with a divider for the wakeup. don't worry about the extra 4.7k the voltage breaks down to ~1.1 V due the load (without it never wake up). VBAT is always on.

​

​

after releasing the buttons I connect the jumper wire to VBUS and the device comes up as Qualcomm HS-USB Diagnostics 900E.
[Hardware Hacking General] Renate:
Does it behave identically if you don't have USB_BOOT connected?

The WAKEUP is some GPIO that is sensed after the device has already booted.

You need to find the RESET_N on pin 20. Ground it through a 100 ohm resistor (in case you hit power accidentally) while the USB_BOOT is asserted.

This should not matter if it's woken or not.
[Hardware Hacking General] alecxs:
USB_BOOT connected or disconnected makes no difference. before WAKEUP the VDD_EXT is = 0 V and device cannot boot without WAKEUP.

I tried with RESET_N and PWR too, and I tried AA battery 1.6 V permanently soldered with 10k to USB_BOOT, but no success either.

QFIL has option to switch into EDL mode from 900E Diag mode. Did this ever work? First time using it..

I guess on the PCB there is any GPIO pulled-up that prevents EDL mode.
[Hardware Hacking General] Renate:
Yes, but I'm guessing that it does hit the PBL as soon as power and reset are ok. The wakeup is just continuing the boot.

To verify any of this you'd have to monitor the current when it powers without wakeup.

Did you check the far side of the resistor to see if it was holding up.

I don't know what the pulldown on the GPIO is. Usually they are high-ish.

I've never used QFIL and there are many people who have tried on many devices to change 900e to 9008.
[Hardware Hacking General] alecxs:
I tried several times with and without connecting main battery first. Yes the 1.6 V of AA battery on USB_BOOT pin (after resistor) remains stable.

with usb cable connected it boots into 900E diag mode. full boot only works without USB_VBUS. during the first 20 seconds, connecting usb cable will trigger a controlled shutdown and reboot, which ends up in 900E diag mode. I can see it on the Debug-UART.

without usb cable it will boot into RNDIS mode. modem is ready after 2-3 minutes, during this time there is no usb connection and no sign of life. Then the RNDIS VID=05c6 PID=f626 device appears but without any COM port, instead ethernet device is created.
[Hardware Hacking General] Renate:
And you've checked to see that there is only one interface with three (or two) endpoints?

It could be that the wakeup is hardwired to power management.

Me, I'd look at the current going in, play with wakeup and reset to see what's going on.

Here's the reference design for the EC25. Since the pinout is the same it will give you some insight.

https://www.dragino.com/downloads/d...ctel_EC25_Reference_Design_Rev.E_20170406.pdf

The vdd_ext is supposed to be 1.8V and never higher.

It's provided as a reference voltage for level shifters.
[Hardware Hacking General] alecxs:
there is only one interface in linux, on windows I don't know how to check.

not sure how to measure the current, as the modem is soldered on pcb. anyway, I left it alone unpowered over night, then first connected USB_BOOT to AAA battery hardwired, then connected VBAT and then USB_VBUS. no success.

I tried to connect other UART but I used known pins on the connector. I have no clue on which pins these are connected because of the optocoupler. At least I can see data, but it doesn't accept AT commands. I noticed that it communicates with the STM32 on 5 V level while the STM32 is 3.3 V, which is kinda funny for such product.
[Hardware Hacking General] Renate:
Why do you think that there are optocouplers?

There could be level shifters, but you said it's all 1.8V
[Hardware Hacking General] alecxs:
level shifter/optocoupler idk just guesswork. The heartbeats send on both UARTs are different. If I can see data on the test points, it should be possible to identify the pins with oscilloscope. according to the documents it is possible to send AT commands on UART. The AT commands are well documented, it should be possible to enable ADB with AT+QCFG="usbcfg",0x2c7c,0x125,1,1,1,1,1,1,1
[Hardware Hacking General] Renate:
The Inseego modems have an USB HID interface for switching modes on USB but I don't think that you have that.
[Hardware Hacking General] alecxs:
Here are some of the test points I measured, it has three UART and one USB.
[Hardware Hacking General] Renate:
How have you been powering this?

How much voltage on the "36V" did you have to put?
[Hardware Hacking General] Renate:
Ok, I got it going with 10V.

Hey, it's my lunch hour.
[Hardware Hacking General] Renate:
Ok, I got my RNDIS.

On your pinout that corner "3V" is not a supply. It's a high signal to be grounded to enable the DC converters for the module.

I just strapped it to ground. That means that the the module can stop but it can't really power fully down.

Close enough for me.

Lousy photo.

I can't seem to get the USB_BOOT to work but I'll try to think through their caveats.
[Hardware Hacking General] alecxs:
Yes, it is in stand-by, but it boots either on USB_VBUS or by grounding that transistor on the right.

Regarding the 3V3 test point maybe I measured wrong, thought it was connected to the DF13EA-20 socket - where pin 19 indicates with HIGH if the STM32 is booted (I use it wake the ESP32 when battery is charging)
[Hardware Hacking General] Renate:
It is pin 19, but it doesn't seem to be any of the SLM pins.

Before lunch it was behaving rationally (but still no 9008).

Afterwards it was reseting all the time.

I pulled the SIM and now it behaves coherently.

I think the networks here drive it insane.

It still takes about 3 minutes for the RNDIS to pop up.
[Hardware Hacking General] Renate:
I've come to the conclusion that the USB_BOOT pin is not connected inside the SLM itself.

Could you test with a DVM on diode test?

Powered off, red goes to shield, black goes to the pin that you're testing (i.e. reversed).

USB_BOOT will measure infinity. Its neighbor on the corner "Reserved" will measure diode-ish, 400-500, at least a number.

Edit: Unless my unit was blown up?
[Hardware Hacking General] alecxs:
then no need to ground it.

I did not open it, but if you tell me I can try to measure.

I don't think so. Maybe they prevented EDL mode intentionally? there is a special bootloader to prevent fastboot at least.
[Hardware Hacking General] Renate:
Ok, I'm getting confused here.

After checking some things I came to the conclusion that the "bathtub" style shield on the bottom opposite the big electrolytic and big diode was a preregulator from ~36V to ~12V.

Was I wrong? You never said what the lowest voltage was that you could get this to work using the 36V in.

If I power this up using the spot which I think is the output of the preregulator with 12V I don't get any voltage to the VBAT_BB or the VBAT_RF.

All the other power pins on the SLM are outputs from internal regulators that feed to the SD card and the SIM and reference 1.8V (VDD_EXT).

Pin 19 of the 20 pin, which is also available on the left test point with the white wire jumper measures 3.07V.

Grounding it takes 0.013 mA, which works out to a pullup of about 230k. So not a supply by any means.

As far as I can see there is no feed of 3.3V to the motor controller. It must regulate 36V for its own micro.

Since there is no Vbat without grounding pin 19 the various (optional) wake/sleep pins on the SLM can't do anything.

No, I was not asking you to pop the lid on the SLM, merely to measure (two of the) 80 external pins vs ground on diode test.

As I am measuring completely open on my USB_BOOT, I can only surmise three possibilities.

There is an internal zero ohm jumper inside the SLM that they intentionally left out

That they accidentally left the jumper out

That through a mishap the trace/input was vaporized

I looked inside the SLM for a possible unpopulated spot but couldn't find it.

I may get rid of the rest of the shield and look further.

I may have to do that to disable the flash which I think is in the shielded section

The NM1482KSLAXCL-3B is 2 GB RAM.

The actual 9008 is not optional to the MDM9207 so it has to be there and it can't be ignored.

Whether I can actually find it is another thing.
[Hardware Hacking General] alecxs:
idk, it's a black box to me :D

I powered the device on the test points 17 + 15 with 12V. normally it is straight connected to the battery 36-42V.

yeah, VBAT_BB and VBAT_RF is powered down in sleep mode. to make it boot, either short-circuit the transistor on the right (red circle in the test point PDF), use the WAKEUP_IN (pin 1) or provide 5V directly on USB_VBUS (pin 71) of the MeiG SLM750 Module (Beware VDD_EXT raises up to 2.4 V)

No, not a supply. it's a GPIO most likely configured as input.

This is the STM32 motor controller (similar model). If it is in stand-by, the test point 19 is LOW, and if controller is awake, the controller provides a HIGH (on a 3V3 level). I aleady burned two GPIOs on the ESP32 because I didn't limit the current (I use it as replacement for the SLM750). Now I use a 1k resistor to connect the STM32 with the ESP32. :)

Idk but I always left it floating when debugging the SLM750 unit. I didn't ground it, but it does not harm to ground, because the motor controller does the same when in sleep. just not sure what the software does. this is the only information I have: 白色L19-充电开机 (label of the wire from picture)

Ok let me try. I never figured the UART pins with this, that's why I assume there is some level shifter. I soldered USB_BOOT and N_RESET on SLM750 pins 115 and 20 directly, as I did for USB_VBUS on pin 71.

yeah I am curious you can manage it, but don't waste to much time for this, it's not important to the project, just a bonus :)
[Hardware Hacking General] Renate:
Well, I removed the cans and it still boots ok. Upper left: regulators and clock, upper right: RF power amps.

My bad, the NANYA is 4Gb (512MB) flash, 2Gb (256 MB) LPDDR2.
[Hardware Hacking General] alecxs:
Oh you removed the shield. This is too tiny for my eyes :)

I measured 50k between (20) N_RESET and GND, but nothing in (115) USB_BOOT. If you want me to measure something else I could try with magnifier and needle.
[Hardware Hacking General] Renate:
No, I wanted specifically (reverse) diode test. Don't you have a little diode symbol on your DVM?

Here is a photo of a good test of Reserved, USB_BOOT is the next one up.
[Hardware Hacking General] alecxs:
Ok I never used that mode before, but still there is nothing on USB_BOOT.

Spoiler content hidden.
[Hardware Hacking General] Renate:
Thanks, I guess that USB_BOOT is just a fake-out.

I used a damp Q-tip (ear swap) and the megohm range to find any connection, but there was nothing.

With a Q-tip you can test lots of points at once.

I did get in 900e mode once, but that's where it goes when a boot fails, not like 9008 which is instantaneous.

I tried to load a loader, but no luck.

I just hooked up a foot switch so I can power cycle this easily.
[Hardware Hacking General] alecxs:
Don't know if you hooked up the DBG-UART it mention GPIO_ID=37 for fastboot mode during boot. According to the manual one of the UARTs should accept AT commands.
[Hardware Hacking General] Renate:
Yes, I've hooked up the DBG UART you have on the 20 pin. I used TPs on the bottom of the PC though.

I've seen the GPIO_ID bit.

Oh!

C:\>edl /n /r e:\slmdump
Found EDL 9008, configuring... nope, configuring... nope, configuring... ok
Requesting info on LUN 0... ok
Bad blocks: 1536, 1537, 1996
Requesting read slmdump... ok, reading 75% ok
Requesting read slmdump... ok, reading 97% ok
Requesting read slmdump... ok, reading 100% ok

C:\>edl /n /g
Found EDL 9008, configuring... nope, configuring... nope, configuring... ok
Requesting info on LUN 0... ok
Bad blocks: 1536, 1537, 1996
Requesting volume table... ok, receiving... ok

# Name Start Count
-- ---------------- ---------- ----------
1 SBL 0 640
2 MIBIB 640 640
3 EFS2 1280 3072
4 backup_efs 4352 640
5 TZ 4992 320
6 RPM 5312 256
7 aboot 5568 256
8 boot 5824 2048
9 SCRUB 7872 192
10 modem 8064 17792
11 misc 25856 384
12 recovery 26240 2048
13 cache 28288 384
14 recoveryfs 28672 5888
15 sec 34560 128
16 aboot_bak 34688 256
17 boot_bak 34944 2048
18 sys_bak 36992 13056
19 tz_bak 50048 320
20 rpm_bak 50368 256
21 efs2_bak 50624 576
22 usrdata 51200 17984
23 usrlog 69184 12864
24 system 82048 49024

https://github.com/bkerler/Loaders/...480e100000000_cc3153a80293939b_fhprg_9x07.mbn

C:\>edl /lslmbad.bin
Found EDL 9008, handshaking... version 2.1
HWID: 000480e100000000, JTAG: 000480e1, OEM: 0000, Model: 0000
Hash: cc3153a80293939b-90d02d3bf8b23e02-92e452fef662c749-98421adad42a380f (x3)
Sending slmbad.bin 100% ok, starting... ok, waiting for Firehose... ok

So slmbad works, so that means that this is not fused, you can modify sbl (xbl) and abl if you like.

(slmbad has a text edit and rehash which wouldn't pass if this were secure.)
[Hardware Hacking General] alecxs:
Cool! You made it! :cowboy:

I will try it tomorrow. my goal is to enable usb-debugging and access userdata.
[Hardware Hacking General] alecxs:
What do I have to do to enter EDL mode? I shorted the test points with 1k then connected the 3.7V LiPo cell, usb and vbus, but I always get 900E Diag mode.