yashsingh1/xdaforums huggingface dataset:
[Touch Diamond, MDA Compact IV Themes and Apps] chiron83:
There is no general solution for this.

In most cases the CAB files are inside an installer EXE. The possibility and effort to "extract" the cab varies depending from the EXE (there are many different packers and installers on the market).

Some of them can be opened with packers like WinRAR or 7zip, others can't.

There is one thing they all have in common: the CAB has to be (temporary) installed onto your harddisk. This might be under "Programm Files\Software Vendor\", ActiveSync directory or an temp directory, for example "C:\Documents and Settings\<user>\Local Settings\Temp\<subdir?>" in Windows XP. In some cases the CAB will be deletet when the setup programm ends.

So, unfortunately, there is no generic method to extract the CAB.
[Touch Diamond, MDA Compact IV Themes and Apps] Addicteddddd:
open the exe in winrar or a similar archiving program and look for the cab (probably a jumbled up name, though still has the .cab file extension)
[Touch Diamond, MDA Compact IV Themes and Apps] lude219:
just extract the EXE using winrar and copy the CAB file in there to your mobile device.
[P8lite Q&A, Help & Troubleshooting] Eloy68:
Hello, this is my phone story: I had a Samsung S9 which screen died, I was thinking on getting another phone, so I bought a new phone which is going to take a while to arrive and I had no phone so i found this Huawei p8 lite laying around and I tried to get it working, but its all screwed up because some years ago I was trying to install another rom and I flashed something that I shouldn't, ended up hardbricking the device (red and green light flashing, faastboot not working) I managed to recover it by getting it into testpoint and then booting xloader & fastboot and flashing the stock firmware with a hisilicon tool, the device was alive but the IMEI was gone for good, I didn't looked much into it and leave it.

Today I wonder if I could recover the IMEI, I have the number but I don't have the partitions so I have no idea how to recover it, I have tried HCU tool to write the number without success.

If someone culd provide me the partitions or something it would be helpful.

Any Help would be very nice, Thanks!
[Moto G 5G Plus Questions & Answers] supermafari2.0:
Hello I have a hardbrick that so far I cannot solve, because I want to close the bootloader, the fastboot rejects any command that I enter (including the "fastboot oem unlock") and when turning on motorola it generates the error 0xC2224571 "No valid operating system could be found. The device will not boot ". I thought about doing a "Blankflash", but I don't know what the Motorola "test point" is. Does anyone know how to do it and get to EDL mode?
[Moto G 5G Plus Questions & Answers] shadowchaos:
seems a/b partition problem.

try fastboot flash recovery_a twrp.img

fastboot flash recovery_b twrp.img
[Moto G 5G Plus Questions & Answers] supermafari2.0:
I already tried that of recovery_a and recovery_b, and nothing happens, that gives CMD:

1) fastboot flash recovery_a twrp-3.5.0-0-nairo.img

Sending 'recovery_a' (59392 KB) OKAY [ 1.827s]

Writing 'recovery_a' (bootloader) flash permission denied

FAILED (remote: '')

fastboot: error: Command failed

2) fastboot flash recovery_b twrp-3.5.0-0-nairo.img

Sending 'recovery_b' (59392 KB) OKAY [ 1.308s]

Writing 'recovery_b' (bootloader) flash permission denied

FAILED (remote: '')

fastboot: error: Command failed

Also, everything I try to flash ends with this message "flash (bootloader) permission denied".
[Moto G 5G Plus Questions & Answers] shadowchaos:
Could you describe what moves at last time which causes this situation?
[Moto G 5G Plus Questions & Answers] Phil_gloves:
Hey, can I ask you how did you manage to unbrick it? My phone doesn't get recognized via fastboot. It seems dead but when I connect it to the pc, it gets recognized as "Qualcomm HS-USB QDLoader 9008".

What can I do next?
[Moto G 5G Plus Questions & Answers] teh_apple:
Try a blank flash for your phone.
[Moto G 5G Plus Questions & Answers] Awilen:
Hello,

