android - Repack existing boot.img using mkbootimg (cyanogenmod 12.1, lollipop) -

-

this cross-post xda-developers, here knows solution. have trouble re-packing existing boot.img cyanogenmod 12.1 (lollipop 5.1) d2spr (sprint s3). resulting image not boot. built mkbootimg/unpackbootimg source found here: https://github.com/osm0sis/mkbootimg . following:

$ mkdir boot2 $ ../unpackbootimg -i boot.img -o boot2 board_kernel_cmdline androidboot.hardware=qcom user_debug=31 zcache androidboot.bootdevice=msm_sdcc.1 board_kernel_base 80200000 board_name  board_page_size 2048 board_kernel_offset 00008000 board_ramdisk_offset 01500000 board_tags_offset 00000100

this unpacks boot.img into:

$ ls -l boot2 total 7360 -rw-rw---- 1 galets galets       9 apr 22 08:59 boot.img-base -rw-rw---- 1 galets galets       1 apr 22 08:59 boot.img-board -rw-rw---- 1 galets galets      81 apr 22 08:59 boot.img-cmdline -rw-rw---- 1 galets galets       9 apr 22 08:59 boot.img-kerneloff -rw-rw---- 1 galets galets       5 apr 22 08:59 boot.img-pagesize -rw-rw---- 1 galets galets  663238 apr 22 08:59 boot.img-ramdisk.gz -rw-rw---- 1 galets galets       9 apr 22 08:59 boot.img-ramdiskoff -rw-rw---- 1 galets galets       9 apr 22 08:59 boot.img-tagsoff -rw-rw---- 1 galets galets 6842760 apr 22 08:59 boot.img-zimage

then repackage files without modification:

$ ../mkbootimg --kernel boot2/boot.img-zimage \ >              --ramdisk boot2/boot.img-ramdisk.gz \ >              --cmdline "androidboot.hardware=qcom user_debug=31 zcache androidboot.bootdevice=msm_sdcc.1" \ >              --base 0x80200000 \ >              --pagesize 2048 \ >              --output boot2.img $ ../boot_info boot2.img  page size: 2048 (0x00000800) kernel size: 6842760 (0x00686988) ramdisk size: 663238 (0x000a1ec6) second size: 0 (0x00000000) board name:  command line: 'androidboot.hardware=qcom user_debug=31 zcache androidboot.bootdevice=msm_sdcc.1' base address: 2149580800 (0x80200000)

for comparison, original boot:

$ ../boot_info boot.img  page size: 2048 (0x00000800) kernel size: 6842760 (0x00686988) ramdisk size: 663238 (0x000a1ec6) second size: 0 (0x00000000) board name:  command line: 'androidboot.hardware=qcom user_debug=31 zcache androidboot.bootdevice=msm_sdcc.1' base address: 2149580800 (0x80200000)

all seems fine. flash it:

$ heimdall flash --boot boot2.img  heimdall v1.4.0  copyright (c) 2010-2013, benjamin dobell, glass echidna http://www.glassechidna.com.au/  software provided free of charge. copying , redistribution encouraged.  if appreciate software , support future development please consider donating: http://www.glassechidna.com.au/donate/  initialising connection... detecting device... claiming interface... attempt failed. detaching driver... claiming interface again... setting interface...  initialising protocol... protocol initialisation successful.  beginning session...  devices may take 2 minutes respond. please patient!  session begun.  downloading device's pit file... pit file download successful.  uploading boot 100% boot upload successful  ending session... rebooting device... releasing device interface... re-attaching kernel driver...

and device won't boot. help!

edit: here's hex dump of beginning of 2 images:

