Hello, readers.
I am about to receive a MT6577-based phone. My religion prohibits me from using windows :silly: and I am using Linux since good old 1993,
I have done a lot of reading during the past months. I have installed the Android SDK, and thus I have adb up and running and I believe
I won't have problem in rooting the phone (which I must do as first thing). I have found a terminal application. I believe it will be
reasonably easy for me to find myself at home.
The only big gap I still have is on how to proceed about flashing updated/modified roms to the phone. There is a very informative thread
on china-iphone.ru about the specific phone I will get. It is in Russian, but thanks to Babelfish I was able to understand a lot. Most
important, I got hold of the latest official rom for the phone I will receive.
But then, how to proceed with flashing? all tutorials I found describe the windows way of transferring this file's
contents to the phone. Use is made of one of two tools that Mediatek apparently released. This is a no-no for me. I mean: Android is
Linux. I should not have to downgrade to windows to deal with my Linux phone! And then, I simply have no windows whatsoever here.
I see three possible ways for me to proceed:
Find an equivalent software that runs under Linux
Try to run one of Mediatek's softwares under Wine
Obtain from Mediatek, or elsewhere, the precise specs about the USB protocol being used, and implement my tool
Reverse-engineer the protocol
The first item is, I believe, a dead end. I think my search has been exhaustive enough.
The second one is a path I'd rather not tread.
The third one would be a nice project, but I perceive that Mediatek is a bit opaque when it comes to providing technical specifications.
The fourth one would very quickly come to a dead end, I believe, with a bricked device.
Any suggestion on the above, or on other possible ways?
Also: I have come across some very vague mentions about flashing this sort of devices from recovery mode.
From what I have gathered, you put the rom file on a SD card, and then enter recovery mode and let the phone do its own flashing.
This would be ideal for me, but I came across no mention about this mechanism on threads that are specific to this class of phone.
Do MT6577-based phones come with recovery mode? How is it used?
I would be thankful to anyone who could provide details on this aspect.
So far I have only flashed a custom recovery into my MTK6577 phone and I did it with dd.
The full ROM is exposed on /dev/block/mmcblk0.
Once you have rooted your phone you can use dd along with the info in the scater file (from windows tool) or from Memory/eMMC in the EngineerMode (at least in my phone).
Good Luck
P.S.: In my phone the recovery can be booted into from the phone info in Settings.
Or pressing volume up when turning on the phone and releasing volume up once it vibrates (if not it goes to factory mode that has a bunch of tests in it).
Or using adb reboot revovery
FrankVM said:
The full ROM is exposed on /dev/block/mmcblk0.
Once you have rooted your phone you can use dd along with the info in the scater file (from windows tool) or from Memory/eMMC in the EngineerMode (at least in my phone).
Click to expand...
Click to collapse
Thanks a lot.
Indeed, I had found out about using dd plus the info in the scatter file. At first I completed the task of loading a different recovery image, and that was sufficient at the moment. Later on, I spent another weekend on this: I started working on a Ruby script that, by interfacing with the phone via ADB, would dump and upload any partition, and possibly do the reverse, too. The upload part sort-of worked, and I was able to get hold of the current booting partition. What I wanted to do was to modify the boot script to let me run at boot a script resident on one of the sdcards.
I got to the point of unpacking the data in the gzipped/cpio-ed root fs archive, and certainly I would not have had problems modifying the script. But I was blocked when I tried to find the data about the format of ROOTFS. I mean: I could find the start of the compressed material, but I could not find exact reference about those few bytes that preceed it. Must those bytes change if the actual content changes?
I only have one phone, and I certainly do not want to brick it (or have to pour half-days of work into blind-man debugging mode...)
The block is 512 bytes long, filled with 0xff's except for (in my case)
00000000 88 16 88 58 │ 9F 94 08 00 │ 52 4F 4F 54 │ 46 53 00 00 │ 00 00 00 00 . X ..ROOTFS......
00000014 00 00 00 00 │ 00 00 00 00 │ 00 00 00 00 │ 00 00 00 00 │ 00 00 00 00 ....................
and it seems quite clear that the only data that may change are the first 8 bytes - presumably 4 shorts, which in my case would have the values:
5768
22664
38047
8
When I find out what these numbers are, and when I have another free weekend, I may go on in my exploring path.
I looked into modifying boot/recovery images a few weeks back but haven’t gotten around to fiddling with mine.
The initial data is the uboot header, if I remember correctly. It does need to change.
There is a tool out there in perl that does all the required to unpack and repack the boot images for MTK65xx phones.
Here is forum page with the tool info: http://forum.xda-developers.com/showthread.php?t=1587411
my way to do it on ubuntu
well I basically did it on ubuntu, but it was actually virtual box windows under ubuntu so...whatever
This thread is from 2012... 3 years later in 2015 and not a single mtk flash tool was developed for linux... i bet using a windows based phone it will be easyer to find that kinda tool
Now there is a flash tool for Linux available, (look for needrom.com -> sp-flash-tool-v5-1424-00),but I can't get it to work. I suppose there is a vcom driver missing. Unfortunately my phone (UMI Hammer) does not support adb flash, otherwise I would be very happy to do it that way.
I think it took so long that a linux flash tool became available because MediaTek didn't share their code with developers. They changed their policy about a year ago, though.
I wrote a tutorial for setting up the SP_Flash_Tool_Linux
It works
Related
Hey all,
I've been looking into how QDLTool works a bit and figured out how to swap the images that it flashes. Please note that QDLTool verifies image hashes for a good reason. You should understand the risks before attempting to meddle with QDLTool for any reason. Anything you do is at your own risk.
I would *strongly* recommend not flashing anything but amss, system, recovery and boot from any custom builds. Any time you flash a partition image, dbl, fsbl or osbl, you run the risk of bricking your device beyond recovery.
Important note: The information below is based entirely on analysis of QDLTool. I haven't used this to flash an image yet. If you plan on using this for development, you'll have to take that step.
Let's get to the details:
QDLTool automatically determines what to flash from the images/ directory. It stores a hash internally for each of the files that it will flash. This hash is basically just a 32-bit XOR of the bytes in the file:
Code:
#!/usr/bin/python
import sys
x = open(sys.argv[1], "rb").read()
print "%02x%02x%02x%02x" % (reduce(lambda x,y: x^ord(y), x[3::4], 0), reduce(lambda x,y: x^ord(y), x[2::4], 0), reduce(lambda x,y: x^ord(y), x[1::4], 0), reduce(lambda x,y: x^ord(y), x[0::4], 0))
To swap out an image, you need to patch the old hash of a file that was previously flashed with the new hash of the file that you'd like to flash.
For this post, I'll assume you're looking at QDLTool from streakflash.zip with MD5 = 63b64ba6a9d1ee770998d2a0e4a19df1.
In this file, the hashes start at offset 0x5fa90. There are 14 of them:
Code:
0005fa90 0b b0 a7 5c 3e e9 bb 29 17 4e 8d ac a0 dc 43 62
0005faa0 2c 3f 4e f1 fb 6b fc 80 11 9d 22 07 66 70 22 4a
0005fab0 bc 38 64 95 d2 c6 72 29 6d f8 99 e2 cc 74 14 49
0005fac0 1b ad 7a 9c 77 fb ee cc
As 32-bit words, they are:
5CA7B00B
29BBE93E
... etc ...
9C7AAD1B
CCEEFB77
In order, they are:
00. Partition (hash = 5CA7B00B)
04. Dbl (hash = 29BBE93E)
08. Fsbl
0c. Osbl
10. Amss
14. Dsp1
18. DT
1c. Appsbl
20. Boot
24. System
28. Userdata
2c. Recovery
30. Logfilter
34. RCFile
So, if I wanted to flash a new recovery, I'd take the hash of my recovery file via the Python script above, then replace the bytes at 0x5fa90 + 2c = 0x5fabc with my hash (stored in little-endian, of course).
It's a bit of manual work at this point, but I think a lot of this could be automated. You'd probably be better off and safer using batch files and fastboot though.
we discovered batch files to flash the images is a bad idea as some images cant be flashed using the normal fastboot mode
Thanks,
i'am looking some infomation about QDLTool also.
but i've no idea what hash was
i'll probatly wait for some "automated" way
QDLTools has so much potention. Somebody that knows coding should make it a automated system for us the little people...
Sent from my Dell Streak using XDA App
Yes, it would be nice if someone could figure out a way to insert new "roms" into the QDL tool, so when new updates are release, it would be a no brainer to do the updates without having to go through a bunch of command lines, or hocus-pokus to get an updated rom (minus the bloated carrier rom) onto the device.
Years ago, I played around with Linux, and found the same issue. A lot of command line knowledge is required. My command line stopped at dos 6.x, going all the way back to dos 2.x
Windows spoiled everyone
I have successful compiled the exFAT userspace driver from http://code.google.com/p/exfat/ together with libfuse.
So we are theoretically able to mount every exFAT formatted drive (connected via OTG and also the external sdcard, BUT THIS IS NOT YET FULL TESTED).
This howto is far away from being perfect. Also my english isn't perfect - sorry. Feel free to send me corrections.
@Mods: I think it's a development-related thread. If this is not your mind, please move it to the right section - thank you very much (and also for your continuously work in the "background").
* For updates please have a look in the footer of this post, I forgot to reserve a second "post space" *
Please be very careful! I am not responsible for any damage or lost data on your phone or storage. I have tested this on my phone with a connected card reader and with the "external" sdcard
(Galaxy S2, usually mounted at /sdcard/external_sd).
ATTENTION:
I have discovered one "big" problem that must be solved before all other things and I NEED PERHAPS SOME HELP!
Binaries attached read update no. 2:
After every reboot the exFAT partition will be damaged WITHOUT modification of the vold.fstab config, so don't use a card or drive with important data on it.
This has to do with the automount function of the "New Volume Manager Daemon" Vold.
I suspect that the daemon wants to mount the exFAT volume as FAT32 read/write and overwrites the first bytes of the the first block. I will check this.
It doesn't matter if it's the "external" card or a connected drive/sdcard reader.
The problem:
dd if=/dev/block/mmcblk1p1 of=/sdcard/exfat_ok.bin count=1 bs=1024
hexdump -C /sdcard/exfat_ok.bin
the correct hex:
00000000h: EB 76 90 45 58 46 41 54 20 20 20 (three bytes and then the string EXFAT plus three spaces. This is the recognition string for the exfat-utils (exactly 8 bytes)
dd if=/dev/block/mmcblk1p1 of=/sdcard/exfat_not_ok.bin count=1 bs=1024
hexdump -C /sdcard/exfat_not_ok.bin
after a reboot of the phone the string changes to
00000000h: 52 52 61 41 58 46 41 54 20 20 20 (four new bytes at the beginning -> AXFAT, the recognition of the partition fails) I think no more changes are made.
This is not in relation to the exFAT tools or the FUSE library, the "damage" happens before!
Beside that, the exFAT card seems to be usable and after manually mount to /sdcard/external_sd the card can be activated (under settings - memory) - Sorry I have a german GUI...
STOP READING HERE IF YOU DON'T WANT TO PLAY WITH YOUR DATA ON THE EXFAT PARTITION!
There is no long term experience with this. Don't try it if you don't have some skills with Linux and Android. Make a full backup!
You have been warned...
[Q] Why exFAT and not using ext2/3/4 or any other file system?
[A] I don't know. It's your decision. exFAT is developed mainly for flash memory and could be used "out of the box" with newer windows versions and Mac OS X in contrast to ext2/3/4.
Sadly there is no good extX windows driver out available.
exFAT also supports XDHC card from 32 GB upwards. See http://en.wikipedia.org/wiki/ExFAT for more details.
XDHC cards are reported to work with the SG2.
This makes it interesting for micro sdcards greater than 32 GB (if your are lucky and have one) and for large files (greater than 4 GB), like video files.
Note: FAT32 is of course able to address more than 32 GB, but not "official".
There are many disadvantages as well, read the article.
[Q] Is it free and/or free to use?
[A] Once again, I don't know exactly. Tuxera http://www.tuxera.com/ has an agreement (licence program) with Microsoft and announced an exFAT driver for Android, but I couldn't find a free downloadable (source) package.
The driver is probably free to use but not free to distribute and until now not released.
The exFAT project on Google Project Hosting is licensed under GNU GPL v3, so we will and can use it free. But it's still in beta stage.
[Q] What do I need?
[A] A rooted Android phone with a suitable kernel and fuse support, take siyah (because it a good kernel). I have only a Samsung Galaxy S2, that's because the thread is here.
Enough free memory. Installed busybox. Access via adb shell or a ssh-terminal connection (QuickSSHd or SSHDroid from the market).
An other option is to use a terminal window on the phone.
[Q] What could be possible?
[A]
automatically mount the OTG drive with util-linux-ng or vold or something like that (needs support from kernel or ROM)
replace the FAT32 partition of the "external" sdcard (external_sd) with exFAT (needs support from both kernel and ROM I think)
OK, let's start...
First option, the harder way (you need a linux machine for this): Compiling the driver and utils
Download the CodeSourcery Toolchain/Crosscompiler for ARM EABI for Linux from https://sourcery.mentor.com/sgpp/lite/arm/portal/[email protected]=lite (tested with 2011.03-41, I saw a newer untested version Sourcery G++ Lite 2011.03-42)
Install the compiler on your linux box with (for example) sh ./arm-2011.03-41-arm-none-linux-gnueabi.bin, the installer will asking you a few questions, it should be easy.
Download latest stable fuse (fuse-2.8.6.tar.gz) from http://fuse.sourceforge.net/
Download fuse-exfat (exfat-utils-0.9.5.tar.gz and fuse-exfat-0.9.5.tar.gz) from http://code.google.com/p/exfat/ or use my prepared packages with the Makefiles
Prepare the cross compiler, this is my example script, please change the path (CROSS_PATH) to the CodeSourcery binaries and the CROSS_ROOT path
Make a directory (CROSS_ROOT) for the libraries and the headers, ex.:
/android/src/cross/lib
/android/src/cross/include
---- File prepare_codesourcery.sh
#!/bin/bash
export CROSS_PATH=/android/CodeSourcery
export CROSS_ROOT=/android/src/cross
export ARCH=arm
export PATH="$CROSS_PATH:$PATH"
# version 2011.03-41-arm-none-linux-gnueabi
export CROSS_COMPILE="$CROSS_PATH/bin/arm-none-linux-gnueabi-"
export CFLAGS=' -I$CROSS_ROOT/include -g -O2 -static -march=armv6 -mfpu=neon -mfloat-abi=softfp'
export LDFLAGS=' -L$CROSS_PATH/arm-none-linux-gnueabi/libc/lib -L$CROSS_ROOT/lib -Wl,--whole-archive -lpthread -lrt -ldl -Wl,--no-whole-archive'
export CC="$CROSS_PATH/bin/arm-none-linux-gnueabi-gcc"
----
Export the setup:
. ./prepare_codesourcery.sh
Check the path with
arm-none-linux-gnueabi-gcc -v
Compile libfuse
./configure --host=arm-linux --enable-util --enable-lib --disable-mtab --enable-static=yes --enable-shared=no
make
copy the static libraries libfuse.a and libulockmgr.a from fuse-2.8.6/lib/.libs to $CROSS_ROOT/lib
copy the headers (.h-files) from fuse-2.8.6/include to $CROSS_ROOT/include
c) and d) is not really necessary, but is used for the flags to find the headers and libs, see the file prepare_codesourcery.sh above.
Compile fuse-exfat
I had no luck with SCons (a substitution for make) to cross compile for ARM, so I created some Makefiles to build fuse-exfat and exfat-utils, see attachement
Note: the next step is not necessary, libexfat is also included in exfat-utils if you use the attached source package:
Use your downloaded sources package and copy the Makefiles from my packages to every directory or use my source packages
In fuse-exfat/fuse-exfat-0.9.5 run make
Compile exfat-utils
In fuse-exfat/exfat run make
Note: If you get errors like strip: "Unable to recognise the format of the input file" then you have to symlink arm strip to strip temporary with
ln -s $CROSS_PATH/bin/arm-none-linux-gnueabi-strip $CROSS_PATH/bin/strip
so arm-strip is used instead of strip from your linux dist
Second option: Download the binaries
1.-9. Don't care about it...
Copy all binaries to your phone. They are big but "portable" because of the static build. You can use adb or any other method. The files must be executable, so place them for example in /system/xbin or /data/ and chmod them 755
Connect an empty hard drive, empty pen drive or a card reader with an empty sdcard to the phone with an OTG cable. The drive should only contain a prepared partition (don't care about the file system).
But you can also create a partition with fdisk on the phone, if your busybox installation is useable.
Check the connection of the USB devices with
lsusb
or something like that
Check the partitions with
cat /proc/partitions
You have to see a new partition like sdc1. The partition is visible under /dev/block/platform/s3c_otghcd/sdc1
Create a new exFAT partition with
mkexfatfs /dev/block/platform/s3c_otghcd/sdc1
Check the type of partition with
fdisk -l /dev/block/platform/s3c_otghcd/sdc
(you should see it as "HPFS/NTFS")
Make a new directory ex.
mkdir /data/exfat
for the mount point
Mount the new exFAT partition read/write with
mount.exfat-fuse -o rw /dev/block/platform/s3c_otghcd/sdc1 /data/exfat
to mount point /data/exfat or any other path
or for testing with
mount.exfat-fuse -o ro /dev/block/platform/s3c_otghcd/sdc1 /data/exfat
readonly
To unmount the device use
sync
umount /data/exfat
Thanks to gokhanmoral for his great kernel, tolis626 and olifee (members of this forum) to give me the idea of doing this, unknown devs from http://repository.timesys.com/ for a example Makefile to bypass
the unwieldy "SCons". I wasn't able to use it for cross compiling because of tons of parameters and variables, my shame...
Links:
exFAT (GPL): http://code.google.com/p/exfat/wiki/QuckStartGuide (it's not a typo)
Some informations: http://en.wikipedia.org/wiki/ExFAT
SiyahKernel: http://forum.xda-developers.com/showthread.php?t=1263838
exFAT Makefile: http://repository.timesys.com/buildsources/f/fuse-exfat/fuse-exfat-0.9.5/fuse-exfat-0.9.5-make.patch
CodeSourcery: https://sourcery.mentor.com/sgpp/lite/arm/portal/[email protected]=lite
FUSE (Filesystem in Userspace): http://fuse.sourceforge.net/
Update no. 1 | 01/12/2011
I think I made one step forward: It's vold as I can see.
I have commented out the block for the external_sd in /system/etc/vold.fstab
# external sdcard
#{
# ums_path = /sys/devices/platform/usb_mass_storage/lun1/file
# asec = enable
#}
#dev_mount sdcard1 /mnt/sdcard/external_sd auto /devices/platform/s3c-sdhci.2/mmc_host/mmc1
Now after new rebooting the partition is not damaged and I was able to mount it as expected at /sdcard/external_sd.
The disadvantage is now is that the system cannot recognize the card as a regular sdcard and the memory part in settings is greyed out.
It's like the card is not insert for the ROM, nevertheless the directories are shown in a file explorer like "root explorer" (with free/used values and I could edit a text file with a build-in editor)
Update no. 2 | 05/12/2011
I am now sure after some (more) tests, it's the vold daemon.
To mount a exfat volume, the configuration /system/etc/vold.fstab needs modification.
DO NOT MOUNT A VOLUME WITHOUT MODIFICATION
vold (version 2) is locked to VFAT/FAT32 volumes. Earlier versions had support for ext(2/3/4 ???) volumes too, this was removed by Google and/or Samsung (don't know).
Sadly I can't find a documentation for vold2 and I am stuck here. Because for replacing the "external_sd" from FAT32 to exFAT it's also necessary that vold2 recognizes the card correctly. (Because of the "asec" mounts for Apps2SD).
Perhaps it's possible to map this mounts to the internal sdcard (setting asec = enable in vold.fstab), but I haven't tried this yet.
Conclusion: It's possible to mount such exFAT volume with some restrictions and with modification of the vold.fstab.
Specs:
/data/bin/dumpexfat /dev/block/mmcblk1p1
dumpexfat 0.9.5
Volume label
Volume serial number 0xb965fe93
FS version 1.0
Sector size 512
Cluster size 32768
Sectors count 25173456
Free sectors 25169728
Clusters count 393284
Free clusters 393277
First sector 0
FAT first sector 128
FAT sectors count 3136
First cluster sector 3264
Root directory cluster 5
Volume state 0x0000
FATs count 1
Drive number 0x80
Allocated space 0%
Please no questions about the values, there is a second ext4 partition on the card...
So the configuration in vold.fstab and perhaps some other files have to be changed. I have nearly no knowledge with "void". Is a expert out there?
From command line a short speed test shows this result (no other GUI test possible in the moment):
/data/bin/hdparm -tT /dev/block/mmcblk1p1
/dev/block/mmcblk1p1:
Timing cached reads: 228 MB in 2.01 seconds = 113.27 MB/sec
Timing buffered disk reads: 36 MB in 3.02 seconds = 11.92 MB/sec
Card: Patriot 16 GB Class 10, no OC
RESERVED
Reserved...
Did you test the overhead of a FUSE filesystem on Android? As far I know the performance may be sub-optimal because of the overhead of using a filesystem on userspace mode. The Tuxera driver uses kernel mode and is very optimized, but as far I know it's only for OEM's that want to license the module for their devices.
Anyway, very interesting, mainly because exFAT is the default filesystem for SDXC.
z3r0n3 said:
Did you test the overhead of a FUSE filesystem on Android? As far I know the performance may be sub-optimal because of the overhead of using a filesystem on userspace mode. The Tuxera driver uses kernel mode and is very optimized, but as far I know it's only for OEM's that want to license the module for their devices.
Anyway, very interesting, mainly because exFAT is the default filesystem for SDXC.
Click to expand...
Click to collapse
No, I have not tested this. It will be one of the next steps if there is a solution for the problem I wrote about. In the moment I don't know if it's kernel related, rom/vold related or anything other. But I think it should have less overhead than NTFS in userspace, surely more than FAT32. Please read the comments about speed at http://code.google.com/p/exfat/updates/list And yes, the Tuxera driver is not for us "end users". Perhaps Samsung will give us a present in the next official ROM release
z3r0n3 said:
Did you test the overhead of a FUSE filesystem on Android? As far I know the performance may be sub-optimal because of the overhead of using a filesystem on userspace mode. The Tuxera driver uses kernel mode and is very optimized, but as far I know it's only for OEM's that want to license the module for their devices.
Anyway, very interesting, mainly because exFAT is the default filesystem for SDXC.
Click to expand...
Click to collapse
I also did not test it . However, it should be comparable to a desktop machine (taking the slower CPU into account). My NTFS-3G experience for several years has shown it is actually pretty fast, but takes up a lot of CPU time if high fragmentation is present. Nevertheless, I think the throughput (with our devices CPU) will still be much higher than writing to SD-card in most cases.
And yes, although Linus said FUSE-filesystems are just toys, http://www.spinics.net/lists/linux-fsdevel/msg46078.html, they are very fast and stable toys in my experience.
I think we will not see an open-source kernel-module for exFAT / NTFS-3G in the near future. For one, there is the licensing-issue (which will be much more of a problem if it is included in the kernel-sources / can be built against them), and on the other hand, it always took some YEARS time until a new filesystem was reliable enough to warrant an accepted kernel module. After all, btrfs is just becoming widely accepted and stable after 4 years of development (and a shorter time in-kernel). And this is expected to be the next-gen filesystem for linux, and as such the focus of development. With the correct mount-options, it should also be nice to SD-cards . Maybe there will be some time to try it when kernel 3.1 (with the 'stable' version) comes to our phones.
So for the next years, the FUSE-solution is the best we can get, and for Android, the most compatible one across kernels and devices (it only needs a kernel-dependent kernel-module in addition to whats cooking here, after all). The perfomance graphs by Tuxera on their site even show that their fuse-exFAT is faster than in-kernel FAT, so I guess we should not worry about performance even with the open-source beta implementation. Maybe battery life could be an issue if CPU-usage spikes when copying large files, that might be worth some testing.
I'm personally not switching to exFAT in the near future, but will watch this thread and might do some experiments in some weeks when I have more time .
Thanks for the good work, smitna!
olifee said:
I also did not test it . However, it should be comparable to a desktop machine (taking the slower CPU into account). My NTFS-3G experience for several years has shown it is actually pretty fast, but takes up a lot of CPU time if high fragmentation is present. Nevertheless, I think the throughput (with our devices CPU) will still be much higher than writing to SD-card in most cases.
And yes, although Linus said FUSE-filesystems are just toys, http://www.spinics.net/lists/linux-fsdevel/msg46078.html, they are very fast and stable toys in my experience.
I think we will not see an open-source kernel-module for exFAT / NTFS-3G in the near future. For one, there is the licensing-issue (which will be much more of a problem if it is included in the kernel-sources / can be built against them), and on the other hand, it always took some YEARS time until a new filesystem was reliable enough to warrant an accepted kernel module. After all, btrfs is just becoming widely accepted and stable after 4 years of development (and a shorter time in-kernel). And this is expected to be the next-gen filesystem for linux, and as such the focus of development. With the correct mount-options, it should also be nice to SD-cards . Maybe there will be some time to try it when kernel 3.1 (with the 'stable' version) comes to our phones.
So for the next years, the FUSE-solution is the best we can get, and for Android, the most compatible one across kernels and devices (it only needs a kernel-dependent kernel-module in addition to whats cooking here, after all). The perfomance graphs by Tuxera on their site even show that their fuse-exFAT is faster than in-kernel FAT, so I guess we should not worry about performance even with the open-source beta implementation. Maybe battery life could be an issue if CPU-usage spikes when copying large files, that might be worth some testing.
I'm personally not switching to exFAT in the near future, but will watch this thread and might do some experiments in some weeks when I have more time .
Thanks for the good work, smitna!
Click to expand...
Click to collapse
I have some bad experiences with NTFS-3g on my netbook. Trying to transfer a large number of files from my netbook (running Arch Linux) to my external HDD (that is NTFS) and the transfer was slow and my CPU time are always on 100%. That's why I asked if it was tested, because I don't really know if FUSE is suitable for embedded devices. But yeah, the only way to know is to test, and it's still too early for that .
But licensing is really a issue? I know that Linux have module to read a NTFS partition (but not write, this is why we have NTFS-3g) and there was some work for a read-only module for exFAT too (sadly, it didn't get much attention).
Anyway, I'm not switching for exFAT too anyway and I don't know how they aprove exFAT as the default filesystem on SDXC cards, but it's important anyway and will be critical somewhere in the future to have support to this filesystem.
First of all, thanks for your work on this. I was shocked to discover that my SGS2 wouldn't support any filesystems that support large files on external sdcards. I was able to get your solution working in the sense that I could format an sdcard with exfat, mount it, write to it, and unmount it. Awesome! I am having one serious problem though: After editing the vold.fstab and rebooting, I get constant FCs after trying to install any APKs. It doesn't matter if I have my external_sd mounted or not. And these are not apps that are trying to install to the sdcard. Any ideas?
I've got the AT&T version of the SGS2 (i777), but I'm running Siyah's latest kernel. The FCs just say it's the media process.
dildano said:
First of all, thanks for your work on this. I was shocked to discover that my SGS2 wouldn't support any filesystems that support large files on external sdcards. I was able to get your solution working in the sense that I could format an sdcard with exfat, mount it, write to it, and unmount it. Awesome! I am having one serious problem though: After editing the vold.fstab and rebooting, I get constant FCs after trying to install any APKs. It doesn't matter if I have my external_sd mounted or not. And these are not apps that are trying to install to the sdcard. Any ideas?
I've got the AT&T version of the SGS2 (i777), but I'm running Siyah's latest kernel. The FCs just say it's the media process.
Click to expand...
Click to collapse
Sorry for my later answer!
This should be nevertheless a problem with the app2sd service and I have no solution for this. My thread here is only a howto, nothing for the "daily to use"...
I also don't know why there is no other selectable alternative file system for "us users" to use for the external card by default and not FAT32.
The media service depends on the vold daemon to my knowledge. So I cannot recomment this for the default external sdcard, because of the media service scans. If you want to store larger files (e.g. video files), you should better split your sdcard in one FAT32 partition and an additional ext2/3/4 partition. On this partition there is no 4 GB limit. The "media scanner" will not scan the files (videos etc.) on the partition, but you can choose the videos from your favorite player with the file chooser.
Hope this helps you a little bit.
Thanks for the response. I was actually trying out multiple partitions over the weekend to no avail. Granted, I was trying a combination of FAT32 and NTFS. It would actually work for a while until the NTFS partition would appear to get corrupted. I thought about ext2, but my understanding is that Samsung somehow disabled ext* support for external SD cards. Is that not the case? Anyway, I'm surprised that more folks haven't caught onto your work here because storing large files seems to be a fairly common issue for SGS2 users.
dildano said:
Thanks for the response. I was actually trying out multiple partitions over the weekend to no avail. Granted, I was trying a combination of FAT32 and NTFS. It would actually work for a while until the NTFS partition would appear to get corrupted. I thought about ext2, but my understanding is that Samsung somehow disabled ext* support for external SD cards. Is that not the case? Anyway, I'm surprised that more folks haven't caught onto your work here because storing large files seems to be a fairly common issue for SGS2 users.
Click to expand...
Click to collapse
I am using an ext3 partition with deactivated journalling and noatime option on the sdcard since months without problems. Of course I have also a FAT32 partition on the card to stay compatible with vold and media scanner. With a start script it is mounted after every phone restart.
OK, I must have misunderstood. So is it just that vold will not allow us to automatically mount ext* partitions? I'll try it with a script as soon as I can get some time. Thanks.
I would like to try this, for use connecting my camera which has a exfat formatted sdxc card in it via OTG. But have a couple questions since I can't test at this moment.
1: Do the binaries work on a ICS build (Siyah Kernel) or do they need updated?
2: Do I have to make any vold.fstab changes to prevent FS damage when using a OTG cable or is that just external sd?
3: If I have to make the changes will other devices (not memory) work normal without manual interaction?
shadowofdarkness said:
I would like to try this, for use connecting my camera which has a exfat formatted sdxc card in it via OTG. But have a couple questions since I can't test at this moment.
1: Do the binaries work on a ICS build (Siyah Kernel) or do they need updated?
2: Do I have to make any vold.fstab changes to prevent FS damage when using a OTG cable or is that just external sd?
3: If I have to make the changes will other devices (not memory) work normal without manual interaction?
Click to expand...
Click to collapse
Hello, I am still on GB, but I guess it should work on ICS too.
If ICS (or better the vold daemon) has not changed its behavior you have to modify vold.fstab to prevent damages. To do this, you have to disable automounting the exfat OTG device (commenting out the part for OTG and reboot). The other partitions (internal and external memory should work like before). Then mount your camera card manually. But be very careful with your data/pictures!
Hello, I'm working on an HTC Mazaa with Windows Phone and inside a partition I've found several times the EXFAT header, so I'm trying to mount it, but looks like it's EXFAT 2.0, while your implementation covers only 1.0.
Do you know if it's somehow possible to mount EXFAT 2.0? On Windows, on Linux, modifying your tool, whatever!
Here's the header:
Code:
012f7400 eb 76 90 45 58 46 41 54 20 20 20 00 00 00 00 00 |.v.EXFAT .....|
012f7410 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
012f7440 00 00 00 00 00 00 00 00 00 1b 00 00 00 00 00 00 |................|
012f7450 20 00 00 00 36 00 00 00 8c 00 00 00 74 1a 00 00 | ...6.......t...|
012f7460 02 00 00 00 94 01 eb 07 00 02 10 00 09 00 02 80 |................|
012f7470 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
012f7480 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
012f75f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
012f7600 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
012f77f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
012f7800
Thanks!
WhiteTrap said:
Hello, I'm working on an HTC Mazaa with Windows Phone and inside a partition I've found several times the EXFAT header, so I'm trying to mount it, but looks like it's EXFAT 2.0, while your implementation covers only 1.0.
Do you know if it's somehow possible to mount EXFAT 2.0? On Windows, on Linux, modifying your tool, whatever!
Here's the header:
Code:
012f7400 eb 76 90 45 58 46 41 54 20 20 20 00 00 00 00 00 |.v.EXFAT .....|
012f7410 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
012f7440 00 00 00 00 00 00 00 00 00 1b 00 00 00 00 00 00 |................|
012f7450 20 00 00 00 36 00 00 00 8c 00 00 00 74 1a 00 00 | ...6.......t...|
012f7460 02 00 00 00 94 01 eb 07 00 02 10 00 09 00 02 80 |................|
012f7470 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
012f7480 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
012f75f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
012f7600 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
012f77f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
012f7800
Thanks!
Click to expand...
Click to collapse
I don't think that I can give you a good answer, sorry. It's not my tool, it's the exFAT driver from http://code.google.com/p/exfat/, the latest is fuse-exfat-0.9.7.tar.gz and I don't see any notes for a "version 2" in the ChangeLog. Are you really sure about the version? If there is a version 2, I guess it's more than only a change to the header.
I recommend you to post the question in the mailing list https://groups.google.com/group/exfat?hl=en. It is rumored that exFAT works natively on the new S3, but I don't know if this will be true and I have strong doubts that Samsung will release the sources of the driver.
smitna said:
I don't think that I can give you a good answer, sorry. It's not my tool, it's the exFAT driver from http://code.google.com/p/exfat/, the latest is fuse-exfat-0.9.7.tar.gz and I don't see any notes for a "version 2" in the ChangeLog. Are you really sure about the version? If there is a version 2, I guess it's more than only a change to the header.
I recommend you to post the question in the mailing list https://groups.google.com/group/exfat?hl=en. It is rumored that exFAT works natively on the new S3, but I don't know if this will be true and I have strong doubts that Samsung will release the sources of the driver.
Click to expand...
Click to collapse
It's fuse-exfat itself that says the version is 2.0. I'll try on the ML, but looks like there are big differences. If I make fuse-exfat ignore the fact that it's 2.0 it says that there are 2 FAT, which I think non-banal modifications to the implementation.
Thanks!
Seems that exFAT 2.0 is (or is very similar to) TexFAT.
I just wanted to say thanks I just tested this and the binaries works great on ICS 4.0.3 (LPG) using Siyah Kernel.
I plugged in my Panasonic Lumix TS2 digital camera with a 64GB sdxc card and was able to mount it fine on my S II with a OTG cable.
shadowofdarkness said:
I just wanted to say thanks I just tested this and the binaries works great on ICS 4.0.3 (LPG) using Siyah Kernel.
I plugged in my Panasonic Lumix TS2 digital camera with a 64GB sdxc card and was able to mount it fine on my S II with a OTG cable.
Click to expand...
Click to collapse
Fine and thanks for sharing your experience! It's good to hear that the driver is useful for you.
I have galaxy s3 and the 64 gb exfat formatted card works on the stock rom of it.
But when i switch to custom rom which are not based on galaxy s3 own stock rom the card stops working.
No other rom beside galaxy s3's own come with exfat driver. so i was wondering if i use this in custom rom as for now its Cyanogenmod 10, would this mod of yours work?
please let me know.
thanks.
Scroll down for recent updates;
Has anyone ever heard more from h311sdr0id about his post (see here) to get more info about this "state" that allows you to flash MDK over ME7 in Odin? I'm curious to see if we can use that state, maybe in QDL mode to somehow either push an image to the phone or communicate with it using some methods/commands that E:V:A refers to on this page and a few pages after and before. It's also possible that we then might be able to use a modified unbrick.img (see here) to restore an MDK bootloader. So far those are the two ideas that I think have the best chance.
Also in this thread I started with the intention of compiling the entire stock firmware for the Dev edition (OYUAMDK), I mentioned at the bottom that when flashing the stock MDK restore Odin tar on an ME7 phone users usually get a "SW REV. CHECK FAIL: FUSED: 3, Binary: 1" message meaning that your current fuse counter in aboot is set to 3 but the binary your attempting to flash is set to 1 so the flashing attempt will fail and I'm willing to bet if you're on VRUDMI1 and you attempt to flash the MDK restore you will get a similar message but the FUSED: value will be set to 4, you can see the counter upped in this post from jeboo here. However, with flashing the dev OYUAMDK aboot file on S4's with a ME7 bootloader users will receive a "SECURE CHECK FAIL: aboot" message instead, I don't know if we might be able to use dev OYUAMDK aboot file and bypass the fused counter entirely, since the dev edition has an unlocked bootloader and the fuse is an efuse, so software enforced, not a hardware enforced qfuse. If anyone wants to go into more detail, or wants to expand on these ideas we I can expand on this info or we can collaborate ideas in the Dev discussion thread.
Other points to consider:
If you know how to use IDA pro, and can help with the base address of the binaries, that is probably our best bet to find a vulnerability in aboot, you can see jeboo and djrbliss discuss this a bit (here) and you can see Ralekdev show his findings here, also this gives the explanation of why you see the "custom unlock" boot screen that people constantly post about in the Q&A thread. Both of these threads along with djrbliss' blog discussing the S4 aboot vulnerability that lead to Loki (here), and exploiting the TrustZone (tz.mbn) on Moto's bootloaders (here) are good starting points in trying to find a new vulnerability.
If you know how to hexedit, then hexedit aboot.mbn from MDK, ME7, OYUAMDK, and MI1. You can see ME7 and MI1 are similar in both size and content, while MDK and OYUAMDK are more similar to each other in size and content. Obviously OYUAMDK differs from the others in the way it checks the recovery and boot partitions, (in djrbliss' blog on the S4 exploit he says "This bootloader differs between "locked" and "unlocked" variants of the Galaxy S4 in its enforcement of signature checks on the boot and recovery partitions.") but we are able to flash all bootloader partitions from the OYUAMDK firmware restore Odin file I made except aboot, so if you have any ideas on how we might be able to exploit any of that, please feel free to share.
If you do hexedit a dd'ed partition (if you copy mmcblk0p6 from your phone to your pc) you will see that its padded with zeroes at the end. You have to cut the padded zeros from the dd'ed image in order for the partition to be registered as a signed partition in Odin, etc. To do this, use Linux, open a terminal and type
Code:
sudo apt-get install hexedit
then enter your password and hit enter. Then go to the folder that contains the partitions you want to hexedit (for instance type cd /home/Your user name folder/Desktop/S4partitionbackups/" where "your user name folder" is whatever your username is and "S4partitionbackups" is a folder you create on your desktop containing a backup of your partitions) If you don't have a back up of your partitions you can create them using something like the command below, substituting mmcblk0p6 and aboot.mbn with the partition(s) you are interested in.
Code:
adb shell su -c 'dd if=/dev/block/mmcblk0p6 of=/sdcard/backup/aboot.mbn'
then
Code:
adb pull /sdcard/backup/aboot.mbn /home/Your user name folder/Desktop/S4partitionbackups/
then
Code:
cd /home/Your user name folder/Desktop/S4partitionbackups/
Code:
hexedit aboot.mbn
Quick guide on Hexedit controls/keys
shift+> will take you to the end of the hex file
shift+< will take you to the beginning
page up/page down it will take you up a page and down a page respectively
ctrl+c you will exit the hex file without saving any changes
esc+t you will truncate the file at the current location
ctrl+x you will save the file with all changes you have done.
This is an example of a padded aboot.mbn, before hexediting, and prior to truncating the file a at the first "0" in the string "00 01" found between the end of the actual file and the padded zero's and repeating F's
View attachment 2353922
This is an example of a properly signed aboot.mbn after hexediting
View attachment 2353923
How to find start addresses
First you have to open the selected bootloader with a hex file editor and look at the header, converting for little endian you can find the start addresses and offsets
Code:
[B]sbl1.mbn = 0x2a000000[/B]
00000000 D1 DC 4B 84 34 10 D7 73 15 00 00 00 FF FF FF FF ..K.4..s........
00000010 FF FF FF FF 50 00 00 00 [COLOR=Red]00 00 00 2A[/COLOR] 40 72 01 00 ....P......*@r..
00000020 40 41 01 00 40 41 01 2A 00 01 00 00 40 42 01 2A @[email protected]*[email protected]*
00000030 00 30 00 00 01 00 00 00 04 00 00 00 FF FF FF FF .0..............
[B] sbl2.mbn = 0x2e000000[/B]
00000000 16 00 00 00 03 00 00 00 00 00 00 00 [COLOR=Red]00 00 00 2E[/COLOR] ................
00000010 40 51 02 00 40 20 02 00 40 20 02 2E 00 01 00 00 @[email protected] [email protected] ......
00000020 40 21 02 2E 00 30 00 00 12 00 00 EA 5F 00 00 EA @!...0......_...
00000030 62 00 00 EA 65 00 00 EA 68 00 00 EA 6B 00 00 EA b...e...h...k...
[B] sbl3.mbn = 0x8ff00000[/B]
00000000 18 00 00 00 03 00 00 00 00 00 00 00 [COLOR=Red]00 00 F0 8F[/COLOR] ................
00000010 20 20 04 00 20 EF 03 00 20 EF F3 8F 00 01 00 00 .. ... .......
00000020 20 F0 F3 8F 00 30 00 00 D3 F0 21 E3 D3 F0 21 E3 ....0....!...!.
00000030 00 70 A0 E1 09 02 A0 E3 00 D0 A0 E1 DB F0 21 E3 .p............!.
[B] aboot.mbn = 0x88e00000 offset = 0x285[/B]
00000000 05 00 00 00 03 00 00 00 00 00 00 00 [COLOR=Red]00 00 E0 88 [/COLOR] ................
00000010 10 56 14 00 10 25 14 00 10 25 F4 88 00 01 00 00 .V...%...%......
00000020 10 26 F4 88 00 30 00 00 06 00 00 EA F0 38 00 EA .&...0.......8..
00000030 F6 38 00 EA FC 38 00 EA 02 39 00 EA 08 39 00 EA .8...8...9...9..
[B] tz.mbn = 0x2a000000[/B]
00000000 19 00 00 00 03 00 00 00 00 00 00 00 [COLOR=Red]00 00 00 2A[/COLOR] ...............*
00000010 C4 3A 03 00 C4 09 03 00 C4 09 03 2A 00 01 00 00 .:.........*....
00000020 C4 0A 03 2A 00 30 00 00 09 00 00 EA 90 F2 9F E5 ...*.0..........
00000030 90 F2 9F E5 90 F2 9F E5 90 F2 9F E5 84 F2 9F E5 ................
[B] rpm.mbn = 0x00020000[/B]
00000000 17 00 00 00 03 00 00 00 00 00 00 00 [COLOR=Red] 00 00 02 00[/COLOR] ................
00000010 38 57 02 00 38 26 02 00 38 26 04 00 00 01 00 00 8W..8&..8&......
00000020 38 27 04 00 00 30 00 00 06 00 00 EA 1E 00 00 EA 8'...0..........
00000030 2C 00 00 EA 39 00 00 EA 46 00 00 EA 53 00 00 EA ,...9...F...S...
EDIT: 2/01/2014 - Updated OP to include where we're at
2/01/2014
1. Figuring out what Hellsdroid's method was - Unfortunately this seems unlikely as of now (figuring out what he did that is) On the other hand, @TMcGrath50 and I discussed a method we thought to be similar to his starting around here and then I learned how to use ida better as time went on and recently disassembled that I9505 S4 USB repair tool. I have not done a thorough analysis of the pseudocode yet though. But even so, this method has never been done before (as far as I know) and
in addition to assuming the information in the pic below is true, and we can in fact reset the emmc on our devices with Secure Boot 3.0 (would this be a way of getting around having to reset the Secure Boot bit in the pbl to "0"?) I still think this idea needs to be refined a bit before its worth exploring because some questions remain in regards to if it would even work in the first place. For example, when a JTAG solution was tested previously, the VRUAMDK aboot.mbn didn't flash on a device with VRUAME7 after all the partitions were wrote over with VRUAMDK partitions via JTAG, why? @jeboo may be able to help answer that.
Also, it was previously questioned whether or not the flash programmer (8064 hex) would need to be signed or not. As I have two S4's one thats working and one in QDL QHSUSB dload mode, in doing some recent testing through usb (S4 to S4) I was able to get some info back about my bricked S4, namely that I had sent it the wrong hex file ( see the last line here) because the dmesg and last_kmsg logs say something to the effect of "the the cpu clocks cannot start because its configured for the wrong device" and the last line from the my pastebin post says "8660" among other things as well.
Status - Unknown - More Research Required
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
2. Using a Developer edition S4 to unlock a retail S4 - So here's what we know, the dev kernel (boot.img) is flashable and will work with retail S4's, but the recovery.img and aboot will not. Flashing the dev recovery.img will succeed in Odin/Heimdall, but if you try to boot into recovery it will inform you that your device is "tampered" and and will void your warranty by setting the Knox warranty bit to 0x1. Before I discuss why aboot.mbn wont flash consider this; neither the Developer edition of the GS4 nor the Developer edition of the Note 3 has every received an OTA or a factory Odin tar. This is not by random chance. Every Developer edition owner has a unique MD5 for their aboot. If you couple this with the fact that Dev edition devices have retail stickers under their dev stickers, you will probably come to the conclusion that Samsung/Verizon/AT&T haven't released updates to dev devices because they would have to do it on a 'per device' basis, that or risk handing us a method to convert retail devices into developer edition devices. If the method by which Samsung uses device specific info to sign developer edition aboot partitions were discovered this may work, or if their method to determine if a device is a developer edition or consumer retail edition is similar to what Dan R (djrbliss) took advantage of then this could be a possibility.
3,4,5,6, coming up....updating...this will be a long post...advance warning.
Status - Possibly - More Research Required
This really sucks. Looks like the dev that knows how to downgrade from ME7 to MDK is locked up for a while.
h311sdr0id is currently indisposed and will probably not be getting out anytime soon. He has court next month. If anyone is interested in writing him, please send a message to his account and I will give you his info.
- Mrs. h311sdr0id
Travisdroidx2 said:
This really sucks. Looks like the dev that knows how to downgrade from ME7 to MDK is locked up for a while.
h311sdr0id is currently indisposed and will probably not be getting out anytime soon. He has court next month. If anyone is interested in writing him, please send a message to his account and I will give you his info.
- Mrs. h311sdr0id
Click to expand...
Click to collapse
Man... Samsung's really cracking down...
Sent from my SCH-I545 using XDA Premium 4 mobile app
Is it confirmed this is Samsung's doing?
Sent from my SCH-I535 using XDA Premium 4 mobile app
Travisdroidx2 said:
This really sucks. Looks like the dev that knows how to downgrade from ME7 to MDK is locked up for a while.
h311sdr0id is currently indisposed and will probably not be getting out anytime soon. He has court next month. If anyone is interested in writing him, please send a message to his account and I will give you his info.
- Mrs. h311sdr0id
Click to expand...
Click to collapse
WOW, this is news to me! It explains why I haven't seen him update his VS3 rom in awhile.
@Nicgraner
Sarcastic joke, or are you serious?
I noticed in the note 3 part of the forum a member started a petition to unlock the boot loader. Can someone start one or combine with the note 3 page?
Petitions just turn into complaint threads. I wanted to give this a last shot, so I posted alot of info and plenty of references with the intent that even less experienced s4 users could learn and eventually contribute to helping unlock this bootloader. I also offered some ideas as a starting point. Ive never joined irc's or google talk sessions with others in trying to solve things, I mostly read and learned on my own and im by no means a dev. But I don't think we can unlock this unless we stop complaining and one-uping each other and start working together. I wish that people would stop asking if devs are still trying to unlock this, or being pessimistic about it and start being part of the solution by reading a little and then helping contribute to a solution. All suggestions are welcome. But if you don't know what comprises the "bootloader", learning the flashing order of the partitions at least uptil tz.mbn would benefit you greatly.
P.S.
Just because your not a dev doesn't mean you cant help, most devs are knowledgeable about their devices, but some don't know much beyond how to use android kitchen.
Sent from my XT912 using xda app-developers app
Surge1223 said:
Petitions just turn into complaint threads. I wanted to give this a last shot, so I posted alot of info and plenty of references with the intent that even less experienced s4 users could learn and eventually contribute to helping unlock this bootloader. I also offered some ideas as a starting point. Ive never joined irc's or google talk sessions with others in trying to solve things, I mostly read and learned on my own and im by no means a dev. But I don't think we can unlock this unless we stop complaining and one-uping each other and start working together. I wish that people would stop asking if devs are still trying to unlock this, or being pessimistic about it and start being part of the solution by reading a little and then helping contribute to a solution. All suggestions are welcome. But if you don't know what comprises the "bootloader", learning the flashing order of the partitions at least uptil tz.mbn would benefit you greatly.
P.S.
Just because your not a dev doesn't mean you cant help, most devs are knowledgeable about their devices, but some don't know much beyond how to use android kitchen.
Sent from my XT912 using xda app-developers app
Click to expand...
Click to collapse
On that note, I thank you for developing the OYUAMDK FW. I have not tried it yet just waiting for another guinea pig or at least have a backup device to swap SIMs so that I can have something to use.
Samsung has their first Dev Conference today in San Francisco and hopefully there will be Devs there to get better insight on Samsungs position on ROMs and bootloaders etc...
Awesome analysis Surge, that hellsdroid thread piqued the interest of several devs, including myself. Unfortunately I believe his thread was a bit misleading, which may explain why he closed it. There has been no demonstrated method to boot vulnerable BLs (ie, loki-fiable aboot) once the qfuse has been incremented.
Some of us are looking at the binaries, but no exploit has popped out yet. I did find it interesting they updated SBL1 in the latest OTA, that may be a hint towards something..
jeboo said:
Awesome analysis Surge, that hellsdroid thread piqued the interest of several devs, including myself. Unfortunately I believe his thread was a bit misleading, which may explain why he closed it. There has been no demonstrated method to boot vulnerable BLs (ie, loki-fiable aboot) once the qfuse has been incremented.
Some of us are looking at the binaries, but no exploit has popped out yet. I did find it interesting they updated SBL1 in the latest OTA, that may be a hint towards something..
Click to expand...
Click to collapse
So I just started analyzing my emmc back up (took the entire 16gb mmcblk0 to make sure I didnt miss anything) have you looked through the emmc? I think the modem and apnhlos are more involved in the security checks than we previously thought. Plus these tima, tzapps, and apps.mbn etc files may have contributed to the failure of flashing the mdk aboot on the me7 device you guys were attempting, is there a reason you guys didnt include the mdk modem and apnhlos in your attempt to restore the mdk bootchain? I flashed the dev bootloader with the exception of the dev aboot, boot and recovery using 3 heimdall packages. The first contained the modem, apnhlos and sbl1-3. The second contained rpm and tz, and the third contained boot and recovery (as expected this package failed) the result was my device was now on the dev bootchain with the exception of aboot, boot and recovery and confirmed these results via hexedit. So I think we can rule out sbl3 being the main culprit in checking the fuses when trying to flash a new aboot, also I dont get the "fused 3 binary 1 aboot" failure message when I attempt to flash aboot anymore, just the "secure check fail aboot" message. I definitely think its worth looking into using the dev tz.mbn to find an exploit because I no longer ever see the "samsung custom unlock" boot screen and my device believes its unmodified, and reports its official. My device is so far from unmodified its ridiculous. That means the dev tz.mbn partition I flashed is behaving as if my s4 is a dev edition (see ralekdev's post I linked to in the OP)
Sent from my TouchPad using xda app-developers app
Surge1223 said:
So I just started analyzing my emmc back up (took the entire 16gb mmcblk0 to make sure I didnt miss anything) have you looked through the emmc? I think the modem and apnhlos are more involved in the security checks than we previously thought. Plus these tima, tzapps, and apps.mbn etc files may have contributed to the failure of flashing the mdk aboot on the me7 device you guys were attempting, is there a reason you guys didnt include the mdk modem and apnhlos in your attempt to restore the mdk bootchain? I flashed the dev bootloader with the exception of the dev aboot, boot and recovery using 3 heimdall packages. The first contained the modem, apnhlos and sbl1-3. The second contained rpm and tz, and the third contained boot and recovery (as expected this package failed) the result was my device was now on the dev bootchain with the exception of aboot, boot and recovery and confirmed these results via hexedit. So I think we can rule out sbl3 being the main culprit in checking the fuses when trying to flash a new aboot, also I dont get the "fused 3 binary 1 aboot" failure message when I attempt to flash aboot anymore, just the "secure check fail aboot" message. I definitely think its worth looking into using the dev tz.mbn to find an exploit because I no longer ever see the "samsung custom unlock" boot screen and my device believes its unmodified, and reports its official. My device is so far from unmodified its ridiculous. That means the dev tz.mbn partition I flashed is behaving as if my s4 is a dev edition (see ralekdev's post I linked to in the OP)
Sent from my TouchPad using xda app-developers app
Click to expand...
Click to collapse
So does this mean if I flash your OUYAMDK ODIN image my Dev Ed phone will think its OOB without custom unlock?
Theres a post in that thread where a dev owner achieved those results as well he only flashed a couple partitions, you can get more details there
Sent from my XT912 using xda app-developers app
thread cleaned of selling and or trading and the ensuing discussion.
Use Swappa.com for that.
neh4pres said:
Is it confirmed this is Samsung's doing?
Sent from my SCH-I535 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
I've always known Samsung to be like Google when it comes to consumer development. Google supports and encourages the freedom to modify Android, it being open source in the first place. Samsung doesnt mind, themselves; it's carrier security teams that require companies like Samsung to create their own methods of locking down the device for the average user. I'm quite impressed with the Knox bootloader and secure VM app. It may not be done anytime soon, but it can always be cracked. But, the fact that this code is so hard to modify, thanks to carriers, is actually a good thing.
Hey guys I am totally supporting this thread. Unfortunately i have no experience in this kinda stuff or else i would help. Good luck!
Much like most of us. Still out there Surge?
Sent from my SCH-I545 using xda app-developers app
Still here I use tw based roms so my motivation for wanting to unlock this isnt for AOSP or custom kernels. Its just the challenge, that and out of hate for Verizon lol. The Droid X sitting on my desk is a painful reminder of defeat. Cant let them win twice..
Sent from my SCH-I535 using xda app-developers app
Surge1223 said:
Still here I use tw based roms so my motivation for wanting to unlock this isnt for AOSP or custom kernels. Its just the challenge, that and out of hate for Verizon lol. The Droid X sitting on my desk is a painful reminder of defeat. Cant let them win twice..
Sent from my SCH-I535 using xda app-developers app
Click to expand...
Click to collapse
No doubt... can't believe i left my G-Nex for this locked down thing... unfortunately i had to craigslist an upgrade and couldn't snag one of these when they first came out.
i am also in full support of this thread! running stock MJ7 never rooted my phone once, i have taken all the OTAs i'm really crossing my fingers that someone can break this thing so i can finally root and install a stock google rom, i hate TW so much! with all the headache with safestrap and junk on the MI1 i was not wanting to root my device just to have a half assed recovery.
Does it mean anything that my S4 is still showing unlocked and custom? Should it still show that even if it is in fact locked?
I have problem when i try to unpack boot.img from CM10.1.3 Stable version for I9100G.
I tried many time but It say can't find kernel or ramdisk.
Any body help me please?
Anybody help me please???????????????????????
Very few people post here these days, not even the mods seem to be around. If you want help with this, you're either going to have to be really patient (understatement, don't be surprised if you still don't have an answer in a week), or go ask in the CM discussion thread. Your question isn't exactly a 'Hlap mai fone borked ! Odin don't werk !' type query. There aren't many people who post to S2 forums anymore who can answer this type of question.
So you can either sit in this thread & not get the answers you're looking for, or you can be proactive & seek them out.
I tried to worked out with few boot images before. I dont know what is yours
can you upload it please.
If you have windows it will be easy for you to explore that image in hex editor
That what i know so far is. Open your image in hex editor and look for "error" phrase
and you will find several of that 'error' kernel error header error compression error
im my case it is last one before compressed file. You need to recognize magic of
compressed file it is just after 'error'
Ex.
for gzip is: 1F 8B 0B
for LZMA is: 5D 00 00 00 04 FF FF
you can look for that instead 'error' And then you need to cut of everything before
magic number. Make your file start of that magic number. If you do that you will be able to
decompress it. gunzip file.gz or unlzma file.lzma
or you can use your android to find archive in your boot.img
hexdump -C boot.img | grep '1f 0b 08'
and result is
000046b0 72 6f 72 00 1f 8b 08 00 00 00 00 00 02 03 ac bd |ror.............|
ant then you have hex address 46b0 witch is pointing on first byte of that line. Its 72
hex is not easy to count in your memory so we need to convert it to dec value
echo $((16#46b0))
result is
18096 but remember this addres is pointing on 72. We need address of next 4 byte 1f
so we need to count in a memory then. Addres of 1f is 18100
Its easy now. We need to extract archive from boot.img
dd if=boot.img of=archive.gz bs=18100 skip=1
And then decompress it. Thats not all it is just a clue i hope it will work out for you
EDIT: This unfortunately doesn't seem to work for Windows 11. It worked reliably under Windows 10 for me, but on Windows 11 it's back to needing a USB 2.0 hub. I'll update again if I figure out another fix, but in the meantime, this should still be good for at least Windows 10 users.
This really isn't specific to the Pixel as it also solves the same issue for many other phones, but as I've seen the issue widespread in ROM threads here I thought I'd share it here.
First of all, while it is highly recommended to use Google's USB driver, for many of us that doesn't solve the problem - I don't know why it works on some systems, but it doesn't on either of mine. Fastboot and sideload would either error out and reboot the phone, or get some small percentage in and then hang. What does work is a small registry tweak. On both my laptop and my PC, this has enabled using USB 3.0 (and 3.1, 3.2, including USB-C) connections for fastboot and sideload with no errors and at full speed, and with no apparent downside.
I'm attaching a ZIP containing a simple .reg file you can run to automatically apply the fix - if you have any concerns applying a .reg file to your Windows install, feel free to open it up in Notepad and verify that it only does as described in the "Manual method" spoiler below.
Spoiler: Manual method
In regedit, under Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\usbflags:
* Create a key (folder) named 18D1D00D0100 if it doesn't already exist
* In that key/folder, create three Binary Values (REG_DWORD) named osvc, SkipBOSDescriptorQuery, and SkipContainerIdQuery (that's an uppercase i as in ID)
* Set osvc to 00 00
* Set SkipBOSDescriptorQuery to 01 00 00 00
* Set SkipContainerIdQuery to 01 00 00 00
You may need to reboot before the changes take effect, after either applying the .reg file or following the manual instructions above.
I've not seen any problems from making these changes, myself, but reverting them if so desired is as simple as deleting the entire registry key (folder): HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\usbflags\18D1D00D0100
Think i ran into this exact issue trying to flash the latest OTA via pixel flasher. On windows 11, using USB 3,0 the phone was detected fine via Adb but vanished once it rebooted to fastboot. Luckily I had a Linux laptop laying around and did my flashing on that that device just fine. Will bookmsrk this and will try it the next time i need to update. Thanks!