I am in a similar situation and also interested in the test point for EDL mode, so rather than opening a new thread I figured I'd reply here.

As it stands, my phone has the /e/ project ROM and recovery flashed on it, the "Allow OEM unlock" option is disabled, and the bootloader is locked. Meaning, the OS doesn't get recognized and doesn't boot, flashing is disallowed across the board, fastboot oem unlock <UNLOCK_KEY> is rejected, and fastboot boot <any recovery stock or otherwise>.img fails.

fastboot oem blankflash returns "Command Restricted" and well, subsequently tells me it failed.

So my own ignorance left myself with a rather expensive paperweight and the last resort I believe is to flash a stock ROM in EDL mode. I have found a teardown video of the device and seen a few test points there (including 3 under the large heatsinking graphite film), and I'm ready to remove the back cover on mine. It seems that the EDL test point isn't documented... If need be, I could try to find the test points myself. I just need more info to not short and break anything.

Edit: so I've gone and done it. Stabbed all visible test points, one of them scores at 1.8v, one at 1.5v, the rest at 0v. [EDIT] Some actually show something below 0.5v.

The 1.8v test point is connected to a trace going to the connector's pin. Another pad goes just beside that pin. It is very enticing right now to try and bridge them, however I'm not confident those are the EDL test points and I may short something I don't want to. I'm gonna get resistors.

The missing connector tells me it's a connector that's important for Motorola, and clearly not for the end-user. This is a cost-saving measure, don't need to run extensive tests when the device is finalized, you only need the test points to... enable EDL? Ahah. The fact the connector pads are still there is because designing the rerouting to remove them also costs money.

The 1.5v test point is between the screen and bottom daughterboard flexible flat cables connectors. Without certainty, I believe it may be a voltage for one of those or both.

Attached is the photo of the test points around the missing connector, if that helps at all.

Edit2: I found this post about trying for test points. I'm lacking resistors right now to further test. https://xdaforums.com/t/phone-doesnt-boot-even-in-edl-mode.4411915/#post-87260675

Edit3: welp, bridging the points linked to the missing connector pads did nothing. What I tried is keep the phone off, bridge the points, plug the USB, but it keeps sending me to "OS not found" error or fastboot, depending on if fb_mode_set or fb_mode_clear have been used.
[Moto G 5G Plus Questions & Answers] SomeRandomGuy:
Hey @Awilen please keep us posted. I too want to play with this phone, but am frustrated by lack of easy access to EDL mode (to unbrick). (I want to try to roll my own GSI/AOSP build + Moto proprietary drivers, which will likely not boot the first thirty or so times I try it.)