$ hexdump -c boot.img | more 00000000  41 4e 44 52 4f 49 44 21  88 69 68 00 00 80 20 80  |android!.ih... .| 00000010  c6 1e 0a 00 00 00 70 81  00 00 00 00 00 00 10 81  |......p.........| 00000020  00 01 20 80 00 08 00 00  00 00 00 00 00 00 00 00  |.. .............| 00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................| 00000040  61 6e 64 72 6f 69 64 62  6f 6f 74 2e 68 61 72 64  |androidboot.hard| 00000050  77 61 72 65 3d 71 63 6f  6d 20 75 73 65 72 5f 64  |ware=qcom user_d| 00000060  65 62 75 67 3d 33 31 20  7a 63 61 63 68 65 20 61  |ebug=31 zcache a| 00000070  6e 64 72 6f 69 64 62 6f  6f 74 2e 62 6f 6f 74 64  |ndroidboot.bootd| 00000080  65 76 69 63 65 3d 6d 73  6d 5f 73 64 63 63 2e 31  |evice=msm_sdcc.1| 00000090  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................| * 00000240  bc 67 a2 74 d6 d0 01 0e  b4 56 47 6f bd ad 4d 85  |.g.t.....vgo..m.| 00000250  30 c1 ee 43 00 00 00 00  00 00 00 00 00 00 00 00  |0..c............| 00000260  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................| * 00000800  00 00 a0 e1 00 00 a0 e1  00 00 a0 e1 00 00 a0 e1  |................| * 00000820  02 00 00 ea 18 28 6f 01  00 00 00 00 88 69 68 00  |.....(o......ih.| 00000830  01 70 a0 e1 00 00 30 e3  00 80 a0 11 02 80 a0 01  |.p....0.........| 00000840  20 30 9f e5 00 00 93 e5  1c 10 9f e5 01 00 30 e1  | 0............0.| 00000850  06 00 00 1a 00 00 a0 e3  00 00 83 e5 0c 00 93 e5  |................| 00000860  08 10 93 e5 04 f0 93 e5  00 f0 ff ff 07 b0 5d 4a  |..............]j| 00000870  00 20 0f e1 03 00 12 e3  01 00 00 1a 17 00 a0 e3  |. ..............| 00000880  56 34 12 ef 00 20 0f e1  c0 20 82 e3 02 f0 21 e1  |v4... ... ....!.| 00000890  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................| 000008a0  5c 41 9f e5 65 00 00 eb  57 0f 8f e2 4e 1c 90 e8  |\a..e...w...n...|   $ hexdump -c boot2.img | more 00000000  41 4e 44 52 4f 49 44 21  88 69 68 00 00 80 20 80  |android!.ih... .| 00000010  c6 1e 0a 00 00 00 20 81  00 00 00 00 00 00 10 81  |...... .........| 00000020  00 01 20 80 00 08 00 00  00 00 00 00 00 00 00 00  |.. .............| 00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................| 00000040  61 6e 64 72 6f 69 64 62  6f 6f 74 2e 68 61 72 64  |androidboot.hard| 00000050  77 61 72 65 3d 71 63 6f  6d 20 75 73 65 72 5f 64  |ware=qcom user_d| 00000060  65 62 75 67 3d 33 31 20  7a 63 61 63 68 65 20 61  |ebug=31 zcache a| 00000070  6e 64 72 6f 69 64 62 6f  6f 74 2e 62 6f 6f 74 64  |ndroidboot.bootd| 00000080  65 76 69 63 65 3d 6d 73  6d 5f 73 64 63 63 2e 31  |evice=msm_sdcc.1| 00000090  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................| * 00000240  bc 67 a2 74 d6 d0 01 0e  b4 56 47 6f bd ad 4d 85  |.g.t.....vgo..m.| 00000250  30 c1 ee 43 00 00 00 00  00 00 00 00 00 00 00 00  |0..c............| 00000260  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................| * 00000800  00 00 a0 e1 00 00 a0 e1  00 00 a0 e1 00 00 a0 e1  |................| * 00000820  02 00 00 ea 18 28 6f 01  00 00 00 00 88 69 68 00  |.....(o......ih.| 00000830  01 70 a0 e1 00 00 30 e3  00 80 a0 11 02 80 a0 01  |.p....0.........| 00000840  20 30 9f e5 00 00 93 e5  1c 10 9f e5 01 00 30 e1  | 0............0.| 00000850  06 00 00 1a 00 00 a0 e3  00 00 83 e5 0c 00 93 e5  |................| 00000860  08 10 93 e5 04 f0 93 e5  00 f0 ff ff 07 b0 5d 4a  |..............]j| 00000870  00 20 0f e1 03 00 12 e3  01 00 00 1a 17 00 a0 e3  |. ..............| 00000880  56 34 12 ef 00 20 0f e1  c0 20 82 e3 02 f0 21 e1  |v4... ... ....!.| 00000890  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................| 000008a0  5c 41 9f e5 65 00 00 eb  57 0f 8f e2 4e 1c 90 e8  |\a..e...w...n...|

