mitm on android emulator: a howto - Android Software/Hacking General [Developers Only]

Hello all,
I'd like to braindump how I managed to make android emulator v30 work with mitm, hope that helps someone.
Since it was not possible to neither write nor make writable the /system partition, I decided to roll my own system.img and that actually worked. I'm not going to upload a script because I might not remember 100%, but I'll going to descibe the steps in full, even though they exist elsewhere. The commands might not be exact, too, so if there's a typo you'll need to figure it out yourself.
Also, it will be a bit confusing because I shall refer to 2 files named system.img, one is the 2G file that comes with android, the other is 700M or something file that you will be creating in the process. I'll refer them as #1 and #2.
1. What is needed: android studio and emulator, linux, xattr, https://github.com/LonelyFool/lpunpack_and_lpmake , https://github.com/tytso/e2fsprogs, mitmproxy, parted. Build these github projects, you'll need their binaries in the process.
also, 'mkdir build' somewhere.
2. Find system.img (#1) in your android studio installation, then extract the system partition:
$ losetup -f system.img
$ losetup -a | grep system.img
/dev/loop5
$ partprobe /dev/loop5
$ ls /dev/loop5p*
/dev/loop5p1 /dev/loop5p2
$ lpunpack_and_lpmake/bin/lpunpack /dev/loop5p2 build
$ ls build
system.img system-ext.img product.img vendor.img
$ losetup -d /dev/loop5
3. Make system.img (#2) writable and usable. This is ext4 crunched with feature shared_blocks, which makes it not really writable even in theory, as it deduplicates identical blocks in the filesystem. You'll need to convert that to a normal ext4, but, there's not enough space to do that operation. So you'll need to expand the partition to accomodate for this. How much? Empirically, I added 30M to a 700M partition:
$ ls -l system.img
700000000 # for example
$ e2fsprogs/resize/resize2fs system.img 730M
$ ls -l system.img
730000000 # for example
$ e2fsprogs/e2fsck/e2fsck -f system.img
$ e2fsprogs/e2fsck/e2fsck -E unshared_blocks system.img
$ e2fsprogs/e2fsck/e2fsck -f system.img
4. Modify the now writable partiton to your heart's content (we're still with system.img #2 here). I needed to add just one file, mitmproxy-ca-cert.cer . According to the mitmproxy docs, the name must be the hash of the certificate:
$ losetup -f system.img
$ losetup -a | grep system.img
/dev/loop6
$ mount /dev/loop6 /mnt
$ hashed_name=`openssl x509 -inform PEM -subject_hash_old -in mitmproxy-ca-cert.cer | head -1
$ echo $hashed_name
c8750f0d
$ cp mitmproxy-ca-cert.cer /mnt/system/ext/security/cacerts/$hashed_name.0
$ cd /mnt/system/ext/security/cacerts/
$ chmod 644 $hashed_name.0
Now check if your android has extra attributes in these certificate files. Mine does:
$ xattr 00abcde.0 # some random certificate
security.selinux
$ xattr -p security.selinux 00abcde.0
ubject_r:system_security_cacerts_file:s0
if yes, you'll need it on this file too:
$ xattr -w security.selinux ubject_r:system_security_cacerts_file:s0 $hashed_name.0
and be done with the partition
$ umount /mnt
$ losetup -d /dev/loop6
5. Create new super-partition, the one we used as /dev/loop5p2. You'll need the file sizes of your .img partitions, and your command to create a super.img file will look like this:
$ cat repack
#!/bin/sh
P=/android/super/1
~/src/lpunpack_and_lpmake/bin/lpmake --metadata-size 65536 --super-name super --metadata-slots 2 --device super:2496462848 --group main:2647101440 \
--partition system:readonly:786432000:main --image system=$P/system.img \
--partition system_ext:readonly:131952640:main --image system_ext=$P/system_ext.img \
--partition product:readonly:1468575744:main --image product=$P/product.img \
--partition vendor:readonly:102739968:main --image vendor=$P/vendor.img \
--output $P/super2.img
the interesting numbers are the corresponding partition sizes (in --partition), and, if f ex you increased the system.img #2 to 30M in the step 3, the number in --device:super should be the size of /dev/loop5p2 in bytes plus at least these 30M (but also okay if a bit more).
6. Finally, create a new system.img #1 . Create a backup copy of it, and then append some 30M there, and fix the partition
$ dd if=/dev/zero of=system-new.img flags=append bs=1M size=30
$ losetup -f system-new.img
$ losetup -a | grep system-new.img
/dev/loop7
$ parted /dev/loop7
GNU Parted 3.3
Using /dev/loop7
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p
Model: Loopback device (loopback)
Disk /dev/loop7: 2444MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 1049kB 2097kB 1049kB vbmeta
2 2097kB 2443MB 2441MB super
you will need to expand the partion 2 to the max (plus minus same 30M). If is fails fix the number and retry:
(parted) resizepart 2 24460MB
Error: The location 24460MB is outside of the device /dev/loop7.
and finally copy data back:
$ partprobe /dev/loop7
$ dd if=super.img of=/dev/loop7p2 bs=1M
$ losetup -d /dev/loop7
and that's it. After that, rename system-new.img to system.img, and hopefully the emulator could run this new image.
Also, to check that the certificate is there and recognized, go to the setting/certificates/trusted certificates, the mitmproxy one should be in the list.
Hopefully this will be helpful.
Cheers!
/dk

Related

[Q] What does the option "-s" used for in "make_ext4fs" ?

Hello,
I'm trying to make /system to ext4 image and boot up
I found that in system/extras/ext4_utils/mkuserimg.sh, the command is
make_ext4fs -s -l $SIZE -a $LABEL $OUTPUT_FILE $SRC_DIR
the out image with option "-s" cannot be mounted when bootup
but without the "-s" option, image can be mounted successful
I checked the image diff, the image with "-s" add crc header and spare format, so it definitly cannot be mounted directly , right ?
My question is : what the option "-s" used for ? Am I need this option in my experiment ?
Thanks
As far as i know -s = silent mode "no shell lines displayed during execution"
GchildT said:
As far as i know -s = silent mode "no shell lines displayed during execution"
Click to expand...
Click to collapse
Appriciate your reply
But, are you sure?... the option '-s' indeed pased as 'spare' in source code, and the out image cannot be mounted...
-s is sparse
you need to use the simg2img tool
This is what we do at work (TI)
From: omappedia.org/wiki/Using_EMMC_on_OMAP4_devices
./simg2img system.img system.img.raw
mkdir tmp
sudo mount -t ext4 -o loop system.img.raw tmp/
<<change stuff>>
sudo ./make_ext4fs -s -l 512M -a system system.img.new tmp/
sudo umount tmp
rm -rf tmp
Hope this helps
/chris
PS: The forum won't let me link the URL above
ufgeek said:
-s is sparse
you need to use the simg2img tool
This is what we do at work (TI)
From: omappedia.org/wiki/Using_EMMC_on_OMAP4_devices
./simg2img system.img system.img.raw
mkdir tmp
sudo mount -t ext4 -o loop system.img.raw tmp/
<<change stuff>>
sudo ./make_ext4fs -s -l 512M -a system system.img.new tmp/
sudo umount tmp
rm -rf tmp
Hope this helps
/chris
PS: The forum won't let me link the URL above
Click to expand...
Click to collapse
If you don't mind me asking,
What does simg2img do exactly? and what would be the potential risk if not using -s option?
steeldusk said:
If you don't mind me asking,
What does simg2img do exactly? and what would be the potential risk if not using -s option?
Click to expand...
Click to collapse
I figured it out. simg2img is just a bin file to strip sparsed image and make non-sparsed image, and not using -s just build system without any header. so as long as you can burn image to a right partition, you don't need -s option
make_ext4fs -s -l command
This is how i make my ext4 images. I did not got to test on real device my self yet.
Im building my images from cm source btw. This is the command i use to build recovery: make -j4 recoveryimage
After i build a image i run the make_ext4fs command.(userdata.img and system.img seem to be ext4 build by default for me)
make_ext4fs -s -l 1073741824 -a data out/target/product/m805_892x/userdata.img out/target/product/m805_892x/data
make_ext4fs -s -l 10485760 -a data out/target/product/m805_892x/boot.img out/target/product/m805_892x/data
make_ext4fs -s -l 10485760 -a data out/target/product/m805_892x/recovery.img out/target/product/m805_892x/data
make_ext4fs -s -l 314572800 -a data out/target/product/m805_892x/system.img out/target/product/m805_892x/data
gives:
Creating filesystem with parameters:
Size: 314572800
Block size: 4096
Blocks per group: 32768
Inodes per group: 6400
Inode size: 256
Journal blocks: 1200
Label:
Blocks: 76800
Block groups: 3
Reserved block group size: 23
Created filesystem with 911/19200 inodes and 31635/76800 blocks
Install system fs image: out/target/product/m805_892x/system.img
out/target/product/m805_892x/system.img+out/target/product/m805_892x/obj/PACKAGING/recovery_patch_intermediates/recovery_from_boot.p total size is 126213892
[email protected]:~/ICS$
I my BoardConfig i have this:
BOARD_BOOTIMAGE_PARTITION_SIZE := 10485760
BOARD_RECOVERYIMAGE_PARTITION_SIZE := 10485760
BOARD_SYSTEMIMAGE_PARTITION_SIZE := 314572800
BOARD_USERDATAIMAGE_PARTITION_SIZE := 1073741824
(Google for: build android from source if you dont get what im doing..)
The sizes need to be in bytes it seems.
DD dump you´re partitions and you see the amount of bytes.
Just edding some nice info to a old post
what of for a 128mb phone
ufgeek said:
-s is sparse
you need to use the simg2img tool
This is what we do at work (TI)
From: omappedia.org/wiki/Using_EMMC_on_OMAP4_devices
./simg2img system.img system.img.raw
mkdir tmp
sudo mount -t ext4 -o loop system.img.raw tmp/
<<change stuff>>
sudo ./make_ext4fs -s -l 512M -a system system.img.new tmp/
sudo umount tmp
rm -rf tmp
Hope this helps
/chris
PS: The forum won't let me link the URL above
Click to expand...
Click to collapse
my phone refuses to flash the image and i think its because of its size 145mb. how do i create a system.img for a 12mb internal memory phone
$ make_ext4fs
Expected filename after options
make_ext4fs [ -l <len> ] [ -j <journal size> ] [ -b <block_size> ]
[ -g <blocks per group> ] [ -i <inodes> ] [ -I <inode size> ]
[ -L <label> ] [ -f ] [ -a <android mountpoint> ]
[ -S file_contexts ]
[ -z | -s ] [ -t ] [ -w ] [ -c ] [ -J ]
<filename> [<directory>]
All is very simply
-s sparse (cut empty bytes)
-l len (size image)

[Q] nvflash/APX mode help

Calling all developers with extensive knowledge of NVflash
I know NVflash commands but I have never tried to run NVflash on a device with an encrypted bootloader nor have I had to try to source all the necessary files so I have some questions.
1. Would the following command be correct? Because even this simple sync command is exiting with a failure.
nvflash --bl bootloader.bin --sbk [boot key here] --sync
2. Is the bootloader.bin file universal or is it device specific? Where do I find one, can I edit one to work, etc?
I am working with the Acer Iconia A200 which is relatively new so no one has cracked NVflash on it yet so any help at all would be greatly appreciated.
Thanks!
I don't have extensive knowledge, but I did watch a youtube video once. Nvflash is used on several devices, so check out the acer/zoom/transformer forums. I think it also has some roots in graphics cards, so some of the tweaker forums might have some useful insight about syntax.
Code:
Nvflash started
nvflash action [options]
action (one or more) =
--help (or -h)
displays this page
--cmdhelp cmd(or -ch)
displays command help
--resume (or -r)
send the following commands to an already-running bootloader
--quiet (or -q)
surpress excessive console output
--wait (or -w)
waits for a device connection (currently a USB cable)
--create
full initialization of the target device using the config file
--download N filename
download partition filename to N
--setboot N
sets the boot partition to partition N
--format_partition N
formats contents of partition N
--read N filename
reads back partition N into filename
--getpartitiontable filename
reads back the partition table into filename
--getbit filename
reads back BIT into filename
--getbct
reads back the BCT from mass storage
--odm C Data
ODM custom 32bit command 'C' with associated 32bit data
--go
continues normal execution of the downloaded bootloader
options =
--configfile filename
indicates the configuration file used with the following commands:
--create, --format_all
--bct filename
indicates the file containing the BCT
--sbk 0x00000000 00000000 00000000 00000000
indicates the secure boot key for the target device
--bl filename
downloads and runs the bootloader specified by filename
--odmdata N
sets 32bit customer data into a field in the BCT, either hex or
decimal
--diskimgopt N
sets 32bit data required for disk image convertion tool
--format_all
formats all existing partitions on the target device using the config file,
including partitions and the bct
--setbootdevtype S
sets the boot device type fuse value for the device name.
allowed device name string mentioned below:
emmc, nand_x8, nand_x16, nor, spi
--setbootdevconfig N
sets the boot device config fuse value either hex or decimal
--verifypart N
verifies data for partition id = N specified. N=-1
indicates all partitions
Intended to be used with --create command only.
--setbct
updates the chip specific settings of the BCT in mass storage to
the bct supplied,used with --create, should not be with --read,and
--format(delete)_all,format(delete)_partition,--download, and--read
--sync
issues force sync commad
--rawdeviceread S N filename
reads back N sectors starting from sector S into filename
--rawdevicewrite S N filename
writes back N sectors from filename to device starting from sector S
Here's what I use
nvflash --bct transformer.bct --setbct --configfile flash.cfg --bl bootloader.bin --odmdata [device specific odm data] --sbk [mysterious sbk] --sync
All the files are device specific and the flash.cfg is where all the partitions and sizes are specified. Nvidia used to have a developers website that had a generic HC and GB rom. I flashed it, but was configured for different screen sizes/trackpad, etc.
If you are going to format the device, then you will use the --create flag and I think you need the flash.cfg file.
Thanks! I am primarily after --read and --getpartitiontable so that I can create a stock backup so those that brick have a recovery option. Sounds like the most important part now for me is getting the correct files together. I have the SBK though unconfirmed.
I personally have never used --odmdata, do you have any insite into that command?
My previous device, the Dell Streak 7, had a fully unlocked NVflash so there was no SBK or anything like that to worry about. I miss those times
I thought the omdata were device specific things like memory configuration? Not sure how important it is for reading partitions.
The other thing with nvflash is once you start it, you can send more commands with the resume command:
Nvflash sbk bootloader etc
Nvflash -r --read 6 blah blah
Nvflash -r -- read 7 blah blah
...
Nvflash -r --go
Or something like that...
sent while running with scissors
I don't really know because at least on the Dell Streak 7 it was a command I never used and I never saw used by others either. Hopefully someone has incite somewhere on how to get the files I need.
If you have root you should be able to read the BCT and bootloader from the device with dd and then decrypt them.
I have root and an unlocked bootloader. Please explain. DD? I have Windows 7 and Linux at my disposal.
Thanks!
Wetzel402 said:
I have root and an unlocked bootloader. Please explain. DD? I have Windows 7 and Linux at my disposal.
Thanks!
Click to expand...
Click to collapse
Yes, dd.
Copy some raw data from the block device on the device, something like
Code:
# /system/bin/dd if=/dev/block/mmcblk0 bs=512 count=13312 of=/sdcard/data.raw
Then transfer the dump to the computer and extract the BCT and boot loader.
I started writing a description but it quickly started to get long and it is late...
So you get a small ugly script that shows the steps instead.
This requires openssl, dd and hexdump.
Code:
#!/bin/bash
#This script extracts the BCT and bootloader out of a dd dump of the block device on a tegra 2 device
#The first 6.5M should be enough, something like:
#/system/bin/dd if=/dev/block/mmcblk0 bs=512 count=13312 of=/sdcard/data.raw
#SBK written together
#e.g. 0xDEADBEEF 0xBAADF00D 0xCAFEFEED 0xBADDCAFE => "DEADBEEFBAADF00DCAFEFEEDBADDCAFE"
SBK="DEADBEEFBAADF00DCAFEFEEDBADDCAFE"
#Input file
raw_file="data.raw"
#Output files
bct_file="out.bct"
bl_file="bootloader.bin"
echo "Extrating the BCT data"
dd if=$raw_file of=bct_encrypted.bin bs=16 count=254 skip=1 2> /dev/null
echo "Decrypting the BCT data"
openssl aes-128-cbc -K $SBK -iv 0 -d -in bct_encrypted.bin -out bct_decrypt.tmp -nopad
dd if=bct_decrypt.tmp of=out.bct bs=16 count=254 seek=1 2> /dev/null
rm bct_decrypt.tmp
rm bct_encrypted.bin
#Read some general information
bct_version="$(hexdump -n 4 -s 0x20 -e '1/4 "0x%x\n"' $bct_file)"
block_size=$((2 ** $(hexdump -n 4 -s 0x24 -e '1/4 "%u"' $bct_file)))
page_size=$((2 ** $(hexdump -n 4 -s 0x28 -e '1/4 "%u"' $bct_file)))
odm_data=$(hexdump -n 4 -s 0xFE4 -e '1/4 "0x%08x\n"' $bct_file)
#Boot loader 1
bl_start_block=$(hexdump -n 4 -s 0xA98 -e '1/4 "%u\n"' $bct_file)
bl_length=$(hexdump -n 4 -s 0xAA0 -e '1/4 "%u\n"' $bct_file)
if [ "$bct_version" != "0x20001" ]; then
echo "ERROR: Unexpected BCT version: $bct_version"
exit 1
fi
echo "Block size: $block_size"
echo "Page size: $page_size"
echo "Boot loader 1 start block: $bl_start_block"
echo "Boot loader 1 length $bl_length"
echo "ODM Data: $odm_data"
echo "Extracting the booot loader"
bl_start_byte=$(( $(($bl_start_block - 64)) * $block_size ))
bl_padded_length=$(( $bl_length + $((16 - $(($bl_length % 16)) ))))
echo "Extracting $bl_padded_length starting at offset $bl_start_byte"
dd bs=1 if=$raw_file of="bootloader.enc" skip=$bl_start_byte count=$bl_padded_length 2> /dev/null
echo "Decrypting boot loader"
openssl aes-128-cbc -K $SBK -iv 0 -d -in bootloader.enc -out bootloader.tmp -nopad
dd if=bootloader.tmp of=$bl_file bs=$bl_length count=1 2> /dev/null
I may have gotten the block to byte convertion wrong, it is correct for the offsets on the device I have, but we will see.
Currently way over my head considering I just finally figured out mount commands
I will start doing some research on the topic to learn more and before you know it I should have the files I need
I did get the bct file but the bootloader.bin file is not working. With this line:
openssl aes-128-cbc -K $SBK -iv 0 -d -in bootloader.enc -out bootloader.tmp -nopad
I keep getting an error "option 0 doesn't exist". Any ideas? Also when you have some time could you please explain what exactly all of this is doing? I understand very little of this syntax because I am quite noobish with Linux.
Thanks!
Wetzel402 said:
I did get the bct file but the bootloader.bin file is not working. With this line:
openssl aes-128-cbc -K $SBK -iv 0 -d -in bootloader.enc -out bootloader.tmp -nopad
I keep getting an error "option 0 doesn't exist". Any ideas?
Click to expand...
Click to collapse
That looks like you don't have SBK set (so it is trying to use "-iv" as key, and then don't know what to do with the leftover 0).
The steps must be performed in order and in the same shell as some of them are depending on variables set by previous steps.
Wetzel402 said:
Also when you have some time could you please explain what exactly all of this is doing? I understand very little of this syntax because I am quite noobish with Linux.
Click to expand...
Click to collapse
Sure, it is mostly just about reading some values at known offsets.
Code:
dd if=$raw_file of=bct_encrypted.bin bs=16 count=254 skip=1
Will read 254 blocks of 16 bytes, skiping one block from $raw_file into bct_encrypted.bin. So we are reading bytes 16-4080 into bct_encrypted.bin.
We are skipping the first 16 bytes since this is a checksum (CMAC) and not part of the encrypted data, so bringing that along would mess up the decryption of the next 16 byte due to the cipher block chaining.
Code:
openssl aes-128-cbc -K $SBK -iv 0 -d -in bct_encrypted.bin -out bct_decrypt.tmp -nopad
Decrypt the content of bct_encrypted.bin using the SBK and store the decryped data in bct_decrypt.tmp.
Code:
dd if=bct_decrypt.tmp of=out.bct bs=16 count=254 seek=1
We skipped the first 16 bytes previously, so the decrypted data is a bit incorretly offset.
So this takes bct_decrypt.tmp and writes it to out.bct offset 16 bytes so that we get a 4080 bytes file again.
Code:
bct_version="$(hexdump -n 4 -s 0x20 -e '1/4 "0x%x\n"' $bct_file)"
Reads the version field of the BCT, this is a 32bit integer at offset 0x20.
I would expect the version to be 0x20001.
Code:
block_size=$((2 ** $(hexdump -n 4 -s 0x24 -e '1/4 "%u"' $bct_file)))
Reads the block size field in the BCT, also a 32bit integer, at offset 0x24.
The block and page size is stored in log2, so then we need to raise 2 to the value we found to get the actual block/page size.
For example, if we found the value 14 the block size is 2**14 = 16384.
Code:
#Boot loader 1
bl_start_block=$(hexdump -n 4 -s 0xA98 -e '1/4 "%u\n"' $bct_file)
bl_length=$(hexdump -n 4 -s 0xAA0 -e '1/4 "%u\n"' $bct_file)
Read start block and size of the first boot loader (the BCT file have space for four boot loaders)
Code:
bl_start_byte=$(( $(($bl_start_block - 64)) * $block_size ))
We have the start position of the boot loader in blocks, but we need it in bytes.
So multiply the block number with the block size. Unfortunatly this is not quite right, so we need to offset it a bit.
Code:
bl_padded_length=$(( $bl_length + $((16 - $(($bl_length % 16)) ))))
The encryption used, AES 128, works on blocks of 16 bytes, but there is no guarantee that the length of the boot loader is a multiple of 16 so we need to pad it to make sure it is.
Code:
dd bs=1 if=$raw_file of="bootloader.enc" skip=$bl_start_byte count=$bl_padded_length
Cut the encrypted boot loader out of the $raw_file.
Code:
openssl aes-128-cbc -K $SBK -iv 0 -d -in bootloader.enc -out bootloader.tmp -nopad
Decrypt it
Code:
dd if=bootloader.tmp of=$bl_file bs=$bl_length count=1
And take only the actual length of the decrypted data, discarding the extra padding data we took just to make it an even number of 16 byte blocks.
Very impressive
Prior to this I have messed mostly with kitchens, cd, and mount so this is definitely a learning experience for me. After you described these commands I am convinced I could use most of these minus the fact I would have no clues what values to use in them
Thanks! I will have to try rerunning everything and see if I can get the bootloader.bin to come out.
Here is my terminal output after copying and pasting in your script.
Code:
[email protected]:~# cd /root/Desktop
[email protected]:~/Desktop# SBK="B8A4C201EB6FF106EB00150430772103"
[email protected]:~/Desktop#
[email protected]:~/Desktop# #Input file
[email protected]:~/Desktop# raw_file="data.raw"
[email protected]:~/Desktop#
[email protected]:~/Desktop# #Output files
[email protected]:~/Desktop# bct_file="out.bct"
[email protected]:~/Desktop# bl_file="bootloader.bin"
[email protected]:~/Desktop#
[email protected]:~/Desktop# echo "Extrating the BCT data"
Extrating the BCT data
[email protected]:~/Desktop# dd if=$raw_file of=bct_encrypted.bin bs=16 count=254 skip=1 2> /dev/null
[email protected]:~/Desktop#
[email protected]:~/Desktop# echo "Decrypting the BCT data"
Decrypting the BCT data
[email protected]:~/Desktop# openssl aes-128-cbc -K $SBK -iv 0 -d -in bct_encrypted.bin -out bct_decrypt.tmp -nopad
[email protected]:~/Desktop# dd if=bct_decrypt.tmp of=out.bct bs=16 count=254 seek=1 2> /dev/null
[email protected]:~/Desktop# rm bct_decrypt.tmp
[email protected]:~/Desktop# rm bct_encrypted.bin
[email protected]:~/Desktop#
[email protected]:~/Desktop#
[email protected]:~/Desktop# #Read some general information
[email protected]:~/Desktop# bct_version="$(hexdump -n 4 -s 0x20 -e '1/4 "0x%x\n"' $bct_file)"
[email protected]:~/Desktop# block_size=$((2 ** $(hexdump -n 4 -s 0x24 -e '1/4 "%u"' $bct_file)))
[email protected]:~/Desktop# page_size=$((2 ** $(hexdump -n 4 -s 0x28 -e '1/4 "%u"' $bct_file)))
I don't understand the page size line enough to know what is going wrong or to change things but after that line displays the terminal exists without errors.
Any ideas?
Wetzel402 said:
I don't understand the page size line enough to know what is going wrong or to change things but after that line displays the terminal exists without errors.
Any ideas?
Click to expand...
Click to collapse
You are probably hitting the exit in BCT version check, since you are running it directly in the shell that would make the terminal dissapear.
What does out.bct look like?
What does
Code:
hexdump -n 4 -s 0x20 -e '1/4 "0x%x\n"' out.bct
give?
That was the problem.
Code:
[email protected]:~# cd /root/Desktop
[email protected]:~/Desktop# hexdump -n 4 -s 0x20 -e '1/4 "0x%x\n"' out.bct
0xf16cb00b
So I modified the following line:
Code:
[email protected]:~/Desktop# if [ "$bct_version" != "0xf16cb00b" ]; then
Everything ran and out came the bootloader.bin. This should be the correct file then? Also the other two files (bootloader.enc&.tmp) were stepping stones to the final product (bootloader.bin) and are not needed correct?
When I get home from work if I have time I will try the following and see if life is good
Code:
nvflash --bl bootloader.bin --getbct --bct out.bct --sbk 0xB8A4C201 0xEB6FF106 0xEB001504 0x30772103 --go
nvflash -r --getpartitiontable partition.txt
Wetzel402 said:
That was the problem.
Code:
[email protected]:~# cd /root/Desktop
[email protected]:~/Desktop# hexdump -n 4 -s 0x20 -e '1/4 "0x%x\n"' out.bct
0xf16cb00b
So I modified the following line:
Code:
[email protected]:~/Desktop# if [ "$bct_version" != "0xf16cb00b" ]; then
Everything ran and out came the bootloader.bin. This should be the correct file then?
Click to expand...
Click to collapse
I would not expect a different version, I think it is more likely the decryption failed.
Could you make the data.raw file available to me?
Here it is.
Wetzel402 said:
Here it is.
Click to expand...
Click to collapse
The data looks ok, but it can not be decrypted using that key so you must have the wrong SBK.
Assuming it follows the same format as the Iconia A500 that SBK would belong to a device with UID 042800484400D057, is this the UID of your device?
Yes that is correct. So you think Acer is using a different encryption method?
I tried the NVflash commands anyway and it doesn't run. Exits with the standard failure.
Wetzel402 said:
Yes that is correct. So you think Acer is using a different encryption method?
Click to expand...
Click to collapse
Depending on what you mean, maybe and no. They are maybe allocating the SBK differently, but the encryption in still AES128.
Wetzel402 said:
I tried the NVflash commands anyway and it doesn't run. Exits with the standard failure.
Click to expand...
Click to collapse
Nvflash uses the key you give it to encrypt the command before sending it to the device, then the decrypts the command using the builtin key. If those two does not match the result will not be a recognizable command.
Depending on how you got the UID it may be worth trying a different way, some devices does not report the UID as their USB serial number.
Save this as apxuid.c and compile this using gcc -Wall -pedantic -o apxuid apxuid.c -lusb-1.0. Then run ./apxuid directly after starting the device is in apx-mode and see if you get the same UID.
Code:
#include <libusb-1.0/libusb.h>
#include <stdio.h>
#include <stdint.h>
int main(void)
{
unsigned char data[64];
int received_length;
int r = 1;
libusb_context* ctx = NULL;
libusb_device_handle* dev_handle = NULL;
libusb_init(&ctx);
dev_handle = libusb_open_device_with_vid_pid(ctx, 0x0955, 0x7820);
if(dev_handle)
{
r = libusb_bulk_transfer(dev_handle, 0x81, data, sizeof(data), &received_length, 10000);
if (r == 0)
{
if(received_length == 8)
{
printf("uid: %#016lx\n", *(uint64_t*)data);
}
else
{
r = 1;
printf("Error: We got %d bytes of data insetad of the 8 bytes we expected...\n", received_length);
}
}
else
{
printf("Error: USB read failed!\n");
}
libusb_release_interface(dev_handle, 0);
}
else
{
printf("Error: Failed to open device!\n");
}
libusb_exit(ctx);
return r;
}

[ARM][x86_64]ElfTool - Pack and unpack boot image for sony mobile devices

ElfTool​
This tool will help you to pack and unpack boot image for sony mobile devices.
Usage :
For unpacking
Code:
elftool unpack -i input-path -o output-path
For packing
If you have header file containing address of kernel, ramdisk etc..
Code:
elftool pack -o output-path header=path/to/header kernel-path ramdisk-path,ramdisk ipl-path,ipl rpm-path,rpm [email protected]
Else
Code:
elftool pack -o output-path [email protected] [email protected],ramdisk [email protected],ipl [email protected],rpm [email protected]
The tool was created for injecting twrp recovery ramdisk to fxp cm10 boot images to prevent overwriting of cwm ramdisk over twrp ramdisk. I hope this tool will be useful for other developers also.
Here is how I used it for injecting twrp to fxp cm10 boot images.
During start of twrp run backup.sh. This will extract twrp ramdisk from the boot partition and store it in /cache/backup
Code:
mount /cache
cd /cache
mkdir backup
cd backup
dump_image /dev/block/mmcblk0p3 /cache/backup/oldboot.img
mkdir oldboot
elftool unpack -i /cache/backup/oldboot.img -o /cache/backup/oldboot
cd oldboot
mkdir uramdisk
cd uramdisk
gzip -dc ../ramdisk | cpio -i
mv sbin/ramdisk-recovery.cpio /cache/backup/ramdisk-recovery.cpio
cd /cache/backup
rm -irf oldboot
rm oldboot.img
When a new zip file is installed inject.sh is run. This will extract the newly installed boot image and inject the twrp ramdisk into it and then flash the newly created bootimage.
Code:
#!/sbin/sh
mount /cache
dump_image /dev/block/mmcblk0p3 /cache/newboot.img
mkdir /cache/newboot
elftool unpack -i /cache/newboot.img -o /cache/newboot
rm cache/newboot.img
cd /cache/newboot
mkdir uramdisk
cd uramdisk
gzip -dc ../ramdisk | cpio -i
rm ../ramdisk
if [ -e "/cache/backup/ramdisk-recovery.cpio" ];then
cp /cache/backup/ramdisk-recovery.cpio sbin/ramdisk-recovery.cpio
cd ..
mkbootfs uramdisk > ramdisk.cpio
cat ramdisk.cpio | gzip > ramdisk
rm -irf uramdisk
rm ramdisk.cpio
elftool pack -o /cache/injectboot.img [email protected] [email protected],ramdisk [email protected]
cd /cache
rm -irf newboot
if [ -e "/cache/injectboot.img" ];then
erase_image /dev/block/mmcblk0p3
flash_image /dev/block/mmcblk0p3 /cache/injectboot.img
rm /cache/injectboot.img
fi
fi
Both arm and x86_64 versions are available.
Thanks to sony for providing boot image format in packelf.py
Source code can be found here
yeah
thanks bro
srl3gx said:
ElfTool​
This tool will help you to pack and unpack boot image for sony mobile devices.
Click to expand...
Click to collapse
Thanks for this tool. It helped me edit a kernel.
Btw, I've used the source to compile x86 version. I've attached it here.
I'm trying to use it on my ubuntu but it doesn't work. I get error: elftool: command not found
I want to unpack CM10 boot.img
Great. Will try it as soon as possible Thanks

Samsung Galaxy S insert SIM CARD problem

Hi,
Can you please help me how I can CODE in my mobile ( SAMSUNG GALAXY S - GTI9003)
I m happy to see the solution given by you.. but dont know how to code on ADB shell in my device
Thanks in advance
vssvaas
01binary01 said:
I think every issue to do with losing the baseband has a slight twist, I'm beginning to think not every problem can use the same solution.
I've fixed mine, using similar lines as the posting in http://forum.xda-developers.com/showthread.php?t=1261948
As I couldn't get 7Zip to edit/modify the tar file without the file getting corrupt.
Finally I resorted did the unpacking and re-tarring via my Mac (with android sdk installed) to preserve id's etc.
** The following is just a simple guide, which worked for me, I made sure I had plenty of power on the phone and kept original states of my efs directory **
On my phone via 'adb shell'
Code:
$ su
# mkdir /sdcard/efsbck
# cd /
# busybox tar zcvf /sdcard/efsbck/orig-broke-efs.tar.gz efs
# exit
$ exit
On my mac
Code:
cd <where-ever-your-android-sdk-is>/platform-tools/
adb pull /sdcard/efsbck/orig-broke-efs.tar.gz
mkdir mod
sudo su
cd mod
sh-3.2# #*Note the 'p' on the tar to preserve the original id's etc on various files
sh-3.2# gunzip -c ../orig-broke-efs.tar.gz | tar xvpf -
sh-3.2# cd efs
sh-3.2# ls -ltra | grep nv_data
-rwx------ 1 1001 1001 32 31 Dec 2010 .nv_data.bak.md5
-rwx------ 1 1001 1001 2097152 31 Dec 2010 .nv_data.bak
-rwx------ 1 1001 1001 32 21 Sep 00:46 nv_data.bin.md5
-rwx------ 1 1001 1001 2097152 21 Sep 00:46 nv_data.bin
sh-3.2# rm nv_data.bin.md5
sh-3.2# rm nv_data.bin
sh-3.2# cp -p .nv_data.bak nv_data.bin
sh-3.2# cp -p .nv_data.bak.md5 nv_data.bin.md5
sh-3.2# cd ..
sh-3.2# tar cvf - efs | gzip -c - > mod-efs.tar.gz
a efstar: getpwuid(1001) failed: No such file or directory
a efs/.files
...
...
sh-3.2# ../adb push mod-efs.tar.gz /sdcard/efsbck/mod-efs.tar.gz
Then 'adb shell' back to the phone. I checked the tar file list was ok and wasn't corrupt.
Code:
$ su
# cd /sdcard/efsbck
# busybox tar ztvf mod-efs.tar.gz
Then for the final run, butt clenching bit, still on the phone via 'adb shell'
Code:
$ su
# cd /sdcard/efsbck
# umount /efs
# mke2fs /dev/block/mmcblk0p1
# mount -w -t ext4 /dev/block/mmcblk0p1 /efs
# ls /efs
lost+found
#
# busybox tar zxvf mod-efs.tar.gz -C /
# ls /efs
... check that the nv_data.bin is there ... and has radio radio id's
# exit
$ exit
Then after a reboot - Phone was still in 'airplane mode' - But went into settings - checked baseband - it was visible rolleyes ! , went to wireless network 'Flight Mode' was correctly green 'ticked', undid. And got my signal back.cool
I also had to re-activate data network settings for my GPS to sort itself out.
The procedure worked for me, I can't say it'll work for everyone.
Click to expand...
Click to collapse

Problem unpack kernel pxa1908 (Android Image Kitchen)

Hello,
I own a samsung xcover 3 (sm-g388f, android lollitop) and out of curiosity I start to be interested in the android system. I downloaded the ROM and get back the file boot.img, i try to get the file Image.gz (kernel) with Android Image Kitchen.
Code:
./unpackimg.sh boot.img
I get:
Code:
Android Image Kitchen - UnpackImg Script
by osm0sis @ xda-developers
Supplied image: boot.img
Setting up work folders...
Image type: AOSP-PXA
Footer with "SEAndroid" type detected.
Splitting image to "split_img/"...
BOARD_KERNEL_CMDLINE
BOARD_KERNEL_BASE 0x10000000
BOARD_NAME
BOARD_PAGE_SIZE 2048
BOARD_KERNEL_OFFSET 0x00008000
BOARD_RAMDISK_OFFSET 0x01000000
BOARD_SECOND_OFFSET 0x00f00000
BOARD_TAGS_OFFSET 0x00000100
BOARD_DT_SIZE 475136
BOARD_UNKNOWN 0x03000000
Unpacking ramdisk (as root) to "ramdisk/"...
Compression used: gzip
4739 blocs
Done!
I get the file boot.img-kernel, i use dumpimage:
Code:
./dumpimage -i boot.img-kernel -p 0 Image.gz
The return is:
Code:
./dumpimage: invalid option -- 'i'
Usage: ./dumpimage -l image
-l ==> list image header information
./dumpimage [-T type] [-p position] [-o outfile] image
-T ==> declare image type as 'type'
-p ==> 'position' (starting at 0) of the component to extract from image
-o ==> extract component to file 'outfile'
./dumpimage -h ==> print usage information and exit
./dumpimage -V ==> print version information and exit
I try the command:
Code:
./dumpimage -T boot.img-kernel -p 0 Image.gz
i get:
Code:
./dumpimage: Invalid type
I no longer see what to do, here is the boot.img
If anyone has an idea I’m interested
Thanks

Categories

Resources