FWIW, I tried this method and a pre-bought cable that allegedly does the same thing- no dice either. :(

The fact that there ARE EDL IMAGES out there gives me hope.
[Moto G 5G Plus Questions & Answers] SomeRandomGuy:
This repository has some other tricks to try, if you are brave enough:

Use a edl cable (Short D+ with GND) and force reboot the phone (either vol up + power pressing for more than 20 seconds or disconnect battery), works with emmc + ufs flash (this will only work if XBL/SBL isn't broken)

If emmc flash is used, remove battery, short DAT0 with gnd, connect battery, then remove short.

If a ufs flash is used, things are very much more complicated. You will need to open the ufs die and short the clk line on boot, some boards have special test points for that.

Some devices have boot config resistors, if you find the right ones you may enforce booting to sdcard instead of flash.

(I've tried #1)
[Moto G 5G Plus Questions & Answers] Renate:
FWIW, I've never had any success with any "EDL cable" on any device, but that could be entirely due to timing/incompetence on my part.

A few devices I've been able to find EDL test points.

On some non-Qualcomm devices I have gotten to ROM bootloader by using a 100 ohm resistor (for safety, instead of a dead short) from some random test point near eMMC to ground.

Edit: Since then I've seen some devices that can react to an EDL cable.

It's a question of whether the OEM put the test for grounded USB 2 D+ in the sbl/xbl.
[Moto G 5G Plus Questions & Answers] SomeRandomGuy:
Hey @Renate the cable works on my OnePlus (which, also, has a key sequence to do it, making the cable superfluous), so I know that isn't the issue here. I just don't want to unglue the phone and risk breaking something just to play. Once the battery becomes useless and that's inevitable, then I'll probably become a MB-shortin'-mo-fo.
[Moto G 5G Plus Questions & Answers] Awilen:
Hey! I was waiting on my EDL cable. I just tried it... no dice. No dice at all. I believe I've exhausted all non-intrusive tricks in the book, the next step is cleanly desoldering the EM shield over the processor and flash/RAM combo ICs.

Since the device is out of warranty anyway, I'll try for a repair shop to desolder it, as the only powerful-enough heat source I have is a large heat gun blowing 150°C, 450°C or 600°C air. Other than that I have a 60W soldering iron, I doubt that'll be enough.

The only problem with the desoldering is that the EM shield is part of the cooling solution for the processor/RAM/Flash ICs. It will need to be reapplied.

Edit: I made a thread on the e.foundation forums listing everything I tried: https://community.e.foundation/t/bo...and-wont-boot-am-i-out-of-luck/43362?u=awilen
[Moto G 5G Plus Questions & Answers] SomeRandomGuy:
TIL “fastboot oem qcom-on” and “fastboot oem qcom-off” are a thing.
[Moto G 5G Plus Questions & Answers] supermafari2.0:
For my part, to this day I cannot find a way to access this mode, I still have my theories, since on one page I found "official" diagrams of this motorola and the phrase "EDL" is indicated at various points, but I don't really know how to interpret them on the motherboard, I'll leave the link in case someone wants to review it, it's from a Brazilian page:

Motorola_Moto_G_5G XT2075 - LEMCELL.COM.BR.zip

drive.google.com

In that one there are several files, with more technical specifications, in case someone wants to review it and see what they find useful out there, to see if it is possible to reach EDL mode on this model.
[Moto G 5G Plus Questions & Answers] Awilen:
The missing connector I shot in my photos is a JTAG connector. Make of that what you will. ;)

I have desoldered the EMI shield above the SoC/eMCP area and there's no dice there either. The traces are hidden, the parts are BGAs, there's no "pin" to short there. The schematics may or may not have confirmed my suspicion the physical trace for the clock signal to the eMCP is unreachable, making reaching EDL mode through "PBL panic from not being able to access the flash" impossible.

The SMDs around the eMCP may or may not seem to all be related to power delivery smoothing, and shorting those is blue smoke waiting to happen. I'll resolder the shield later, I don't think there's any point in desoldering it in the future for the purpose of reaching EDL mode.

There are official blankflash utilities freely available. I have no doubt EDL mode is accessible. This connector must be just how.
[Moto G 5G Plus Questions & Answers] supermafari2.0:
so you activated the qcom, but it is not responding to the blankflash? at least it's an advance, maybe it's a blankflash problem or do you think it's some kind of board protection?

Later I will try on my own on my board
[Moto G 5G Plus Questions & Answers] SomeRandomGuy:
Congrats on your quest. Were you literally shorting them, or did you use a resistor? You had to touch all three together?

I guess I still am confused how there is a blankflash out there for this phone, but no way to trigger EDL without a hardware kit. I just ran through all the key combinations (V+,V-, PWR) and USB in/out just to make sure I didn't miss something... no dice to EDL.
[Moto G 5G Plus Questions & Answers] Awilen:
I am confident EDL mode flashing worked. I used a different phone's blankflash that had the same SoC and it worked, giving me a visually different "No OS found" error screen. I posted the log of the blanking process. The "Allow OEM Unlock" bit is still set to "disabled" after blanking, such that I still can't use "fastboot oem unlock" successfully.

There's this line that makes me think the system is still intact: "Skipping UFS provsioning as target is secure", meaning the UFS filesystem might have not been actually blanked. Since singleimage.bin is a signed binary, there's no way to force UFS provisioning or modify it in any other way. I think the only way in will be with a firehose and QFIL... Except I haven't found one for this SoC. The programmer.elf is the firehose, but again that needs to be signed to be useful after getting extracted.

I marked two pads of the missing connector with a green rectangle (I reused the photo I posted earlier on which I had already marked the test points' voltages, disregard the test points). I shorted them with only one voltmeter probe.

The idea is that the EDL pads I marked in green are connected to a 1.8V supply and a pin on the SoC with "infinite resistance", so there's no need for an additional resistor. You are not at risk of shorting anything and cause a major disaster on pins on the row of the green rectangle. The connector is very small, so stab confidently in the middle of the row of pads!

The (V+, PWR) combination may be available in development units, and be disabled in production units at the hardware level (missing components).

(Keep in mind I'm talking in hypotheticals at times to keep up plausible deniability regarding the files posted earlier by supermafari2.0... Those are surely under copyright.)

Layers of security upon layers of security just to get a stock firmware on an empty filesystem on my own device... This is getting old...

Edit: I have, out of boredom, decomposed the singleimage.bin into its various files. Here is the file format:

* SINGLE_N_LONELY Header [256 bytes]
* FILE:
Header:
* file name: 248 bytes (name + "\0" padding)
* file size: 8 bytes, little-endian
Data:
* data: file size in bytes
* 0xA0 padding if (file size % 4096) != 0 : file size + 4096 - (file size % 4096) bytes
[* FILE...]
* LONELY_N_SINGLE Footer [256 bytes]

Do note the 4096 magic number is the flash sector size, thus is device-dependant. In singleimage.bin, there was gpt.bin which also follows the same format. Among the files is programmer.elf, a strong candidate to be a firehose, I'll try to use with QFIL tomorrow. I do take note of Motorola's attempt at psychological warfare.
[Moto G 5G Plus Questions & Answers] Awilen:
So I tried the programmer I found in the singleimage.bin file, it's indeed capable of programming through QFIL! (Do note I needed to get QFIL through QPST to get it to work.) However now I'm faced with this as I'm trying to flash recovery.img to get to recovery and get recovery to reinstall a working system:

INFO: TARGET SAID: 'ERROR: range restricted: lun=5, start_sector=142688, num_sectors=25600'

I guess the programmer checks for the flash being in a locked state, so it's time to try to patch the programmer to force the flash, if at all possible...

Edit: guessed right. The programmer has a routine that does various checks. It isn't encrypted, but I found data that could indicate the file is signed. I didn't see either the PEEK or POKE strings in there, meaning these primitives weren't included in the programmer, so there's no way to manually poke any image by hand, or just enable that blasted "Allow OEM unlock" bit (the fact I don't know where it is not withstanding.)

I think that's the end of the line for my device. At this point the only way it will ever work again will be either getting a patched and signed firehose (unlikely), or getting Motorola to reflash a stock image internally (even more unlikely) or just changing the motherboard (which defeats the purpose of searching how to get the device back in working order after messing up!)
[Moto G 5G Plus Questions & Answers] SomeRandomGuy:
Hmm... so blankflash fails, too? Wouldn't that have all the needed signatures? I mean, you may need to redo with stock firmware post-blank-flash, then let it activate the OEM unlock switch, then unlock it, then start the game all over again, but it saves the hardware? Not saying you are wrong or anything, I've never gotten even this far with EDL (acknowledging there is a functioning EDL mode) on a Moto before. No one else in the moto communities I've looked at ever discuss it; the OnePlus folks are well aware and routinely use it to unbrick stupidities (myself included, many times).

I may be entirely wrong, but I thought if you had a signed programmer (e.g. the ELF file) the actual firehose contents (e.g. what you flash) weren't signed or otherwise verified, and you could overwrite any of the partitions (including where the 'Allow OEM unlock' is stored)? I figure the worst was that verified boot would limit you to a properly signed bootloader until the OEM unlocking is completed- but we have the signed stock image, right? Just as a fastboot-mode flash vs EDL/Sahara mode image (I do, if you don't... just DM me).
[Moto G 5G Plus Questions & Answers] Arealhooman:
Oo, I don’t have this device, but I was reading this discussion and was really hoping for a happy ending :( you can always hope for a patched+signed firehouse but I doubt it.
[Moto G 5G Plus Questions & Answers] Awilen:
Yes, the signatures are valid. Some parts do flash alright, including the bootloader (I tried flashing a Motorola "Racer" bootloader which has the same SoC and it worked, giving me a different-looking error message that read the same thing about not finding a valid OS). For some reason, the signed recovery.img isn't written through the protection, and I just find it dumb that it's not. Considering my recovery right now is a custom /e_project/ one that won't boot either...

The "range restricted" I quoted in my previous message is the recovery partition, measuring 25600 sectors of 4kB for a grand total of 100MB, just the size of the recovery.img file. That img file I got from a up-to-date stock firmware zip file... It's just... dumb or actively evil at this point. Flashing recovery with a stock recovery.img, how innovative and safe of an idea, amirite?

This is my first time venturing in the Android flashing scene, and I think I did everything I could to get it back in working condition. Thanks for the support ^^ I'll contact Motorola, see if I can get anything done through them. Doubt it even more though...
[Moto G 5G Plus Questions & Answers] SomeRandomGuy:
The sport of this gave me a Shower Thought last night: do we know what it is actually restricting? If it is hardcoded to not write to part of flash by position, is it restricting the partition table, too? If not, could it be repartitioned to put the images down in a pattern that skips the protected section?

I've never reversed a Moto .bin file, but the OP images (happy to share if you don't want to dig) have the UFS provisioning files and firehose programming that lay it out, hinting that it is possible. But they do come with this neat note, though:

<!-- WARNING: PROVISIONING UFS IS A ONE TIME OPERATION IN FACTORY -->

<!-- SO CARE MUST BE TAKEN TO ENSURE THE PARAMETERS -->

<!-- IN THIS CONFIGURATION FILE MEETS THE END PRODUCT -->

<!-- REQUIREMENTS. PLEASE REFER TO THE QUALCOMM FLASH IMAGE -->

<!-- LOADER (QFIL) USER GUIDE (80-NN120-1) FOR MORE DETAILS -->

<!-- ON THE PROVISIONING -->

<!-- -->

<!-- THIS FILE IS FOR UFS 3.1 DEVICES WITH -->

<!-- JEDEC COMPLIANT WRITE BOOSTER FEATURE -->

I think it's over my head at this point, but I'm sure there is a way somehow; something they didn't think of.
[Moto G 5G Plus Questions & Answers] Renate:
I ran into this "range restricted" too on my Moto G 2021 XT2117-4.

I ran into this before on a MotoE5 or E6, I forget, and gave up.

In any case, I can read any (512 byte) block from 0 to 255.

That means I can dump the GPT and see what/where the partitions are.

It also means that I can't read anything useful.

C:>edl /lmotog.bin
Found EDL 9008
HWID: 0014d0e102e80000, QC: 0014d0e1, OEM: 02e8, Model: 0000
Hash: abbcc86fe393b13d-59e2a2ec944af26d-a3fa3d4b2a1ccd2f-b383c73e0fffc30d
Sending motog.bin 100% Ok
Waiting for Firehose... Ok

C:\>edl /g
Found EDL 9008
Configuring... Ok
Requesting GPT 0 header... Ok, receiving... Ok, requesting entries... Ok, receiving... Ok

# Name Start Count Type
-- ---------------- ---------- ---------- --------------------
1 xbl_a 131072 10240 Inactive
<big list of partitions>
77 userdata 24266752 97875935 User data

C:\>edl /r /c256 foo
Found EDL 9008
Configuring... Ok
Requesting read foo... Ok, receiving 100% Ok

C:>edl /r /c257 foo
Found EDL 9008
Configuring... Ok
Requesting read foo...
<log value="ERROR: range restricted: lun=0, start_sector=0, num_sectors=257" />
Nope
[Moto G 5G Plus Questions & Answers] HemanthJabalpuri:
Off-topic but thanks for the stucture explanation. I can't able find any reference to extract this file and searching "SINGLE_N_LONELY" in Google pointed to your post. Here is a quick LUA program to extract my Moto G52 SINGLE_N_LONELY files

#!/usr/bin/env lua5.3
-- parse files with magic SINGLE_N_LONELY
-- Tested only files of Moto G52(bootloader.img, radio.img, gpt.bin, singleimage.bin)

function abort(msg)
io.stderr:write(msg .. "\n")
os.exit()
end

function getString(n)
local dat = f:read(n)
return dat:gsub("\x00", "")
end

function getLong()
local long = { string.unpack("I8", f:read(8), 1) }
return long[1]
end

function extract(name, offset, length)
of = io.open(name, "wb")
f:seek("set", offset)
of:write(f:read(length))
of:close()
end

if #arg < 1 then
abort("Usage: parsegpt.lua gpt.bin")
end

f = io.open(arg[1], "rb")

magic = getString(256)
if magic ~= "SINGLE_N_LONELY" then
abort("Unsupported")
end

fsize = f:seek("end")
f:seek("set", 256)

for i = 1,64 do
name = getString(248)
size = getLong()
if name == "LONELY_N_SINGLE" then
break -- no more files
end
io.write(string.format("Name: %s, Offset: %d, Size: %d", name, f:seek(), size))
extract(name, f:seek(), size)
pad = 0
if size % 4096 ~= 0 then
pad = 4096 - (size % 4096)
f:read(pad)
end
print(", Padding: " .. pad)
end

f:close()
[Moto G 5G Plus Questions & Answers] Renate:
Yes, we do.

There are tables in the Firehose loader that tells you what you are allowed to access.

I've added extraction of these tables to my QcomView.exe utility.

C:\>qcomview motog.bin /r
Addr LUN Start Count
------ --- -------- --------
008220 0 0 32
008238 0 -5 5
008250 1 0 32
008268 1 -5 5
008280 2 0 32
008298 2 -5 5
0082b0 3 0 32
0082c8 3 -5 5
0082e0 4 0 32
0082f8 4 -5 5
008310 5 0 32
008328 5 -5 5
008340 1 0 2048
008358 2 0 2048
008370 3 0 2356
008388 5 0 2356
0083a0 0 2080 512

0083b8 0 0 256
0083d0 0 -33 33
0083e8 0 131072 284992
008400 0 416064 2048
008418 1 1 1

The top part is for UFS, the bottom part for eMMC.

So, for my eMMC that says that I can read the GPT, the GPT backup, xbl_a - storsec_b and ddr.

Note that I can dump (if I want) the whole xbl_a - storesec in one chunk, but I have to dump ddr separately.

The allowed contiguous chunks can not be merged.
[Moto G 5G Plus Questions & Answers] SomeRandomGuy:
Wow, that's really cool. Your page has lots of great stuff... wish I ran Windows to play with it natively. Any thoughts on open sourcing it or building a *nix compile?

Using your /r mode, is it only concerned with reading, or does a presence in the entries suggest RW capabilities?

Was this (printed above) the loader from blankflash?
[Moto G 5G Plus Questions & Answers] Renate:
The /r is for restriction.

It certainly applies to reading, you might be allowed to write.

I haven't even tried writing.

Do you have an actual Lenovo/Motorola Firehose loader that you want to check?

What are you using? Just give me the md5sum, I might already have a copy.

I can print the range restrictions for you.