an obvious difference in 2 hexdumps word stored starting 20 bytes image - 0x81200000 in yours vs 0x81700000 in original - stands out because 0x20 space while 0x70 printable "p" appearing in right column.

examining bootimg.h, 

struct boot_img_hdr { unsigned char magic[boot_magic_size];  unsigned kernel_size;  /* size in bytes */ unsigned kernel_addr;  /* physical load addr */  unsigned ramdisk_size; /* size in bytes */ unsigned ramdisk_addr; /* physical load addr */  unsigned second_size;  /* size in bytes */ unsigned second_addr;  /* physical load addr */

where first element 8 bytes, appear ramdisk_addr, image trying load ramdisk lower address original.

further, both images try load kernel @ 0x80208000, , kernel 0x00686988 in size, loading ramdisk @ around 0x80700000 looks reasonable, while trying load @ 0x80200000 broken ramdisk @ size of 0x000a1ec6 won't fit before kernel starting 0x00008000 later, , end overwriting it. don't think result of different designed order of two, 1 of having ramdisk offset 0 result of never being configured.

the source code seems suggest there --ramdisk_offset <base offset> argument, might try that. have figure out of argument option should offset relative base, or absolute, examination of documentation, or source, or simple experiment , hexdump should sort out.

this may not issue (you can use commandline options diff find offsets of other differences) - looks @ least 1 of problems need deal with.


Comments

Post a Comment

Popular posts from this blog

c++ - No viable overloaded operator for references a map -

-
i trying use map can make tag names reference number. when try , use it, in code error (6 in total every time reference map): src/main.cpp:25:45: error: no viable overloaded operator[] type 'std::map<std::string, std::string>' const char* idcs = node.child_value(tagmap[3]); this code: #include "pugi/pugixml.hpp" #include <iostream> #include <string> #include <map> int main() { pugi::xml_document doca, docb; std::map<std::string, pugi::xml_node> mapa, mapb; std::map<std::string, std::string> tagmap {{"1", "data"}, {"2", "entry"}, {"3", "id"}, {"4", "content"}}; if (!doca.load_file("a.xml") || !docb.load_file("b.xml")) { std::cout << "can't find input files"; return 1; } (auto& node: doca.child(tagmap[1]).children(tagmap[2])) { co
Read more

java - Custom OutputStreamAppender not run: LOGBACK: No context given for <MYAPPENDER> -

-
i wish write custom appender on basis of outputstreamappender . wrote following class package tests; import java.io.ioexception; import java.io.outputstream; import ch.qos.logback.core.outputstreamappender; public class myappender<e> extends outputstreamappender<e> { public myappender() { system.out.println("myappender created"); setoutputstream(new outputstream() { @override public void write(int b) throws ioexception { throw new unsupportedoperationexception(); } }); } } then wrote following runner: package tests; import org.slf4j.loggerfactory; import ch.qos.logback.classic.logger; public class runner { private static final logger log = (logger) loggerfactory.getlogger(runner.class); public static void main(string[] args) { //log.addappender(new myappender<iloggingevent>()); log.info("hello world"); } } finall
Read more

java - Cannot secure connection using TLS -

-
i'm trying establish secure socket connection between java client applet (built jdk 1.7.0_75-b13) , vc++ server application. as test vehicle, used vc++ client/server sample found in msdn forums, modified use schannel , able establish socket using cipher suite tls_rsa_with_aes_128_cbc_sha. works of tls 1.0/1.1/1.2. when try opening socket java applet same server application, connection rejected server reporting following: tls 1.0 acceptsecuritycontext failed: 0x80090327 tls 1.1 acceptsecuritycontext failed: 0x80090331 tls 1.2 acceptsecuritycontext failed: 0x80090331 this java code used create socket: debugprint("setting secure connection"); sslsocketfactory sslsocketfactory = (sslsocketfactory) sslsocketfactory.getdefault(); sslsocket sslsocket = (sslsocket) sslsocketfactory.createsocket("127.0.0.1", socketnumber); debugprint("starting handshake"); sslsocket.settcpnodelay(true); sslsocket.setsolinger(false, 0); sslsocket.s
Read more