I have a hard bricked P30 Pro VOG-L29 which I am trying to recover but all the recovery information refers to a scatter file in the firmware folder.I have downloaded various firmware files but have never found a scatter file and I am unable to access the phone to create one. Is there a generic scatter file available to download or are scatter files only found in older firmwares?
As far as i know, scatter files come with devices which have processors from mediatek (mtk), not with prcessors from qualcomm or huawei or samsung for example. i maybe wrong, but since android 10 the structure of ram and rom have changed and i didnt heard of scatter files a longer time ago., so i assume that scatter files, which contain the structure of memory are unnessasary/not used in newer Devices respectively in other devices than mtk ... sorry for my not very professional explanation. i hope, a specialist will later give you a more solid answer...
P.S.: I would try to acces to the device via adb or fastboot mode, there is an emergency mode, too if i know well...
Thanks for the reply its much appreciated.
I found references all over the net regarding scatter files for the P30 Pro, but as we all know, the net can be a dangerous place. It was my last hope of recovering the phone as there is no life apart from a slight vibration when trying to turn the phone on. I don't feel that it is worth the expense of a phone repairer as there is also a slight crack in the screen so will probably put it on fleabay and cut my losses.
I disconnected the battery and when I reconnected I was stuck in fastboot mode. I disconnected the battery a second time and then the phone was dead.
Related
I am interested in creating a forensic image of a Xperia x8 internal memory (school purpose). When I connect the device with the USB cable I can only see the SD card partition. I tried with different tools: ProDiscoverer Basic, WinHex...
How can this be accomplished ?
I don't want to root, install a particular app or alter in any way the content of the internal memory, that will ruin the hole ideea of a forensic image..
Oh yeah.. on previous owned devices: SE Elm or SE Z520, after connecting the device I did have access to the internal memory.
Connecting the device in USB storage mode won't get you any far. That way, as you already worked out, you only gain access to the SD card contents.
You actually need to look into the "adb" commandline tool that comes as a part of the Android SDK (if you look around on XDA you will find adb.exe plus the two required DLLs so you don't need to install the whole SDK along with the Java JDK).
The problem you will face:
If the the phone isn't rooted you won't be able to gain access to all parts of the internal file-system (i.e. some directories may appear empty though there are files and directories inside).
Apart from that - that's not a approach fit for forensic analysis.
IF you would want to tap into a device that's up for forensic investigation the worst thing you can possibly do is to actually turn the device on, let alone boot it up. Chance are that this could destroy valuable evidence (don't take everything you see in CSI:Retards for real) or trigger a "killswitch" that could delete data.
To perform a real forensic analysis you would actually take the phone apart and tap into the system through the JTAG interface. There you are talking directly to the hardware without the phone being booted or even "turned on" (it'll just sit there in "standby-ish" mode).
From there you would then dump the contents of the NAND (the internal memory of the phone where the Android OS, data and installed apps reside) into a file on your computer to perform further analysis.
Once the content of the NAND is secured you can crack down on the SD card (to secure further data for investigation) by slapping it into a card reader being WRITE PROTECTED and do a dump of the SD into a image you can then later mount or hex-view on the computer.
In other words ... to "emulate" a forensic analysis (by ignoring the fact to break basic safety measures) you would actually need to ROOT the phone. Once you did that, and therefore have busybox and su in your ROM, you can then use "mtd_utils" to dump the nand into a file for further analysis.
EDIT:
MTD Utils (i.e. dump the content of the NAND)
These files need to go onto your phone! This are NOT executables for Windows or Linux desktop PCs!
ADB (Windows, Android Platform Tools r10 at the time of writing)
Download the ZIP and extract it ... you only need adb.exe, adbwinapi.dll and adbwinusbapi.dll
Do NOT forget that the Android drivers for your phone need to be installed!
Thanks for the answer. Do you know/have any links regarding what cables/connectors or other hardware tools I need to tap into the system through the JTAG interface.
I found a link:
gsm-technology.com/index.php/en_US,details,id_pr,8466,menu_mode,categories.html
.. dude has a lot o hardware equipment and cables... where can I get & buy stuff like that?
I would try eBay first - or look into finding online retailers selling you a RIFF Box plus required toolset.
Since you said it's for a study project I'm not sure if the equipment you need to really replicate a "professional forensic analysis" will match your budget. A RIFF Box usually goes for USD 150+ over the counter, and then you need some experience to get it to good use and also know a thing or two about electronics in general.
EDIT: Well, the link you posted is the JTAG Header adapter (for the X8 and possibly also W8). If you scroll down they also have the RIFF Box for EUR 119,00 enlisted. And it seems that's actually a online retailer where you could buy the stuff.
---------- Post added at 11:12 AM ---------- Previous post was at 11:02 AM ----------
Ok, to pull it together ...
Xperia X8/W8 is based on the MSM7227 CPU, hence you need ...
Medusa JTAG Box EUR 119,00 (w/o VAT)
Supports MSM7227 based devices. Cables come with the box.
JTAG Xperia X8 EUR 8 (w/o VAT)
That's the JTAG header adapter
Apart from that you may need some software and a good idea about how to wire the cable from the Medusa Box to the pins on the JTAG adapter. Chances are you may also need a power adapter to power the JTAG (if powering the phone through USB doesn't work).
EDIT: Forgot: While the Xperia phones aren't really listed at the RIFF Box that box should work as well.
(I know this thread maybe should belong to Development forum, but I'm posting here since I don't have enough posts to discuss there yet)
I'm in the second year of Computer Science, being a dynamic/interpreted languages programmer for over 6 years now, C/C++ for 2 years.
I have a solid understanding on the x86 PC architecture: interrupts, buses, etc. I'm pretty good at basic x86 assembly... Been studying UEFI for over a month... Whatever.
I've lost the past couple hours searching but didn't find anything on the architecture of our device. Is the "Bootloader" here compared to a BIOS? Or is it like any PC bootloader (MS-DOS, Windows, Linux bootloaders). Is there anything like a BIOS at all or does the OS, once booted, manages all the hardware interrupts by itself? Can I use INT 10H on XT890? Is it ANYTHING close to the PC architecture?
PCI, ISA, (parallel and serial) "ports" managed by a chipset between the peripherals and the x86 core itself?
Ok, it's x86. Once the system has booted, we can call x86 instructions, ok... But what is under that? Is there any reference on this? How can I boot my own code, if it's not Linux?
I really got nowhere trying to learn about the architecture underneath Android and Motorola's Bootloader on Medfield. Found nothing on Intel nor Motorola websites. What am I doing wrong?
Thanks in advance!
I'm studying this myself but there is a lot that i need to learn. Check those to see if helps.
http://bootloader.wikidot.com/android
http://elinux.org/Android_Booting
http://www.ibm.com/developerworks/linux/library/l-linuxboot/
I would like more info about the RAZR I as well, considering it's the only mainstream phone with a x86 processor I'd expect more documentation about it, I am receiving a RAZR I soon.
For what I know, it's boot process is similar to other Android devices, it loads and decompresses a boot.img file that includes a ramdisk and the kernel, you should be able to load another non-linux OS by chainloading a secondary bootloader there, I honestly would like to see more development on the Razr i, specifically to get native Gnu-linux with x11 running
Using @thiagomtl's links, I was able to understand a little more about the Boot process. XT890 seems to have basically the same mechanics of the ARM ones, but x86 tuned.
However I'm yet to understand the differences between "normal" Linux bootstrapping and the Android Bootloader's one.
On a average legacy Linux box we have GRUB/LILO on the MBR. Making a hell of a simplification here: The user turns the PC on, BIOS does the POST and then loads whatever code is on the MBR. GRUB is a very small program there, which simply loads a driver for the storage device, loads vmlinuz and the f*ing ramdisk on the memory and executes it (effectively by simply pointing the IP to the address where the kernel is on the memory).
Samuelgames said:
I would like more info about the RAZR I as well, considering it's the only mainstream phone with a x86 processor I'd expect more documentation about it, I am receiving a RAZR I soon.
For what I know, it's boot process is similar to other Android devices, it loads and decompresses a boot.img file that includes a ramdisk and the kernel, you should be able to load another non-linux OS by chainloading a secondary bootloader there, I honestly would like to see more development on the Razr i, specifically to get native Gnu-linux with x11 running
Click to expand...
Click to collapse
But the Boot process is just a part of my original question. Ok, a important one, but a part.
What about the structure of the device? How it's all implemented? Is the display using plain old VESA VBE? Are the input devices PS/2? USB? Is the power implemented using ACPI standards? lol
As far as I'm concerned Atom SoC doesn't respect many industry standards for the architecture, even for those who run Windows 8, buttons on the Razr I should be naturally be defined as GPIO as the notification LED, I don't think the display respects VESA standards (SGX 540 can't even do scaling) but it should fallback to them at some extent depending on how you initialize the framebuffer.
All of this should be in the Motorola kernel, I haven't taken a look at it but I'll surely will once I get my phone
@Hazou, @YaPeL, @Omar-Avelar
you guys know anything about this?
Ok this is all i know about it by searching through the code and internet and by finding out myself (no sources included, just my memory). It's all linux, nothing like Windows.
Kernel:
We indeed are making a x86 kernel, but not for normal PC's. We use the mid-x86 implementation within the x86 code of the kernel. (arch/x86/platform/mid-x86) MID is the intel word for all the socs for mobile platforms intel is using. The normal upstream linux doesn't provide all the necessary code. And is has changed with the new android version 4.4.2 for our device.
Boot sequence:
The android devices use some sort of bootloader. Droidboot. Droidboot includes the fastboot commands and starts the bringup of the android system. You can read about it on the internet. In most devices (ARM) it is the first thing thats get called for.
Our intel device is a little different. Before the droidboot gets loaded the firmware of the device loads another OS. Also called POS (i think preprocessor OS, or something). Those gets updated with the dix and efwi(wrong name) files we got. The POS can be accessed by booting in the medfield download through the camera button, if i am correct. The POS then loads the droidboot which will in turn load the rest, like a linux device which loads from the bootloader.
The partition layout can be found in the gpt.bin. It can be flashed through fastboot and can change every partition afaik.
So the boot order is:
1. POS/RADIO
2. DROIDBOOT
3. BOOT.IMG is like linux. First the kernel then the ramdisk with the kernel modules.
4. ANDROID
To comment about the JB implementation.
We can build our own kernel and we can, if we want and take the time, upgrade the kernel to the newest version (for android is that 3.10, but we should be able to manage to go fully upstream 3.17). But that takes a lot of time.
I also noticed that, from what i heard, some kernel modules specific for our device has changed and now the kernel that we have can't load the new firmware files in 4.4. So we will need the next kernel from Moto to compile our own when 4.4.2 is released. Those changed are not upstream.
Hazou said:
The POS then loads the droidboot which will in turn load the rest, like a linux device which loads from the bootloader.
The partition layout can be found in the gpt.bin. It can be flashed through fastboot and can change every partition afaik.
So the boot order is:
1. POS/RADIO
2. DROIDBOOT
3. BOOT.IMG is like linux. First the kernel then the ramdisk with the kernel modules.
4. ANDROID
Click to expand...
Click to collapse
This is the most interesting part for hundreds of us. Is there a way we can find what sectors are used for the pos so we can possibly repair code corrupt?
I have a feeling the gpt is messed up so any amount of writing to the dnx or ifwi will be in the wrong location.
I can't find any information on this phone at all.
I think it's time I bought a spare mobo and dumped everything to compare a broken to working
Flacid Monkey said:
This is the most interesting part for hundreds of us. Is there a way we can find what sectors are used for the pos so we can possibly repair code corrupt?
I have a feeling the gpt is messed up so any amount of writing to the dnx or ifwi will be in the wrong location.
I can't find any information on this phone at all.
I think it's time I bought a spare mobo and dumped everything to compare a broken to working
Click to expand...
Click to collapse
If i am correct they are present on the partition layout of the phone. I just don't know wish ones are the right ones. Never looked good enough at that.
Also to repair the gpt and write the dnx or ofwi to the right location u need a dd command or flash command with the right parameters. The flash command most likely won't work because of the gpt partition and the DD command wont either because most of the time u don't have access to a recovery anymore.
But my knowledge about this is limited, so if u dare to put your phone on the line and have maybe the knowledge and skills to do what some people need, please do I can't and need my phone working
Hazou said:
If i am correct they are present on the partition layout of the phone. I just don't know wish ones are the right ones. Never looked good enough at that.
Also to repair the gpt and write the dnx or ofwi to the right location u need a dd command or flash command with the right parameters. The flash command most likely won't work because of the gpt partition and the DD command wont either because most of the time u don't have access to a recovery anymore.
But my knowledge about this is limited, so if u dare to put your phone on the line and have maybe the knowledge and skills to do what some people need, please do I can't and need my phone working
Click to expand...
Click to collapse
Skills/knowledge = limited. I'm no programmer but I take information in like a 100 petabyte SSD.
My phones knackered, I'm trying to fix it but it's not easy! If it's fixed, I'll break it again to make sure the fix works :good:
It's going to be a long road, there is zero success since the first report of code corrupt.
As you say, I need the right param. There's almost no information about it anywhere and what information is about is very fragmented.
I'll keep you updated
Flacid Monkey said:
Skills/knowledge = limited. I'm no programmer but I take information in like a 100 petabyte SSD.
My phones knackered, I'm trying to fix it but it's not easy! If it's fixed, I'll break it again to make sure the fix works :good:
It's going to be a long road, there is zero success since the first report of code corrupt.
As you say, I need the right param. There's almost no information about it anywhere and what information is about is very fragmented.
I'll keep you updated
Click to expand...
Click to collapse
I am almost certain it can be fixed as long as it is a software failure (some maybe have a hardware failure). As this seems one of them it should be fixable as long as your BL is unlocked. With a locked bootloader u don't stand any chance (nah, maybe with medfield flasher, but that one is also limited).
Take a look at the acer padphone or something. Dunno how it is called exactly. Is also uses the intel SOC and makes use of the medfield flasher.
I never had a phone thats corrupt so can't say much about it, but i can help with thinking my way through. If u have that problem can u boot in fastboot or is that even impossible? I know we can flash the POS and fastboot through xfstk. So with the right combination it should work. And if not we can try flash the modem as extra if that is possible. But do know it can hard-brick the device (modem, lowest thing of the device) of-course, aldo u don't have much choice now
Another thing, because fastboot (and even recovery) can flash the dix, ifwi and bootloader files. I 'assume' xfstk (that can also flash the ifwi, dix and bootloader) can flash the whole emmc with indeed the right parameters. We have the source code of the fastboot/recovery ifwi, dix and bootloader flasher. Also called update_osip.
So think it out, i will wait and see.
uart console
Has somebody tried to access a uart console on our razr-i? would be nice for debugging.
Intels datasheet says the board has 3 uart ports. http://ark.intel.com/products/70097
I hope one uart port can be accessed via usb or audio jack. Like on this device: http://forum.xda-developers.com/showthread.php?t=1081743
Or is it only possible with opening the phone and looking for jtag pins?
Hi!
I accidentally installed the 2.05 bios in the mirek flasher on my teclast x98 air III m5c5 now i just get stuck at the chinese letters boot screen och some green battery?!
I can get into DnX mode and Bios menu but when i try to flash the pad again the mirek flasher wont recognize the unit.
I also tried to unbrick the unit through this thread (http://forum.xda-developers.com/x98-air/help/unbrick-bios-softbrick-withouth-eeprom-t3285054/page4) butall i get when trying that in dnx mode is the handle 344 error??
So basically what i need is the program that Ionioni had in that thread but now removed.
Please help
thanks in advance
There WAS (is) other universal unbrick tool from ionioni!
http://forum.xda-developers.com/x98-air/help/baytrail-dnx-mode-bios-flashing-tool-t3295105
I dont know what happened, why it had to be deleted, I have not got this tool.
someone maybe have this tool and update it?
Yep, I got it. I will post it asap.
*****UPDATE*******
Here you can download it flash_bios_dnx_v3 : https://drive.google.com/open?id=0B1EG-i0pY3FINlYyT3E1ekZwOHc
I didn't try it yet, I used ionioni's other tool (C5J8 bios restore).
IT IS YOUR RESPONSIBILITY!!! I have no answers to you.
Instructions:
Baytrail DNX mode BIOS flashing tool
what:
this is an EFI exclusive application (aka what runs on your BIOS chip). the name says it
should work on ALL Baytrail (did not tried other SoC but could be that works there too)
why:
some are having issues in using kernel based tools so this will work for them (hopefully)
how:
1. unzip in some folder (there are only 2 files in the zip, the efi loader and an additional tool)
2. place your bios in this same folder and IMPORTANT run the md5add tool on your bios file (md5add.exe your_bios_file your_signed_bios_file). the tool simply takes the original bios file, computes the md5 for it and then concatenates those two producing the output file. i could have left the bios file pushed to the tab "unsigned" yet it's better this way (so that you are SURE that the file that will be flashed is identical and no bits have been lost corrupted during the fastboot pushing etc). you can check with a hex editor, it only adds 16 bytes (the md5 hash) at the end. if you will try to push an 'unsigned' bios it will NOT accept it!
3. start in dnx mode and input:
fastboot flash osloader bios_flasher.efi
fastboot boot your_signed_bios_file
now wait and read the screen... everything goes AUTOMATICALLY
it seems that on some Baytrail devices (x98?) after the Intel flasher finishes writing the new bios it hangs (on my tab i never experienced that) yet i have owners of x98 that did have the hang. because of this the next verify operation will never start and the tab will hang... if such a case nothing much you can be done, but force a power off (in all the cases experiencing hangs the bios was flashed ok). the verify operation is not so much important (i never had a failed verify operation in past, moreover the flashing is done while in EFI/BIOS stage so nothing can interrupt it in order to mess the writes)
risks... of course there are (but i would say a less than flashing from windows or android)... but since you need to use this i guess it's either this or a flash programmer
ps. goes without saying ... WHAT bios file YOU will use is your responsibility so make sure you use a correct one for your tab model or you might HARD-BRICK!!!... this tool just takes it and writes it on your device!
So it happened day before yesterday, 8-22-17 @ ~5:50 PM, my Verizon S6 Edge (G925VZKE [64GB]) bricked out. No LED Light, nothing on Screen, nothing as if actually Hard Bricked. No booting, No download Mode, nothing. But it's not fully hard bricked actually. When I plug the device into my PC, Windows will either pop and say the device malfunctioned or it will read as "Exynos7420". I'm not quite sure what to do about it at the moment, I've read [a little] about what to do with phones in this mode using a "USB_Down_Load_32bit"/Multidownloader. I believe it to be stuck in a Diagnostic Mode I'm not versed in. This all happened while I was in the ADB Root Shell (su:s0) while the device was powered off and charging.
I am making this thread here for any devs you would want to use the knowledge and files here, to take the project further. As I cannot currently use my device at all. And I won't be getting a replacement S6 Edge for at least a month, maybe two. I love the S6, and will still choose it over most devices. I've been dedicated to researching and posting about the Samsung Exynos7420 Hardware since September 2016. That was when I came up with the plan for The Greyhat Root Project. You may recall my other thread once in the Original Development Forum & now in General. If you search "Greyhat Root" in google. My thread will be the first result. It gained a lot of traction, very very quickly. But is now dead, and the mods probably hate me for making a new thread. But I'm not trying to put new news out there this time.
It focused on how to use Kali Linux and Metasploit. It also focused on the articles at the time that was new exploit & malware research, that boasted of the possibilities we've now come to know as the Vault7 leaks. There's probably a reason I was a victim of the malware myself and I took down most of the posts. Most of the good file and resources I posted to that thread were either flagged by end users or removed by google. The real treasure of that thread is lost to the internet now, as that was the only backup I had of some of the critical files needed for the process. If you actually look through my individual posts all over, you will find some juicy tidbits of knowledge spread around this site that I've not compiled into one. A lot of it is still over my head as it was then, and partly why I took it down then. But I've been chipping away at that knowledge base everday for 10 months going on a year now. It's possible to root this device if One can take the knowledge of how to leverage the news worthy exploits from the past 2 years into a single repo/application. "Android-InsecureBankv2" is one example of such a platform. But as a teaching platform, it is not configured to provide a SuperSu Root Solution out of the box. It would still require modification of someone else's codebase w/Learning Curve.
No I have not managed to find a way to unlock the bootloader because I do not have a copy of IDA Pro or the Hex Rays Decompiler, and if I did, I still wouldn't know to use them fully. But I have managed to find quite a number of very possible attack vectors, if I can get some serious developers to take my sentiments seriously. I proved that when the posts about dirtycow were largely ignored due to device interest, and then @droidvoider helped make some of my ideas possible with the "Greyhat Root Console" he made. Realistically at this point I only wish I were an Assembler. I'm only one guy trying to poke at a Hardware/Software Package created by multiple departments of people in a conglomerate corporation. I only bring people together. I do know that in order to disassemble the Exynos7420 sboot, you're going to need to understand U-Boot on Arm64. A Uboot version dating back to either January 2016 or August 2015. I say those two dates because, The 4BOG7 files on my device date to August 2015, the 4AOJ1 files, to January 2016. Project Zero (who does a lot of tests on the G925v btw), posted in February 2017 about they found a way to bypass the KASLR feature of the stock kernel. A Kernel I do believe we can still flash to the device. It didn't gain much attention I don't think at the time because it was only one piece to the puzzle. That exploit wasn't patched until January. I know it sounds bad when I say it like this but, what this device truly needs is a friendly Botnet-C&C-Style rootkit that has it's client and server controlled by a User-Controlled, SuperSu-Style management application. Yes, it would be a rootkit you would never want to have someone else in control of. But if SuperSu were controlled by someone else other than the end user at the time, it would be just as bad. It's just a different approach to a yet unpublished methodology.
*
** The Device I refer to is currently flashed with:
******
** Full 4 File Firmware: COMBINATION_VZW_FA50_G925VVRU4AOJ1_VZW4AOJ1_CL5133452_QB6486176_REV02_user_mid_noship.tar
** BL: G925VVRU4AOJ1 ENG sboot.bin
** AP Kernel: G925VVRU4BOG7 ENG Kernel
** TrustZone Type: t-base-tui (Filenames suggesting Mobicore present as well)
******
Trying to enter Recovery Mode with the Combo firmware, in my experience, typically sends the device into a Panic and boots into "Upload Mode" if it does not simply reboot. The combination firmware does not supply a recovery.img that I've found. And inorder to recover the ENG Combination Recovery, you would have to disassemble the OJ1 ENG sboot.bin in IDA Pro and pull it out.
During the initial boot the device will enter its own recovery mode for a moment while it does its erasing stage. I used "nand erase all, re-partition, F.Reset Time, Phone Bootloader Update options in ODIN. During this breif moment with the "Erasing..." text on-screen, the phone is available in ADB Devices and shows up in recovery mode. Meaning ADB Shell should be accesible in recovery. If that's possible that means the device keystore should be accessible as well. The Recovery images tend to be bigger because the signatures are stored in the recovery from what I've read. Can't dirtycow patch anything it can see if your shell can't change it?
Using those files, I have full su authority anytime I am in ADB Shell, the shell runs within the "su:s0" context, and not the "shell:s0" context. Any and All changes are possible through the shell. Writing a new partition Table to '/dev/block/platform/15570000.ufs/sdb' using the "partx" tool, is probably what broke my phone. So in theory installing SuperSu in System Mode should work much the same as it did on G95x S8/Plus I'm gathering. @dragoodwael was correct in supposing "sdb" to be the bootloader overall, as I do now too. Once the reboot command was issued, I lost the ability to do anything at all. All thats possible now, is to find a tool that will communicate with the driver my PC's Device Manager loaded for my phone.
Every boot.img I've unpacked using Android Image Kitchen specified that a signature of "SEAndroid Type was found". BUT, the only boot.img/Kernel that did not specify that it was an "SEAndroid Type" while being unpacked, is the Stock boot.img from the 4AOJ1 Combination Firmware. Out of the 7 boot images I've unpacked, AIK determined the OJ1 Combination boot.img did NOT have an SEAndroid Signature on it.
boot.imgs I've unpacked:
1. N920A - PB2 Eng boot.img
2. N920A - FA51 Combi - PH1 boot.img
3. N920A - FA51 Combi - PL1 boot.img
4. G925V - FA50 Combi - OG2 boot.img
5. G925V - FA50 Combi - OJ1 boot.img
6. G925V - OG7 Stock boot.img
7. G925V - OG7 ENG boot.img
I'm not quite sure what that means yet, but I do know that the zip file I have that contains the 4AOJ1 factory Binary is not a tar.md5 like usual, it is just a normal .tar. What I'd LOVE to know is, can the 4AOJ1 stock boot.img be unpacked, then repacked, and retain its flashable characteristic. Because AIK does not register a standard signature. Does that mean the Oj1 boot.img uses a different mechanism for signature verification than a standard user binary, or is it simply signed with publicly available signing keys? It's a good question, what is different about its signature compared to other stock signatures. Even if we don't understand the signatures fully.
I'm also aware of the fact, that the Combination firmware doesn't actually contain a recovery.img to flash. Probably why the Device goes into Upload Mode and Panics when trying to boot recovery after using "nand flash all" and/or "re-partition" in ODIN. But if there were a Recovery Image for the OJ1 firmware, I imagine it would not have an SEAndroid signature on it as well. So there must be something to that.
I wonder what would happen if you tried to flash the OJ1 boot.img to the recovery partition as recovery.img like in the "EasyRecowvery" project, while using the full factory binary.
Is it possible that the newer "ustar" tar format used by Samsung in ODIN packages, could be using the custom fields available in a ustar header block to hold at least part of the signing mechanism? I believe so. And I say it because on my Device, it runs the Odin3 Engine (v1.1203), which looks an aweful lot like ODIN v1.12.3. Besides the naming conventions used there, ODIN expects to send/receive images within tar archives. Specifically USTAR format tar archives. So if the ODIN Engine on the phone is anything like the PC Client application, it expects USTAR format Tar archives as well. If it expects to read in a USTAR Header block, there are custom fields possible in known locations of the official tar files. Which when parsed correctly, should lead to finding the extra data after the payload 7-Zip refers to when the tar.md5 files are extracted. I'm of the mind the "Star" utility and not the the "Tar" utility is what we should be using to create and modify ODIN firmware the way our OEM's do. That is hypothesis on my part yes, but I don't think I'm very far off base.
Here is a man page on the "ustar" utility I found interesting and extremely in-depth: ustar(1) - unique standard tape archiver - Linux man page
If you want to see a list of files involved in all of this research, please refer to this folder here: https://drive.google.com/open?id=0B_EcHdXbjhT_dDRneE56WUg3Mlk
It contains all the files I've mentioned except for the OJ1 Firmware itself. This is all I'm posting for today, it's a sad day indeed. But I have to gather the bookmarks again to post the links to articles.
Hi everyone.
I have bricked my phone and I don't know how to fix it. When I turn it on, it shows a green screen with two rectangles (one blue, one red).
Sometimes, after that screen with the rectangles, there is a menu to configure my device, ant it says "welcome to device D188" , and when I choose the language, setting as new phone, it tries to connect to network but it never does. So I'm stuck there.
Before this mess, I made a backup of the oem info with twrp, but I think something went wrong because it seems that this oem info has a one ".bin" archive (that i what I've seen looking in the internet), and my twrp backup is a folder with a lot of files(with .win, .sha2, .in extensions). I have two called oeminfo.emmc (one is .win, one is .sha2).
I've tried creating a dload folder with the update.app file in my micro sdcard, and then try to update but it shows "failed".
I was going to try and flash my phone via ADB but then I realised that I have to extract this update.app and I cannot do it because appears the error: RECOVERY_RAMDIS.img: Invlid header crc - Expected: 36587 Got: 6910.
PD: all this comes because I have the Huawei P10 chinese version, and Android Pay wasn't working in Europe (I had some problems adding my card). I thought that was a problem of the chinese ROM in Europe (because when I was in China, I dind't have that problem). So, what I did is rebrand my phone, but Android was still not working (this time because android pay detected a custom rom), and anyway, I didn't like it because the update system option disappeared, in system was a lot of information that wasn't about my phone, that it was wrong (things as processor, ram, etc.). And here is the crazy thing, I went to TWRP, and I restored, when I only had a backup of OEM, system and something else...
I think my phone is now usless and canoot be fixed, but I had to try posting this, just in case someone can help me.
Thanks.